AWS Shared Responsibility Model

The model has two sides

The AWS shared responsibility model explains how security and compliance work are divided between AWS and the customer. AWS describes its side as security of the cloud: AWS operates, manages, and controls components such as the host operating system, virtualization layer, and physical security of facilities. The customer side is security in the cloud and depends on the AWS services selected and how they are used.

For the AWS Certified Cloud Practitioner exam, this concept is a named task in the current CLF-C02 guide. The guide is intended to test broad AWS Cloud knowledge rather than one job role. It asks candidates to understand and explain the shared responsibility model and security best practices. This article teaches that distinction with an original scenario; it is not an AWS exam item or a prediction of a score.

The easiest way to reason about a question is to name the resource and the security control. “Who secures the cloud?” is too broad. Ask instead: who maintains the physical facilities? Who patches the guest operating system? Who controls which users can read an object? Who configures a firewall rule? The service and layer usually make the responsibility clearer.

Security of the cloud

AWS is responsible for the infrastructure it operates to provide AWS services. The AWS shared responsibility documentation identifies the host operating system, virtualization layer, and physical facilities among the components managed by AWS. This boundary is often summarized as security “of” the cloud.

That does not mean a customer must ignore the provider's controls. Customers may review AWS control and compliance documentation when evaluating controls and performing their own verification procedures. The documents can support a customer's assessment, but the customer still needs to understand which control applies to its environment and what evidence its own requirements call for.

Provider-managed infrastructure is a different layer from the customer's application and data. A secure data center does not decide which employees should access a customer's files. AWS operating a facility does not set every customer account's permissions. Keep the boundary at the component or control being discussed rather than treating “cloud security” as a single task.

Security in the cloud

Customers remain responsible for the choices and configurations they control. Depending on the service, this can include data, identities and permissions, application software, operating-system updates, network rules, encryption choices, and how services are connected to the rest of the environment. The AWS whitepaper specifically assigns customers responsibility for the guest operating system, including updates and patches, associated application software, and configuration of the AWS-provided security-group firewall in the described service context.

The customer must understand applicable laws and regulations for its use of the service. AWS notes that responsibility varies with the services deployed, their integration into the customer's IT environment, and applicable legal and regulatory requirements. A provider's certification or control report does not automatically establish that a customer's workload meets every obligation.

Data protection choices also belong in context. An organization should know what information it stores, who may use it, and what protections its requirements call for. AWS describes customer technology options such as host-based firewalls, host-based intrusion detection or prevention, encryption, and key management as ways to address security or compliance needs. These tools do not make every deployment compliant by themselves; their settings and use still matter.

Think of the customer side as a set of decisions: choose a service appropriate to the requirement, configure access, protect and classify data, operate the customer-managed components, monitor relevant activity, and verify that controls work. The exact task list depends on the service model. You should not assume every customer patches an underlying host or that AWS decides every application setting.

Service choice changes the work

With a service where the customer manages a guest operating system, the customer has more operating-system and application work. AWS manages the underlying infrastructure described in the model, while the customer handles its own guest system, patches, software, data, and configuration responsibilities. The specific service documentation controls the exact division.

With a more managed service, AWS performs more of the underlying operation. That can reduce the customer's operational burden, but it does not make the customer's data, users, access choices, or legal obligations disappear. The responsibility model follows the actual service and control. Read the question for what is being secured, and do not transfer a responsibility merely because a service is managed.

This is why “cloud means AWS handles security” is wrong, and “the customer manages every layer” is also wrong. Both statements erase the service boundary. The practical answer names the provider-managed layer and the customer-controlled setting that matters to the scenario.

Use the model with a concrete example

A small team runs a web application on an AWS compute service and stores customer files in cloud storage. A developer says the application is secure because the AWS data center is physically protected. Later, an object is found accessible to people who should not have it. How should the team reason about responsibility?

First separate facility security from access to the team's stored data. AWS's facility controls address the provider-operated physical environment. The team still needs to configure who can access its files and application, protect credentials, and decide how the data should be handled. The physical control does not determine the customer-facing permission setting.

Next identify the relevant service and setting. If the workload includes a customer-managed guest operating system, the team must account for its patches and application software. If it uses a security group, the configuration of that firewall is a customer responsibility in the AWS whitepaper's stated context. For the storage access issue, inspect the customer's permissions and how identities are granted access. The team should also consider whether its data handling matches applicable requirements.

Finally, assign an action to the owner of each control and verify the result. The provider's responsibilities and evidence can be reviewed for provider-managed controls. The customer should correct its own configuration, review access, and validate that the intended users can reach the data while unauthorized access is blocked. Keep incident response and any required notifications consistent with the organization's policies and applicable obligations.

This scenario is intentionally general. It does not prescribe a particular AWS architecture, permission policy, or incident procedure. Those choices require details about the actual service, data, threat, and applicable requirements.

A reliable exam reasoning method

When a question asks who is responsible, use four steps. First, identify the service or component. Second, identify the specific task: physical protection, infrastructure operation, guest operating system, application, firewall configuration, identity, or data. Third, determine whether that task belongs to AWS or the customer for the service described. Fourth, account for any integration or legal requirement stated in the question.

Watch for broad wording. If a question asks about a guest operating-system patch in a customer-managed compute environment, provider facility security is not the answer. If it asks about physical access to an AWS-operated data center, a customer's application team does not run that facility. If it asks about application permissions, first identify who configures those permissions rather than relying on the word “cloud.”

For a managed service, do not assume that AWS takes over every security decision. Ask which components the managed service operates and which customer settings remain. The precise split varies, and service documentation should be consulted for an actual implementation. In exam practice, use the service named in the prompt and the responsibility language in the active guide.

Control operation and verification are shared

The shared model also applies to IT controls. AWS may manage controls associated with physical infrastructure, while the customer evaluates and verifies controls relevant to its environment. AWS makes control and compliance documentation available to support customer evaluation. A customer should connect that evidence to its own control objective instead of treating a report as proof that every customer-side configuration is correct.

For example, a provider report may support an assessment of a provider-operated control. It cannot establish that a customer's access list is current or that its data classification is appropriate. The customer needs evidence for those customer-controlled choices. In a real audit or compliance review, define the requirement, identify the control owner, obtain evidence for each side of the boundary, and document any gap.

Common misconceptions

A common mistake is treating AWS certification as a substitute for customer control work. Provider documentation can help with assessment, but it does not configure customer identities or show that the customer's data use complies with its obligations.

Another mistake is thinking that customer responsibility means the customer must operate the underlying cloud hardware. The model assigns AWS responsibility for the provider-operated infrastructure described in its documentation. The customer focuses on the layers and controls it manages for the chosen service.

A third mistake is memorizing one fixed list without checking the service. Responsibility changes with the services deployed and their integration. Learn the boundary principle, then apply it to the component in the question.

How this fits CLF-C02

The CLF-C02 guide places security and compliance in a 30% content domain, and specifically lists understanding and explaining the shared responsibility model among the tasks the exam validates. It also states that the target candidate is not expected to code, design cloud architecture, troubleshoot, implement systems, or conduct load and performance testing. A useful response should explain the responsibility boundary at a foundational level rather than invent a deployment design.

Use the current AWS exam guide's service references when studying named services. AWS maintains in-scope and out-of-scope service lists, which can change. This article is a concept explanation, not a complete service inventory or a substitute for the active guide. Practice scores from an article cannot predict an AWS scaled score.

Apply the boundary by service type

On an Amazon EC2 instance, AWS secures the physical host, data center, and foundational networking. The customer selects and hardens the guest operating system, manages patches, configures network rules, protects credentials, and secures application data. The exact division can depend on the service and contract, but the core exam distinction is that EC2 gives the customer more operating-system responsibility than a fully managed application service.

With Amazon RDS, AWS operates more of the database infrastructure and service maintenance. The customer still chooses access permissions, protects credentials and data, configures the database for its needs, and decides how applications use it. Managed does not mean responsibility-free. A question about physical infrastructure differs from a question about who can read a customer’s records.

For Amazon S3, AWS operates the storage service infrastructure. The customer controls bucket policies, identity permissions, encryption choices, and data classification or retention settings relevant to the workload. Public exposure caused by an overly permissive policy is a customer configuration issue. A question about operating the disks in an AWS facility belongs to AWS’s side.

Original scenarios: decide who owns the action

A company discovers that an EC2 operating system has an overdue security patch. The customer owns the patching task because it manages the guest operating system on the instance. AWS maintains the underlying host infrastructure, but that does not patch the customer’s operating system. The clue is the layer named in the finding.

A company finds that its S3 bucket permits anonymous reads. The customer must correct the access configuration and investigate exposure. AWS supplies the service and security features, but the customer decides who can read its objects. A managed storage service does not make its access policy correct automatically.

A customer asks who protects the AWS data center from unauthorized physical entry. That is AWS’s responsibility as part of security of the cloud. If the same question asks who decides which employees may download the customer’s data, that is the customer’s identity and data-access responsibility. The phrase data center signals provider infrastructure; employee permissions signal customer configuration.

Shared responsibility is not a single fixed checklist

The responsibility boundary shifts with the service abstraction. A customer using virtual machines performs more operating-system and application work than a customer using a managed platform or software service. AWS remains responsible for the infrastructure it operates, while the customer remains responsible for its use of the service, its data, identity choices, and required configuration. Read the scenario’s layer and service rather than memorizing one list as universal.

Some controls are shared in practice. AWS provides tools and secure infrastructure; customers configure and monitor them. Encryption may involve AWS capabilities and customer decisions about keys and access. Logging may require AWS services and customer retention, review, and response. The exam asks for the party accountable for a specific action, so distinguish the provider’s capability from the customer’s responsibility to use it correctly.

A quick reasoning sequence

1. Name the service in the scenario: EC2, RDS, S3, or another managed service.
2. Identify the layer: facility, host hardware, guest OS, service configuration, identity, application, or data.
3. Ask whether AWS operates that layer or the customer configures and uses it.
4. Select the party responsible for the stated action, not the party that supplies a related tool.
5. If the question describes an exposure, separate fixing the configuration from operating the underlying service.

The best exam response is often the narrowest one: AWS secures the physical infrastructure; the customer patches the EC2 guest operating system; the customer controls S3 data access. Avoid broad claims such as “AWS is responsible for security” or “the customer is responsible for everything.” The shared model divides work according to service and layer.