The Shared Responsibility Model

AWS describes this split as security "of" the cloud versus security "in" the cloud.

• AWS's responsibility ("of" the cloud): the physical data centres, the underlying hardware, the host virtualization layer, and the global network infrastructure that everything else runs on.
• The customer's responsibility ("in" the cloud): how you configure the services you use, who inside your organisation can access or change them, the data you put into them, and your own application code and its configuration.

1. Physical data centre security — deciding who can physically walk into a building and touch a server is entirely AWS's job. No customer, no matter what they use, manages this themselves.
2. IAM permissions inside a customer's account — deciding which employees can create, modify, or delete cloud resources is entirely the customer's job. AWS provides the IAM service itself, but doesn't decide an individual company's permission structure for it.
3. Data stored inside a customer's own database or storage service — the content itself, and choices like whether it's encrypted or who it's shared with, are the customer's responsibility, even though the storage service runs on infrastructure AWS operates.

It would be an oversimplification to say the split is always the same 50/50 line. The more AWS manages a service for you, the more of the day-to-day operational burden shifts to AWS. For example, a fully managed database service takes on patching the underlying database engine itself, while a more "raw" virtual server leaves the customer managing more of that software stack directly.

Think of it as a sliding scale rather than a fixed rule — later modules point out exactly where that line sits for each specific service as they're introduced.

None of this requires deep IAM knowledge yet — that's the whole subject of Module 2 — but a few principles apply from day one regardless:

• Protect the root user specifically (covered last lesson) and treat MFA on it as non-negotiable.
• Don't casually create or share access keys — they're credentials, not conveniences.
• Never commit AWS credentials of any kind into a Git repository, even a private one. A key committed to source control should be treated as compromised the moment it's pushed.
• Remember the Shared Responsibility Model itself: AWS securing its infrastructure doesn't protect you from a permission mistake or an exposed credential on your side of the line.