SOC 2 on AWS: the shared responsibility model and mapping native services to controls
Running on AWS does not make you SOC 2 compliant, but it gives you most of the building blocks. Here is how the shared responsibility model works and which native services map cleanly to Trust Services Criteria.
AWS is a subservice organization, not your compliance program
The single most common misunderstanding is that hosting on AWS confers SOC 2 compliance. It does not. AWS maintains its own SOC 1, SOC 2, and SOC 3 reports covering the security of the cloud itself: data centers, hardware, the hypervisor, and the managed-service control plane. In SOC 2 language, AWS is a subservice organization to your audit, and its report demonstrates that the infrastructure layer is sound. Everything you build on top of it, your data, identities, network configuration, and application logic, falls under security in the cloud and is squarely your responsibility. Your auditor will assess your controls against the AICPA Trust Services Criteria, and a clean AWS report does nothing to cover gaps in how you configured your account.
How the shared responsibility line actually falls
AWS frames its model as security of the cloud versus security in the cloud, and the practical division depends heavily on which services you consume. With raw EC2 you own patching, OS hardening, and host configuration; with managed services like RDS, Lambda, or Fargate, AWS absorbs more of the operational burden but you still own access, encryption choices, and data lifecycle. Network boundaries via VPCs, security groups, and NACLs are entirely yours to design, as are key policies, logging configuration, and IAM. A useful exercise before an audit is to walk each Common Criteria area and write down which side of the line each control sits on, because auditors increasingly expect you to articulate this mapping rather than wave at the AWS report.
Mapping native services to Trust Services Criteria
Most of the Common Criteria map to AWS primitives you may already run. IAM, with least-privilege policies, roles, permission boundaries, and enforced MFA, supports the logical access criteria (CC6). CloudTrail captures management and data-plane API activity for the audit-logging expectations under CC7, while CloudWatch and EventBridge handle alerting and anomaly thresholds. KMS, with customer-managed keys and rotation, underpins encryption at rest, and ACM plus TLS policies cover encryption in transit. Config tracks resource state and drift, Security Hub aggregates findings against standards like the AWS Foundational Security Best Practices and CIS benchmarks, and GuardDuty provides threat detection across accounts. AWS Backup, with documented retention and tested restores, supports availability and recovery if you scope that criterion in.
Carving out AWS in your report
Nearly every AWS-hosted company uses the carve-out method, where your system description names AWS as a subservice organization and explicitly excludes AWS's controls from your auditor's testing. The alternative, the inclusive method, would fold AWS's controls into your report and is impractical because AWS will not submit to your auditor. Choosing carve-out is not a free pass: you must document the controls you rely on AWS to perform, the complementary subservice organization controls, and crucially your own monitoring of AWS. In practice that means obtaining AWS's SOC 2 report through AWS Artifact at least annually, reviewing it for exceptions and the bridge period, and retaining evidence that you actually performed that review. Auditors look for this vendor-management step and frequently flag its absence.
Practical guidance for AWS-native teams
Start by enabling CloudTrail across all regions and accounts, turning on Config recorders, and switching on GuardDuty and Security Hub organization-wide; these generate the continuous evidence trail auditors want and are cheap relative to remediation under time pressure. AWS Audit Manager ships a prebuilt SOC 2 framework that maps Config rules, Security Hub findings, and CloudTrail events to control activities and automates much of the evidence collection, which pairs well with a compliance-automation platform if you use one. Treat multi-account structure through AWS Organizations as a control in itself, since blast-radius isolation and centralized guardrails are easier to evidence than per-account exceptions. Finally, remember the audit tests operating effectiveness over a Type 2 window, so the goal is consistent configuration over months, not a one-time cleanup the week before fieldwork begins.