What Is the AWS Shared Responsibility Model?
Learn what the AWS shared responsibility model means, how security duties split between AWS and customers, and why misconfiguration causes most breaches.
Expected Interview Answer
The Shared Responsibility Model defines that AWS is responsible for the security 'of' the cloud — the physical infrastructure, hardware, and managed service internals — while the customer is responsible for security 'in' the cloud — how they configure identity, data, and network controls on top of it.
AWS secures data centers, host operating systems, virtualization, and the physical network for its infrastructure and manages patching for its managed services down to varying depths. Customers, in turn, own configuration of everything they control: IAM policies and least-privilege access, security group and NACL rules, encryption of data at rest and in transit, guest OS patching on EC2 instances, and application-level security. The exact split shifts by service model — for EC2 (IaaS) the customer patches the guest OS; for RDS (PaaS-like) AWS patches the database engine but the customer still manages access control and data; for a fully managed service like S3, AWS handles almost everything except bucket policies, encryption settings, and what data the customer chooses to store. Misconfiguring customer-side controls, like leaving an S3 bucket public, is the most common real-world cause of cloud breaches, not a failure of AWS's side.
- Clarifies exactly which security tasks are AWS's versus the customer's
- Frees customers from managing physical data center security
- Focuses customer effort on IAM, encryption, and configuration
- Scales differently by service type (IaaS, PaaS, SaaS-like)
- Underpins most cloud compliance frameworks and audits
AI Mentor Explanation
The shared responsibility model is like a stadium operator maintaining the pitch, floodlights, and structural safety of the ground, while the visiting team is responsible for its own strategy, fielding positions, and player conditioning on match day. If a batsman gets run out because of poor calling between wickets, that is on the team's decisions, not on the stadium's groundskeeping.
Step-by-Step Explanation
Step 1
AWS secures 'of' the cloud
Physical data centers, hardware, host OS, and the underlying network infrastructure are AWS's responsibility.
Step 2
Customers secure 'in' the cloud
IAM configuration, security groups, data encryption, and guest OS patching (on EC2) are the customer's job.
Step 3
Responsibility shifts with service type
For IaaS (EC2), customers patch the OS; for managed services (RDS), AWS patches the engine but customers manage access and data.
Step 4
Compliance inherits from both sides
AWS provides compliance certifications for its infrastructure, but customers must configure their workloads to meet the same standards.
Step 5
Misconfiguration is the common failure point
Public S3 buckets and overly broad IAM policies are customer-side misconfigurations, not AWS infrastructure failures.
What Interviewer Expects
- Clearly separates 'security of the cloud' (AWS) from 'security in the cloud' (customer)
- Explains how the split shifts across IaaS, PaaS-like, and fully managed services
- Gives concrete examples: guest OS patching, IAM policies, S3 bucket policies
- Notes that most real breaches stem from customer-side misconfiguration
- Connects the model to compliance and audit responsibilities
Common Mistakes
- Assuming AWS is responsible for securing customer data and access configuration
- Believing the split is identical across every AWS service
- Thinking compliance certification of AWS infrastructure covers the customer's workload automatically
- Not patching guest operating systems on EC2, assuming AWS handles it
Best Answer (HR Friendly)
“AWS takes care of the physical security of its data centers and hardware, but customers are responsible for configuring their own access controls, encryption, and settings correctly. Most cloud security incidents happen because of a customer misconfiguration, not because AWS's own infrastructure was breached.”
Code Example
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::app-data-bucket/*",
"Condition": {
"Bool": { "aws:SecureTransport": "true" }
}
}
]
}Follow-up Questions
- How does the shared responsibility model differ between EC2 and a fully managed service like DynamoDB?
- What are some common S3 misconfigurations that cause data breaches?
- Who is responsible for patching the guest OS on an EC2 instance?
- How does the model apply to container services like ECS or EKS?
- How would you explain this model during a compliance audit?
MCQ Practice
1. Under the shared responsibility model, who secures the physical data centers?
AWS is responsible for 'security of the cloud,' including physical data center and hardware security.
2. Who is typically responsible for patching the guest operating system on an EC2 instance?
For EC2 (IaaS), the customer owns guest OS patching since they control the instance's operating system.
3. What is the most common real-world cause of cloud security incidents?
Most cloud breaches trace back to customer misconfigurations such as overly permissive bucket policies or IAM roles, not AWS infrastructure failures.
Flash Cards
What is AWS responsible for in the shared responsibility model? — Security 'of' the cloud: physical infrastructure, hardware, and host-level security.
What is the customer responsible for? — Security 'in' the cloud: IAM, data encryption, network configuration, and (for IaaS) guest OS patching.
Does the split change by service type? — Yes — AWS takes on more for managed services like RDS or DynamoDB than for raw EC2.
What is the most common cause of cloud breaches? — Customer-side misconfiguration, such as a publicly accessible S3 bucket.