All Articles
AWSCloud SecurityArchitecture

Understanding the AWS Shared Responsibility Model: What You Secure vs What AWS Secures

The most commonly tested AWS concept — know exactly where your responsibility begins and AWS's ends

2026-07-15 7 min read

The Shared Responsibility Model is perhaps the single most important concept in AWS certification and technical assessments. It defines the security boundary between what AWS manages (security OF the cloud) and what you manage (security IN the cloud).

Misunderstanding this boundary is the root cause of most cloud security incidents. This guide provides a clear, practical breakdown with concrete examples for each layer of the stack.

The Core Principle: OF the Cloud vs IN the Cloud

AWS is responsible for security OF the cloud — the physical infrastructure, hardware, networking, and the managed services layer. You are responsible for security IN the cloud — your data, access controls, application configuration, and operating system patches.

Think of it like renting an apartment. The landlord (AWS) maintains the building structure, locks on the main door, fire systems, and plumbing. You (the tenant) are responsible for locking your own door, not leaving valuables visible through windows, and whom you give keys to.

This model shifts based on which AWS services you use. With EC2 (Infrastructure as a Service), you manage more. With Lambda (Function as a Service), AWS manages more. Understanding this spectrum is critical for assessment questions.

AWS's Responsibilities: Security OF the Cloud

AWS manages and secures the foundational infrastructure that runs all AWS services. This includes physical security of data centers (biometric access, 24/7 guards, surveillance), hardware infrastructure (servers, storage devices, networking equipment), the hypervisor layer that provides virtualization for EC2, and the global network infrastructure (fiber connections between regions and availability zones).

AWS also maintains the software that runs managed services. For RDS, AWS patches the database engine. For Lambda, AWS patches the runtime. For S3, AWS manages the storage firmware and replication logic.

You cannot audit these layers directly. AWS provides compliance certifications (SOC 2, ISO 27001, PCI DSS) as third-party verification. You can download these from AWS Artifact.

Your Responsibilities: Security IN the Cloud

Customer responsibilities vary by service type but always include: data classification and encryption decisions, identity and access management (IAM policies), network configuration (Security Groups, NACLs, VPC design), and application-level security.

For EC2 instances, you are responsible for: choosing the AMI and keeping the operating system patched, configuring the firewall (Security Groups), installing and updating application software, encrypting data at rest and in transit, and managing SSH keys or access credentials.

For S3 buckets, you are responsible for: bucket policies and access control lists (ACLs), enabling encryption (SSE-S3, SSE-KMS, or client-side), configuring logging, blocking public access, and managing lifecycle policies.

For IAM, you are responsible for: creating least-privilege policies, enabling MFA for all human users, rotating access keys, monitoring with CloudTrail, and never using the root account for daily operations.

The Spectrum: IaaS vs PaaS vs SaaS

Your responsibility decreases as you move from IaaS to PaaS to SaaS, because AWS manages more of the stack.

EC2 (IaaS): You manage the OS, middleware, runtime, application, and data. AWS manages the hardware and hypervisor. This gives maximum control but maximum responsibility.

RDS (PaaS): AWS manages the OS, database engine patching, backups (if enabled), and failover. You manage database-level access (users, grants), data encryption settings, Security Group rules, and the data itself.

Lambda (FaaS/Serverless): AWS manages everything below your code — the OS, runtime patches, scaling, availability. You manage your function code, IAM execution role, environment variables, and any secrets your function uses.

S3 (Managed Storage): AWS manages durability (11 nines), availability, and the storage infrastructure. You manage access policies, encryption configuration, versioning, and data lifecycle.

Common Assessment Questions

Assessment questions often present a security scenario and ask who is responsible. Here are the patterns:

Question pattern: 'Who is responsible for patching the operating system on an EC2 instance?' Answer: The customer. EC2 gives you a virtual machine — you manage everything above the hypervisor.

Question pattern: 'Who is responsible for patching the database engine in RDS?' Answer: AWS. RDS is a managed service where AWS handles engine patches during maintenance windows you configure.

Question pattern: 'Who is responsible for physical security of the data center?' Answer: Always AWS, regardless of service type.

Question pattern: 'A publicly accessible S3 bucket leaked customer data. Who is responsible?' Answer: The customer. AWS provides the tools to block public access (bucket policies, Block Public Access settings), but the customer must configure them correctly.

Practical Security Checklist for AWS Deployments

Based on the shared responsibility model, here is what you must always configure as a customer, regardless of which services you use:

Identity: Enable MFA on root and all IAM users. Create individual IAM users (never share credentials). Apply least-privilege policies. Use IAM roles for EC2/Lambda instead of access keys.

Network: Configure Security Groups to allow only necessary inbound traffic. Use private subnets for databases and backend services. Enable VPC Flow Logs for monitoring.

Encryption: Enable encryption at rest for all storage (S3, EBS, RDS). Use TLS for data in transit. Manage keys through KMS with appropriate key rotation policies.

Monitoring: Enable CloudTrail for API audit logging in all regions. Configure CloudWatch alarms for unusual activity. Enable AWS Config for compliance tracking.

These responsibilities exist regardless of whether you use EC2, Lambda, RDS, or any other service. The specific details change, but the categories remain constant.

Frequently Asked Questions

Does the shared responsibility model change for GovCloud or regulated workloads?

The boundary remains the same. AWS GovCloud provides additional compliance certifications (FedRAMP, ITAR) but does not shift responsibility. For regulated workloads (HIPAA, PCI), you have additional configuration responsibilities (encryption, audit logging, access controls) but AWS's infrastructure responsibility is unchanged.

If AWS has a service outage, am I still responsible for availability?

AWS is responsible for the infrastructure availability they commit to in their SLA. However, designing for high availability (multi-AZ deployments, failover configuration) is your responsibility. A single-AZ deployment that fails during an AZ outage is a customer architecture decision, not an AWS failure.

Who is responsible for DDoS protection?

Both. AWS provides baseline DDoS protection (AWS Shield Standard) for all customers at no cost. For advanced protection, customers can enable AWS Shield Advanced and configure AWS WAF rules. The customer is responsible for designing their architecture to absorb or deflect traffic (CloudFront, ALB, Auto Scaling).

Ready to practice?

Put this into action with our independently reviewed practice material.

Start practising free