3.3. Reflection Checkpoint: Security, Compliance, and Shared Responsibility

Key Takeaways

• The Shared Responsibility Model splits along a hard line: AWS secures "of" the cloud (physical infrastructure, host OS, hypervisor), while you secure "in" the cloud (your data, IAM configuration, guest OS patching, application code) — misunderstanding which side you're on is the single most common security failure mode.
• Security Groups (instance-level, stateful, allow-only) and Network ACLs (subnet-level, stateless, allow and deny) work together as layered defense — a Security Group alone can't compensate for an open NACL, and vice versa.
• Encryption at rest (KMS-backed) and encryption in transit (TLS/SSL via ACM) protect data at different points in its lifecycle — both are needed, neither substitutes for the other.
• IAM's Principle of Least Privilege and MFA are the practical mechanics of access control: users/groups/roles answer "who," policies answer "what they can do."
• AWS Artifact, Config, CloudTrail, and Organizations' Service Control Policies are the tools that turn "we're compliant" from a claim into something you can prove to an auditor.

Connecting Forward

With security and compliance responsibilities clear, Phase 4 moves to the financial side of running on AWS: how pricing actually works, the tools that keep spending visible, and the support plans available when something goes wrong.

Self-Check Questions

• Your company stores customer data in S3 and an auditor tells you "AWS is responsible for security." Where exactly does that responsibility end, and what remains yours to configure?
• A web server only needs to accept HTTPS traffic from the internet, and its database in a private subnet must never be reachable directly from the internet. Which combination of Security Groups and NACLs enforces this, and why does relying on just one of them leave a gap?