The AWS Shared Responsibility Model defines which security tasks AWS handles and which ones you handle when you use their cloud services. AWS secures the underlying infrastructure — hardware, data centers, networking, and the virtualization layer — while you remain responsible for securing your data, access controls, and how you configure the services you use. Misunderstanding this split is the leading cause of cloud security incidents, not AWS infrastructure failures.
Ask any AWS architect where security "lives" in the cloud, and you'll get the same answer: it depends on who's responsible for what. That's the entire premise of the Shared Responsibility Model — a framework that splits security duties between AWS and the customer rather than assigning it all to one party. This article breaks down exactly where that line falls, how it shifts depending on the service you're using, and what it means practically for anyone building, securing, or auditing workloads on AWS.
What Is the AWS Shared Responsibility Model?
The Shared Responsibility Model is AWS's way of defining who secures what. AWS takes ownership of a defined portion of security, and the customer takes ownership of the rest. Neither party owns the whole picture, and that's by design.
This isn't a vague partnership — it's a documented, service-by-service division. AWS publishes exactly which controls it manages for a given service, and which controls are left to you. Understanding this split is foundational to passing the Cloud Practitioner exam, and it's just as foundational to actually running secure infrastructure.
The model exists because cloud computing changes who has physical access to hardware, but it doesn't change who owns the data, the configurations, or the business logic sitting on top of that hardware. Someone still has to secure those layers — and that someone is you.
Security "Of" the Cloud vs Security "In" the Cloud
AWS describes its side of the split as security "of" the cloud. That means AWS is responsible for protecting the infrastructure that runs every service it offers — the physical data centers, the networking backbone, the host hardware, and the virtualization layer.
- Physical security: data center access controls, surveillance, and environmental protections are entirely AWS's job.
- Hardware and global infrastructure: servers, storage devices, and the network connecting AWS regions and availability zones fall under AWS's control.
- Foundational software: the hypervisor and host operating system that make virtualization possible are patched and maintained by AWS.
The customer's side is security "in" the cloud — what you build and configure on top of that infrastructure.
- Your data: classifying it, encrypting it, and controlling who can read or modify it.
- Identity and access management: deciding who gets into your AWS account and what they're allowed to touch once they're in.
- Configuration: security group rules, network ACLs, bucket permissions, and every setting that determines whether a resource is locked down or exposed.
AWS can build the most secure data center on the planet, but it has no way of knowing whether you intended a storage bucket to be public or private. That decision — and its consequences — sits with you.
Master the right skills for your goal
Not sure which path fits? Get a free 1:1 consultation with our team.
How the Split Changes by Service Type
The line between "of" and "in" the cloud doesn't sit in the same place for every service. It moves depending on how much of the stack AWS manages for you.
- Infrastructure as a Service (EC2): AWS secures the physical host and hypervisor, but you're responsible for the guest operating system, patching, firewall rules, and anything you install. This is the most customer-heavy end of the spectrum.
- Managed services (RDS): AWS takes on more — it handles OS patching, database engine maintenance, and underlying infrastructure. You're still responsible for access policies, network configuration, and data encryption settings.
- Serverless (Lambda, S3): AWS manages almost the entire operational stack, including scaling and runtime patching. Your responsibility narrows to your code, your permissions, and how you configure access to the data stored or processed.
As AWS manages more of the stack, more responsibility shifts toward them. But one thing never moves: you always own your data and you always own access management, regardless of how "managed" the service is.
Think of AWS as the landlord who guarantees the building won't collapse — the locks on your apartment door, and who you hand the keys to, are still entirely your problem.
Real-World Examples of the Divide
The model becomes much clearer when you map it to actual incidents. Here's who's on the hook in common scenarios.
- Unpatched OS on an EC2 instance: if an attacker exploits a known vulnerability in your instance's operating system, that's a customer failure. AWS secures the hypervisor, but patching the guest OS is your job.
- A misconfigured S3 bucket left publicly readable: this is almost always a customer configuration error, not an AWS infrastructure failure. The bucket's access controls are yours to set correctly.
- A weak or overly permissive IAM policy: if a compromised credential has far more access than it needs, that's a customer-side access management failure, not a gap in AWS's platform.
- An unencrypted database holding sensitive records: AWS offers encryption options on services like RDS, but enabling them is a configuration choice left to the customer. Leaving data in plaintext is a customer decision, not an AWS default failing you.
Notice the pattern: in every one of these cases, the underlying AWS infrastructure performed exactly as designed. The gap opened on the customer's side of the line, usually through a missed setting rather than a flaw in AWS's platform.
Why This Model Matters for Compliance and Risk
Compliance frameworks like SOC 2, PCI DSS, and HIPAA don't disappear just because you moved to the cloud — and the Shared Responsibility Model determines who proves what during an audit.
AWS maintains its own certifications covering the infrastructure it controls, and publishes audit reports you can reference. But "AWS is certified" does not mean your workload is certified. Auditors still need evidence that your configurations, access controls, and data handling meet the standard in question.
- Physical and infrastructure controls: covered by AWS's own compliance programs and audit reports.
- Application-layer and data controls: your responsibility to design, document, and prove during an assessment.
- Access governance: auditors will ask how you manage permissions, which ties directly into practices like the zero trust security model where trust is never assumed based on network location alone.
Treating AWS's certifications as a substitute for your own compliance work is one of the most common — and costly — assumptions enterprises make when moving workloads to the cloud.
Applying the Model: A Practical Checklist
Knowing the theory is one thing; verifying you're actually covering your half is another. Use this as a working checklist.
- Review IAM policies regularly: look for overly broad permissions, unused credentials, and roles that grant more access than the task requires.
- Enable encryption everywhere it's offered: turn on encryption at rest and in transit for storage, databases, and backups rather than relying on defaults.
- Audit security groups and network ACLs: confirm that only the necessary ports and sources are open, and remove rules left over from testing.
- Use AWS Config to track configuration drift: set rules that flag resources falling out of compliance with your security baseline.
- Run Trusted Advisor checks: let AWS's built-in tooling flag publicly exposed resources, unused access keys, and other common misconfigurations.
- Document your side of the line: keep records of your configurations and controls so you're not scrambling when an audit or incident review happens.
None of these steps require AWS to change anything on its end — they're all actions that live entirely within the customer's half of the model.
Common Misconceptions
A few assumptions about this model persist even among experienced teams, and they tend to cause real damage when left unchecked.
- "AWS secures everything": this is the single most expensive misconception in cloud security. AWS secures the infrastructure; you secure what you put on it.
- "The cloud is inherently insecure": cloud infrastructure is often more rigorously secured than on-premises data centers — the risk usually comes from customer-side misconfiguration, not AWS's platform.
- "The cloud is inherently secure, full stop": the opposite assumption is just as dangerous. A secure platform doesn't protect you from a public S3 bucket or a sloppy IAM policy.
- "The split is the same for every service": as covered earlier, the line moves depending on whether you're using EC2, a managed service, or a serverless offering. Assuming a single fixed boundary leads to gaps.
This same of-platform-versus-in-platform tension shows up outside AWS too — it's worth comparing how multi-cloud provider comparison frameworks define responsibility across Azure and Google Cloud, since the boundaries aren't identical everywhere. For anyone preparing for the Cloud Practitioner exam, this model tends to show up repeatedly across question formats, which is part of why it gets dedicated coverage in the the AWS Cloud Practitioner Course programme.
Finally, remember that understanding the boundary is different from testing it. Teams serious about validating their half of the model often bring in ethical hacking practices to confirm that configurations hold up under real attack conditions, not just on paper.
- AWS secures the infrastructure 'of' the cloud; you secure what you build and configure 'in' the cloud.
- The exact split shifts depending on the service — IaaS (EC2) puts more on you, managed/serverless services (RDS, Lambda) put more on AWS.
- Most real-world cloud breaches trace back to customer misconfiguration, not AWS infrastructure failure.
- AWS's compliance certifications cover their side only — your workload must be independently configured and verified to meet the same standards.
- On the Cloud Practitioner exam, know the 'security of the cloud vs security in the cloud' phrasing exactly as AWS states it.
Glossary
- Shared Responsibility Model: AWS's framework dividing security duties between AWS (infrastructure) and the customer (data, access, configuration).
- IaaS (Infrastructure as a Service): A cloud model like EC2 where AWS manages hardware and virtualization but you manage the OS and above.
- IAM (Identity and Access Management): AWS's service for controlling who can access which resources and what actions they can perform.
- Security Group: A virtual firewall attached to AWS resources that controls inbound and outbound traffic rules.
- Data Encryption: Protecting data at rest and in transit, typically a customer-managed responsibility even on managed AWS services.
- Compliance Certification: Formal validation (e.g., SOC 2, PCI DSS, HIPAA) that infrastructure or a workload meets a defined security standard.
Learning AWS Cloud Practitioner Course: from concept to capability
Understanding the concept is the start. Being able to apply it is a separate skill, and it follows a fairly consistent path — this is the arc a structured programme takes you through.
The typical learning arc
- *{position:relative;z-index:1} .ci-header{display:flex;align-items:flex-start;justify-cont
- AWS Cloud Concepts
- AWS Global Infrastructure
- Compute and Networking Services
- Storage and Database Services
- Security and Compliance
- Monitoring and Management
- Pricing Billing and Support
The concrete skills it builds
*{position:relative;z-index:1} .ci-header{display:flex;align-items:flex-start;justify-cont · AWS Cloud Concepts · AWS Global Infrastructure · Compute and Networking Services · Storage and Database Services · Security and Compliance · Monitoring and Management · Pricing Billing and Support
Want a structured, instructor-led path through all of this — with hands-on projects and real feedback? → AWS Cloud Practitioner Course
Frequently asked questions
What exactly does AWS secure versus what do I secure?
AWS secures the physical infrastructure: data centers, hardware, networking, and the virtualization layer that runs their services. You secure everything you put into that infrastructure — your data, applications, operating system patches (on EC2), identity and access management, and network configuration like security groups.
Does the shared responsibility model change for serverless services like Lambda?
Yes. With serverless and managed services, AWS takes on more of the operational burden — patching the OS, managing the runtime, handling scaling — but you still own your code, your data, your IAM permissions, and how you configure triggers and access policies.
If my S3 bucket is publicly exposed and leaks data, is that AWS's fault?
No. Bucket permissions and access policies are entirely the customer's responsibility. AWS provides the tools (bucket policies, Block Public Access settings) but doesn't configure them for you, so a misconfigured bucket is a customer-side failure.
Does AWS's compliance certification cover my application automatically?
No. AWS's infrastructure holds certifications like SOC 2, PCI DSS, and ISO 27001, which cover the parts they manage. Your application and data must be independently configured and audited to meet those same standards — inheriting AWS's certification doesn't make your workload compliant.
Is the split the same for EC2 and RDS?
No. On EC2 (IaaS), you manage the OS, patching, and firewall rules yourself. On RDS (a managed service), AWS handles OS patching and database engine maintenance, leaving you responsible mainly for data, access credentials, and network access rules.
What happens if a team doesn't understand their side of the model?
This is the single biggest driver of cloud security incidents — not AWS outages, but customer misconfiguration like open ports, exposed storage, or over-permissioned IAM roles. Understanding the boundary is foundational to designing and auditing any AWS workload safely.
Ready to build this capability?
Browse our upcoming batches — live, instructor-led, delivered on Orbit.