CLOUD CONCEPT

AWS shared responsibility model

The AWS shared responsibility model divides security and compliance duties between AWS, which secures the cloud infrastructure, and customers, who secure their workloads and how they use AWS services.

Cloud Concepts Hub →

What is AWS shared responsibility model

AWS and its customers have distinct responsibilities for protecting systems, data, and operations, with the boundary changing according to the services used. Understanding that boundary helps engineers implement appropriate controls and collect the right evidence instead of assuming that AWS compliance certifications automatically make a workload compliant.

The AWS shared responsibility model separates security of the cloud from security in the cloud. AWS is responsible for protecting the infrastructure that runs its services, including physical facilities, hardware, networking, and the virtualization layer. Customers are responsible for their data, identities, access permissions, workload configurations, and other controls that remain within their authority. This division also applies to compliance: AWS can provide evidence about its controls, but customers must demonstrate that their own use of the services satisfies applicable requirements.

The exact boundary depends on the service. With Amazon EC2, AWS operates the underlying infrastructure, while the customer manages the guest operating system, patches, installed applications, instance roles, and security group rules. With Amazon S3, AWS manages the service infrastructure and operating environment, while the customer controls matters such as bucket policies, public access settings, data classification, and applicable encryption configuration. A managed service transfers some operational duties to AWS; it does not eliminate customer accountability for access or data protection.

Engineers apply the model by mapping each compliance requirement to a control, a responsible party, and supporting evidence. For a physical access requirement, relevant AWS assurance reports may provide evidence for the provider-operated infrastructure. For a requirement to restrict administrative access, the customer must show appropriate IAM policies, authentication controls, and access reviews. Some control categories are shared: AWS patches its infrastructure, and customers patch the components they manage. The responsibilities address different layers rather than both parties performing the same task on the same resource.

AWS Artifact provides access to AWS security and compliance reports and certain agreements. These documents help customers evaluate AWS-operated controls and determine whether relevant services, Regions, and reporting periods are covered. An AWS report is not evidence that a customer's bucket policy, identity configuration, or application is secure. Customers must also check whether a report identifies complementary controls that they need to implement.

AWS Audit Manager has been in maintenance and closed to new customers since March 31, 2026; existing customers can continue using it to collect and organize evidence for assessments using frameworks and controls. Depending on the control and configuration, evidence can come from AWS API activity, resource configuration snapshots, compliance checks, or manual uploads. Engineers should configure the assessment scope, review evidence relevance, assign reviewers, and supply manual evidence for activities such as policy approval or staff training. An assessment report supports an audit; it is not a certification, and collecting evidence does not automatically establish that every control is effective.

For existing AWS Audit Manager customers, a practical workflow combines AWS Artifact reports for provider responsibilities with AWS Audit Manager evidence for customer responsibilities. AWS Config can record resource configurations and evaluate configured rules, while AWS CloudTrail can provide records of account activity. For example, a team investigating an S3 access-control requirement might use configuration evidence to show bucket settings, activity records to identify policy changes, and an approved access review as manual evidence.

The main trade-off is reduced infrastructure management in exchange for a continuing need to understand service-specific boundaries. Outsourcing infrastructure does not outsource legal obligations, risk decisions, or accountability for customer-controlled settings. Common mistakes include treating a compliant AWS service as a compliant application, assuming managed services require no security configuration, and confusing evidence collection with remediation. A sound implementation explicitly assigns ownership, verifies control effectiveness, and preserves evidence that matches the audit scope and period.

Key aspects of AWS shared responsibility model

The model requires service-specific control ownership, separate evidence for AWS and customer responsibilities, and ongoing validation of customer-controlled security and compliance.

Security of the cloud versus security in the cloud

AWS protects the infrastructure supporting its services, while customers secure their workloads and customer-controlled configurations. Use this distinction to assign control ownership before choosing implementation or audit tools.

Service-dependent responsibility boundaries

Customer duties vary with the service's abstraction level. Managing an EC2 guest operating system requires customer patching, whereas an S3 customer focuses on data protection and access configuration rather than service operating-system maintenance.

Separate provider and customer compliance evidence

AWS assurance reports support claims about AWS-operated controls; customer evidence supports claims about workload controls. Check report scope, relevant services, reporting periods, and any complementary customer controls.

Evidence collection does not establish compliance

Automated evidence helps document control operation but requires review for relevance, completeness, and effectiveness. Customer procedures, approvals, and organizational controls may require manually supplied evidence.

Shared control categories across different layers

Some categories, such as patch management and configuration management, involve both AWS and the customer. Each party manages the components within its responsibility rather than sharing ownership of every individual task.

Continuing customer accountability

Using managed services reduces operational work but does not remove responsibility for data, permissions, or applicable obligations. Maintain explicit control owners and remediate findings instead of treating audit reports as a substitute for security operations.

Cloud services for AWS shared responsibility model

AWS Artifact supplies assurance materials for AWS-operated controls, while AWS Audit Manager organizes evidence for assessments of the customer's environment. AWS Config contributes resource configuration history and rule evaluations, and AWS CloudTrail contributes records of relevant account activity. Together, these services help distinguish provider assurance from customer control evidence. Engineers must still select the correct accounts, resources, reporting periods, and event coverage, review evidence quality, and supply documentation for organizational processes. Findings should drive remediation and follow-up validation rather than being treated as proof that a workload is compliant merely because evidence was collected.

AWS Audit Manager image AWS Audit Manager

Existing customers can continue using AWS Audit Manager to collect and organize evidence against assessment controls to help evaluate customer responsibilities. Teams must define the assessment scope, review automated evidence, and add manual evidence where required; the service does not certify compliance.

Open AWS Audit Manager →
AWS Artifact image AWS Artifact

AWS Artifact provides access to AWS security and compliance reports and certain agreements that support evaluation of AWS responsibilities. These materials do not establish compliance for customer configurations or applications.

Open AWS Artifact →
AWS Config image AWS Config

AWS Config records supported resource configurations and evaluates them against configured rules. Its configuration history and compliance results can support evidence about customer-controlled settings, but rule coverage must match the control being assessed.

Open AWS Config →
AWS CloudTrail image AWS CloudTrail

AWS CloudTrail records supported account activity, helping demonstrate who performed actions affecting customer-controlled resources. Configure appropriate event coverage, retention, and log protection, including data events where the audit requires them.

Open AWS CloudTrail →