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: a publicly readable bucket or an over-permissive role is a customer-side failure, however well secured the infrastructure underneath it is.

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 a common 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. The whole hardware lifecycle: procuring, installing, maintaining, replacing failed servers and components, and securely decommissioning storage devices and other equipment. When a disk that held your data is retired, AWS destroys it according to its media-disposal process. That covers AWS's physical media, not your logical copies: snapshots, backups and read replicas you created are your resources, and deleting the ones you no longer need is your job. This holds even on an EC2 Dedicated Host: the physical server is dedicated to one customer, but it is still AWS hardware, so AWS maintains and replaces it.
• Durability of the infrastructure. Building storage services so that data survives hardware failure is AWS's job — Amazon S3, for example, is designed to store objects redundantly so that a failed disk or device does not lose them. That protects your data from AWS hardware failing; it does not protect it from your own users deleting it (see the customer's side).
• 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, on every tenancy option: shared instances, Dedicated Instances, and Dedicated Hosts. Dedicated tenancy changes who else runs on the hardware, not who operates it; a Dedicated Host shows you its sockets and cores for licensing, but gives you no access to its hypervisor or host operating system. (EC2 bare metal instances run without a hypervisor, but the underlying Nitro hardware and firmware remain AWS's.)

For managed services, AWS's responsibility extends upward into the software layer. With Amazon RDS, DynamoDB, or Lambda, AWS also handles the underlying operating system, platform patching, the service software itself, and — for serverless services such as Lambda — the platform's capacity and scaling. 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. Because you cannot inspect AWS's layer yourself, AWS evidences it through independent third-party audits — reports such as SOC 2, which customers download from AWS Artifact. Because the hypervisor and the data centers are outside your reach, evidence about those layers can only come from AWS's third-party reports, never from your own testing. The compliance programs themselves belong to a separate task (2.2); for this topic, know that AWS proves its side of the model so that 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. Even on the most fully managed service AWS offers, the customer's data remains the customer's responsibility. That includes protecting it from your own mistakes: AWS's durability guards against failed hardware, but if a user with delete permission removes an S3 object, recovering it depends on settings you chose — S3 Versioning, backups, and least-privilege permissions that keep delete rights to the few who need them. Deciding where it lives is literal: your content stays in the AWS Region you choose. AWS spreads it across Availability Zones within that Region for durability (S3 Standard, for example, stores data across at least three AZs), but it does not move or copy your content to another Region unless you agree to it. Any copy outside the Region — S3 Cross-Region Replication, a snapshot or backup copied to another Region — exists only because you configured it, and you answer for where that copy sits.
• 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. This includes the roles your own workloads use: the execution role a Lambda function assumes, and which policies (AWS managed or customer managed) are attached to it, is your design even on a fully serverless stack. Compare a service-linked role, which an AWS service creates for itself with permissions AWS predefines and you cannot edit. (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 and installed software. On Amazon EC2, you control the instance's operating system and everything you install on it (a web server, a database, agents), so you must patch it, apply security updates, and manage administrative access to it. Using an AWS-provided AMI or an AWS tool such as AWS Systems Manager Patch Manager does not change this: Patch Manager automates the work, but which patches are approved and when they run are still your settings, and the outcome is still your responsibility.
• 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. Choosing server-side or client-side encryption, choosing and managing keys, and protecting data in transit. AWS builds the encryption capabilities — and the decisions about using them are yours (details below).

Secure defaults do not move the decision

Some AWS services now encrypt by default: Amazon S3 has applied server-side encryption with S3 managed keys (SSE-S3) to every new object since January 2023, and Amazon DynamoDB encrypts every table at rest. A default is a starting point, not a transfer of responsibility — you still decide whether it meets your requirements. SSE-KMS with a customer managed key in AWS KMS goes further than the default: you control the key through its key policy, and every use of the key is logged in AWS CloudTrail. Other services leave even the default to you: an Amazon EBS volume is encrypted only if you create it encrypted (or from an encrypted snapshot) or turn on EBS encryption by default for your account in that Region.

Note the boundary between rows: encrypting an EBS volume protects data at rest on that volume — it does nothing for data your application sends over the internet, which needs TLS. Features such as S3 Versioning protect earlier versions of objects; they do not control or record key use.

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, and you evidence them with AWS's independent audit reports (such as SOC 2). Those reports cover AWS's side only. Using an audited service does not make your workload compliant: your shared and customer-specific controls — access, encryption, data handling — still need your own evidence.

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 — the guest OS on your EC2 instances, the DB parameter groups and settings of your RDS 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.

To classify a control, ask who performs it. Only AWS performs it: inherited. Both perform it, each in its own layer: shared — and the three named shared controls are patch management, configuration management, and awareness and training. Only you perform it: customer-specific. Hypervisor patching and data center security are AWS-only (inherited); IAM permissions and data classification are customer-only. These three names are the model's whole vocabulary: terms such as "compensating control" or "detective control" are general audit language for what a control does, not categories of the shared responsibility model.

The model's key 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. Access on RDS has two layers, and both are yours: IAM policies decide who can perform management actions on the DB instance through the AWS API, and the database's own user accounts and privileges decide who can read and write the data. You do control when patches land: RDS applies them during the weekly maintenance window you set on the DB instance, and you choose whether minor engine versions upgrade automatically. RDS gives you no OS or SSH access to the host, which is exactly why OS patching cannot be yours. (Amazon RDS Custom is the deliberate exception: it gives you OS access and hands back a matching share of the responsibility.) On Lambda, AWS manages the servers, the execution environment's operating system (for functions deployed as .zip archives), capacity and scaling, and — when you use a managed runtime such as a supported Python or Node.js version — the security updates to that runtime. Two qualifiers matter. If you deploy a function as a container image, the runtime and the operating-system layers of the base image you package are yours to rebuild and update; if you use an OS-only runtime to bring your own language runtime, AWS still patches the underlying Amazon Linux OS but the runtime you package is yours. And on any runtime, third-party libraries you bundle with your code are yours to keep patched. Beyond that, your responsibility is your function code, its execution role and 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 lets you place most tasks quickly.

Always AWS (security OF the cloud)

• Physical security of data centers, guards, and environmental controls
• Hardware lifecycle: servers and storage, replacement of failed hardware (including Dedicated Hosts), and secure disposal of retired media
• Durability of the storage infrastructure against hardware failure
• The global infrastructure: Regions, Availability Zones, and edge locations
• The hypervisor and host operating systems, on every tenancy option
• Maintaining and patching the software of managed services (the RDS database engine, Lambda managed runtimes, the S3 service itself) and the capacity of serverless platforms

Always the customer (security IN the cloud)

• Customer data — its classification, protection, and encryption, on every service without exception — including protection against accidental deletion (versioning, backups, least privilege), which Region it lives in and any copy you replicate to another Region, and deleting the snapshots, backups and replicas you created
• IAM: users, roles (including the execution roles your functions assume), permissions, database user accounts inside managed engines such as RDS, MFA (including on the root user), and credential management
• Encryption choices: keys and settings at rest (even where a default exists), EBS encryption, and TLS for data in transit
• Security group and network ACL configuration, and service-level settings such as S3 Block Public Access
• Guest OS patching and application software on EC2 (even when automated with Patch Manager); runtimes you package and libraries you bundle on Lambda

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 (guest OS, DB parameter groups, buckets, security groups)
• Awareness and training — AWS trains its people; you train yours

Two anchors are worth repeating because so many questions rest on them. 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 — during the weekly maintenance window the team chooses — 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. With managed runtimes there is no OS, runtime, or database engine for the team to patch, and no capacity to plan — AWS manages all of it. The team's remaining responsibilities are the function code and the libraries it bundles, the IAM execution roles and table permissions, the choice of encryption key for the table (DynamoDB encrypts at rest regardless), 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. Moving a database from EC2 to RDS transfers OS and database-engine patching to AWS; the data and IAM do not move.

Shared-responsibility questions are recognition items — quick if you know the model, easy to fumble if you rush. These are common traps to watch for.

Trap 1: the OF/IN swap. Questions use the model's own vocabulary and ask you to sort a task into security of the cloud or security in 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. Responsibility for operating-system patching depends on the service: the customer on EC2, AWS on RDS and on Lambda functions deployed as .zip archives. Always check which service is named before deciding who patches. 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 3b: a default or a tool is not a transfer. S3's default encryption, an AWS-provided AMI, and Systems Manager Patch Manager all make the customer's job easier, but none moves it to AWS. The test is who makes the decision: if you choose the key, the baseline, the schedule, or the setting, the responsibility is yours. Likewise, a Dedicated Host or an AWS SOC 2 report changes nothing about who runs the hypervisor or who must evidence the customer's own controls.

Trap 4: misfiled shared controls. A shared control is one both parties perform in their own layer — patch management, configuration management, and awareness and training. "Physical security" is AWS-only (inherited) and "data classification" is customer-only (customer-specific), however they are phrased. Audit terms such as "compensating control" are not one of the model's categories.

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 works for most Task 2.1 questions.