AWS Shared Responsibility Model Explained

One of the most dangerous assumptions when starting to work with cloud environments is believing that workloads are secure by default. After all, if you are using the cloud, the provider should take care of security, right?

Not exactly.

Cloud providers are responsible for security, but only to a certain extent.

Imagine checking into a hotel and booking a room. The hotel is responsible for maintaining the building, hiring security staff, and monitoring cameras to secure entrances and hallways. It provides locks on the doors, installs smoke detectors and sprinklers, ensures that electricity and water work, and even offers a safe in each room for guests’ valuables.

In other words, the hotel is responsible for keeping the hotel itself secure.

You, the guest, are still responsible for locking your room when you leave. You decide who is allowed to enter, and you choose whether or not to use the safe to protect your valuables.

The hotel gives you a lock, but you must actually use it.

The same concept applies in the cloud. Cloud providers ensure that the underlying cloud infrastructure is secure, but you are responsible for securing your workloads and protecting your environment.

This division of responsibility, in the context of AWS, is known as the Shared Responsibility Model, and it is exactly what we are going to explore in this post.

What is the AWS Shared Responsibility Model?

The AWS Shared Responsibility Model defines how security responsibilities are divided between:

• AWS (the cloud provider) is responsible for security of the cloud
• You (the customer) are responsible for security in the cloud

This concept is best illustrated by [AWS] itself:(https://aws.amazon.com/es/compliance/shared-responsibility-model/)

AWS Responsibility

AWS is responsible for protecting the infrastructure that runs all AWS services. This includes:

• Physical data centers (buildings, locks, guards, cameras)
• Hardware (servers, storage devices, networking equipment)
• Global infrastructure (regions and availability zones)
• Core services infrastructure (compute, storage, networking foundations)
• Hypervisors and underlying virtualization layers

For example, if a physical server in an AWS data center fails or is physically tampered with, AWS is responsible for detecting and resolving that issue. Customers never manage or even see this hardware, and as such, they don't need to worry about:

• Data center access control
• Physical server patching
• Power, cooling, or hardware lifecycle

AWS handles all of it.

Customer responsiblity

As a customer, you are responsible for how you configure and use AWS services, which includes:

• IAM users, roles, and permissions
• Operating systems (for EC2)
• Network configurations (VPCs, security groups, NACLs)
• Data encryption and key management
• Application security
• Logging and monitoring
• Compliance with your own regulatory requirements

Let's look at an example to better understand this.

Imagine your marketing team stores images of an unreleased product in a private S3 bucket. The images are protected from the outside world because the bucket has strict access controls. However, a mistake occurs and the S3 bucket is made public temporarily, but long enough for someone to access and download the images.

Even though the bucket is hosted on AWS infrastructure, this incident is your responsibility, because you control and manage the security configuration of that bucket.

Real Examples

Amazon EC2 (Virtual Servers)

With EC2, you have significant control and responsibility.

AWS handles:

• Physical servers
• Hypervisor
• Data center security

You handle:

• OS patching (Linux/Windows updates)
• Firewall rules (security groups)
• SSH/RDP access
• Installed software vulnerabilities
• Application-level security

Common mistake:
Assuming AWS patches your EC2 operating system automatically. AWS does not.

Amazon S3 (Object Storage)

S3 is fully managed, but configuration is your responsibility.

AWS handles:

• Storage infrastructure
• Durability and availability
• Physical protection of disks

You handle:

• Bucket access policies
• Public vs private access
• Encryption settings
• Who can read or write data

Common mistake:
Leaving buckets publicly accessible because “AWS would block that if it was unsafe.”

AWS Lambda (Serverless)

As services become more managed, your responsibilities decrease, but never disappear.

AWS handles:

• Servers and OS
• Runtime environment
• Scaling and availability

You handle:

• IAM permissions for the function
• Secure handling of secrets
• Application logic
• Data access controls

Why This Model Matters for Security

There is a common misconception that security incidents in AWS are caused primarily by sophisticated attacks, but that could not be farther from the truth.

In reality, most incidents in AWS stem from customer-side errors, such as misconfigurations, weak identity controls, and insufficient monitoring. This is consistently highlighted in industry research, including Tenable 2025 Cloud Security Risk Report and Top Threats to Cloud Computing 2024 report published by the Cloud Security Alliance (CSA)

Because of this, it is critical to understand what falls under your responsibility so you can apply the appropriate security controls and guardrails to prevent issues such as:

• Public data exposure
• Overly permissive IAM roles
• Data tampering
• Unpatched systems
• Missing logs and alerts

Final Thoughts

AWS provides a highly secure cloud platform, but security is a shared effort. AWS secures the foundation; you secure everything built on top of it.