AWS Compliance Certifications: The Complete Guide

AWS compliance certifications are one of the strongest selling points Amazon Web Services has against on-premises infrastructure. AWS holds active attestations and certifications across roughly 100 frameworks across the major US, EU, APAC, and government markets.

The heavy hitters are SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, ISO 27701, PCI DSS Level 1, HIPAA eligibility, FedRAMP, IRAP, and C5. This guide explains which AWS compliance certifications matter for your business in 2026, how AWS's shared responsibility model works against each AWS compliance certification, and the common mistakes that turn a compliant cloud platform into a non-compliant deployment.

If you are evaluating AWS for a regulated workload, the question is not "is AWS compliant?" but "which AWS compliance attestation covers the controls my auditor will ask about?" Cloud compliance is layered. AWS attests to the controls that protect the underlying infrastructure. You attest to the controls that protect what you run on top of it. Misunderstanding that line is the single most expensive AWS compliance mistake.

If you are new to compliance frameworks generally, start with the cybersecurity compliance guide. For an apples-to-apples cloud comparison, see Azure compliance certifications. For the SaaS layer specifically, see SaaS compliance frameworks.

The AWS shared responsibility model in plain language

The shared responsibility model is the foundation of every AWS compliance conversation. AWS publishes the formal version on its compliance page; the practical version looks like this:

AWS is responsible for security OF the cloud:

• Physical security of data centers
• Hardware and the host operating system below the hypervisor
• Network infrastructure
• Service availability and underlying redundancy
• Underlying infrastructure software

You are responsible for security IN the cloud:

• Operating systems on EC2 (patching, hardening)
• Application code
• Data classification, encryption keys, and access controls
• Network configuration (security groups, NACLs, VPCs)
• Identity and access management
• Customer data, backups, and lifecycle

For managed services like S3, RDS, DynamoDB, and Lambda, AWS takes on more of the operating system layer, but you still own data, encryption, IAM, and network configuration. For fully managed AI and SaaS-style services like Bedrock or Q, AWS owns even more.

This split matters because every AWS compliance attestation covers only the AWS side of that line. Your SOC 2 auditor will not accept "AWS is SOC 2 attested" as evidence that your application is SOC 2 compliant. They will ask you to show how YOU manage IAM, encryption, logging, and access controls in the AWS account. That is your job.

AWS compliance certifications by framework

AWS publishes attestations or certifications across every major framework you are likely to be asked about. The four highest-volume ones for SaaS, fintech, and healthcare buyers are SOC, ISO, HIPAA, and PCI DSS.

SOC 1, SOC 2, and SOC 3 on AWS

AWS publishes a SOC 1 Type 2, SOC 2 Type 2, and SOC 3 report covering the in-scope AWS services. These are renewed semi-annually and cover the full 12-month preceding period.

• SOC 1: Focused on financial reporting controls. Useful if you process financial data on AWS and your customer is a publicly traded company subject to SOX.
• SOC 2 Type 2: Focused on security, availability, processing integrity, confidentiality, and privacy. The most-asked AWS attestation. Available under NDA via AWS Artifact.
• SOC 3: A public-facing summary of the SOC 2 report. No NDA required. Useful for marketing pages and prospect-facing security questionnaires.

The 2024 AWS SOC 2 Type 2 report covers more than 200 in-scope services across 32 regions, including all the high-volume building blocks (EC2, S3, RDS, Lambda, DynamoDB, IAM, KMS, CloudWatch, CloudTrail, GuardDuty, etc.) and most of the higher-level services. Newer services (typically launched in the last 6 to 12 months) are often out of scope until the next attestation cycle. AWS publishes a complete services-in-scope list at the AWS Services in Scope page.

For the SOC 2 framework itself, see the SOC 2 compliance guide. For the audit cost reality, see the SOC 2 audit cost guide.

ISO 27001, ISO 27017, ISO 27018, and ISO 27701 on AWS

AWS holds four ISO certifications, each addressing a different concern:

All four are issued by EY CertifyPoint, an accredited ISO certification body, and are renewed annually with a 3-year recertification cycle. For more on the AWS compliance certifications mapped to ISO 27001 and your own ISO 27001 program, see the ISO 27001 certification cost guide and the ISO 27001 Annex A controls breakdown.

HIPAA eligibility on AWS

HIPAA on AWS works differently from SOC 2 or ISO. AWS does not get "HIPAA certified" because no such certification exists (see the HIPAA vs HITRUST guide for why). What AWS provides instead is:

1. A signed Business Associate Addendum (BAA) you can execute through AWS Artifact.
2. A list of "HIPAA-eligible services" you can use to handle PHI under that BAA.

As of 2026, AWS lists more than 150 HIPAA-eligible services. The high-volume ones (EC2, S3, RDS, Lambda, DynamoDB, EFS, CloudFront, EBS) are all eligible. Some specialized services are not (legacy Mechanical Turk for example). AWS publishes the canonical list at the HIPAA Eligible Services page.

The BAA is a legal document, not a technical attestation. Signing the BAA does not automatically make your application HIPAA compliant. You still must:

• Encrypt PHI at rest and in transit (KMS for encryption keys is HIPAA-eligible).
• Configure IAM correctly (no shared admin accounts, least privilege).
• Maintain access logs (CloudTrail) and review them.
• Implement breach detection and response.
• Sign downstream BAAs with any subcontractors who touch PHI.

A working HIPAA program on AWS still needs a HIPAA risk assessment, HIPAA technical safeguards, and signed business associate agreements with downstream vendors.

PCI DSS Level 1 on AWS

AWS is a PCI DSS Level 1 service provider, which is the highest level (over 6 million transactions per year). The PCI DSS Attestation of Compliance (AOC) is renewed annually and covers more than 175 services as of 2026. The AOC is available through AWS Artifact.

What this gives you:

• AWS handles infrastructure-level PCI DSS controls (data center security, network segmentation between tenants, etc.).
• You can use AWS for cardholder data environments without disqualifying yourself from PCI DSS.
• AWS provides the AOC as evidence to your QSA during your own PCI DSS audit.

What this does NOT give you:

• Compliance for your application. You still need your own PCI DSS SAQ or QSA-led audit.
• Automatic scope reduction. Your scope is determined by where cardholder data flows in your application, not by AWS.
• Permission to skip PCI DSS pen testing. Application-layer pen tests are still required.

For the PCI DSS framework details, see the PCI DSS compliance guide and PCI DSS 4.0 requirements.

FedRAMP, ITAR, and government workloads on AWS

For US government workloads, AWS publishes attestations across FedRAMP, DoD SRG, ITAR, CJIS, and FIPS 140-2/3. The two AWS environments built specifically for government workloads:

• AWS GovCloud (US): Two regions (US-East and US-West) with FedRAMP High authorization, DoD SRG IL2/IL4/IL5, ITAR support, and a dedicated US-citizen-only operations team.
• AWS Secret Region: Restricted access for US Intelligence Community workloads at the SECRET classification level.

Standard AWS commercial regions hold FedRAMP Moderate authorization, which is sufficient for most non-classified federal workloads. For CMMC and NIST 800-171 requirements, the GovCloud regions are typically required for CUI handling. See the NIST 800-171 CMMC requirements guide for details.

EU and APAC compliance on AWS

For EU and APAC markets, AWS holds:

• C5 (Germany): Cloud Computing Compliance Controls Catalog, required by some German federal customers.
• ENS High (Spain): Esquema Nacional de Seguridad, required for Spanish government suppliers.
• TISAX (Germany): Automotive industry data exchange standard.
• IRAP (Australia): Information Security Registered Assessors Program, required for Australian government workloads.
• MTCS Tier 3 (Singapore): Multi-Tier Cloud Security standard.
• K-ISMS (Korea): Information Security Management System.
• MEITY (India): Empanelment for Indian government cloud workloads.
• GDPR readiness: AWS is not "GDPR certified" (GDPR has no certification scheme), but AWS publishes a GDPR-ready Data Processing Addendum and ISO 27018 attestation. For your own GDPR program, see the GDPR compliance guide.

Where to find AWS compliance certifications: AWS Artifact

AWS Artifact is the on-demand portal for downloading every AWS compliance certification report under NDA. SOC 1, SOC 2, ISO 27001 certificates, PCI DSS AOC, FedRAMP package, and the BAA are all there. Access requires an AWS account with the appropriate IAM permissions.

A few practical notes from auditor-facing engagements:

• The SOC 2 report from Artifact is acceptable evidence for your own SOC 2 audit when listed in your subservice organization controls.
• The ISO 27001 certificate is acceptable evidence for your own ISO 27001 supplier review.
• The PCI DSS AOC is the document your QSA will need to validate AWS as a service provider in your scope.
• You typically refresh these documents in your evidence library every 6 months.

Where AWS compliance ends and your work begins

A common mistake we see in SOC 2 audits for SaaS startups: the team assumes "we're on AWS" answers most security questions on a vendor risk assessment. It does not. The auditor will still ask:

• How do you manage IAM users and roles? (Your IAM, not AWS's.)
• How do you rotate access keys? (Your policy.)
• How do you encrypt data at rest? (Your KMS configuration.)
• How do you log and review access? (Your CloudTrail and CloudWatch setup.)
• How do you scan for vulnerabilities in EC2 AMIs and container images? (Your scanner, your remediation process.)
• How do you respond to security incidents? (Your runbooks, your team.)

AWS being SOC 2 attested is the floor, not the ceiling. Every auditor we have worked with treats AWS attestations as a precondition for their work, not a substitute for it.

For the broader cloud security setup, see the best CSPM tools guide and the best vulnerability scanners list.

Common AWS compliance certifications mistakes

A short list of the patterns that show up in audit findings most often:

1. Public S3 buckets. Still the most common AWS audit finding. Block Public Access at the account level by default. Use AWS Macie or a CSPM tool to detect drift.
2. Long-lived IAM access keys. Rotate every 90 days at most. Prefer IAM Roles for Service Accounts (IRSA) and SSO over long-lived users.
3. Disabled CloudTrail in some regions. CloudTrail must be enabled in every region you operate in, with logs centralized and immutable.
4. Missing encryption defaults. Enable default encryption on S3, EBS volumes, and RDS. Use KMS with customer-managed keys (CMKs) for regulated data.
5. Untagged resources. No tags means no ownership, no cost attribution, and no scoping for compliance. Enforce a tagging policy via AWS Organizations SCPs.
6. Forgotten regions. Workloads spin up in regions not in your compliance scope. Lock regions via SCPs from day one.
7. No formal account separation. Production, staging, and dev should be separate AWS accounts. Use AWS Control Tower to enforce.
8. Out-of-scope services. A team uses a service AWS launched 3 months ago that is not yet in the SOC 2 / PCI / HIPAA scope list. Check the in-scope list before adoption.

A working compliance automation tool catches most of these in continuous monitoring. See the compliance automation tools guide for vendor options.

Frequently Asked Questions

Is AWS HIPAA compliant?

AWS is HIPAA eligible, not HIPAA certified (no such certification exists). To use AWS for PHI, you must execute the AWS BAA via AWS Artifact and use only HIPAA-eligible services from the published list. You still need your own HIPAA program: risk assessment, technical safeguards, signed BAAs with downstream vendors, and an incident response plan.

Is AWS SOC 2 compliant?

Yes. AWS publishes a SOC 2 Type 2 report covering 200+ services, refreshed semi-annually. Available via AWS Artifact under NDA. The SOC 3 report is publicly available for marketing use. AWS being SOC 2 attested does not mean your application is SOC 2 compliant, you still need your own audit.

Is AWS PCI DSS compliant?

AWS is a PCI DSS Level 1 service provider, the highest tier (over 6 million annual transactions). The Attestation of Compliance is available via AWS Artifact and covers 175+ services. Your application still needs its own PCI DSS audit (full QSA-led ROC or self-assessment SAQ).

Is AWS FedRAMP compliant?

AWS holds FedRAMP Moderate authorization for commercial regions and FedRAMP High authorization for AWS GovCloud (US). For most federal workloads, GovCloud is required when handling CUI or operating under DoD impact levels above IL2.

What does AWS Artifact provide?

AWS Artifact is the portal for downloading AWS compliance documents: SOC 1, SOC 2, SOC 3, ISO certificates, PCI DSS AOC, FedRAMP package, BAA, ENS, C5, IRAP, and many others. Access requires an AWS account with appropriate IAM permissions.

Does AWS being compliant mean my application is compliant?

No. AWS handles security OF the cloud (data centers, hypervisor, network). You handle security IN the cloud (IAM, encryption, application code, data, OS patching). Every AWS compliance attestation covers only the AWS side. You still need your own audits for your application layer.

How often does AWS refresh its compliance attestations?

SOC reports refresh every 6 months. ISO certifications recertify every 3 years with annual surveillance audits. PCI DSS AOC refreshes annually. FedRAMP authorizations have annual continuous monitoring with 3-year reauthorization cycles. Refresh your evidence library every 6 months.

Sources and further reading

• AWS Compliance programs official page.
• AWS Services in Scope by Compliance Program.
• AWS HIPAA Eligible Services Reference.
• AWS Artifact (compliance reports portal).
• AWS Shared Responsibility Model.