The Shared Responsibility Model in Plain English

Carlos misconfigured an S3 bucket. Customer records — names, emails, partial card numbers — were publicly readable for nine days. When the breach went public, his CTO sent one email to AWS support: "How did you let this happen?"

AWS's response, in essence: we did not. You did.

The shared responsibility model is the contract that explains why. It is also one of the most-tested concepts on the Developer Associate exam, because misunderstanding it is how real-world breaches happen.

Security Of the Cloud vs Security In the Cloud

The split is exactly this:

• AWS is responsible for security OF the cloud — the physical data centers, the hardware, the networking backbone, the hypervisor;
• You are responsible for security IN the cloud — your data, your IAM policies, your network configuration, your application code, your encryption choices. AWS makes sure the building does not burn down. You make sure you lock the door of your apartment.

Where the Line Moves

The exact split shifts depending on the service:

• For EC2 (a virtual machine), AWS handles the host, you handle the OS, patching, firewall rules, and everything you install;
• For Amazon RDS, AWS handles the OS and database engine patching, you handle schema, queries, and access control;
• For Lambda, AWS handles the OS, runtime, and scaling, you handle the function code and permissions;
• For DynamoDB and S3, AWS handles almost everything below the data — you handle data, access policies, and encryption choices. The more managed the service, the smaller your slice. But your slice never disappears — there is always something you own.

What You Always Own

No matter which AWS service you use, four things are always yours:

• Your data — what gets stored, how long, who can read it;
• IAM policies and credentials — who can do what in your account;
• Application-level security — your code, your dependencies, your input validation;
• Encryption choices — whether to enable encryption at rest, whether to use customer-managed keys. Carlos owned all four of these for the bucket he misconfigured. AWS provided the encryption options, the access controls, the public-access blocks. He just did not turn them on.

Exam Trap to Watch For

A classic exam question goes: "Who is responsible for patching the underlying OS of an Amazon RDS instance?" The intuitive but wrong answer is "the customer." The correct answer is AWS — RDS is a managed service.

Memorize the pattern:

• Self-managed compute (EC2) → you patch;
• Managed services (RDS, Lambda, DynamoDB, S3) → AWS patches;
• Network configuration (security groups, NACLs, route tables) → always you;
• Identity and access (IAM) → always you.

Why This Matters Beyond the Exam

When something goes wrong in your AWS account, the first question is "which side of the line was this on?" If it was AWS's side, support handles it. If it was yours, no amount of escalation changes that. Carlos learned that the slow way.