Is AWS SOC 2 Compliant? What the Shared Responsibility Model Means
AWS holds its own SOC 2 Type 2 report covering 188 services — but that report says nothing about whether your company is compliant.
The question comes up constantly, especially from startups that have just been asked for a SOC 2 report by a prospective customer: "We run entirely on AWS — doesn't that count for something?"
It counts for quite a bit, actually. But not in the way most people assume.
AWS does have a SOC 2 report
Yes — AWS holds a current SOC 2 Type 2 report audited by an independent CPA firm. The Spring 2026 report covers 188 AWS services over the 12-month period from April 1, 2025 through March 31, 2026, and it addresses the Security, Availability, Confidentiality, and Privacy Trust Services Criteria. AWS publishes its SOC compliance details here, and the actual report is available through a self-service portal called AWS Artifact.
To get the report: log in to your AWS Management Console, navigate to AWS Artifact, find the SOC 2 Type 2 report under AWS reports, and download it. There's no fee. You will agree to terms that restrict how you share the document — it's not for public distribution, and you should treat it the way you'd treat any confidential vendor report. Your auditor will want access to it; sharing it with a prospective customer's security team for due diligence is also reasonable.
AWS releases new reports twice a year (typically spring and fall), so whatever you download today reflects controls tested over the most recent full audit period.
What that report actually proves
AWS's SOC 2 report is an auditor's opinion that AWS's controls over its infrastructure met the Trust Services Criteria for the covered period. Physical data centers, hardware, networking, the hypervisor layer, the global backbone: all of that lives in AWS's report.
What it doesn't say anything about: your application, your data, your IAM configuration, your logging setup, your incident response plan, or your access control policies. Those belong to you.
This is the crux of the AWS Shared Responsibility Model, which AWS has documented clearly and which auditors understand well. AWS calls it "security of the cloud" versus "security in the cloud." AWS's report covers the former. Your SOC 2 audit covers the latter.
What you actually inherit from AWS
The shared model isn't a reason to feel empty-handed. Running on AWS genuinely reduces the scope of what your auditors need to evaluate. You don't have to demonstrate physical access controls for your data center — AWS's report handles that. You don't have to describe how you protect the hypervisor from other tenants.
Controls you're likely to inherit (because AWS handles them in their report):
- Physical security of data center facilities
- Hardware maintenance and end-of-life procedures
- Network redundancy and backbone resilience
- Hypervisor security and multi-tenant isolation
Controls you definitely still own:
- Identity and access management (IAM policies, least-privilege configurations, MFA enforcement)
- Encryption settings for your data at rest and in transit
- Security group and VPC configurations
- Logging and monitoring (CloudTrail, CloudWatch, or your own SIEM setup)
- Vulnerability management for your application code and OS-level software
- Access reviews for your users and service accounts
- Incident response procedures
That second list is where most SOC 2 findings end up for companies running on AWS. The infrastructure is trustworthy; the configuration and operational discipline on top of it is the actual audit surface.
The common mistake: conflating AWS's report with your own compliance
Every year I see companies add "hosted on AWS" to their security page as if it implies something about their own controls. It doesn't, and a buyer with a capable security team will know it doesn't.
The correct framing is: "AWS's SOC 2 report covers the infrastructure layer. Our SOC 2 report covers the application and operational controls we've built on top of it." Both matter. The first doesn't replace the second.
A related mistake is scoping your SOC 2 audit and then forgetting to include AWS-specific evidence: screenshot of MFA enforcement on your AWS root account, a policy showing how you handle IAM key rotation, evidence that you review which IAM roles have broad permissions and how often. These are precisely what an auditor will test, and they're yours to produce — not AWS's.
How to reference AWS's report in your own audit
When you go through your own SOC 2 Type 2 audit, your auditor will likely ask about your "complementary subservice organization controls" — the controls you've outsourced to vendors like AWS and are relying on as part of your control environment. The standard way to handle this is to obtain AWS's SOC 2 report, review it, confirm the controls you're relying on are included and operated effectively, and document that review.
This is a real deliverable, not a checkbox. If you say in your own description of controls that "physical security is managed by our cloud infrastructure provider," your auditor will want to see that you've verified the provider's report says so — and that the report period is current.
The same principle applies to every significant vendor you rely on. Your own vendor risk program should include an annual review of your critical vendors' reports. AWS is usually the first one on that list for a cloud-native company, but it's never the last. I'd work through a structured review using the vendor risk assessment checklist to make sure you're capturing the right control areas from each provider's report.
Your auditor doesn't care that AWS passed its audit. They care that you reviewed AWS's report, understood which controls you're relying on, and built compensating controls for everything the report doesn't cover.
SOC 2 Type 1 vs Type 2 for AWS's report specifically
AWS publishes only Type 2 reports, which is the right answer. A snapshot of existence would be fairly meaningless for infrastructure at AWS's scale. The bi-annual cadence means the most recent report is always reasonably fresh, covering a 12-month period.
For your own company's audit, the Type 1 vs Type 2 question is separate and depends on your timeline and what customers are demanding. If you're starting from zero and a deal is on the line, a Type 1 unblocks you faster. But enterprise buyers who actually read security paperwork will want a Type 2 showing your controls ran consistently over time. It's the same logic as why AWS only publishes Type 2. I covered that tradeoff in detail in SOC 2 Type 1 vs. Type 2.
How to actually verify AWS's SOC 2 status yourself
For any vendor you're evaluating — not just AWS — the right verification method isn't asking their sales team. It's:
- Go to their trust center or compliance page (for AWS: aws.amazon.com/compliance/soc-faqs)
- Confirm they publish SOC 2 Type 2 reports and check how frequently they're updated
- Request or download the actual report — AWS makes this self-service through Artifact, but many other vendors require an NDA or a manual request
- Check the audit period: is the report current, or is it two years old?
- Confirm your specific services are in scope — AWS lists its in-scope services at aws.amazon.com/compliance/services-in-scope/SOC/
That last point matters more than people realize. AWS's report doesn't cover every service automatically — it covers the services in scope for the relevant audit period. If your architecture depends on a newer AWS service that isn't yet in the report, you'll need to handle that in your own controls or wait for it to make the next report cycle.
The same verification method works for any vendor, and it's worth internalizing as a practice. When a vendor says "we're SOC 2 compliant," the right follow-up is always "can you share the Type 2 report?" — not because you distrust them, but because that's the only claim that's been independently verified. The full SOC 2 guide explains what's actually inside those reports and how to read them.