The Shared Responsibility Model

Security in the cloud is a partnership. AWS (Amazon Web Services, Amazon’s cloud platform) does not hand you a finished, fully-secured system; instead, AWS secures the parts it controls, and you secure the parts you control. This split is called the Shared Responsibility Model, and understanding exactly where the line sits is the single most important security idea in all of cloud computing. Get it wrong and you can leak millions of records while genuinely believing “AWS handles security.”

Security OF the cloud vs security IN the cloud

The model splits responsibility into two halves with a memorable phrasing.

AWS is responsible for security OF the cloud. This means the physical and foundational layer: data centers (the buildings full of servers), the physical hardware, the networking cables, the hypervisor (the software that runs many virtual machines on one physical server), and the internals of managed services. You never patch an AWS data center’s air conditioning or replace a failed hard drive — AWS does.
You are responsible for security IN the cloud. This means everything you put into the platform: your data, who can access it, the operating system and patches on your servers, firewall rules, encryption settings, and how you configure each service.

A simple way to remember it: AWS secures the infrastructure; you secure what you build and store on top of it.

Layer	Example	Who secures it
Physical data center	Building access, power, cooling	AWS
Hardware and host OS	Servers, storage disks, hypervisor	AWS
Network infrastructure	Backbone cables, edge routers	AWS
Guest OS and patches	Updating Linux on your EC2 server	You
Application code	Bugs, dependencies	You
Data	Encryption, classification	You
Access management	IAM users, roles, permissions	You
Network config	Security groups, S3 bucket policies	You

Gotcha: “AWS is secure” and “your AWS account is secure” are completely different statements. The platform can be world-class while your account is wide open because you left a door unlocked.

How the line shifts for managed services

The dividing line is not fixed — it slides depending on how “managed” the service is. The more AWS manages, the more of the stack AWS secures, and the less is left to you.

EC2 (Elastic Compute Cloud, virtual servers you rent): You get a bare virtual machine. You own the operating system, patching, firewall (security group) rules, and everything above. This is the most responsibility for you.
RDS (Relational Database Service, managed databases): AWS patches the database engine and the underlying OS for you, handles backups, and manages the host. You still control which users connect, network access, encryption choices, and the data inside.
Lambda (run code without managing servers): AWS manages the OS, runtime patching, and scaling entirely. You are responsible for your function code, its IAM permissions, and the data it touches — and almost nothing else infrastructure-wise.

Concern	EC2	RDS	Lambda
OS patching	You	AWS	AWS
DB engine patching	You	AWS	n/a
Scaling	You	Mostly AWS	AWS
Your code / data	You	You	You
IAM permissions	You	You	You
Network access rules	You	You	You

When to use this framing: every time you adopt a new service, ask “what just moved to AWS, and what is still mine?” The answer tells you exactly what you must still configure and monitor. Do not assume a managed service means “zero security work” — your data, access, and network config are always yours.

The biggest gotcha: misconfiguration is your fault

Here is the part that catches teams out. Nearly every famous AWS data breach was not an AWS failure — it was a customer leaving something misconfigured. The two repeat offenders are public S3 (Simple Storage Service, AWS object storage) buckets and over-permissive IAM (Identity and Access Management, the AWS permissions system).

Warning: If you make an S3 bucket public and someone downloads your customer data, that is 100% your responsibility, not AWS’s. AWS gave you the lock; you chose to leave it open.

Two cheap, fast checks catch most of this. First, confirm S3 Block Public Access is on for your account.

Console steps:

Sign in to the AWS Management Console and open the S3 service.
In the left menu, choose Block Public Access settings for this account.
Click Edit, tick Block all public access, and Save changes.

CLI: Account-level S3 Block Public Access (replace 123456789012 with your 12-digit account ID):

aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

To verify the setting took effect:

aws s3control get-public-access-block --account-id 123456789012

Output:

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}

Second, find any IAM users with no multi-factor authentication (MFA, a second login step beyond a password):

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 --decode

Output:

user,arn,password_enabled,mfa_active
alice,arn:aws:iam::123456789012:user/alice,true,true
bob,arn:aws:iam::123456789012:user/bob,true,false

Here bob has a password but no MFA — fix that immediately.

You can also enforce Block Public Access on new buckets with infrastructure as code (defining resources in a file instead of clicking):

Resources:
  SecureBucket:
    Type: AWS::S3::Bucket
    Properties:
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true

Cost note: none of these controls cost anything. S3 Block Public Access, IAM, MFA, and credential reports are all free — there is no financial excuse to skip them.

Best Practices

Treat your data and access management as always yours — these never shift to AWS, no matter how managed the service.
Turn on account-level S3 Block Public Access on day one, before any buckets exist.
Require MFA for every human IAM user, and never use the root account for daily work.
For each new service you adopt, explicitly write down what AWS now secures and what remains your job.
Use IAM least privilege: grant only the permissions actually needed, not broad * access.
Enable AWS Config and Security Hub to continuously flag misconfigurations instead of finding them after a breach.
Encrypt data at rest and in transit — the option is yours to turn on, so turn it on.

The Shared Responsibility Model

Security OF the cloud vs security IN the cloud

How the line shifts for managed services

The biggest gotcha: misconfiguration is your fault

Best Practices

Related Topics