AWS Shared Responsibility Model Explained: Who Secures What?

Simple explanation

AWS runs the buildings, the servers, the network cables, and the software that makes services like EC2, S3, and Lambda work. That is their security job. Your security job is everything you deploy and configure on top of those services: your data, your user permissions, your encryption settings, your application code, and your network rules.

The exact split changes depending on which AWS service you use. When you run an EC2 instance, you manage the operating system. When you use Lambda, AWS manages the OS and runtime for you. But no matter how managed the service is, your data, IAM configuration, and application code are always your responsibility.

Why this matters

The vast majority of cloud security breaches are customer misconfigurations, not AWS infrastructure failures. Real-world examples include:

• S3 buckets left publicly accessible, exposing customer records or internal documents
• IAM roles with wildcard permissions (:) that give attackers full account access when credentials leak
• EC2 instances running unpatched operating systems with known vulnerabilities
• Secrets like database passwords and API keys hardcoded in application code or environment variables
• Security groups with 0.0.0.0/0 inbound rules exposing services to the entire internet
• CloudTrail disabled, leaving no audit trail when something goes wrong

How it works

AWS describes the model using two phrases:

• Security of the cloud is AWS’s responsibility. This covers the physical infrastructure, hardware, hypervisor, global network, and the managed layers of AWS services.
• Security in the cloud is your responsibility. This covers the data, identities, permissions, configurations, encryption, code, and monitoring that you deploy and manage on top of AWS.

The boundary between the two is not a single fixed line. It shifts depending on how managed the service is. EC2 gives you a virtual machine, so you own everything from the OS up. RDS gives you a managed database, so AWS owns the OS and engine patching, but you still own the data, access, and encryption settings. Lambda gives you a function runtime, so AWS owns almost the entire stack, but your code and its IAM permissions are still yours.

What AWS is responsible for

AWS secures the security of the cloud, meaning the infrastructure that all AWS services run on:

• Physical security including data centre access controls, biometric scanning, surveillance, and perimeter fencing
• Hardware including servers, storage devices, networking equipment, and hardware lifecycle management
• Global network including the AWS backbone, routers, switches, and DDoS protection at the network edge
• Hypervisor, the virtualization layer that isolates EC2 instances from each other
• Managed service infrastructure where AWS patches the OS, runtime, and engine for services like RDS, DynamoDB, and Lambda
• Availability, meaning region and availability zone uptime within published SLAs

AWS publishes compliance certifications (SOC 1/2/3, ISO 27001, PCI DSS, HIPAA, FedRAMP) that cover these infrastructure-level controls. You inherit those certifications for the infrastructure layer when you build on AWS.

What you are responsible for

You are responsible for security in the cloud, meaning everything you deploy, configure, and run on top of AWS:

• Your data including classification, handling, and controlling who can access it
• IAM configuration including users, roles, policies, and who has access to what in your account
• Operating system on EC2 including patching, hardening, user accounts, and installed software
• Application code including your code, its dependencies, and application-level vulnerabilities
• Network configuration including VPC design, security group rules, NACLs, and route tables
• Encryption for S3, EBS, RDS, and other services (KMS provides the tools; you must turn them on)
• Monitoring and logging through CloudTrail, CloudWatch, and GuardDuty, plus actually responding to alerts
• Secrets handling through Secrets Manager or Parameter Store, not hardcoded in code or environment variables

Security of the cloud vs security in the cloud

These two phrases appear constantly in AWS documentation and certification exams. Here is the direct comparison:

How responsibility changes by service type

The boundary shifts significantly depending on whether you are using infrastructure (EC2), a managed service (RDS), a serverless function (Lambda), or object storage (S3):

When to use this model

The shared responsibility model is not just a certification topic. You should actively think about it:

• Before launching any workload. Ask “what am I responsible for securing on this service?” before you go to production.
• During architecture reviews. When choosing between EC2 and a managed or serverless service, the security boundary is a real factor in the decision.
• During security audits. Auditors will ask you to prove that you own your side of the model (IAM policies, encryption, logging, patching).
• When evaluating managed vs self-managed. Moving from EC2 to RDS or Lambda shifts infrastructure security to AWS, but your data and access controls stay with you.
• When preparing for interviews or certifications. The shared responsibility model appears on every AWS certification exam and in most cloud security interview questions.

Practical security checklist

These are the highest-impact actions on the customer side of the boundary. If you are setting up a new AWS account or reviewing an existing one, start here:

1. Enable MFA on the root account and all IAM users. This is the single most effective control against credential compromise.
2. Apply least privilege to every IAM role and user. Start with zero permissions and add only what is needed.
3. Enable CloudTrail in all regions and send logs to a protected S3 bucket with object lock.
4. Enable GuardDuty for automated threat detection across your account.
5. Enable S3 Block Public Access at the account level to prevent accidental public buckets.
6. Turn on default encryption for S3 buckets, EBS volumes, and RDS instances.
7. Lock down security groups. Never allow 0.0.0.0/0 inbound on SSH or RDP.
8. Automate EC2 patching using Systems Manager Patch Manager.
9. Store secrets in Secrets Manager. Not in environment variables, code, or config files.

# Check if MFA is enabled on the root account
aws iam get-account-summary \
  --query 'SummaryMap.AccountMFAEnabled'

# List CloudTrail trails and check if they are logging
# Step 1: List your trails
aws cloudtrail describe-trails \
  --query 'trailList[*].{Name:Name,MultiRegion:IsMultiRegionTrail}' \
  --output table

# Step 2: Check logging status for a specific trail
aws cloudtrail get-trail-status \
  --name my-trail \
  --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime}'

# Check S3 account-level public access block status
aws s3control get-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text)

# Check if GuardDuty is enabled
aws guardduty list-detectors

Compliance and audits

When your organisation needs PCI DSS, HIPAA, SOC 2, or ISO 27001 compliance, the shared responsibility model defines the split:

• AWS covers physical security, hardware integrity, network infrastructure, hypervisor isolation, and managed service platform controls. AWS publishes compliance reports through the AWS Artifact portal that auditors can review.
• You cover application-level access controls, data classification and handling, user activity logging, vulnerability scanning, incident response procedures, and employee security training.

Real-world examples

These three scenarios show how the boundary moves depending on the service. Pay attention to what stays the same in each one.

Regardless of whether you used EC2, RDS, or Lambda, you were always responsible for IAM, data, encryption choices, and network access. The infrastructure layer changed. The customer responsibilities at the top of the stack stayed the same.