AWS Shared Responsibility Model
The Shared Responsibility Model divides security obligations between AWS, which is responsible for 'security of the cloud' (the physical data centers, the hardware, the network infrastructure, and the virtualization layer), and the customer, who is responsible for 'security in the cloud' (configuring firewalls correctly, managing IAM permissions, encrypting sensitive data, and patching the guest operating system on services like EC2). Misunderstanding this split, for example assuming AWS automatically secures an S3 bucket's access permissions, is one of the most common causes of real-world cloud data breaches.
Cricket analogy: Like a stadium operator (AWS) being responsible for the ground, floodlights, and pitch maintenance while the team's coach (customer) is responsible for player selection and tactics, both parties own distinct parts of match-day success.
What AWS Manages
AWS's side of the split, 'security of the cloud,' covers the physical security of data centers (biometric access, 24/7 guards), the durability and redundancy of the underlying hardware, the isolation between different customers' virtual machines on shared physical hosts, and the patching of the host operating system and hypervisor for managed services. For a fully managed service like S3 or DynamoDB, AWS also manages the underlying operating system and platform patching, since the customer never has direct OS-level access.
Cricket analogy: Like the BCCI ensuring every stadium meets structural safety codes before any match is scheduled, AWS ensures every physical data center meets rigorous safety, redundancy, and access-control standards before any customer workload runs there.
// Example: overly permissive S3 bucket policy — a customer-side misconfiguration,
// NOT something AWS secures automatically
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-customer-data/*"
}
]
}
// Principal: "*" makes every object in this bucket publicly readable —
// this is a customer responsibility to configure correctly, not AWS's.What the Customer Manages
The customer's side, 'security in the cloud,' includes configuring IAM users, roles, and policies with least-privilege access, setting security group and network ACL rules correctly, encrypting data at rest and in transit, patching the guest operating system on unmanaged compute like EC2, and classifying and protecting sensitive data according to relevant regulations like HIPAA or PCI DSS. AWS provides the tools (IAM, KMS, Security Groups, GuardDuty) but does not decide how a customer configures them.
Cricket analogy: Like a captain (customer) deciding field placements and bowling changes using the ground AWS provides, IAM policies and security group rules are decisions the customer must make correctly; AWS just supplies the tools.
The exact split shifts depending on the service model: for EC2 (IaaS), the customer patches the guest OS; for RDS (managed PaaS), AWS patches the database engine; for S3 or Lambda (fully managed/serverless), AWS manages nearly the entire stack below the data itself.
Publicly exposed S3 buckets, overly permissive IAM policies, and unencrypted RDS instances are customer-side misconfigurations, not AWS failures. The majority of publicized cloud data breaches trace back to these avoidable customer mistakes.
- AWS is responsible for 'security of the cloud': physical data centers, hardware, network, and virtualization.
- Customers are responsible for 'security in the cloud': IAM configuration, data encryption, and network rules.
- For unmanaged compute like EC2, customers must patch the guest operating system themselves.
- For fully managed services like S3 or Lambda, AWS manages nearly the entire stack below the customer's data.
- AWS provides security tools (IAM, KMS, Security Groups, GuardDuty), but customers must configure them correctly.
- The majority of real-world cloud breaches result from customer-side misconfigurations, not AWS infrastructure failures.
- The exact division of responsibility shifts depending on whether a service is IaaS, PaaS, or fully managed/serverless.
Practice what you learned
1. Under the Shared Responsibility Model, who is responsible for physical data center security?
2. Who is responsible for configuring an S3 bucket's access permissions correctly?
3. For a fully managed service like AWS Lambda, who patches the underlying operating system?
4. What is a common real-world cause of cloud data breaches according to the Shared Responsibility Model?
5. For an unmanaged EC2 instance, who is responsible for patching the guest operating system?
Was this page helpful?
You May Also Like
What Is AWS?
An introduction to Amazon Web Services, the leading cloud platform, covering what it is, why it exists, and how it changes the economics of running IT infrastructure.
The AWS Management Console and CLI
How to interact with AWS through the web-based Management Console and the Command Line Interface, and when to use each.
AWS Free Tier and Billing Basics
How AWS's Free Tier works, how billing and invoicing are structured, and the tools and habits that keep costs predictable and under control.