AWS Shared Responsibility Model: Security OF the Cloud vs IN the Cloud

When you run workloads on AWS, security and compliance become a partnership. AWS operates the global infrastructure — the buildings, servers, cables, and virtualization software — and you operate whatever you build on top of it. The AWS shared responsibility model is the formal statement of where that dividing line sits. AWS summarizes it in six words you should memorize: AWS is responsible for security OF the cloud, and the customer is responsible for security IN the cloud.

Why does AWS publish this model at all? Because moving to the cloud does not outsource security — it redistributes it. AWS takes over the heavy operational burdens that every on-premises team used to carry themselves: physical data center security, hardware lifecycle, host operating systems, and the hypervisor layer. That relief lets you concentrate your effort on the parts only you can control — your data, who can access it, and how your resources are configured. If you assume "AWS handles security" and stop there, you leave your side of the model wide open; misconfigured customer resources, not AWS infrastructure failures, cause the vast majority of real-world cloud security incidents.

The model has three components you must recognize on the exam: AWS responsibilities (security of the cloud), customer responsibilities (security in the cloud), and shared responsibilities — controls where both parties do their part, such as patch management and awareness training. Crucially, the boundary between AWS and customer responsibilities is not fixed. It shifts depending on the service you use: the more managed the service, the more AWS takes on. That shift — EC2 versus RDS versus Lambda — is the exam's favorite way to test whether you truly understand the model rather than having memorized a single diagram.

AWS is responsible for protecting the infrastructure that runs every AWS service. This infrastructure spans four layers you should be able to list: physical facilities, hardware, networking, and virtualization software.

• Physical security of data centers. Guards, fencing, badge access, surveillance, and environmental controls at every facility. Customers can never visit an AWS data center or touch the hardware — physical security is entirely, permanently AWS's job.
• Hardware and infrastructure. Procuring, installing, maintaining, and securely decommissioning servers, storage devices, and other equipment. When a disk that held your data is retired, AWS destroys it according to its media-disposal process.
• Global network infrastructure. The Regions, Availability Zones, and edge locations, plus the cabling and network hardware connecting them, including protections against infrastructure-level threats.
• Virtualization and host software. The hypervisor that isolates one customer's EC2 instances from another's, and the host operating systems on the physical machines. You never patch a hypervisor on AWS — that is always AWS's responsibility.

For managed services, AWS's responsibility extends upward into the software layer. With Amazon RDS, DynamoDB, or Lambda, AWS also handles the guest operating system, platform patching, and the service software itself. That is exactly why the responsibility line moves per service: "security of the cloud" covers everything AWS operates for you, and managed services mean AWS operates more.

A reliable exam heuristic: if the task requires physical access to hardware, access to the host OS or hypervisor, or maintenance of the software that powers a managed service, the answer is AWS. AWS demonstrates that it meets these obligations through third-party audits and compliance reports — the mechanics of those programs belong to a separate task (2.2), so for this topic just know that AWS proves its side of the model to auditors so customers can inherit those controls.

Everything you create, upload, configure, or grant access to inside AWS is yours to secure. The customer's side of the model — "security in the cloud" — centers on five areas:

• Customer data. You own your data and you are responsible for protecting it: classifying it, deciding where it lives, controlling who can read it, and choosing whether and how to encrypt it. This never changes, on any service, ever. If an exam question asks who is responsible for the customer's data, the answer is the customer — even on the most fully managed service AWS offers.
• Identity and access management. Creating users and roles, assigning permissions, enforcing least privilege, enabling multi-factor authentication, and rotating credentials. AWS provides IAM as a tool, but every permission granted with it is your decision and your responsibility. (What IAM can do is its own task statement, 2.3 — here you only need to know that managing access is customer work.)
• Guest operating systems. On Amazon EC2, you control the instance's operating system, so you must patch it, apply security updates, and manage administrative access to it.
• Network and firewall configuration. Security group rules, network ACLs, subnet design, and routing. AWS supplies the virtual networking; you decide what traffic it permits. A security group that allows unrestricted inbound access is a customer mistake, not an AWS one.
• Encryption choices. Enabling server-side encryption, performing client-side encryption before upload, protecting data in transit with TLS, and managing keys. AWS builds the encryption capabilities; turning them on is up to you.

The unifying idea: AWS cannot see your intent. It cannot know which S3 bucket should be public, which user deserves administrator access, or which data is sensitive. Anything that depends on your decisions is, by definition, security in the cloud — and it belongs to you.

Not every control lands cleanly on one side. AWS classifies controls into three categories, and CLF-C02 expects you to recognize all three.

Inherited controls

Controls you fully inherit from AWS because AWS operates them end to end. Physical security and environmental controls are the classic examples: AWS implements them, auditors verify them, and you simply build on top of the verified foundation. You never perform these controls yourself.

Shared controls

Controls where both AWS and the customer act — each in their own layer. AWS names three you should memorize:

• Patch management. AWS patches the physical infrastructure, host operating systems, and managed-service software. You patch the guest operating systems on your EC2 instances and the applications you install. Same control, two layers, two owners.
• Configuration management. AWS configures its infrastructure devices and host systems. You configure your own resources — instances, databases, buckets, security groups, and applications.
• Awareness and training. AWS trains AWS employees on security. You train your own staff. AWS cannot stop your administrator from falling for a phishing email.

Customer-specific controls

Controls that exist solely on your side of the line because they depend entirely on what you deploy: routing your traffic through specific zones, protecting the content of your data, or applying your organization's data-classification policy. AWS has no equivalent activity to perform.

Exam questions often test the shared category with wording like "Which control is a shared responsibility between AWS and the customer?" If you see patch management, configuration management, or awareness and training among the options, that is almost certainly the answer — the trap options will be purely AWS controls (hypervisor patching, data center security) or purely customer controls (IAM permissions, data classification) dressed up to look shared.

The model's most-tested nuance is that the dividing line moves with the service's management level. Think of it as a slider: with infrastructure services like EC2 you manage the most; with abstracted services like Lambda and S3 you manage the least. What you keep in every case is your data, your access decisions, and your service-level configuration.

Read the table by columns and the pattern jumps out. On EC2, AWS stops at the hypervisor: you patch the guest OS, install software, and configure the firewall. On RDS, AWS climbs higher — it patches the operating system and the database engine, while you keep the data, the schema, access controls, and settings such as backups and encryption. On Lambda, AWS manages everything up through the runtime; your responsibility shrinks to your function code, its permissions, and your data. On S3, there is no server for you at all — you manage bucket access configuration, encryption choices, and the objects themselves.

Read it by rows and you see the second pattern: the bottom three rows — data, encryption choices, and IAM — say Customer in every column, and the top row says AWS in every column. Some responsibilities shift; those never do.

Before the exam, be able to reproduce this three-bucket list from memory. It resolves the majority of shared-responsibility questions in seconds.

Always AWS (security OF the cloud)

• Physical security of data centers, guards, and environmental controls
• Hardware: servers, storage, and secure disposal of retired media
• The global infrastructure: Regions, Availability Zones, and edge locations
• The hypervisor and host operating systems
• Maintaining and patching the software of managed services (the RDS database engine, the Lambda runtime, the S3 service itself)

Always the customer (security IN the cloud)

• Customer data — its classification, protection, and encryption, on every service without exception
• IAM: users, roles, permissions, MFA, and credential management
• Choosing whether to encrypt, and managing client-side encryption and keys where you use them
• Security group and network ACL configuration, and service-level settings such as S3 Block Public Access
• Guest OS patching and application software on EC2

Shared (both act, in their own layer)

• Patch management — AWS patches infrastructure and managed platforms; you patch guest OSs and applications
• Configuration management — AWS configures its infrastructure; you configure your resources
• Awareness and training — AWS trains its people; you train yours

Two anchors are worth repeating because the exam leans on them constantly. First: your data is always your responsibility — no AWS service, however managed, takes ownership of protecting your data's contents or deciding who may access it. Second: physical infrastructure is always AWS's responsibility — no customer action can ever move it. Any answer option that contradicts either anchor is wrong, no matter how plausible the rest of it sounds.

A retail company runs an inventory application and is deciding how to host its PostgreSQL database. Walk through what its team owns in each option — this is exactly the kind of comparison CLF-C02 turns into questions.

Option 1: PostgreSQL on an EC2 instance. AWS secures the facility, the hardware, the network, and the hypervisor beneath the instance. The team must patch the Linux guest OS, patch PostgreSQL itself, configure the security group so only the application tier can reach port 5432, set up backups, enable encryption, and manage IAM access. Maximum control, maximum responsibility.

Option 2: Amazon RDS for PostgreSQL. The line moves up. AWS now also patches the operating system and the PostgreSQL engine and operates the backup machinery. The team still owns the data itself, the database credentials and IAM permissions, the security group rules, and the decisions to enable encryption at rest and automated backups. Notice what did not move: if an engineer sets the database to be publicly accessible with a weak password, the resulting breach is squarely the customer's responsibility — RDS being "managed" never made the data or its access rules AWS's problem.

Option 3: A serverless rewrite with Lambda and DynamoDB. The line moves up again. There is no OS, runtime, or database engine for the team to patch — AWS manages all of it. The team's remaining responsibilities are the function code, the IAM execution roles and table permissions, the table's encryption settings, and, always, the data.

The pattern to internalize: moving from EC2 to RDS to serverless steadily transfers operational security work to AWS — patching, platform maintenance, infrastructure configuration — while the team's ownership of data, access, and configuration choices stays exactly where it started. If a question describes a company "migrating from EC2 to RDS" and asks what responsibility transfers to AWS, the answer is OS and database-engine patching — never the data, never IAM.

Shared-responsibility questions are recognition items — quick if you know the model, easy to fumble if you rush. These are the traps CLF-C02 sets most often.

Trap 1: the OF/IN swap. Questions quote the model's own vocabulary: "Which task is an example of security of the cloud?" Keep the mapping mechanical — OF = AWS = infrastructure; IN = customer = what you put there. Distractors bank on you inverting it under time pressure.

Trap 2: the service-shift trap. "Who is responsible for patching the operating system?" has different answers by service: the customer on EC2, AWS on RDS and Lambda. Always check which service the stem names before answering a patching question. If no service is named and options mention the hypervisor or host OS, those layers are AWS's regardless.

Trap 3: "managed" does not mean "AWS owns everything." Distractors claim AWS is responsible for data stored in S3, or for IAM permissions on a managed database. Both are always the customer's. Similarly, configuring security groups is the customer's job even though AWS provides the security group feature.

Trap 4: misfiled shared controls. When asked for a shared responsibility, the correct option is patch management, configuration management, or awareness and training. Options like "physical security" (pure AWS) or "data classification" (pure customer) are bait.

A four-step routine for any responsibility question: (1) Identify the layer the task lives in — physical/hypervisor, OS/platform, or data/access/config. (2) Identify the service named, and how managed it is. (3) Apply the anchors — data, IAM, and encryption choices are always customer; facilities, hardware, and hypervisor are always AWS. (4) If both parties genuinely act at different layers, it is shared. That routine answers virtually every Task 2.1 item on the exam.