1 The AWS Shared Responsibility Model

The basic division of responsibility

The AWS Shared Responsibility Model divides security and compliance responsibilities between AWS and its customers. AWS protects security of the cloud: the facilities, hardware, networking, and foundational software that run AWS services. Customers protect security in the cloud: their data, identities, applications, and the configuration of the AWS resources they use.

A useful rule is that AWS secures the underlying service, while customers secure their use of it. Using AWS does not transfer responsibility for customer data, access policies, application security, or legal and regulatory obligations to AWS. The exact boundary depends on the service and how it is configured.

How responsibilities vary by service

As a service becomes more managed, AWS generally handles more of the underlying technology. Customers still have security decisions to make, and the following boundaries are general rather than a substitute for service-specific documentation.

• Amazon EC2: AWS generally manages physical facilities, hardware, and virtualization. Customers generally manage the guest operating system and patches, installed applications, security groups, identities, and data.

• Amazon RDS: AWS generally manages hosting infrastructure and many database and operating-system maintenance tasks. Customers generally manage data, access, network exposure, database configuration and use, and service settings such as maintenance choices.

• Amazon S3: AWS generally manages infrastructure, the operating system, and the storage platform. Customers generally manage data classification, permissions, encryption choices, and monitoring.

• AWS Lambda: AWS generally manages infrastructure, the execution environment, and the runtime platform. Customers generally manage function code and libraries, resource configuration, permissions, and data.

AWS may provide and validate patches for a managed service while the customer remains responsible for reviewing updates and scheduling or applying them as required. Check the documentation for the particular service to determine its responsibility boundaries.

Applying the model to security decisions

For each workload, identify the service, the resource settings you control, and the data and obligations involved. Assign an owner for each relevant control and verify that it is implemented.

• Choosing compute: An EC2 instance gives the customer more control, but the customer must patch and harden its operating system and application. A managed service can reduce that work, but does not automatically secure the customer’s application or data.

• Granting access: Use IAM roles and policies to grant each user or service only the permissions it needs. Check resource policies and network controls as well. An overly broad permission can expose data even when AWS’s underlying infrastructure is secure.

• Storing sensitive data: Classify the data, restrict access, choose suitable encryption settings, and enable appropriate logging or detection. With S3, these customer-side choices remain the customer’s responsibility.

• Meeting compliance requirements: AWS audit reports and certifications can support an assessment of inherited controls, but they do not certify a particular workload or make an organization compliant by themselves. Determine which controls are inherited, shared, or the organization’s responsibility to implement and document. AWS Artifact provides access to AWS compliance reports and related materials.

Assigning and reviewing control ownership

A responsibility checklist or matrix can make control ownership explicit. List each relevant control—such as patching, identity, encryption, logging, backups, and incident response—and record whether AWS, the organization, or both perform and verify it.

Revisit the checklist when services, configurations, regulations, or workload integrations change. Managed services shift more infrastructure work to AWS, but customers retain responsibility for their data, access, configuration, applications, and compliance obligations. Consult service-specific documentation, apply least privilege, and explicitly assign and verify the controls the workload needs.