AWS Shared Responsibility Model

The AWS Shared Responsibility Model is a security framework that defines the division of security obligations between AWS and the customer. It exists because cloud computing does not eliminate security responsibilities; it shifts them. In a traditional on-premises data center, you own everything—the building, servers, network cables, operating systems, applications, and data—so you are responsible for securing all layers. In the cloud, AWS provides the infrastructure, but you must secure what you put on top of it.

The model is often visualized as a layered cake: AWS is responsible for the "Security OF the Cloud" (the physical and structural layers), and the customer is responsible for "Security IN the Cloud" (everything they deploy and configure). This distinction is critical because many candidates mistakenly believe AWS secures everything, leading to security breaches and exam errors.

AWS is responsible for: - Physical security of data centers: guards, fences, cameras, biometric access, and environmental controls (power, cooling, fire suppression). - Hardware and software infrastructure: servers, storage devices, networking gear, hypervisors, and the software that manages them. - Network infrastructure: global network backbone, edge locations, and physical network segmentation. - Managed services: for services like Amazon RDS, Amazon S3, and AWS Lambda, AWS also handles the underlying operating system and platform security.

The customer is always responsible for: - Customer data: encryption, classification, and compliance of data stored or processed in AWS. - Identity and Access Management (IAM): users, groups, roles, policies, and multi-factor authentication (MFA). - Operating system and application security: patching, firewalls, antivirus, and configuration of guest OS on EC2 instances. - Network traffic protection: security groups, network ACLs, and firewall rules. - Client-side encryption: encrypting data before sending it to AWS.

For some services, responsibility is shared. For example, with Amazon RDS, AWS manages the database engine patching and backup, but you manage database credentials, schema, and data encryption keys.

The model varies by service type: - Infrastructure as a Service (IaaS) like Amazon EC2: You have more responsibility—you manage the guest OS, applications, and security groups. AWS secures the physical host and hypervisor. - Platform as a Service (PaaS) like AWS Elastic Beanstalk: AWS manages the OS and runtime, but you still manage your application code and IAM permissions. - Software as a Service (SaaS) like Amazon WorkMail: AWS handles almost everything, but you manage users and data.

On-premises: You are responsible for everything from the building to the data. In the cloud, AWS takes over the lower layers, but you still have significant duties. The key difference is that you no longer need to worry about physical security or hardware maintenance, but you must master cloud-specific security tools like IAM and security groups.

You always use the Shared Responsibility Model—it is not a service you choose; it is the underlying security model for all AWS services. Understanding it helps you decide which services to use based on your security compliance needs. For example, if you need full control over the OS, use EC2. If you want to offload OS patching, use RDS or Lambda.

A healthcare startup needs to store patient records in AWS while complying with HIPAA. They use Amazon S3 for storage and Amazon EC2 for application servers. The team must understand the Shared Responsibility Model to pass a compliance audit. AWS is responsible for the physical security of data centers and the HIPAA eligibility of its services (they sign a Business Associate Addendum). However, the startup is responsible for encrypting the patient data at rest (using S3 SSE-KMS) and in transit (using TLS), managing IAM roles to restrict access to authorized personnel, and ensuring the EC2 instances are patched and configured securely. A common mistake is assuming AWS automatically encrypts data—it does not. The startup must enable encryption and configure access policies. If they fail to do so and a breach occurs, the startup bears the liability. Cost-wise, encryption and IAM are free, but the labor to configure them is significant. Misconfiguration, such as leaving an S3 bucket public, can lead to data exposure and fines.

A financial services company runs serverless functions with AWS Lambda to process transactions. They assume that because Lambda is a managed service, AWS handles all security. However, the customer is still responsible for the code, IAM permissions, and data encryption. For example, the Lambda function may access a DynamoDB table; the customer must ensure the IAM role attached to the function has only the necessary permissions (least privilege). Also, the customer must encrypt sensitive environment variables and enable VPC settings if the function needs to access a private database. A real-world incident involved a company that stored API keys in plaintext environment variables, leading to a compromise. The Shared Responsibility Model makes it clear: AWS secures the execution environment, but the customer secures the code and configuration. The exam often tests this—remember that even with serverless, you are responsible for your code and IAM.

A retail company uses Amazon RDS for MySQL to store customer orders. They believe that because RDS is a managed service, AWS handles all security patches. This is partially true: AWS patches the database engine and OS. However, the customer is responsible for managing database user accounts, setting password policies, enabling encryption (RDS encryption is optional and must be enabled at creation), and configuring security groups to restrict network access. A common mistake is not enabling encryption at rest—if the underlying storage is compromised, the data is exposed. Also, the customer must enable automated backups and set retention periods. The exam often asks: who is responsible for patching the database engine? Answer: AWS. Who is responsible for configuring database access? Answer: the customer. This distinction is key.