Free lesson · AWS Fundamentals

The shared responsibility model

Easy6 min read

The Model In One Line

AWS is responsible for the security of the cloud. You are responsible for security in the cloud.

AWS operates and secures the physical facilities, the hardware, the hypervisor, the managed service software, and the global network. You secure everything you put on top of it: your data, your identity configuration, your network rules, your operating systems where you have one, and your application code.

The line sounds clean. In practice, the line moves depending on which service you use, and almost every real-world AWS security incident happens because someone assumed the line was somewhere it was not.

Where The Line Sits

graph TD
    subgraph Customer["CUSTOMER - Security IN the Cloud"]
        C1[Your data and its classification]
        C2[IAM: users, roles, policies]
        C3[Network config: SGs, NACLs, routing]
        C4[Encryption choices and key management]
        C5[OS, patching, runtime - IaaS only]
        C6[Application code and dependencies]
    end
    subgraph AWS["AWS - Security OF the Cloud"]
        A1[Physical data centers]
        A2[Hardware and host infrastructure]
        A3[Hypervisor and host OS]
        A4[Managed service software and patching]
        A5[Global network backbone]
    end
    Customer --> AWS

This diagram shows two stacked responsibility areas. The upper area is the customer's responsibility, security in the cloud, covering data and its classification, IAM users roles and policies, network configuration such as security groups and network ACLs, encryption choices and key management, operating system and patching for infrastructure services only, and application code and dependencies. The lower area is AWS's responsibility, security of the cloud, covering physical data centers, hardware and host infrastructure, the hypervisor and host operating system, managed service software and patching, and the global network backbone. The customer layer sits on top of and depends on the AWS layer.

The Line Moves By Service Type

This is the part that matters and the part most summaries skip. Compare the same responsibility across four services:

Read the columns left to right and one pattern emerges: as you move toward more managed services, AWS absorbs more of the operational security burden - but the four bottom rows never move. Identity, network exposure, encryption decisions, and data governance are yours on every service AWS sells. There is no such thing as a serverless architecture where IAM is somebody else's problem.

Important: The rows that never move are the rows that cause breaches. Public S3 buckets, over-permissive IAM roles, databases in public subnets, and unencrypted data are all 100% customer-side, on every service tier, regardless of how managed the service is.

Inherited, Shared, And Customer-Specific Controls

AWS describes three categories of control, and the vocabulary is worth knowing because it appears verbatim in certification exams and in audit conversations.

Inherited controls - you get them entirely from AWS and do nothing. Physical access control, environmental controls, hardware decommissioning and media destruction.

Shared controls - both parties do a version of the same thing at different layers:

• Patch management: AWS patches the infrastructure and managed services; you patch your guest OS and application dependencies.
• Configuration management: AWS configures its infrastructure; you configure your resources.
• Awareness and training: AWS trains its employees; you train yours.

Customer-specific controls - entirely yours, determined by your data and regulatory context. Data classification, zone security, application-level authorisation, and any sector-specific control your regulator requires.

Tip: AWS Artifact is where you download AWS's audit reports - SOC 1/2/3, ISO certifications, PCI attestations. When an auditor asks you to demonstrate the inherited controls, this is the answer. Knowing this exists saves a week of the wrong kind of conversation. It covers the AWS side only; you still have to evidence your own.

Common Failure Modes

Warning: "It's managed, so it's secure." RDS being a managed service means AWS patches the engine. It does not mean your RDS instance is not reachable from the internet with a weak password. Managed removes operational toil, not architectural responsibility.

"S3 encrypts by default, so we're compliant." Server-side encryption protects data at rest against physical media compromise. It does nothing against an over-permissive bucket policy - the request is authorised, so the data is decrypted and served. Encryption and access control solve different problems.

Base image assumptions. An AMI or container base image you pulled six months ago carries six months of unpatched CVEs. AWS patches the hypervisor beneath it and nothing inside it.

Third-party software on managed services. A vulnerable library in your Lambda deployment package is entirely yours. Lambda being serverless does not scan your dependencies.

Assuming AWS backs up your data. Durability is not backup. S3 durability protects against hardware failure; it does not protect against you deleting the objects or an application bug overwriting them. Versioning, Object Lock, and AWS Backup are things you must turn on.

How To Use The Model In Practice

Treat it as a design-time checklist rather than a compliance poster. For every service in an architecture, answer six questions:

1. Who patches the thing that runs my code?
2. What is the network exposure, and who configured it?
3. Where does the data sit, is it encrypted, and who holds the key?
4. Which IAM principals can reach this, and how did I verify that?
5. What is the backup and recovery story, and did I enable it?
6. What logs exist proving all of the above, and where do they go?

Anything you answer with "AWS, probably" is a gap in your understanding, not a gap in your risk.

Why This Matters In An Interview

Interview: What interviewers are listening for:

• You can articulate that the boundary shifts by service model rather than reciting "security of vs security in" as a slogan.
• You correctly assign responsibility in a scenario - especially the trap cases where a managed service still leaves the risk with you.
• You separate encryption from access control cleanly. Conflating them is a common and visible mistake.

This appears in every AWS certification, from Cloud Practitioner through Security Specialty, usually as a scenario: "A company's data was exposed because X. Who is responsible?" The answer is the customer far more often than candidates expect.

Common follow-ups:

• "An EC2 instance was compromised through an unpatched kernel vulnerability. Whose responsibility?" → Customer. Guest OS patching is customer-side on EC2. Then discuss Systems Manager Patch Manager as the mitigation.
• "Does moving from EC2 to Lambda reduce your security responsibility?" → It reduces the operational surface - no OS, no patching, no runtime management. It does not reduce IAM, data, or code responsibility, and it introduces new concerns around function permissions and event source configuration.
• "How do you prove to an auditor that the physical controls are adequate?" → AWS Artifact for the AWS-side attestations, plus your own evidence for the customer-side controls.

Practice

Exercise: Starter. Pick three services you use and write down, for each, who patches the software your workload depends on.

Intermediate. Take the six questions above and run them against a real architecture - yours or a public reference architecture. Write the answer for every component. Count how many you had to look up.

Advanced. Write a one-page responsibility matrix for a workload spanning EC2, RDS, S3, and Lambda, suitable for handing to an auditor. For each row, state the control, who owns it, and what artifact evidences it. The exercise is finding the rows where you have no evidence.

Related Topics

• Module 02 - Identity: IAM policy evaluation logic, permission boundaries
• Module 10 - Security & Governance: encryption patterns, GuardDuty, compliance programs and Artifact
• Module 05 - Storage: S3 access control and Block Public Access

Back to AWS Fundamentals