The Shared Responsibility Model

Who secures what: AWS secures the cloud itself, you secure what you put in it.

What is it?

Security in AWS is a split. AWS is responsible for *security of* the cloud: the physical data centers, hardware, networking, and the virtualization layer. You are responsible for security in the cloud**: your data, identities, permissions, operating systems you manage, application code, and network configuration.

The line moves with the service type:

  • Infrastructure services (EC2): AWS secures the host and hypervisor; you patch the guest OS, configure the firewall, and protect the application and data.
  • Container services (RDS, ECS-managed pieces): AWS also handles the OS and database platform patching; you manage database settings, access, and data.
  • Abstracted / serverless services (S3, DynamoDB, Lambda): AWS runs even more of the stack; you mostly manage data, IAM permissions, and encryption choices.

Some responsibilities are shared, like patch management (AWS patches the infrastructure, you patch your guest OS and apps), configuration management, and awareness/training.

Explain like I'm 10

Renting an apartment: the landlord is responsible for the building's structure, the roof, and the main door lock. You are responsible for locking your own apartment door, who you give keys to, and what you leave on the table. If the landlord keeps the building safe but you leave your door wide open, a theft is on you.

Examples

Who handles what

Task                                   EC2      RDS      S3
-------------------------------------  -------  -------  -------
Physical data center security          AWS      AWS      AWS
Hypervisor / host patching             AWS      AWS      AWS
Guest operating system patching        YOU      AWS      AWS
Database engine patching               YOU      AWS      n/a
Network firewall rules (SG)            YOU      YOU      n/a
IAM users, roles, permissions          YOU      YOU      YOU
Data classification and encryption     YOU      YOU      YOU
Bucket public-access settings          n/a      n/a      YOU

Customer-side check: is this bucket blocking public access?

aws s3api get-public-access-block --bucket zykit-demo-bucket-12345
aws s3api put-public-access-block --bucket zykit-demo-bucket-12345 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

AWS provides the control; turning it on is the customer's job.

How it works

Think in layers: physical, hardware, hypervisor, operating system, platform, application, data, and identity. For each service, ask 'does AWS operate this layer or do I?'. The more managed the service, the more layers AWS owns - but your data and your access decisions are always yours.

AWS provides tools to meet your side: IAM, encryption, security groups, logging, and compliance reports in AWS Artifact.

  +----------------------------------------------+
  |  CUSTOMER: security IN the cloud             |
  |  data | identities | OS/apps | network config|
  +----------------------------------------------+
  |  AWS: security OF the cloud                  |
  |  hypervisor | hardware | network | facilities|
  +----------------------------------------------+

Why does it exist?

Without a clear split, either side could assume the other handled something - and gaps are where breaches live. Spelling out the boundary helps auditors, security teams, and engineers know what to verify.

When to use it

Use the model whenever you pick a service, write a security policy, or answer a compliance questionnaire: it tells you what you must configure and what you can inherit from AWS.

When not to use it

It is not a legal contract for a specific incident and it does not replace reading the service's own documentation; edge cases depend on the service.

Common mistakes

  • Assuming AWS patches your EC2 guest OS.

  • Assuming a managed service means you can ignore access control.

  • Leaving a storage bucket public and blaming the provider.

  • Believing compliance certifications of AWS automatically make your application compliant.

  • Forgetting that responsibilities shift per service.

Practice exercises

  1. Easy:

    Sort these into AWS vs customer: hypervisor patching, IAM policies, data center guards, application code, hardware disposal.

  2. Medium:

    Compare the customer's responsibilities for EC2 versus Lambda versus S3. What shrinks and what never changes?

  3. Medium:

    Write a short checklist of five customer-side security tasks for a new RDS database.

  4. Hard:

    A pen test finds an outdated library in an application on Elastic Beanstalk. Whose responsibility is it and why?

Interview questions

Explain the shared responsibility model.

AWS secures the infrastructure that runs its services (security of the cloud); the customer secures what they build and store on it - data, identities, configuration, and guest OS (security in the cloud).

Who patches the guest OS of an EC2 instance?

The customer.

Who is responsible for the physical security of data centers?

AWS.

Exam-style: Which is a customer responsibility? (A) Hypervisor patches (B) Data center cooling (C) Security group configuration (D) Hardware replacement

C.

Exam-style: What is an example of a shared control?

Patch management: AWS patches the infrastructure, customers patch their guest operating systems and applications.