The AWS Shared Responsibility Model

Security in AWS is a partnership. AWS secures the cloud itself, while you, the customer, secure what you put in it. The Cloud Practitioner (CLF-C02) exam loves questions that ask "who is responsible for X?" — and the answer almost always comes down to one memorable split: AWS is responsible for security of the cloud, and the customer is responsible for security in the cloud. Master where that line falls and how it slides for managed services, and this domain becomes easy points.

Core Idea

• AWS secures the cloud; the customer secures what is in the cloud. AWS owns the physical and foundational layers; you own your data and configuration.
• The boundary shifts by service model. With raw infrastructure like EC2 you own more; with managed services like S3, RDS, and Lambda, AWS handles more of the stack.
• Some things are always yours. Data classification, identity and access management (IAM), and how you configure access never transfer to AWS, no matter the service.

What AWS Is Always Responsible For (Security "of" the Cloud)

AWS owns the foundation that customers cannot touch:

• Physical security of data centers — guards, fencing, biometric access, environmental controls.
• Hardware and global infrastructure — servers, storage, networking gear, Regions, Availability Zones, and edge locations.
• The virtualization layer — the hypervisor that isolates one customer's compute from another's.
• The managed software of AWS services — patching and maintaining the underlying software of the services AWS runs for you (for example, the database engine host in RDS).

If it is a wall, a wire, a chip, or the plumbing that makes a service exist, AWS owns its security.

What the Customer Is Always Responsible For (Security "in" the Cloud)

You own everything you bring to and configure in AWS:

• Your data — its content, classification, and where it lives.
• Identity and access management — creating IAM users, roles, groups, and policies, and enforcing least privilege and multi-factor authentication (MFA).
• Network and firewall configuration — security groups, network ACLs, and how you expose resources.
• Encryption choices — deciding what to encrypt at rest and in transit, and managing keys and settings.
• Application and platform configuration — how you set up and secure what you deploy.

How the Boundary Shifts for Managed Services

The line moves depending on how much of the stack AWS operates:

• EC2 (infrastructure, IaaS): You own the most. AWS provides the hardware and hypervisor, but you patch the guest operating system, configure security groups, manage applications, and secure your data. Guest OS patching is the classic "customer" answer for EC2.
• RDS (managed database, PaaS): AWS patches the OS and database engine and handles backups and failover. You still manage database users, network access, encryption settings, and the data itself.
• S3 (managed storage): AWS runs the storage infrastructure and guarantees durability. You control bucket policies, access permissions, and encryption — misconfigured public buckets are always the customer's fault.
• Lambda (serverless): AWS manages the OS, runtime, scaling, and servers entirely. You are responsible only for your function code, its IAM permissions, and your data.

The pattern: the more managed the service, the more AWS absorbs — but data and access management never leave you.

High-Yield Exam Patterns

• "Who patches the OS?" For EC2, the customer patches the guest OS. For managed services (RDS, Lambda), AWS patches the underlying OS.
• Data classification and access management are ALWAYS the customer's job — this is a frequently tested absolute.
• Physical security of data centers is ALWAYS AWS — no exceptions, and customers cannot audit facilities directly.
• "Security OF the cloud" = AWS; "security IN the cloud" = customer — memorize this phrasing; questions echo it.
• A misconfigured S3 bucket or overly permissive IAM policy is a customer failure, never AWS's.
• The more managed a service is, the less the customer must do — but never zero.

Common Traps to Avoid

• Thinking AWS manages your IAM users or data security because the service is "managed" — configuration always stays with you.
• Assuming AWS patches your EC2 guest operating system — that is your responsibility.
• Believing encryption happens automatically — you choose and configure it.
• Confusing physical infrastructure (AWS) with your logical/network configuration like security groups (customer).