Certablo
Sign inCreate account
← Knowledge Base
Cloud Fundamentalsconcept

AWS Shared Responsibility Model

A precise guide to security 'of' the cloud versus security 'in' the cloud, including how the responsibility boundary changes across different service models.

CLF-C02AIF-C01

Visual overview

SECURITY BOUNDARYResponsibility is shared—and the boundary moves by service
CUSTOMER

Security IN the cloud

Data · identities · permissions · configuration · guest OS where applicable

AWS

Security OF the cloud

Facilities · hardware · networking · infrastructure software

More customer operationsEC2→Managed services→S3 / DynamoDBMore AWS abstraction
AWS always operates the cloud infrastructure. Customer responsibilities vary with the service, while data and access decisions remain customer concerns.
AWS SERVICE MAPControls span both sides

Customer identity and data controls complement AWS responsibility for cloud infrastructure.

AWS IAMCustomer access control
AWS KMSKey controls
AWS ArtifactAWS assurance evidence
EXAM-RELEVANT MECHANICS

Technical reference

The boundary moves with service abstraction, but customer ownership of data and configuration does not disappear.

AWSSecurity of the cloud

AWS protects facilities, hardware, networking, and managed service infrastructure.

CustomerSecurity in the cloud

Customers configure identities, permissions, data protection, and workload settings.

EC2 exampleGuest OS is customer-managed

Virtual servers leave guest operating-system configuration and patching with the customer.

Managed servicesBoundary moves upward

AWS performs more platform operations while authorization and data governance remain customer concerns.

Security of the cloud and in the cloud

AWS divides cloud security responsibilities between AWS and the customer. AWS is responsible for security of the cloud: the infrastructure that runs AWS services, including the facilities, hardware, software, and networking that make up the AWS Cloud. Customers do not physically secure AWS data centers or maintain the host hardware that AWS uses to provide its services.

The customer is responsible for security in the cloud. Exactly what that includes depends on which services are selected, how those services abstract infrastructure, and how the customer configures them. Customer data, identity and access choices, and many service configurations remain customer concerns even when AWS manages the underlying platform.

How responsibility changes by service

Amazon EC2 is a useful example of a service with substantial customer control. AWS manages the physical infrastructure and virtualization layer, while the customer is responsible for areas such as the guest operating system, including updates and security patches, application software, and the configuration of AWS-provided security controls such as security groups. Greater control over the operating environment brings greater customer responsibility.

More abstracted services move additional platform responsibilities to AWS. AWS uses Amazon S3 and Amazon DynamoDB as examples where AWS operates the infrastructure, operating system, and platform. The customer still remains responsible for its data and for configuration choices such as encryption options, permissions, and identity access. A managed service therefore reduces operational responsibility; it does not transfer ownership of security decisions about customer data.

Controls can be shared too

AWS also explains responsibility through the idea of inherited, shared, and customer-specific controls. Some physical and environmental controls are inherited entirely from AWS because the customer cannot operate the underlying facilities. Other controls are shared: AWS may protect infrastructure while the customer performs its own configuration or management activities at a different layer.

This is especially important for compliance. Running on AWS does not automatically make a customer's complete application compliant with a regulation. AWS can provide compliant infrastructure, certifications, and evidence for its responsibilities, while the customer must still configure and operate its workload so that its own obligations are met.

How to reason about a new service

When encountering an unfamiliar AWS service, ask what layer AWS is operating and what choices remain in the customer's hands. If the customer controls an operating system, that usually brings patching and hardening responsibility. If AWS fully manages the operating system, focus customer attention on data classification, identities, access policies, encryption configuration, network exposure, application behavior, and logging as applicable to that service.

The most common mistake is to memorize one fixed list of responsibilities and apply it everywhere. AWS explicitly states that customer responsibility varies according to the services used, their integration into the customer's environment, and applicable laws and regulations. The model is a boundary for reasoning, not a single universal checklist.

Key takeaways

  1. 01

    AWS owns security of the cloud; customers own security responsibilities in the cloud according to the services they use.

  2. 02

    EC2 exposes more of the stack to the customer than highly managed services such as S3 or DynamoDB.

  3. 03

    Customer responsibility for data, identities, permissions, and configuration remains central.

  4. 04

    Compliance responsibility is shared and must be evaluated for the actual workload.

Official AWS sources

Use these primary AWS resources for the source material behind this article and for deeper reference.