Shared Responsibility Model

The Shared Responsibility Model divides security responsibilities between AWS and the customer:

• AWS responsibility (security OF the cloud): physical data centers, hardware, networking, hypervisor, and the global infrastructure that runs all AWS services
• Customer responsibility (security IN the cloud): data encryption, IAM configuration, security group rules, OS patching, application security, and network configuration

The line shifts depending on the service type. With EC2 (IaaS), you manage the OS and everything above it. With Lambda (serverless), AWS manages the runtime - you only manage code and IAM permissions. With S3 (managed service), you manage access policies, encryption settings, and data classification.

How It Goes Wrong in Practice

The single most damaging misunderstanding in cloud security is the sentence "AWS is secure, so we are secure". It is half true, and the wrong half gets people breached. AWS has never been responsible for your bucket policies, your security group rules, your IAM permissions, or the passwords in your database. The recurring, well-documented incident class of the last decade, publicly exposed storage buckets full of customer data, is almost never an AWS infrastructure failure. It is customers granting public read access on their side of the line. The same goes for internet-exposed databases: AWS provides the isolation primitives (VPCs, security groups, private subnets), but nothing stops you from configuring a public IP and an open port on a database holding regulated data.

The subtler failure is at the seams, on shared controls. Patch management is the classic example: AWS patches the hypervisor and the underlying infrastructure, but the guest operating system on your EC2 instances is yours. Teams migrating from on-premises sometimes disband their patching process on the assumption that "the cloud handles it", and eighteen months later they are running fleets with known-exploitable kernels. Before adopting any service, write down explicitly which of the two parties patches, encrypts, backs up, and monitors each layer. If you cannot answer for a layer, that layer is probably unowned, and unowned layers are where incidents live.

A Practical Check

You can verify AWS's side of the model yourself instead of taking it on faith. AWS Artifact gives every customer self-service access to AWS's third-party audit reports (SOC reports, ISO certifications, PCI attestations) that document how AWS meets its share of the responsibilities. From the CLI:

aws artifact list-reports

Or in the console: open AWS Artifact, then choose Reports, and download the report your auditors need. Checking your own side has no single command, because your side is the whole configuration surface: this is what AWS Config, Security Hub standards, and IAM reviews exist for.

Frequently Asked Questions

If AWS is ISO 27001 and SOC 2 certified, does that make my workload compliant? No. You inherit the infrastructure-level controls, which genuinely shrinks your audit scope: you do not have to prove data center physical security or hardware disposal procedures. But every control that lives in your configuration (access management, encryption choices, logging, network exposure, change management) is assessed against what you actually built. Auditors call this a shared or inherited controls model: AWS's reports cover their layer, your evidence covers yours.

Who patches what? It depends on where the service sits on the spectrum. On EC2, AWS maintains the hardware and hypervisor; the guest OS, middleware, and application patches are yours. On RDS, AWS applies database engine and OS patching within your maintenance windows, while schema-level security and credentials remain yours. On Lambda, AWS manages the runtime environment, and your responsibility contracts to your code, its dependencies, and its IAM permissions. The rule of thumb: the more managed the service, the more your responsibility concentrates into data, identity, and configuration.

Does AWS look at or protect my data content? Protecting data in the cloud is explicitly a customer responsibility in the model: you choose what to store, how to classify it, whether and how to encrypt it, and who can access it. AWS provides the mechanisms (KMS, encryption options, IAM, Macie for discovery), but deciding to use them, and using them correctly, is your side of the contract.

Is the model different for containers? Container services illustrate how the line moves within one product family. On ECS with EC2 launch type you patch the container hosts; on Fargate, AWS manages the underlying compute and your responsibility shifts to the container images, the task IAM roles, and the network configuration. Same workload shape, different split, which is exactly why the model has to be re-read for every service you adopt.