AWS Shared Responsibility Model: Security OF vs IN the Cloud

Definition

The AWS Shared Responsibility Model is a security framework that divides accountability between AWS and the customer. AWS is responsible for security OF the cloud — the physical infrastructure, hypervisor, managed services' underlying platforms, and global network. The customer is responsible for security IN the cloud — the data, configurations, access controls, and application code they deploy on AWS.

This model is the single most important security concept in AWS certifications and a foundational principle for every production workload. Misunderstanding it is the root cause of most cloud security incidents.

How It Works

The line between AWS and customer responsibility shifts depending on the service type:

Infrastructure Services (IaaS) — e.g., EC2

AWS manages: physical hosts, storage drives, hypervisor, network infrastructure. Customer manages: guest OS (patching), firewall/security groups, IAM, application code, data encryption, network configuration.

Container / Platform Services (PaaS) — e.g., RDS, ECS on Fargate

AWS manages: everything in IaaS plus the OS, platform patching, and runtime. Customer manages: data, IAM policies, network access (security groups, NACLs), encryption configuration, database user management.

Abstracted Services (SaaS-like) — e.g., S3, DynamoDB, Lambda

AWS manages: everything through the platform and runtime. Customer manages: data, access policies (IAM, bucket policies, resource policies), encryption settings, client-side encryption if required.

The more managed the service, the more responsibility shifts to AWS — and the less the customer must handle.

Key Features and Limits

AWS responsibility (security OF the cloud): physical data centers, hardware lifecycle, hypervisor security, managed service patching, global network backbone, edge locations, AZ and Region isolation.
Customer responsibility (security IN the cloud): IAM users/roles/policies, security group rules, NACLs, OS patching (EC2), data classification, encryption at rest and in transit, application-level firewall rules, compliance validation.
Shared controls: patch management (AWS patches infrastructure, customer patches guest OS), configuration management (AWS configures its infrastructure, customer configures services), and awareness/training.
Service-specific nuances: for RDS, AWS patches the DB engine but the customer manages DB users and query-level access. For Lambda, AWS manages the runtime but the customer manages function code and IAM execution roles.
Compliance is shared: AWS maintains certifications (SOC, ISO, PCI, HIPAA) for its infrastructure, but customers must validate that their configurations meet their own compliance requirements.

Common Use Cases

Security audits — auditors ask "who is responsible for X?" The model provides the answer for every layer.
Compliance scoping — for PCI DSS or HIPAA, the model clarifies which controls AWS covers (inherit) and which the customer must implement.
Incident response — if an S3 bucket is publicly exposed, that is a customer responsibility failure, not an AWS failure.
Architecture decisions — choosing Lambda over EC2 shifts OS patching responsibility to AWS, reducing the customer's security burden.
Vendor risk assessments — procurement teams use AWS Artifact to obtain AWS compliance reports and map them to the model.

Pricing Model

The Shared Responsibility Model itself is a framework, not a billable service. However, AWS offers security services that help customers meet their side of the model:

AWS Config — continuous compliance monitoring (per rule per Region per month).
GuardDuty — threat detection (per volume of CloudTrail events, VPC Flow Logs, DNS logs analyzed).
Security Hub — centralized security findings (per security check per month).
Inspector — vulnerability scanning for EC2 and Lambda (per instance/function assessed).
Macie — S3 data classification (per GB scanned).

All are pay-as-you-go. Many have free-tier allowances or 30-day trials.

Pros and Cons

Pros

Creates a clear, documented division of security accountability.
Lets customers inherit AWS's massive investment in physical and infrastructure security.
Choosing managed services (Lambda, Fargate, RDS) meaningfully reduces customer security burden.
AWS compliance certifications (SOC 2, ISO 27001, PCI DSS) cover the "OF the cloud" layer, simplifying customer audits.
Universally understood across AWS certifications, teams, and auditors.

Cons

The boundary shifts per service, which confuses teams new to AWS.
"Shared" can create ambiguity — some controls (like patching) are split between AWS and the customer.
Customers sometimes assume AWS handles more than it does (e.g., S3 bucket policies are 100% customer responsibility).
Does not eliminate the need for customer-side security expertise — it reallocates it.
Multi-cloud environments need separate responsibility models for each provider.

Comparison with Alternatives

| | AWS Shared Responsibility | Azure Shared Responsibility | GCP Shared Fate | | --- | --- | --- | --- | | Core concept | Security OF vs IN the cloud | Same split — provider vs customer | "Shared Fate" — Google invests in making customer-side security easier | | IaaS customer owns | OS, apps, data, IAM, network config | Same | Same | | PaaS customer owns | Data, access, encryption config | Same | Same | | SaaS customer owns | Data, access policies | Same | Same | | Key difference | Original cloud security model, most widely referenced | Nearly identical to AWS | Adds opinionated defaults and blueprints to reduce customer burden |

All three major clouds use essentially the same division. AWS coined the most widely cited version. The practical difference is in tooling and defaults, not the model itself.

Exam Relevance

Cloud Practitioner (CLF-C02) — Security & Compliance domain is 30% of the exam. Expect 3–5 direct questions: "Which is a customer responsibility?" "Which is an AWS responsibility?" Know the model for EC2 (customer patches OS), RDS (AWS patches engine), S3 (customer configures bucket policies), Lambda (AWS manages runtime).
Solutions Architect Associate (SAA-C03) — scenario questions: "A company must ensure database patches are applied. Which service reduces their patching burden?" Answer: RDS or Aurora (AWS patches) vs EC2-hosted DB (customer patches).
Security Specialty (SCS-C02) — deep dive into shared controls, compliance inheritance, and how services like Config, GuardDuty, and Security Hub help customers fulfill their side.

Exam trap: encryption at rest and in transit is always the customer's responsibility to enable, even though AWS provides the tools (KMS, ACM, S3 default encryption).

Frequently Asked Questions

Q: What does "security OF the cloud" vs "security IN the cloud" mean?

A: "Security OF the cloud" is AWS's responsibility: physical data centers, hardware, hypervisor, managed service infrastructure, and the global network. "Security IN the cloud" is the customer's responsibility: data, IAM configuration, security group rules, encryption settings, OS patching (for EC2), and application code. The dividing line shifts depending on whether you use IaaS (EC2), PaaS (RDS), or serverless (Lambda).

Q: Does AWS patch my EC2 instances?

A: No. EC2 is an Infrastructure as a Service (IaaS) offering. AWS manages the physical host and hypervisor, but the guest operating system, security patches, and application stack are entirely the customer's responsibility. Use AWS Systems Manager Patch Manager to automate OS patching. If you want AWS to handle patching, choose a managed service like RDS, Fargate, or Lambda instead.

Q: Is data encryption AWS's responsibility or the customer's?

A: Encryption is a customer responsibility. AWS provides the tools — KMS for key management, S3 default encryption, RDS encryption at rest, ACM for TLS certificates — but the customer must enable and configure them. Even when AWS manages the encryption keys (SSE-S3, SSE-KMS), the customer decides whether encryption is turned on and which key policy to apply.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS Shared Responsibility Model before making production decisions.