What is a managed service - what AWS runs so you do not

A managed service is any AWS offering where Amazon runs the operational layer underneath your workload — provisioning the servers, patching the operating system, handling failover, and keeping backups — while you keep control of your data, your configuration, and your application code. Amazon RDS, AWS Lambda, Amazon Fargate, Amazon DynamoDB, and Amazon S3 are all managed services. Amazon EC2 on its own is not, because you're still the one patching it. And here's the part almost nobody explains clearly: the exact phrase "AWS Managed Services" is also the brand name of a completely different, enterprise-only product built for the Fortune 1000 — so typing "AWS managed service" into a search bar can hand a small business owner a sales page for something they were never going to buy. Welcome back to our AWS Series, let's explain this concept of Managed service, which will be one of the important topic for you..

Jake found this out the hard way, on a Tuesday, at his phone repair shop.

He'd been running his repair-tickets database on a single Amazon EC2 instance for about a year, because it was cheaper than Amazon RDS by roughly the cost of two lattes a month, and nobody had ever told him what that difference actually bought. A routine operating system update went out one Friday night, something in it collided with the database software he'd installed by hand, and by Monday morning four hours of customer repair history — who dropped off what, when it was promised back — had simply vanished. A regular customer stood at the counter asking where her phone was, and Jake had no record that it had ever come in.

What "managed service" actually means, in plain terms

Strip away the marketing and a managed service is a simple trade. AWS operates a piece of infrastructure — the physical server, the operating system underneath it, the boring recurring chores like patching and backups — and you get to skip doing that work yourself. In exchange, you give up some control over the parts AWS is now running. You can't SSH into the box behind Amazon RDS the way you can with a database you installed yourself on Amazon EC2. That box doesn't officially exist to you anymore. It's AWS's problem now, and that's the entire point.

This isn't unique to AWS — "managed" is a word every cloud provider uses — but AWS has more managed services than almost anyone, spanning compute, databases, storage, messaging, and machine learning. The pattern repeats across all of them: something that used to be your 2 a.m. pager alert becomes a setting you check a box for instead. A managed database service doesn't just save you time; it removes an entire category of mistake, because the person who used to fat-finger a manual patch at midnight is no longer the one applying it.

Jargon check, since it'll come up a lot below: an "instance" is just AWS's word for one running copy of a server or database — the specific machine your workload lives on at a given moment. When this post says AWS "manages the instance," it means AWS is the one deciding where that server runs, keeping its software current, and replacing it if it fails, rather than you doing that from a terminal window.

Ethan puts it a different way when Jake asks him to explain it without the jargon.

"Think about your shop's air conditioning," Ethan says. "You didn't build the compressor, you don't service the refrigerant lines, and you don't know or care what brand of thermostat is wired into the wall. You set the temperature and it's cold in here. That's a managed service. A database you install and run yourself on a server is the opposite — that's you buying the parts, wiring the unit, and climbing on the roof every August when it stops blowing cold air."

Managed vs. unmanaged: AWS's own comparison table

The clearest illustration of this isn't a diagram somebody drew for a blog post — it's a table AWS publishes in its own Amazon RDS documentation, comparing three ways of running a database: on your own hardware, on Amazon EC2 (a virtual server you administer), and on Amazon RDS (the managed version). Every row is a job that has to get done somewhere. The only question is who's doing it.

Read that table left to right and the pattern jumps out. On-premises, everything is your job. Move to EC2 and AWS quietly picks up the physical layer — the building, the power, the actual metal — but you're still the one logging in to patch the operating system and the database software, and you're still the one who has to notice when a disk fills up at 2 a.m. Move again to RDS and that whole middle layer, the actual database administration work, becomes AWS's job too. You're left with exactly one column of responsibility: application optimization. In other words, making your queries and your schema good. Nobody manages that for you, on any tier, ever — and that's a thread worth remembering, because it comes back later in this post.

AWS's own RDS documentation states the advantage directly: Amazon RDS is a managed database service, and it's responsible for most management tasks. Backups, software patching, automatic failure detection, and recovery are all handled without you configuring a cron job or writing a script. Compare that to running the same database engine on an EC2 instance, where AWS manages the hardware layer but the disadvantage, in AWS's own words, is that you're more prone to user error — the kind where a manual operating system update accidentally causes application downtime, and you spend hours checking every change to find out what broke.

Where AWS actually draws the line: the shared responsibility model

There's a formal name for the boundary between what AWS runs and what you run, and it shows up across almost every AWS service's documentation: the shared responsibility model. AWS divides it into two halves. Security of the cloud is AWS's half — the physical hardware, the software, the networking, and the facilities that run every AWS service, worldwide, tested and verified regularly by third-party auditors as part of AWS's compliance programs. Security in the cloud is your half, and exactly how big that half is depends entirely on which service you picked.

Here's the part that connects directly back to "what is a managed service": your half of that line shrinks the more managed the service is. With Amazon EC2, your half includes the guest operating system you're running, its patches, its firewall rules, and everything above that. With a more abstracted, managed service like Amazon S3 or Amazon DynamoDB, AWS is also responsible for the operating system and platform underneath — you never see it, you never patch it, and it isn't yours to secure. What's left for you is configuring the service correctly: who can access your S3 bucket, whether your RDS instance sits behind the right security group, whether your IAM permissions are too generous.

The naming collision nobody warns you about — and there are actually three names in play

This is the thing that tripped Jake up, and it trips up almost everyone doing this exact search for the first time, so it's worth slowing down on. There are, confusingly, three separate things AWS lets go by "managed service" or something close to it, and treating any two of them as the same thing leads straight into a sales page for something you don't need.

The first is the general concept this whole article is about: any AWS offering, from Amazon RDS to AWS Lambda to Amazon S3, where AWS runs the operational layer for that specific service. This is what almost everyone means when they use the phrase casually, and it applies to businesses of every size, including a six-person phone repair shop.

The second is a specific, named AWS product literally called "AWS Managed Services," usually abbreviated AMS. This is a different thing entirely. AWS's own announcement describes it as designed for the Fortune 1000 and the Global 2000 — large enterprises — to accelerate cloud adoption by simplifying deployment, migration, and management of their entire AWS account footprint, backed by a dedicated team of Amazon employees. It comes in operations plans (AMS Accelerate and AMS Advanced), it's priced based on the number of instances and other AWS usage fees in the accounts it manages, and it's built around concepts like a Virtual Data Center linked to your AWS accounts. AMS extends a customer's own operations team with monitoring, incident management, security guidance, patching, backup, and cost optimization work, run through its own reporting and governance layer. None of that is aimed at, or particularly useful for, someone running a small shop's ticketing database.

The third name is the one almost nobody mentions, and it's exactly the kind of thing that turns up when a beginner keeps searching after the second name still doesn't fit: the AWS Managed Service Provider Program (AWS MSP Partner Program). AWS's own partner network blog is explicit that this is not the same thing as AWS Managed Services — it's a rigorous validation and audit process AWS runs on outside consulting companies, so those companies can advertise themselves as vetted "AWS MSP Partners." These are independent businesses — not Amazon itself — who sell their own managed-service offerings on top of AWS, for customers who want a human team but aren't a Fortune 1000 company big enough for AMS.

Ethan has a blunt way of explaining why this confusion happens. "Amazon named a specific, expensive, enterprise product using the exact same words everybody already uses to describe an entire category of AWS services, and then let outside companies get officially certified using a near-identical third name," he says. "That's not a coincidence you can search your way around. You just have to know going in that there are three different things wearing the same outfit."

Real examples: which AWS services are managed, and what they take off your plate

It helps to see the pattern repeated across different types of AWS service, because it looks slightly different each time depending on what's being managed.

Relational databases: Amazon RDS

Amazon RDS makes it easier to set up, operate, and scale a relational database in the AWS Cloud, and it manages the common administration tasks that come with running one — backups, patching, failure detection, and recovery. You still choose the database engine (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, or IBM Db2), you still design your tables, and you still write your queries. AWS just stops you from having to SSH into a box to apply a security patch at midnight.

A relational database that goes further: Aurora Serverless

Amazon Aurora, AWS's own MySQL- and PostgreSQL-compatible database engine, offers a serverless configuration on top of the usual managed layer. Aurora Serverless is an on-demand, auto-scaling configuration that starts up, shuts down, and scales capacity based on your application's needs, so you never have to manage database capacity manually the way you would with a fixed instance size. As of the current version, it can scale all the way down to zero capacity during genuine inactivity and automatically resume when the first new connection arrives, which is a useful thing to know if you've ever wondered whether "managed" databases still bill you for sitting idle overnight.

Compute: AWS Lambda

AWS Lambda is a serverless compute service: you can run code without provisioning or managing servers at all. Lambda automatically manages the underlying infrastructure, including server maintenance, capacity provisioning, scaling, and patching, so you're left to focus on your application logic. You write a function, connect it to a trigger — an object landing in S3, an API call, a message arriving in a queue — and Lambda runs it, scaling horizontally to match demand without you ever choosing an instance size.

Containers: AWS Fargate

If your team already builds with Docker containers, AWS Fargate is a compute engine for Amazon ECS and Amazon EKS that lets you run those containers without managing the servers or clusters underneath them. With Fargate, you no longer provision, configure, or scale clusters of virtual machines yourself — there's no picking instance types or deciding when to add capacity. You package your application into a container, define the CPU and memory it needs, and AWS launches and runs it. This sits next to a genuinely unmanaged option within the same family of services: Amazon ECS also offers an EC2 launch type, which hands you server-level, more granular control over the underlying instances, for teams that specifically want that control back.

Storage: Amazon S3

Amazon S3 is object storage — the kind of service you'd use to hold backups, website assets, or a data lake — and its documentation frames it around management features you configure rather than infrastructure you maintain. You never provision a storage server or size a disk. What you do configure is how objects are organized, how long they're retained, and who can access them, including features like S3 Block Public Access, which is turned on by default at the bucket level specifically because a misconfigured bucket is the single most common way a "managed" storage service still leads to a public data leak.

NoSQL: Amazon DynamoDB

Amazon DynamoDB is a fully managed, serverless NoSQL database service that stores and retrieves any amount of data at any level of request traffic. AWS's own description of it is one of the plainest statements of what "managed" buys you anywhere in its documentation: DynamoDB lets you offload the administrative burdens of operating and scaling a distributed database, so that you don't have to worry about hardware provisioning, setup and configuration, replication, software patching, or cluster scaling. You design the table, choose your keys, and write the application logic. AWS handles the servers underneath entirely, spreading data and traffic across enough of them to meet the capacity you're asking for.

"Managed" vs. "serverless" — not the same word, even though they get used that way

You'll see "managed" and "serverless" used almost interchangeably in casual conversation, and for services like Lambda, Fargate, DynamoDB, and Aurora Serverless, both words genuinely apply. But they're describing slightly different things, and the distinction matters once you're comparing options.

A managed service means AWS runs the operational layer — the patching, the backups, the failover — but you might still think in terms of instances, clusters, or provisioned capacity. Amazon RDS is managed, but you still pick a DB instance class (a db.m7g.2xlarge, for example) and you're aware, at least loosely, that there's a server-sized thing underneath your database.

Serverless goes a step further: it means you don't think about servers at all, not even as a sizing decision. AWS Lambda is serverless — you don't pick an instance type, you set a memory allocation for your function and AWS handles the rest, including scaling from zero to thousands of concurrent executions. AWS Fargate is a serverless compute engine specifically because it removes the EC2 layer entirely from Amazon ECS — no instance types, no cluster capacity planning. DynamoDB and Aurora Serverless extend the same idea to databases: no instance class to pick at all, just a capacity range or a pay-per-request model.

So every serverless AWS service is a managed service, but not every managed service is serverless. Standard, provisioned Amazon RDS is managed but not serverless. Lambda, Fargate, DynamoDB, and Aurora Serverless are both.

What a managed service never takes off your plate

Go back to that RDS responsibility table for a second. Every single column, on every tier, has "application optimization" marked as your job. AWS's own RDS documentation is explicit about this in its shared responsibility section: Amazon RDS is responsible for hosting the software components and infrastructure of DB instances and DB clusters, but you are responsible for query tuning — the process of adjusting your SQL queries to improve performance. That work depends on your database design, your data size, your data distribution, your application's workload, and your query patterns, and AWS states plainly that this is a highly individualized process you own.

Here's the full list of what stays yours, no matter how managed the underlying service is:

1. Your data and schema design. A badly normalized database is just as slow on RDS as it was on your own server. AWS didn't design your tables.
2. Query and application performance. RDS won't rewrite a slow query for you. Tools like Performance Insights will show you which query is the problem — you still have to fix it.
3. Access control and permissions. Who can reach your database, your Lambda function, or your S3 bucket is configured by you through IAM, security groups, and bucket policies. A managed service with an open door is still an open door.
4. Your application code. A memory leak inside your own Lambda function will still bring it down, no matter how reliably AWS runs the execution environment around it.
5. Cost decisions. Instance sizing, storage class choices, and whether you actually need Multi-AZ failover for a given workload are yours to make, and they drive your bill directly.
6. Monitoring and response. AWS sends metrics to CloudWatch automatically, but somebody still has to look at the dashboard, or set an alarm, and act when something looks wrong.

When "it's managed" doesn't save you

The most common way managed services disappoint people isn't a failure of AWS's infrastructure — it's a team assuming "managed" means "solved" and then getting surprised months later. A handful of concrete failure modes to watch for:

The query is still slow. A team migrates from a self-managed database on EC2 to RDS expecting performance problems to disappear along with the patching burden. They don't. If a query was doing a full table scan before the move, it's doing the exact same full table scan after it, just on a server AWS happens to be running. Query tuning was never AWS's job, on any tier.

The bucket is still public. S3 is a managed service, but a misconfigured bucket policy or a disabled Block Public Access setting exposes data just as effectively as an unpatched, self-managed server would. Managed infrastructure doesn't protect against a configuration mistake made entirely on the customer's side of the shared responsibility line.

The function still leaks memory. Lambda will faithfully scale a broken function to thousands of concurrent, equally broken executions. AWS manages the runtime around your code with total reliability; it has no opinion about whether the code inside is any good.

The table design fights the database. DynamoDB's speed comes from access patterns you design up front — the partition key and sort key you choose. A table designed without a clear query pattern in mind will still be slow and expensive on DynamoDB, because AWS manages the servers spreading your data around, not the decision of how that data should be organized in the first place.

Nobody's watching the dashboard. Amazon RDS sends metrics to CloudWatch automatically and at no additional charge, and it can surface automated recommendations about your DB instances. None of that helps if nobody on the team ever opens the console or sets up an alarm. A managed service still generates signals; it doesn't generate attention.

Edge cases: private networks, regulated workloads, and running across regions

"Managed" doesn't mean "public" or "simple by default," and a few situations are worth knowing about before you assume a managed service behaves exactly like a hosted convenience app.

Private subnets and networking. A typical Amazon RDS deployment puts your DB instances in private subnets inside a Virtual Private Cloud (VPC), specifically so no request from the public internet can reach them directly — only your application servers, sitting in their own subnets within the same VPC, can talk to the database. Being managed doesn't mean being exposed; if anything, AWS's own reference architecture for RDS keeps the database further from the internet than a lot of self-managed setups do by default, because it's the pattern AWS documents as the standard way to run it.

Regulated and compliance-sensitive workloads. A managed service isn't automatically off-limits for a regulated industry. AWS Fargate, for example, has been approved by numerous industry-standard compliance programs including HIPAA, PCI, and FedRAMP, and is available in AWS GovCloud regions for workloads that need to meet U.S. government requirements. The shared responsibility model still applies here exactly the way it does everywhere else: AWS's compliance certifications cover its side of the infrastructure, and you're still responsible for configuring the service — encryption settings, access policies, audit logging — in a way that satisfies your specific regulatory obligations.

Running across multiple AWS Regions. High availability within one Region is usually a checkbox — Amazon RDS Multi-AZ deployment lets AWS automatically provision and maintain a standby DB instance in a different Availability Zone within the same Region. Surviving the loss of an entire Region is a different, bigger decision: Amazon RDS supports replicating a DB instance in one Region to a standby in a different Region, so that if one Region becomes unavailable, the instance in the other Region is still reachable. That kind of cross-Region setup is still "managed" in the sense that AWS runs the replication mechanics, but deciding whether you need it, and configuring it, remains entirely a choice you make.

Is a managed service always more expensive than doing it yourself?

Usually, on the sticker price, yes. Running MySQL yourself on a bare EC2 instance is generally cheaper per hour than the equivalent Amazon RDS instance, because part of what you're paying for with RDS is the automation and operational work bundled into that instance rate: automated backups with point-in-time recovery, automatic OS and engine patching during a maintenance window you control, and the option to add Multi-AZ failover.

What that comparison leaves out is everything RDS is doing that you'd otherwise have to do yourself, or pay someone to do. Backups with point-in-time recovery, patch testing and rollout, and failover configuration are all real engineering hours when you build them by hand on EC2 — hours that don't show up on an AWS invoice but absolutely show up somewhere. This is exactly the tradeoff the Well-Architected Framework's operational excellence pillar is pointing at when it recommends using managed services specifically to reduce operational burden: it's not claiming managed services are cheaper on the invoice, it's claiming the total cost of running the unmanaged version yourself is usually higher than it looks.

Serverless options can flip this comparison entirely for the right workload. Aurora Serverless, DynamoDB's on-demand mode, and Lambda's pay-per-use pricing all charge for what you actually consume rather than a fixed instance running around the clock, which means an application with genuinely spiky or idle-heavy traffic — a shop's website that gets almost no visits overnight — can end up cheaper on the serverless option than on a provisioned instance sized for its busiest hour.

How to decide: managed, self-managed on EC2, or somewhere in between

Amazon RDS's own documentation frames this as a spectrum rather than a binary switch, and it's a useful way to think about any managed service, not just databases: if you need the entire database and operating system fully managed by AWS, use the standard managed option. If you need administrative access to the database and underlying operating system for a specific reason, there's often a middle tier — for RDS, that's RDS Custom, which trades some of the "fully managed" convenience for the ability to install custom patches, configure specific database settings, or share a file system directly with an application. And if you want full control and are prepared to take on full responsibility, self-managing on EC2 remains an option AWS itself describes as best for that specific need, not as a mistake.

1. List what you'd actually be doing yourself. Be specific: who patches this at 11 p.m. on a Saturday when a critical CVE drops? If the honest answer is "nobody, reliably," that's a strong signal toward the managed option.
2. Check whether you need OS-level access for a real reason. Some applications genuinely need to install a custom package or a specific file system integration that a fully managed service won't allow. That's a legitimate case for a middle-tier option like RDS Custom, or for self-managing on EC2 — not a reason to avoid managed services on principle.
3. Estimate the operational hours you're not counting. Backup testing, patch validation, and building failover from scratch all take real time. Weigh that against the instance-rate premium a managed service charges.
4. Check whether your traffic pattern is spiky or steady. Steady, predictable load often favors a provisioned managed instance. Bursty or idle-heavy traffic is where the serverless variants — Lambda, Fargate, DynamoDB on-demand, Aurora Serverless — tend to save the most, since you stop paying for capacity you're not using.
5. Start managed, and only step down if you hit a wall. It's far easier to migrate an application designed around a managed database toward more control later than to retrofit failover and automated backups onto something you built by hand under deadline pressure.

The adjacent terms you'll run into next: IaaS, PaaS, and SaaS

Once "managed service" clicks, three related pieces of cloud vocabulary tend to show up right behind it, and it's worth knowing roughly where they sit relative to what's been covered here.

Infrastructure as a Service (IaaS) is the least-managed end of the spectrum — Amazon EC2 is the textbook example, where AWS hands you a virtual server and the operating system decisions are yours. Platform as a Service (PaaS) sits closer to the managed end — you deploy an application and the platform handles the runtime, scaling, and infrastructure around it, similar in spirit to what Lambda or Fargate do for specific workloads. Software as a Service (SaaS) is the far end — you don't manage infrastructure at all, you just use a finished application, the way Jake's point-of-sale software works without him ever thinking about what server it runs on.

"Managed service" doesn't map perfectly onto any one of those three categories — it cuts across them. A managed database like RDS is closer to IaaS with heavy automation layered on top. A serverless compute service like Lambda behaves more like PaaS. The label that actually matters day to day isn't which category a service technically belongs to; it's the responsibility table from earlier in this post. That table tells you exactly what you're on the hook for, regardless of which acronym gets attached to the service.

Frequently asked questions

Is "managed service" the same as "AWS Managed Services"?

No, and this is the single most common source of confusion on this topic. "A managed service" is the general term for any AWS offering — RDS, Lambda, Fargate, S3, DynamoDB, and dozens more — where AWS runs the servers and operational work behind it. "AWS Managed Services" (AMS) is a specific, named product built for large enterprises, priced around managing an entire AWS account footprint with a dedicated Amazon team. Most people searching this phrase want the first meaning.

Is AWS Lambda a managed service or something else?

It's both a managed service and, more specifically, a serverless one. AWS manages the servers, scaling, and patching behind every Lambda function, and it goes a step further than a typical managed service by removing the concept of an instance entirely — you never size or provision a server, even indirectly.

Is Amazon S3 a managed service?

Yes. AWS operates the storage infrastructure and the platform underneath S3, and provides management features — lifecycle rules, replication, access controls — that you configure rather than infrastructure you build. Your responsibility is largely about configuration: who can access a bucket and how data is organized and retained.

Is DynamoDB different from a "regular" managed database like RDS?

Yes, in kind, not just in degree. DynamoDB is a NoSQL, serverless database, so you never choose a server-sized instance class at all — you design table keys and let AWS spread your data across as many servers as your traffic requires. RDS is a managed relational database where you still pick an instance class and think in terms of a single running server, even though AWS patches and backs it up for you.

Do I still need a DBA if I use a managed database?

For query tuning, schema design, and performance troubleshooting, yes. Amazon RDS's own documentation is explicit that query tuning stays the customer's responsibility, because it depends on things specific to your application that AWS has no visibility into. What a managed database removes is the need for someone dedicated to patching, backup infrastructure, and failover configuration.

Are managed services always more expensive than EC2?

On the raw instance rate, usually yes — you're paying a premium that funds the automated patching, backups, and failover built into the service. Whether that premium is actually more expensive overall depends on how much engineering time it would take your team to build and maintain the equivalent yourself, which rarely shows up on an invoice but is a real cost. Serverless variants like Aurora Serverless or DynamoDB on-demand can even come out cheaper for spiky or idle-heavy workloads, since you stop paying for a fixed instance sitting mostly unused.

What's the difference between "managed" and "serverless"?

Managed means AWS runs the operational layer of a service, but you may still think in terms of instances or capacity, as with RDS. Serverless goes further and removes the concept of a server from your thinking entirely, scaling automatically without you sizing anything, as with Lambda, Fargate, DynamoDB, and Aurora Serverless. Every serverless AWS service is managed; not every managed service is serverless.

Can I move a database I already run on EC2 into a managed service?

Yes. AWS offers a migration path that lets you move a self-managed MySQL, PostgreSQL, or MariaDB database running on EC2 into an equivalent Amazon RDS or Aurora database, using Database Migration Service to handle the networking and system configuration involved, rather than requiring you to rebuild it by hand.

Does a managed service mean AWS can see my data?

A managed service means AWS operates the infrastructure and software layer beneath your data, which is a different question from access. Under the shared responsibility model, security in the cloud — including who can access your data through the permissions you set — remains your configuration to control, through tools like IAM policies, bucket policies, and security groups.

What happens if the managed service itself goes down?

This is exactly what features like Amazon RDS Multi-AZ deployments exist for: AWS automatically provisions and maintains a secondary standby instance in a different Availability Zone, and fails over to it if the primary has a problem, without you building that redundancy by hand. It's an optional feature you turn on, not something every managed service includes automatically at no extra cost. Surviving an entire AWS Region going down is a bigger, separate decision involving cross-Region replication.

Do managed services still need patching from me?

For the infrastructure and database software itself, no — that's the point of the managed tier, and AWS applies those patches during a maintenance window. What you're still responsible for is your own application code and configuration, none of which AWS can patch on your behalf because AWS doesn't know what your code is supposed to do.

Is Amazon RDS Custom a managed service?

Yes, but it's a middle tier. AWS describes it as the choice when you need administrative rights to the database and underlying operating system to support dependent applications, while standard RDS restricts that access entirely to deliver a more hands-off managed experience. RDS Custom trades away some of that full automation in exchange for more access.

Are AWS MSP Partners the same as AWS Managed Services?

No, and this is the third layer of the naming collision. AWS Managed Services (AMS) is Amazon's own enterprise product. The AWS Managed Service Provider Program is a separate certification AWS runs on outside consulting companies, so customers can identify vetted "AWS MSP Partners" — independent firms selling their own managed-service offerings on top of AWS, distinct from AMS itself.

What's the difference between managed service and PaaS?

They overlap but aren't identical labels. PaaS (Platform as a Service) describes a category of cloud service where you deploy applications onto a managed runtime without handling infrastructure. "Managed service" is a broader, less formal term that spans everything from managed databases (closer to infrastructure with automation layered on) to serverless compute (closer to a pure platform). The responsibility table matters more day to day than which category label technically applies.

Will a managed service fix a badly designed database?

No. AWS's shared responsibility model for RDS places query tuning and the effects of database design on the customer, since they depend on schema, data size, and query patterns unique to that customer's application. The same principle applies to DynamoDB, where a poorly chosen partition key will still be slow and costly no matter how many servers AWS spreads it across. A managed service addresses operational problems, not design problems.

How do I know which AWS services are managed and which aren't?

As a rule of thumb: if a service asks you to choose and patch an operating system, it's unmanaged or only partially managed — Amazon EC2 is the clearest example. If a service asks you to configure settings and hand over infrastructure decisions entirely, it's managed — Amazon RDS, AWS Lambda, AWS Fargate, Amazon DynamoDB, and Amazon S3 all fit this description, each documented individually by AWS as handling server provisioning, patching, or scaling on your behalf.

Revision note. Written September 2026, covering Amazon RDS, Aurora Serverless, AWS Lambda, AWS Fargate, Amazon DynamoDB, and Amazon S3 as they're documented today, along with the current AWS Managed Services (AMS) enterprise offering and the separate AWS MSP Partner Program. This will need a fresh look whenever AWS renames AMS, adds a new managed database engine, or shifts the RDS/EC2 responsibility split — AWS has adjusted defaults like this before. If you're the one stuck patching a server at midnight right now, you're not doing anything wrong; you just haven't drawn the line in the right place yet, and that's a fixable thing.