Understanding the AWS Shared Responsibility Model: Who Secures What in the Cloud?
Cloud security explained through practical examples using Amazon EC2, Amazon S3, IAM, and AWS CloudTrail.
Introduction
Moving applications to the cloud changes how organizations manage infrastructure, but it does not eliminate their security responsibilities.
One of the most common misconceptions among cloud beginners is that once an application is deployed on Amazon Web Services (AWS), AWS becomes responsible for securing everything.
In reality, cloud security requires collaboration between the cloud provider and its customers.
AWS addresses this through the Shared Responsibility Model, a security framework that defines which responsibilities belong to AWS and which remain with the customer.
Understanding this model is essential for developers, cloud engineers, and cybersecurity professionals because even a highly secure cloud infrastructure can become vulnerable through incorrect configurations.
In this article, we will explore how the AWS Shared Responsibility Model works, examine practical examples, and discuss how organizations can strengthen their security posture.
1. What Is the AWS Shared Responsibility Model?
The AWS Shared Responsibility Model divides security responsibilities into two main categories:
- Security OF the Cloud: The responsibility of AWS.
- Security IN the Cloud: The responsibility of the customer.
AWS protects the infrastructure that operates its cloud services, while customers are responsible for securely configuring and using the services they deploy.
For example, AWS secures the physical servers running Amazon EC2 instances. However, customers must ensure that their EC2 instances use appropriate security groups, operating system patches, and access permissions.
This separation allows organizations to benefit from AWS infrastructure security while retaining control over their applications and data.
2. AWS Responsibilities: Security OF the Cloud
AWS is responsible for protecting the underlying infrastructure that supports its cloud services.
These responsibilities include:
Physical Data Center Security
AWS manages physical access controls, environmental safeguards, and the security of facilities housing its infrastructure.
Hardware and Infrastructure
AWS maintains physical servers, storage hardware, networking equipment, and other infrastructure components.
Virtualization Infrastructure
AWS manages the underlying virtualization and host infrastructure that enables customers to run virtual machines and other cloud services.
Foundational Networking
AWS protects the underlying networking infrastructure supporting AWS services.
Consider an organization hosting its e-commerce application on Amazon EC2.
The organization does not need to physically secure the AWS data center, replace failed server hardware, or maintain the underlying virtualization platform.
AWS handles those responsibilities.
However, this does not mean AWS manages every security control within the customer's EC2 instance.
That distinction becomes important when examining customer responsibilities.
3. Customer Responsibilities: Security IN the Cloud
Customers are responsible for securely configuring and operating the AWS resources they use.
Typical responsibilities include:
- Identity and access management.
- Application security.
- Data protection and access controls.
- Operating system patching for self-managed instances.
- Network security configuration.
- Logging and security monitoring.
- Compliance with applicable organizational and regulatory requirements.
The exact responsibilities depend on the AWS service being used.
For instance, Amazon EC2 provides customers with significant control over their operating systems, while managed services such as Amazon RDS reduce some infrastructure and database administration responsibilities.
Let's explore several practical examples.
4. Practical Example 1: Securing an Amazon EC2 Instance
Imagine a software company deploying a Linux web server using Amazon EC2.
The server hosts a customer-facing web application.
AWS is responsible for securing the physical infrastructure and underlying virtualization environment.
The customer must secure the guest operating system, application, and network access configuration.
Scenario: An exposed SSH port
A developer creates an EC2 security group with the following inbound rules:
| Port | Protocol | Source |
|---|---|---|
| 22 | SSH | 0.0.0.0/0 |
| 443 | HTTPS | 0.0.0.0/0 |
The second rule may be appropriate for a public web application.
However, the first rule allows SSH connection attempts from any IPv4 address on the internet.
Although authentication is still required, unnecessary exposure increases the potential attack surface.
A more secure approach
Instead of exposing SSH publicly, the organization can use AWS Systems Manager Session Manager for administrative access.
This can eliminate the need to open inbound SSH ports when the required permissions and connectivity are properly configured.
Other important practices include:
- Regularly updating the guest operating system.
- Applying the principle of least privilege.
- Using IAM roles instead of storing long-term AWS access keys on instances.
- Enabling appropriate monitoring and logging.
- Restricting inbound traffic to required ports and sources.
Key lesson: AWS protects the infrastructure running the virtual machine, but customers are responsible for securing the operating system, applications, and access configurations inside their EC2 environments.
5. Practical Example 2: Protecting Data in Amazon S3
Amazon Simple Storage Service (Amazon S3) is widely used to store application files, backups, documents, and other objects.
Imagine a healthcare application storing confidential patient reports in an S3 bucket.
AWS maintains the underlying storage infrastructure, but the customer is responsible for deciding who can access the reports and how that access is controlled.
Scenario: Excessive bucket permissions
Suppose a developer unintentionally grants public read access to sensitive objects.
Even though the underlying S3 infrastructure is secured by AWS, the data could become exposed because of an incorrect customer configuration.
This demonstrates why access control remains a customer responsibility.
Recommended security controls
1. S3 Block Public Access
Enable and enforce S3 Block Public Access settings to prevent unintended public exposure.
2. IAM Policies
Grant users and applications only the permissions needed to perform their tasks.
3. Encryption
Amazon S3 automatically encrypts new object uploads at rest using SSE-S3 by default.
For workloads requiring additional control over encryption keys, customers can use AWS Key Management Service (AWS KMS) with SSE-KMS.
4. Logging
AWS CloudTrail can record supported Amazon S3 API activities.
For object-level operations such as reading or uploading files, configure the relevant CloudTrail data events.
These events are not enabled automatically for every object.
5. Secure Transport
Use HTTPS and, where appropriate, enforce TLS-based access through bucket policies.
Key lesson: AWS protects the storage infrastructure, but customers remain responsible for appropriate permissions, data classification, encryption choices, and monitoring configurations.
6. Practical Example 3: IAM and the Principle of Least Privilege
Identity security is one of the most important customer responsibilities in AWS.
Consider a development team building a web application that uploads images to an S3 bucket.
The application needs permission to upload objects, but it does not need permission to delete buckets or manage IAM users.
Granting unnecessary permissions would violate the principle of least privilege.
Example IAM policy
The following example permits uploading objects into a specific S3 bucket:
1
2
3
4
5
6
7
8
9
10
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::example-app-uploads/*"
}
]
}Replace
example-app-uploads with the appropriate bucket name.This policy allows the
s3:PutObject action on objects in the specified bucket. It does not grant broad S3 administration permissions.Actual access also depends on other applicable policies and controls, including explicit denies.
For an EC2-hosted application, this policy could be attached to an IAM role assigned to the instance.
Additional security recommendations include using temporary credentials, requiring multi-factor authentication for human users, protecting the AWS account root user, and reviewing permissions regularly.
Key lesson: AWS provides IAM as a security service, but customers must design and maintain appropriate identity permissions.
7. How Security Responsibilities Change Across AWS Services
An important characteristic of the Shared Responsibility Model is that customer responsibilities vary depending on the services selected.
Consider the following comparison:
| Security responsibility | Amazon EC2 | Amazon RDS | AWS Lambda |
|---|---|---|---|
| Physical infrastructure | AWS | AWS | AWS |
| Underlying host infrastructure | AWS | AWS | AWS |
| Guest operating system patching | Customer | AWS | AWS-managed environment |
| Application code security | Customer | Customer | Customer |
| IAM and resource permissions | Customer | Customer | Customer |
| Customer data access controls | Customer | Customer | Customer |
This comparison illustrates a key concept: managed services reduce some operational responsibilities, but they do not eliminate customer security responsibilities.
For Amazon RDS, AWS manages the underlying infrastructure and supported database software maintenance processes. Customers still configure database access, networking, and applicable maintenance preferences.
For AWS Lambda, AWS manages the underlying execution infrastructure and supported managed runtimes. Customers remain responsible for their function code, dependencies, IAM permissions, and application configuration. Customer-provided container images and custom runtimes introduce additional maintenance responsibilities.
Choosing managed services can reduce the infrastructure maintenance burden, allowing teams to focus more on protecting applications and data.
8. Monitoring and Auditing Security in AWS
Implementing security controls is only part of cloud security.
Organizations also need visibility into activities, configurations, vulnerabilities, and potential threats.
AWS offers several services to support these activities.
| AWS service | Main security purpose |
|---|---|
| AWS CloudTrail | Records supported AWS API and account activity |
| Amazon CloudWatch | Collects metrics, logs, and alarms |
| AWS Config | Tracks and evaluates supported resource configurations |
| Amazon GuardDuty | Detects suspicious activity and potential threats |
| Amazon Inspector | Identifies supported workload vulnerabilities and exposure |
| AWS Security Hub | Centralizes security findings and evaluates security posture |
Example: Investigating an IAM policy change
Imagine that an administrator notices an unexpected change to an IAM policy.
AWS CloudTrail can help identify the relevant API activity, including information such as the identity that made the request and when the action occurred.
AWS Config can provide configuration history for supported resources and help evaluate them against configured compliance rules.
Amazon GuardDuty can help detect certain suspicious or malicious activities across supported data sources.
These services complement one another, but customers must configure the relevant controls, permissions, retention settings, and integrations according to their security needs.
Key lesson: AWS provides security monitoring tools, but customers must ensure appropriate security visibility and respond to detected risks.
9. Common Shared Responsibility Mistakes
Understanding the theory is useful, but recognizing common implementation mistakes is equally important.
Mistake 1: Assuming AWS automatically secures every application
AWS secures its infrastructure, but vulnerabilities in customer-developed application code remain the customer's responsibility.
Mistake 2: Granting excessive IAM permissions
Administrator-level permissions should not be assigned to users and workloads that only require limited access.
Mistake 3: Exposing unnecessary network ports
Security groups should permit only the inbound traffic required by the workload.
Mistake 4: Ignoring application and operating system updates
Customers operating self-managed EC2 instances must establish appropriate vulnerability and patch-management processes.
Mistake 5: Assuming all security logs are enabled automatically
Some logging capabilities require additional configuration, and certain data collection options can introduce costs.
Avoiding these mistakes helps organizations reduce unnecessary exposure and strengthen their overall cloud security posture.
10. A Practical Security Checklist
Before deploying an application to AWS, consider the following checklist:
- Enable MFA for privileged human access, particularly the root user.
- Apply least-privilege IAM policies.
- Use IAM roles and temporary credentials for workloads.
- Review security group inbound and outbound rules.
- Implement appropriate encryption and key management.
- Protect sensitive S3 data from unintended public access.
- Configure CloudTrail logging appropriate to the workload.
- Enable relevant threat detection and configuration monitoring.
- Establish operating system and application patching processes.
- Regularly review security findings and incident response procedures.
These practices do not guarantee complete security, but they provide a useful starting point for establishing a stronger AWS security foundation.
Conclusion
The AWS Shared Responsibility Model is a foundational concept in cloud cybersecurity.
AWS secures the underlying cloud infrastructure, while customers must securely configure and operate the resources and applications they use.
The balance of responsibility changes depending on whether an organization chooses infrastructure services such as Amazon EC2 or managed services such as Amazon RDS and AWS Lambda.
Understanding these differences helps security teams identify risks, assign ownership, and implement appropriate controls.
For developers and cybersecurity professionals, the most important takeaway is simple:
Moving to the cloud changes how security responsibilities are divided. It does not remove the need for security.
A secure AWS environment requires both a trustworthy cloud infrastructure and responsible customer configurations.
References
- AWS Shared Responsibility Model — AWS Well-Architected Security Pillar
- Security in Amazon EC2
- Amazon S3 Security Best Practices
- AWS Identity and Access Management Security
- Amazon S3 CloudTrail Events
About the Author
A cybersecurity undergraduate at SLIIT with interests in cloud security, ethical hacking, networking, Linux, and secure software development. Currently exploring AWS technologies and their practical applications in building secure cloud environments.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article