Shared Responsibility Model
debt(d5/e5/b7/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints.tools list includes aws-config, scout-suite, prowler, and securityhub — all specialist cloud security scanning tools. Common misconfigurations like public S3 buckets, open security groups, and missing MFA are detectable by these tools but not by a standard linter or compiler. The issues are silent in production until a scan runs or a breach occurs, but the tooling does exist to catch them.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix is conceptually a one-liner ('AWS secures the cloud; you secure everything in the cloud'), but the common_mistakes reveal that remediation spans multiple domains: IAM policy rewrites, S3 bucket policy changes, OS patching processes, and database encryption enablement. Each fix is individually modest, but collectively they touch many parts of the infrastructure configuration, making the remediation effort a multi-file/multi-resource exercise.
Closest to 'strong gravitational pull' (b7). The applies_to covers both web and cli contexts, and the tags (cloud, security, compliance) indicate this is a foundational security posture choice. Every future infrastructure change — new S3 bucket, new EC2 instance, new RDS instance, new IAM role — must be evaluated against the shared responsibility model. It shapes all cloud configuration decisions and imposes a persistent security review overhead on every deployment.
Closest to 'serious trap' (t7). The misconception field directly captures the trap: developers assume that using a managed cloud service (e.g., RDS, S3) means the provider handles all security. This contradicts the reasonable mental model that 'managed' implies 'secured for me.' The trap is serious because it contradicts how similar concepts (fully managed SaaS, on-premises managed services) work, and the 'obvious' assumption — that AWS manages a managed database fully — is dangerously wrong in a security context.
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
https://aws.amazon.com/compliance/shared-responsibility-model/