Shared Responsibility Model

Also Known As

TL;DR

Explanation

AWS, GCP, and Azure all use a shared responsibility model. The provider secures: physical facilities, hardware, network infrastructure, and the managed service (e.g. RDS patches). The customer secures: OS patching (IaaS), application code, data encryption, IAM configuration, network security groups, and secrets management. The boundary shifts with the service type: IaaS gives you OS responsibility; PaaS removes it; SaaS removes almost everything. Most cloud breaches are caused by customer-side misconfigurations, not provider-side vulnerabilities.

Diagram

flowchart TD
    subgraph AWS Responsibility
        PHYS[Physical security<br/>datacenters hardware]
        HYPERV[Hypervisor<br/>network infrastructure]
        MANAGED[Managed service internals<br/>RDS patching S3 durability]
    end
    subgraph Your Responsibility
        OS[OS patching<br/>EC2 instances]
        APP[Application security<br/>code vulnerabilities]
        DATA[Data encryption<br/>classification]
        IAM2[IAM permissions<br/>least privilege]
        NET[Security groups<br/>network ACLs]
    end
    LINE[Shared responsibility line<br/>shifts with service type] -.-> MANAGED & OS
style OS fill:#d29922,color:#fff
style IAM2 fill:#f85149,color:#fff
style DATA fill:#f85149,color:#fff
style LINE fill:#238636,color:#fff

Common Misconception

Why It Matters

Common Mistakes

• Public S3 buckets containing sensitive data — bucket access control is the customer's responsibility.
• Not patching EC2 instance OS — the provider manages the hypervisor; OS patching is your responsibility on IaaS.
• Overly permissive IAM roles — least privilege is always the customer's responsibility.
• Unencrypted data in managed databases — TDE may be available but enabling encryption is the customer's choice.

Code Examples

# Customer-side misconfigurations — cloud provider's fault? No:
# 1. S3 bucket: Block Public Access = OFF → public data breach (customer)
# 2. Security group: 0.0.0.0/0 on port 22 → brute forced (customer)
# 3. RDS: no encryption at rest → compliance failure (customer)
# 4. IAM role: AdministratorAccess on EC2 → SSRF → full account takeover (customer)

# Customer responsibilities checklist:
# ✅ S3: Block Public Access enabled on all buckets
# ✅ Security groups: minimal inbound rules, no 0.0.0.0/0 on SSH
# ✅ RDS: encryption at rest + in transit enabled
# ✅ IAM: least-privilege roles, MFA on root, no access keys for humans
# ✅ EC2: automated OS patching (AWS Systems Manager Patch Manager)
# ✅ Secrets: AWS Secrets Manager, not environment variables in userdata

References

• ↗ https://aws.amazon.com/compliance/shared-responsibility-model/

Tags

Related Terms