AWS Shared Responsibility Model
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
When a company leases a commercial office suite in a high-rise building, the property management firm secures the lobby, maintains the elevators, and ensures the structural integrity of the facility. However, if the tenant leaves their private suite door unlocked overnight or hands their access badge to a stranger, the resulting breach is not the landlord's failure. The tenant and the landlord share the burden of security, but the line dividing their obligations is absolute.
In cloud computing, this dividing line is known as the AWS Shared Responsibility Model. It is the foundational framework that dictates the division of security obligations and compliance obligations between AWS and the customer. Understanding this model is not merely a technical necessity; it is a critical business imperative. For project managers, financial officers, and system architects alike, the Shared Responsibility Model reduces customer operational burden by intentionally shifting certain IT controls from your internal teams to AWS. You no longer pay for engineers to guard data center doors or replace failing hard drives; instead, your capital and labor are focused entirely on the applications and data that generate value for your business.
To navigate the AWS Shared Responsibility Model, you must memorize a single, inviolable rule. This rule dictates the baseline relationship between the cloud provider and the cloud consumer.
The Golden Rule of Cloud Security In the AWS Shared Responsibility Model, AWS is responsible for the security of the cloud. The customer is responsible for security in the cloud.
AWS Responsibilities (Security Of the Cloud)
AWS is responsible for protecting the global infrastructure that runs all services offered in the AWS Cloud. This global infrastructure is the foundation of cloud computing. AWS global infrastructure responsibilities include:
- Physical Facilities: AWS manages the physical security of AWS Regions, AWS Availability Zones, and AWS Edge Locations. This includes securing physical data center facilities against unauthorized access, environmental hazards, and natural disasters.
- Hardware Lifecycle: AWS secures physical hardware. When drives fail or are retired, AWS is responsible for disposing of physical storage devices when the devices reach the end of their useful life, using rigorous cryptographic erasure and physical destruction protocols.
- Core Infrastructure: AWS secures the physical network infrastructure and secures underlying host software.
You cannot visit an AWS data center to verify their locks, which is why AWS provides third-party audit reports (via AWS Artifact) to prove they are holding up their end of the bargain.
Customer Responsibilities (Security In the Cloud)
Customers are responsible for managing their own customer data in the AWS Cloud. While AWS protects the facility, the customer retains full control over the security measures implemented to protect customer data within the AWS environment.
Your fundamental responsibilities include:
- Identity and Access Management (IAM): The customer is responsible for configuring identity and access management policies to control access to AWS resources. Specifically, the customer is responsible for creating IAM users, defining IAM policies, and enforcing multi-factor authentication (MFA) for their AWS accounts. If an unauthorized user accesses your account because you did not enable MFA or restrict IAM permissions, that is a failure of security in the cloud.
- Network Protection: The customer is responsible for protecting network traffic within a customer-managed Amazon Virtual Private Cloud (Amazon VPC).
- Encryption: The customer is responsible for managing client-side data encryption and managing server-side data encryption within customer-controlled AWS environments.
A common concern among legal and compliance professionals is what happens to corporate data once it enters the cloud. The Shared Responsibility Model makes this explicitly clear: the customer retains ownership of their data stored in the AWS Cloud.
Furthermore, AWS treats data sovereignty with strict geographic boundaries. The customer can choose which AWS Region to store their data in. Because of strict compliance obligations worldwide (like GDPR in Europe), AWS will not move customer data outside the customer-selected AWS Region without customer consent. You maintain absolute authority over where your data lives.
The division of security responsibilities between AWS and the customer varies depending on the specific AWS services used. As you move from foundational building blocks to fully managed services, AWS assumes more of the operational burden.
Think of this as a continuum. If you rent a car, you must drive it, fuel it, and navigate. If you hire a taxi, you simply provide the destination. Cloud services operate on a similar spectrum.
Infrastructure as a Service (IaaS): Amazon EC2
Amazon EC2 is an Infrastructure as a Service offering. It provides raw computing power, meaning the customer takes on the maximum amount of responsibility.
- AWS provides: AWS is responsible for the security of the underlying physical host and the security of the hypervisor layer (the software that creates the virtual machines).
- The Customer provides: The customer performs all necessary guest operating system security configurations. When using Amazon EC2, the customer is responsible for applying updates to the guest operating system and applying security patches to the guest operating system. Furthermore, the customer is responsible for configuring network routing and configuring virtual firewalls like security groups.
Platform as a Service (PaaS): Amazon RDS
Amazon RDS is a Platform as a Service offering. Because it is a managed database service, the boundary of responsibility shifts upward.
- AWS provides: For managed database services like Amazon RDS, AWS manages the underlying compute infrastructure, manages the guest operating system, and is responsible for patching the database engine software.
- The Customer provides: The customer no longer worries about OS updates. However, when using Amazon RDS, the customer is responsible for configuring database access controls and managing the stored relational data.
Abstracted Services: Amazon S3
Amazon S3 is an abstracted cloud storage service. You do not provision servers or manage file systems; you simply request and store data via an API.
- AWS provides: For abstracted services like Amazon S3, AWS operates the physical infrastructure layer, manages the underlying operating system, and manages the application platform.
- The Customer provides: When using abstracted services like Amazon S3, the customer is responsible for configuring data access permissions (ensuring your buckets are not public!) and classifying customer data (determining what is sensitive, what is public, and encrypting it accordingly).
Serverless Compute: AWS Lambda
AWS Lambda is a serverless compute service. It allows you to run code without provisioning or managing any infrastructure.
- AWS provides: For serverless compute services like AWS Lambda, AWS handles underlying server provisioning, manages the compute fleet, and manages the execution environment.
- The Customer provides: When using AWS Lambda, the customer is responsible for the security of the provided application code (ensuring your code doesn't contain vulnerabilities) and assigning appropriate identity and access management roles to the function (giving the code only the permissions it needs to run).
| Service Type | Service Example | AWS Responsibilities | Customer Responsibilities |
|---|---|---|---|
| IaaS | Amazon EC2 | Physical hardware, Hypervisor | Guest OS patching, Network routing, Security groups |
| PaaS | Amazon RDS | Compute infra, Guest OS, DB engine patching | DB access controls, Relational data management |
| Serverless | AWS Lambda | Server provisioning, Compute fleet, Execution environment | Security of application code, IAM roles for the function |
| Abstracted | Amazon S3 | Physical infra, Underlying OS, Application platform | Data classification, Data access permissions |
Business Value Note: If your finance team is evaluating a migration from on-premises servers to AWS, recognizing that shifting from EC2 (IaaS) to RDS (PaaS) or Lambda (Serverless) removes the labor cost of OS patching is a major financial lever.
In the cloud, IT controls—the procedures and mechanisms used to manage risk—fall into three distinct categories based on who implements them.
1. Inherited Controls
Inherited controls are security controls that a customer fully inherits from AWS. Because the customer has no physical access to the infrastructure, they rely entirely on AWS to fulfill these obligations.
- Example: Physical and environmental security controls are considered inherited controls in the AWS environment.
2. Shared Controls
Certain controls apply to both AWS and the customer, but the context of the control depends on the layer being managed.
- Patch Management is a shared IT control in the AWS environment. Under the shared patch management control, AWS is responsible for patching flaws within the underlying global infrastructure. Conversely, the customer is responsible for patching customer-managed guest operating systems and patching customer-installed applications.
- Configuration Management is a shared IT control in the AWS environment. Under the shared configuration management control, AWS maintains the configuration of AWS physical infrastructure devices. The customer configures customer-managed guest operating systems, customer-managed databases, and customer-managed applications.
- Employee Awareness and Training is a shared IT control in the AWS environment. Under the shared employee training control, AWS is responsible for security training for AWS employees, while the customer is responsible for security training for customer employees.
3. Customer-Specific Controls
Customer-specific controls are security controls that are solely the responsibility of the AWS customer. These controls are highly contextual; customer-specific controls are based on the specific application deployed within AWS services.
- Zone security (architecting your application to isolate different tiers of data) is an example of a customer-specific control.
- Service and communications protection (setting up specific application-layer protections, like throttling limits or custom routing logic for your unique software) is an example of a customer-specific control.
The AWS Shared Responsibility Model is not a barrier; it is a partnership. By internalizing that AWS provides the security of the cloud (the physical facilities, the hardware, and the underlying hypervisors) while you provide the security in the cloud (your data, your IAM users, and your application code), you ensure a secure architecture. Remember that your specific obligations expand or contract depending on whether you choose IaaS, PaaS, Abstracted, or Serverless services, but your responsibility to protect your data and govern your users remains absolute.