AWS Shared Responsibility Model

Definition

The AWS Shared Responsibility Model splits security and compliance duties between AWS and the customer. AWS is responsible for security of the cloud — physical data centers, hypervisor, managed service infrastructure, and global network. The customer is responsible for security in the cloud — data classification, encryption choices, IAM, network configuration, operating system and application patching (depending on service model), and logging. The split shifts by service type: EC2 puts more on you; S3 and RDS put more on AWS for the underlying stack. Compliance certifications (SOC, ISO, HIPAA eligibility) cover AWS’s portion; your audit still requires customer-side controls.

When to use it

• Architecture and security reviews — map each component to AWS vs customer responsibilities before sign-off.
• Compliance program design — auditors ask what you control vs what AWS attests to; this model is the vocabulary.
• Vendor and customer education — clarifies why “AWS is HIPAA compliant” does not mean your app is compliant by default.
• Incident response runbooks — determines whether a patch, config change, or AWS service event is your action item.
• Service selection — choosing managed services (Lambda, Aurora, Bedrock) vs self-managed EC2 shifts the boundary deliberately.

When not to use it

• Excuse for unencrypted data — “AWS secures the cloud” does not mean your S3 buckets are encrypted or private unless you configure them.
• One-size mapping across all services — responsibility differs for IaaS, PaaS, and SaaS-style AWS offerings; read the service-specific security page.
• Replacing a threat model — the model describes ownership, not attack surface analysis.

Tips

• Read the service-specific security documentation for each workload (RDS, EKS, Bedrock, etc.) — the boundary moves per service.
• Default to encrypt at rest and in transit even when not automatic — RDS, EBS, and S3 often require explicit enablement.
• Own IAM, logging, and backup retention even on fully managed services — AWS provides the capability; you configure retention and access.
• Document customer controls in your System Security Plan or SOC workbook with evidence (Config, CloudTrail, screenshots).
• Use AWS Artifact for AWS compliance reports; pair with your internal control testing for the customer side.

Gotchas

Serious

• Assuming encryption is on by default — many services offer encryption but require you to enable it at creation time; retroactive encryption often means migration.
• Unpatched guest OS on EC2 — AWS patches the hypervisor; you patch the AMI — unpatched EC2 is still your breach vector.
• Compliance conflation — HIPAA-eligible service + signed BAA ≠ your application is HIPAA compliant without access controls, audit logs, and BAAs with your own subprocessors.

Regular

• Blaming AWS for misconfigured security groups — network access control is customer responsibility for EC2/RDS/EKS.
• Ignoring shared controls — patch management, configuration management, and awareness training span both sides depending on service.
• Using root credentials — credential management is entirely customer responsibility.

Official references

• AWS Shared Responsibility Model
• AWS Cloud Security
• Security in AWS documentation
• AWS Artifact (compliance reports)

Related FactualMinds content

• AWS Cloud Security Services
• Cloud Compliance Services
• HIPAA on AWS: Complete Compliance Checklist