What is the AWS shared responsibility model - who fixes what

The AWS shared responsibility model is a simple split: AWS is responsible for the security of the cloud — the data centers, hardware, and network — and you're responsible for security in the cloud — your data, your access controls, and however you've configured the service. What most people miss is the counterintuitive part: that line doesn't sit in the same place for every AWS service. Pick Amazon EC2 and you're holding almost the whole bag — patching, firewall rules, the operating system, all of it. Pick Amazon S3 and AWS is holding almost all of it. Same company, same "shared responsibility model," wildly different amount of work on your side depending on which button you clicked.

Jake found out the hard way. He runs a small phone repair and resale shop, and last year he moved his customer database — names, phone numbers, repair tickets, a bit of payment history — onto an Amazon RDS database because his old spreadsheet setup kept crashing every time two people tried to edit it at once. Three months in, he got a call from a customer who said someone had tried to use her card number. Jake's first words to Ethan were: "I thought Amazon was supposed to keep this stuff locked down. Isn't that the whole point of paying them?"

It turned out the database itself was fine. Amazon hadn't been breached, and nothing about AWS's own infrastructure had failed. What had happened was that Jake, trying to make it easier for himself to check the database from home on a Sunday night, had opened the database's security group to allow connections from any IP address on the internet, and used a password he'd been recycling since 2019. That's not an AWS failure. That's a "security in the cloud" failure — squarely on Jake's side of the line, and entirely preventable with tools AWS had handed him for free.

What "shared responsibility" actually means

AWS puts it plainly on its own compliance page: security and compliance are a shared responsibility between AWS and the customer, and this shared model can relieve your operational burden because AWS operates, manages, and controls the components from the host operating system and virtualization layer down to the physical security of the facilities where the service runs. You take on responsibility for the guest operating system — including its updates and security patches — plus any application software you install, and the configuration of the AWS-provided security group firewall. AWS frames this split with two short phrases you'll see everywhere in AWS documentation, in job interviews, and in compliance audits: security "of" the cloud (AWS's job) and security "in" the cloud (your job).

Here's the part almost nobody explains clearly, and it's the reason this article exists: "security of the cloud" is a fixed, unchanging block no matter what you do. AWS's own diagram of the model spells out exactly what sits in that fixed block — software, compute, storage, and database infrastructure; the networking layer; the hardware and physical infrastructure; and the Regions, Availability Zones, and edge locations the whole thing runs across. That entire list is AWS's, always, on every single AWS service you'll ever touch, whether you're running one EC2 instance or a thousand.

"Security in the cloud," though, is not fixed. It's a sliding scale that depends entirely on which AWS service you picked and how "managed" that service is. AWS's diagram lists what usually sits on the customer's side too: your own data, the platform and application configuration you control, your operating system and firewall configuration where you have one, your encryption choices, and protecting your traffic as it moves. Understanding where that slider sits for the specific service you're using is the actual skill here — not memorizing the phrase "shared responsibility."

Think of an apartment building. The landlord (AWS) is responsible for the building's foundation, the elevator, the fire suppression system in the walls, and the front door lock to the building. That's security of the building. You, the tenant, are responsible for locking your own apartment door, not giving your key to strangers, and not leaving your window open. That's security in your apartment. If a fire starts because of faulty building wiring, that's on the landlord. If a fire starts because you left a candle burning, that's on you. AWS's cloud works exactly the same way — the trouble is that depending on which "apartment" you rent (EC2 versus S3 versus a fully managed database), the amount of stuff inside that apartment that's actually your job to secure changes dramatically.

The three tiers: infrastructure, container, and abstracted services

AWS's own compliance page draws the sharpest example of the sliding scale using two services at opposite ends: Amazon EC2 and Amazon S3. Amazon EC2 is categorized as Infrastructure as a Service, or IaaS — a term worth unpacking the moment you hit it, because you'll trip over it constantly in cloud documentation. IaaS just means "AWS gives you a virtual computer and the network around it, and everything running on that computer is yours to manage" — like renting an empty apartment with just walls, plumbing, and electricity, and you bring your own furniture, locks, and house rules. Because EC2 is IaaS, AWS requires you to perform all of the necessary security configuration and management tasks yourself. If you deploy an EC2 instance, you're responsible for managing the guest operating system — including its updates and security patches — any application software or utilities you install on the instance, and the configuration of the AWS-provided firewall, called a security group, on each instance.

Amazon S3 and Amazon DynamoDB sit at the far other end. AWS calls these "abstracted services" — abstracted just means AWS has hidden (abstracted away) the operating system, the patching, and the underlying servers entirely; you never see them, never touch them, and can't even if you wanted to. For these, AWS operates the infrastructure layer, the operating system, and the platform, and you simply access an endpoint to store and retrieve your data. Your job shrinks down to managing your own data, including encryption options, classifying what you're storing, and using IAM tools to apply the right permissions to who can reach it.

Between those two extremes sits a middle category commonly called "container services" in AWS training material — not Docker containers, a different, older use of the word "container" meaning AWS has packaged a whole application platform for you. Amazon RDS is the classic example. AWS manages the underlying infrastructure, the foundation services, the operating system, and the database application platform itself. You're still on the hook for firewall rules, some data encryption choices, and database-level access, but you're no longer the one patching an operating system or updating the database engine's binaries.

If you can't SSH into it or see an operating system prompt, you're almost certainly in the container or abstracted tier and patching isn't your job. If you can SSH into it, it's yours.

Every layer, side by side: the full checklist

Before diving into individual services, it helps to see the whole picture in one place — every layer AWS's own model draws a line through, and which side of that line it usually sits on. This is the checklist Ethan keeps taped inside a cabinet at Jake's shop.

Notice the pattern: the top two rows never move. The bottom four never move either, just in the opposite direction. The only row that genuinely shifts depending on which service you picked is the guest operating system — and that single row is exactly why EC2 feels like so much more work than RDS, and why RDS feels like so much more work than S3.

EC2: the tier where almost everything lands on you

If you've ever launched an EC2 instance — a virtual server AWS rents you by the hour — you already own the biggest chunk of shared-responsibility homework AWS hands out. AWS's documentation is direct about this: customers who deploy an EC2 instance are responsible for management of the guest operating system, including updates and security patches; any application software or utilities installed by the customer on the instance; and the configuration of the AWS-provided firewall, called a security group, on each instance.

Walk through what that actually means in practice, in order of how it usually bites people:

1. You patch the operating system. Whether that's Windows Server or a Linux distribution, when a critical vulnerability gets disclosed, AWS is not quietly pushing an update onto your running instance the way your phone updates itself overnight. You have to run the update, reboot if needed, and confirm it took.
2. You configure the security group. This is the instance-level firewall — the rules that decide which ports and which IP addresses are even allowed to talk to your server. Leave port 22 (used for remote Linux logins) or 3389 (used for Windows Remote Desktop) open to the entire internet with "0.0.0.0/0" as the source, and you've handed the front door key to anyone scanning the internet for open ports, which happens constantly and automatically, with no human attacker required to be actively targeting you.
3. You secure whatever you install. A web server, a database you installed yourself instead of using RDS, a custom application — none of that is AWS's problem to patch or configure. If you install it, you maintain it, for as long as that instance runs.
4. You manage your own data on the instance. Backups, encryption of the attached storage volume (called an EBS volume), and who has the keys to decrypt it are yours to arrange.

RDS and other managed databases: AWS takes the engine, you keep the door

This is the tier Jake's shop actually lives in, and it's the one people misunderstand most, because "managed" gets read as "AWS handles security" when it really means "AWS handles a specific, larger slice than an EC2 instance, but not all of it."

AWS's Amazon RDS documentation walks through this directly: security is a shared responsibility between AWS and you, described using the same "of the cloud / in the cloud" split. AWS is responsible for protecting the infrastructure that runs RDS in the AWS Cloud, and your responsibility is determined by the service you use, plus factors like the sensitivity of your data and your organization's own requirements. In practical terms for RDS, AWS runs and patches the underlying operating system and the database engine software itself — MySQL, PostgreSQL, Oracle, SQL Server, whichever engine you picked. You don't SSH into an RDS instance and run a manual software update; there's no operating system prompt to reach in the first place.

What's still yours: the VPC and subnet placement of the database (a VPC, or Virtual Private Cloud, is your own isolated slice of AWS's network — think of it as your own private section of a shared office building, walled off from every other tenant), the security groups controlling which resources can even reach it, the database-level user accounts and passwords, whether you're using AWS-managed encryption keys or bringing your own customer-managed keys, and — critically — never exposing the database's port directly to the public internet unless you have an extremely specific reason to.

S3 and DynamoDB: the smallest slice AWS hands you

Amazon S3 (object storage — think of it as an enormous, infinitely scalable filing cabinet accessed over the internet rather than a folder on your computer) and Amazon DynamoDB (a managed database that doesn't use traditional rows-and-columns SQL tables) sit at the far abstracted end of the scale. AWS operates the infrastructure layer, the operating system, and the platform entirely. You never see a server. There's nothing to patch because there's no operating system exposed to you at all.

That doesn't mean your job disappears — it means your job narrows to a small number of decisions that matter enormously precisely because there's so little else for you to get wrong. AWS is explicit that you're responsible for managing your data, including your encryption options, classifying your assets appropriately, and using IAM tools to apply the correct permissions.

Ethan put it to Jake this way once, over coffee at the shop: "The less AWS leaves you to configure, the more each configuration decision you do make actually matters — because there's nowhere else for the mistake to hide." A misconfigured S3 bucket permission — accidentally set to allow public read access to everyone on the internet — has been behind some of the more embarrassing corporate data exposures of the last decade, and every single one of those traces back to a customer-side configuration mistake, not an AWS infrastructure failure. AWS never "left the door open" on those buckets; the customer did, with a checkbox.

Lambda and serverless: you brought the code, AWS brought everything else

AWS Lambda lets you run code — a "function," a small piece of program logic — without ever provisioning or managing a server at all; AWS spins up the environment to run your code only when it's triggered, then tears it back down. It's the extreme end of "serverless" computing, and the shared responsibility split follows the same pattern you've seen in every tier so far, just pushed even further toward AWS.

AWS's own Lambda security documentation states it cleanly: for Lambda, AWS manages the underlying infrastructure and foundation services, the operating system, and the application platform. You're responsible for the security of your code and for the identity and access management, meaning IAM, around the Lambda service and within your function itself. AWS's own diagram of Lambda's shared responsibility model puts the customer's side as three things specifically: your function code and libraries, your resource configuration (memory allocated, timeout length, and how the function connects to your network), and your identity and access management.

Translate that into what actually goes wrong in the real world: a Lambda function itself can't really be "unpatched" by you, because there's no server for you to patch — AWS handles the runtime language environment (Node.js, Python, Java, whichever you picked) and its underlying platform. But if your function's IAM role has far more permissions than it needs — say, full administrative access to your whole AWS account, when the function only needed to read one file from one S3 bucket — that's entirely a customer-side mistake, and it's one of the most common ways a single compromised Lambda function turns into a company-wide incident.

Containers: ECS, EKS, and Fargate — it depends which mode you picked

This is where the shared responsibility line actually moves within a single AWS service, depending on a setting you choose, and it trips up more people than any other part of this topic.

Amazon ECS: the same service name, two different responsibility splits

Amazon ECS (Elastic Container Service, AWS's system for running Docker-style containers, which are lightweight, self-contained packages of an application and everything it needs to run) can run on top of two very different underlying setups. Run your containers on ECS with EC2 instances as the underlying compute, and you're back to IaaS-level responsibility for that layer — you patch the EC2 host operating system yourself, same as any other EC2 instance, on top of managing your container images and application code. Run the exact same containers on ECS with AWS Fargate (a launch mode where AWS runs the underlying compute for you, and you never see or manage an EC2 instance at all) and the responsibility line shifts dramatically toward AWS, closer to how Lambda works — AWS manages the underlying instances, the operating system, and much of the container runtime, and you're mainly responsible for your container image contents and IAM configuration.

AWS documents this exact contrast directly in its Security Incident Response Guide, illustrating how the shared responsibility model changes specifically for Amazon ECS running under the AWS Fargate type of shared responsibility model compared to the standard EC2-backed version. The practical upshot: the same service name, "ECS," can put you on two completely different sides of the patching line depending on one launch-type setting picked at creation time.

Amazon EKS: the control plane is AWS's, the data plane is a sliding scale

Amazon EKS (Elastic Kubernetes Service, AWS's managed offering for Kubernetes, an open-source system for automating how containerized applications get deployed and scaled) splits a Kubernetes cluster into two halves, and this split maps almost perfectly onto the shared responsibility model. The control plane is the "brain" of the cluster — the API server that receives your commands, the scheduler that decides where workloads run, and a component called etcd (a key-value database that stores the cluster's entire state). The data plane is the actual worker machines, called nodes, where your containers run.

AWS's own EKS security documentation is unambiguous about where the line sits: for security "of the cloud," AWS is responsible for the Kubernetes control plane, which includes the control plane nodes and the etcd database. For security "in the cloud," your responsibility includes the security configuration of the data plane — including the security groups that allow traffic to pass from the EKS control plane into your own VPC — the configuration of the nodes and containers themselves, the node's operating system (including its updates and security patches), any other application software you run, setting up network controls like firewall rules, and managing platform-level identity and access management alongside or in addition to IAM.

Where EKS gets genuinely interesting is that the data plane itself has a sliding scale of its own, and AWS documents it as a spectrum from least to most managed: self-managed nodes put you fully in charge of patching and upgrading the worker machines yourself; managed node groups have AWS handle provisioning and lifecycle management of the EC2 nodes, though you still have to initiate the update process yourself; and EKS Auto Mode or Fargate hand AWS responsibility for the underlying instance or runtime almost entirely, with security patches applied automatically. AWS's own guidance sums up the pattern in one line: the more AWS-managed data plane you use, the less responsibility you have.

The things that are never AWS's job, no matter which service you pick

Across every tier, every service, and every launch mode discussed above, a few things never, ever cross over to AWS's side of the line, regardless of how "managed" or "abstracted" the service is:

1. Your data itself. Classifying what's sensitive, deciding what should and shouldn't exist in the cloud at all, and choosing your encryption approach is always yours.
2. Your IAM configuration. Who has which permissions, how strong your passwords and multi-factor authentication policies are, and how tightly you scope access — always yours.
3. Your application-level or business logic. If your own code has a security flaw — a SQL injection vulnerability, a broken authentication check — that's your application, not AWS's infrastructure.
4. Compliance with laws and regulations specific to your industry. AWS gives you tools and, for some services, inherited controls, but whether your specific use case satisfies HIPAA, PCI DSS, or your country's data protection law is your organization's determination to make.

How this plays into compliance audits: inherited, shared, and customer-specific controls

If your business needs to prove compliance with a standard like PCI DSS, SOC 2, or HIPAA, the shared responsibility model isn't just a security concept — it's the exact framework an auditor will walk you through, using three specific categories AWS itself defines.

AWS also names Awareness and Training as one of its worked examples of a shared control: AWS trains its own employees on security practices, but training your employees not to click phishing links or reuse passwords is entirely on you. It's a small line in AWS's documentation, but it's a good reminder that "shared responsibility" isn't purely a technical checklist — some of it is just running your business responsibly.

For audit purposes, AWS also publishes third-party audit attestation documents through a service called AWS Artifact, which lets you review what's already been independently verified so you know which controls you're genuinely inheriting versus which ones you still have to implement and prove yourself. AWS also points customers toward established outside frameworks to help figure out their own compliance objectives, including the NIST Cybersecurity Framework and ISO certification standards, and offers Cloud Audit Academy training programs specifically for internal and external audit teams who need to get up to speed on how cloud-specific compliance actually works.

A practical way to figure out your responsibility for any AWS service

Rather than trying to memorize the responsibility split for every AWS service individually — there are hundreds — Ethan walked Jake through a three-question test that works for almost anything AWS sells:

1. Can I log into an operating system prompt on this service? If yes (EC2, an EC2-backed ECS cluster, a self-managed EKS node), you own OS patching and everything installed on top of it. If no, that patching job belongs to AWS.
2. Do I choose the software version, or does AWS choose it for me? With RDS, you pick the database engine and version but AWS applies the patches (with your permission or on a schedule you control). With Lambda, AWS controls the whole runtime environment and you supply only the code.
3. Can I make a mistake here that has nothing to do with AWS at all? Every service, from EC2 down to the most abstracted SaaS-style offering, keeps this one constant: your IAM permissions, your data classification, and your access management decisions are always yours, always, no matter how much AWS automates underneath you.

"The service name tells you almost nothing," Ethan told Jake. "The question that actually matters is: what can I see and touch? If you can see it, you probably own securing it. If you can't, AWS does — but you still own who's allowed to ask for it."

Myths that get people breached

Myth: "AWS is a huge, security-focused company, so my data on AWS is automatically secure." AWS's own documentation directly contradicts this framing. Security and compliance is explicitly described as shared, not delegated. AWS's scale and expertise cover the infrastructure layer extremely well — but that's exactly the point of the model: it was never designed to cover your layer, and it was never marketed that way by AWS itself.

Myth: "More managed services mean I can stop thinking about security." More managed services mean fewer things to think about, not zero. The things left on your plate — IAM permissions, data classification, encryption choices — tend to be the decisions with the biggest blast radius precisely because there's less else around them to catch a mistake.

Myth: "If AWS's infrastructure is compromised, that's the only way I'd get breached." AWS infrastructure-layer compromises are exceptionally rare and heavily audited. Customer-side misconfiguration — public S3 buckets, open security groups, overly broad IAM roles, unpatched EC2 instances — is the far more common real-world path into an account, and every one of those sits on the customer's half of the line, not AWS's.

Myth: "The shared responsibility model is the same everywhere." As shown across EC2, RDS, S3, Lambda, ECS, and EKS above, the split genuinely moves depending on the service and even depending on a launch-mode setting within the same service. Treating one service's responsibility split as universal across your whole AWS account is exactly how gaps happen.

Myth: "Once I set my security group correctly, I'm done." Security is not a one-time checkbox. New team members get added, new features get deployed, and settings that were correct on day one quietly drift over months. Ethan's rule of thumb for Jake's shop: patching and reviewing your EC2 instance is like changing the oil in the shop's delivery van — skip it once and nothing happens; skip it for a year and you're the one paying for the rebuild, not AWS.

What happens when nobody patches their half

Back to Jake's shop for a minute, because this is where the abstract model gets expensive. After the security-group mistake, Jake's shop spent a weekend — not a Saturday he wanted to lose, given how much foot traffic a phone shop gets on weekends — locking down the database: tightening the security group to only allow the shop's own office IP address, forcing a strong unique password, and turning on RDS's automated backups so a future mistake couldn't also cost him the data itself. None of that required calling AWS support, because none of it was AWS's problem to fix. It was Jake's half of the line, and Jake's half of the line was the only half that had failed.

That's the pattern behind the vast majority of cloud security incidents you'll read about: not a crack in AWS's data centers, but a gap on the customer's side of a well-documented line — a line AWS spells out clearly, in writing, on a public web page, for free, before anyone signs up for an account.

If you're not sure whether something is your responsibility right now

Start by checking the specific service's security documentation on docs.aws.amazon.com — nearly every AWS service has its own "Security in [Service Name]" page that restates the shared responsibility model in terms specific to that exact service, the way the RDS, Lambda, and EKS pages referenced throughout this article do. That page will tell you, in plain language, which side of the line you're standing on for that particular tool.

Backups and encryption: the two responsibilities people forget are theirs

Two specific responsibilities deserve their own callout because they cause quiet, slow-motion disasters rather than dramatic breaches: backups and encryption.

For backups, AWS gives you the tools — automated backups on RDS, versioning on S3, snapshots on EBS volumes — but whether those tools are actually turned on, and whether anyone has ever tested restoring from them, is entirely your decision and your follow-through. AWS isn't going to enable backups on your behalf as a courtesy, and it isn't going to notice on your behalf that your backups have silently stopped running.

For encryption, AWS's own documentation on managing your data specifically calls out encryption options as something the customer classifies and configures — for abstracted services like S3 and DynamoDB just as much as for anything else. AWS provides strong encryption tooling by default in many places, but decisions like whether you're using AWS-managed keys or your own customer-managed keys, and who has permission to use those keys, remain yours.

Applying the model to your own setup

AWS itself frames this as something you determine per use case, not once for your whole account: customer responsibility varies based on the AWS services and Regions chosen, how those services integrate into your IT environment, and the laws and regulations that apply to your organization and workload. AWS points customers toward a handful of concrete exercises to figure this out for a real environment: reviewing the security functionality and configuration options documented in the security chapters of each service's own documentation, evaluating AWS's dedicated security, identity, and compliance services to see how they can help meet your objectives, determining your external and internal compliance requirements against recognized frameworks like the NIST Cybersecurity Framework or ISO certification, reviewing third-party audit attestation documents through AWS Artifact to see what you're already inheriting, and performing a Well-Architected Review of your workloads to check your implementation against AWS's own best practices for security, reliability, and performance.

None of that requires a security team or a big budget for a shop the size of Jake's. It requires going service by service through what you're actually using, and asking Ethan's three-question test for each one: can I see an operating system, does AWS or I choose the software version, and is there a mistake possible here that has nothing to do with AWS at all.

Frequently asked questions

What is the AWS shared responsibility model in simple terms?

It's the division of security duties between AWS and you. AWS handles security "of" the cloud — the physical facilities, hardware, network, and virtualization layer. You handle security "in" the cloud — your data, access permissions, and however much configuration your chosen service leaves in your hands. The exact split shifts depending on which service you're using.

Who is responsible for patching EC2 instances?

You are. AWS's documentation is explicit that customers deploying an EC2 instance are responsible for managing the guest operating system, including updates and security patches, along with any software they install on it. AWS never automatically patches the operating system running inside your EC2 instance.

Does AWS patch RDS databases?

AWS manages and patches the underlying operating system and the database engine software for RDS. You're still responsible for applying available engine patches on your own schedule for standard support, and — if you've enrolled in RDS Extended Support after standard support ends — you're specifically responsible for applying the critical and high-severity patches AWS supplies, plus upgrading to a newer engine version before Extended Support itself runs out.

Who is responsible for S3 bucket security?

You are, for the configuration. AWS operates the infrastructure, operating system, and platform behind S3 entirely. But bucket permissions, whether public access is blocked, encryption settings, and who has IAM permission to reach the bucket are all customer decisions. Public S3 buckets that were never meant to be public are a customer-configuration mistake, not an AWS infrastructure failure.

Is AWS responsible for encrypting my data?

AWS provides the encryption tools and, for many services, strong defaults, but the choice of whether to enable encryption, which type of key to use, and who can access that key is explicitly named in AWS's own documentation as part of the customer's responsibility for managing their data.

Who manages security groups and firewalls, AWS or the customer?

The customer. AWS provides the security group mechanism as a firewall tool, but configuring which ports are open and which IP addresses or resources are allowed through is a customer task on every service where security groups apply, from EC2 to RDS to EKS.

Does AWS's shared responsibility model cover compliance like PCI DSS or HIPAA?

It's the framework auditors use to evaluate your compliance posture on AWS, organized into inherited controls (fully AWS's, like physical data center security), shared controls (both parties have a role, like patch management), and customer-specific controls (entirely yours, based on your application). AWS Artifact provides the audit attestation documents that support this process, but whether your specific setup actually satisfies a given regulation is your organization's determination.

Who is responsible for IAM misconfigurations?

You are, on every AWS service without exception. Identity and access management — who has which permissions — is one of the constants that never shifts to AWS's side of the line, regardless of how managed or abstracted the underlying service is.

What is "security of the cloud" versus "security in the cloud"?

"Security of the cloud" is AWS's fixed responsibility: protecting the infrastructure that runs every AWS service, including hardware, software, networking, and the physical facilities across every Region, Availability Zone, and edge location. "Security in the cloud" is your variable responsibility, determined by which specific AWS service you've chosen and how much configuration that service leaves in your hands.

Does the shared responsibility model change with serverless, like Lambda?

Yes, it shifts even further toward AWS. For Lambda, AWS manages the underlying infrastructure, foundation services, operating system, and application platform. You're responsible for the security of your own code, your function's resource configuration, and IAM configuration around the Lambda service and within your function.

Who is responsible for container security in ECS, EKS, and Fargate?

It depends on the launch mode. Run containers on EC2-backed compute and you retain EC2-level responsibility for that underlying host, including patching. Run the same containers on AWS Fargate and AWS manages the underlying instances and much of the container runtime, shifting the responsibility split closer to how Lambda works. With Amazon EKS specifically, AWS always manages the Kubernetes control plane and its etcd database, while your responsibility for the data plane — the worker nodes — shrinks as you move from self-managed nodes, to managed node groups, to EKS Auto Mode or Fargate.

What happens if there's a data breach — is it AWS's fault or mine?

It depends entirely on which half of the line the failure occurred on. A breach caused by a flaw in AWS's own infrastructure, hypervisor, or physical security would fall on AWS. A breach caused by an open security group, a public storage bucket, an over-permissioned IAM role, weak credentials, or unpatched software you installed falls on the customer. In practice, the customer side is by far the more common origin point, since it's the side with the most day-to-day configuration decisions.

Does AWS ever take over patching if I don't do it myself?

In specific, limited cases, yes. For RDS Extended Support, AWS reserves the right to apply a patch automatically if it's necessary to address a critical security or stability issue, or to require that you install it. If an RDS engine reaches the end of Extended Support without you upgrading, AWS will attempt an automatic engine upgrade, and can delete the instance if that upgrade fails, after preserving your data first. These are exceptions built for specific, narrow scenarios, not a general safety net across AWS services.

Is the shared responsibility model the same for every AWS service?

No, and that's the single most important thing to take away from this whole topic. The underlying principle — AWS handles security of the cloud, you handle security in the cloud — stays constant, but the actual amount of work on your side varies enormously between an IaaS service like EC2, a managed platform like RDS, and a fully abstracted service like S3 or DynamoDB, and it can even vary within the same service depending on a launch-mode setting, as with ECS on EC2 versus ECS on Fargate, or the node type you pick for EKS.

Who is responsible for backups — AWS or the customer?

The customer, in the sense that matters most: AWS provides backup tools and features across most services, but turning them on, configuring the retention you need, and actually verifying restores work is your responsibility. AWS won't enable backups on your behalf, and it won't alert you if a backup process you never actually configured has never been running.

Where can I find AWS's official shared responsibility documentation?

AWS publishes the model directly on its Cloud Security compliance pages, and nearly every individual service has its own dedicated "Security in [Service Name]" page inside AWS's documentation that restates the model in terms specific to that exact service — the RDS, Lambda, and EKS security pages are good examples of how detailed and service-specific this documentation actually gets.

Revision note. Written September 2026. This will change if AWS restructures how it categorizes service tiers or extends automatic patching further than the narrow RDS Extended Support exception described above. If you're the one who just found the open security group or the public bucket, take a breath — this happens to careful people too, and every fix above is something you can do yourself, today, without waiting on anyone.