AWS PCI Compliance: Shared Responsibility for Card Data in AWS

AWS PCI compliance is shared. Amazon Web Services is assessed as a PCI DSS Level 1 service provider, so the data centres, hardware, hypervisor and the infrastructure behind the AWS services it lists as in scope have already been checked. Everything you build on top, from identities and network rules to operating systems, encryption keys, logs, containers and code, is yours to secure and yours to evidence when you are assessed against PCI DSS v4.0.1.

This guide takes the assessor’s view of AWS PCI DSS compliance: what AWS’s attestation lets you rely on, and how to design and document a cardholder data environment (CDE) in AWS. For other hosting models, see our guide to PCI compliant hosting.

Is AWS PCI compliant?

Yes, for the services in its PCI DSS scope. AWS validates as a Level 1 service provider and publishes its Attestation of Compliance (AOC) and a PCI DSS responsibility summary in AWS Artifact, the compliance portal in the AWS console.

Not every AWS service is covered. AWS maintains a list of services in scope for each compliance programme, and you should confirm a service is on it before card data touches it. If it is not, AWS’s AOC gives you nothing for that service and the gap falls on your own assessment.

Which AWS services are PCI compliant?

The AWS PCI services you can rely on are the ones AWS lists under PCI on its AWS Services in Scope by Compliance Program page, and the AOC in AWS Artifact names the services its assessment covered. To check your own set-up:

1. List every service in the card data flow, not just the obvious ones. Supporting services such as IAM, KMS, CloudTrail, CloudWatch, load balancers and the services in your deployment pipeline can affect the security of card data, so they count.
2. Check each one against the PCI list on the AWS Services in Scope page.
3. Download the current AOC and responsibility summary from AWS Artifact and confirm the AOC was signed within the last 12 months.
4. Check again before you adopt a new service. Newly launched services are not always in scope straight away.

A service missing from the list can still be used near your CDE, but it must not store, process or transmit card data, and any control it provides is tested in your own assessment rather than covered by AWS’s AOC.

AWS is a third-party service provider (TPSP) to you, so Requirement 12.8 applies. You must list AWS as a provider, hold a written agreement, monitor its compliance status at least once every 12 months (12.8.4) and record which requirements AWS meets, which you meet and which are shared (12.8.5). The AOC and the responsibility summary are the evidence for all of these.

Does using AWS make me PCI compliant?

No. AWS takes some requirements off your plate, mainly physical security, but it does not validate your environment. You still complete the SAQ or Report on Compliance (ROC) your acquirer requires, and the assessor tests your configuration, not AWS’s. Our free PCI compliance check suggests which SAQ your set-up points to. How much is left depends on the services you use:

The more managed the service, the more AWS takes on. A database on RDS moves operating system patching to AWS; the same database on EC2 leaves it with you. Your own responsibility matrix should map the AWS responsibility summary onto the services you actually run.

How do you segment a CDE in AWS?

Start with account boundaries, then add network and identity controls inside them. In AWS, segmentation is not only a network question, because an IAM role can reach across a boundary that no security group would allow. A pattern that holds up well at assessment:

1. A dedicated AWS account, or accounts, for the CDE under AWS Organizations, with service control policies limiting what can happen there.
2. Private subnets in a dedicated VPC, with security groups allowing only the traffic each component needs and network ACLs as a second layer. Requirements 1.3.1 and 1.3.2 require inbound and outbound CDE traffic to be restricted to what is necessary, with all other traffic denied.
3. VPC endpoints, so CDE workloads reach services such as S3 and KMS without crossing the internet, and controlled egress for anything that must.
4. Separate identities, so no role in an out-of-scope account can assume a role in the CDE account unless that path is itself in scope.

Segmentation cannot remove everything. Systems that connect to the CDE or can affect its security stay in scope. In AWS that usually includes the Organizations management account, your identity provider, the CI/CD pipeline that deploys into the CDE, the central logging account and administrators’ devices. Our PCI DSS scoping guide explains connected-to and security-impacting systems in detail.

If segmentation reduces your scope, Requirement 11.4.5 requires it to be penetration tested at least once every 12 months and after any change to segmentation controls; service providers must test every six months under 11.4.6. Our AWS penetration testing service covers that work, including IAM paths between accounts, and our guide to AWS penetration testing rules explains what AWS allows customers to test.

How do EKS and Kubernetes fit into PCI scope on AWS?

If a pod processes card data, the cluster it runs in is part of your CDE: the worker nodes, the Kubernetes API and its role-based access control, the container images and the pipeline that builds them. That holds whether you run Kubernetes on Amazon EKS or manage your own clusters on EC2; on EC2 you also own the control plane. Kubernetes namespaces alone are not a boundary an assessor will accept without evidence, because pods on the same node share a kernel and, by default, can reach each other over the network.

The cleanest designs give card-processing workloads their own cluster, or at least their own node group with network policies that deny traffic by default, and then prove the isolation by testing. Other points assessors check in Amazon EKS:

• API endpoint access: a private endpoint, or a public one restricted to known addresses, with MFA on every human identity that reaches it.
• Pod identities: each workload has its own narrowly scoped IAM role, rather than inheriting the permissions of the node.
• Images: built from approved base images, scanned for vulnerabilities in Amazon ECR or the pipeline, and patched under 6.3.3.
• Logs: containers are short-lived, so logs must be shipped off the container as they are written. EKS control plane logging is off until you enable it.

The PCI SSC information supplement Guidance for Containers and Container Orchestration Tools, free from the PCI SSC document library, covers these risks in more depth.

What logging evidence do assessors expect in AWS?

The logs usually exist; the gap is showing they are complete, protected and reviewed. Expect to show:

• CloudTrail enabled across all accounts and regions, ideally as an organisation trail, so administrative actions (10.2.1.2) and changes to identities and credentials (10.2.1.5) are recorded.
• Data access logs for individual access to cardholder data (10.2.1.1): CloudTrail data events for S3 buckets holding card data, database audit logs and application logs, plus VPC Flow Logs for CDE subnets.
• Protection: logs sent to a separate log archive account, with S3 Object Lock or equivalent controls so they cannot be altered (10.3.2 and 10.3.3).
• Retention: at least 12 months, with the most recent three months immediately available for analysis (10.5.1).
• Automated review: Requirement 10.4.1.1, mandatory since 31 March 2025, requires automated mechanisms for audit log reviews. GuardDuty, Security Hub or a SIEM can do this, but you must show who acts on the output.
• Time synchronisation from a trusted source such as the Amazon Time Sync Service (10.6).
• Control failure alerts when a critical control such as CloudTrail or GuardDuty stops working (10.7.2, also mandatory since 31 March 2025).

Our guide to PCI DSS Requirement 10 covers every logging sub-requirement.

How should card data be encrypted and keys managed in AWS?

Stored PANs must be unreadable (Requirement 3.5.1), and the keys protecting them must be managed under Requirements 3.6 and 3.7. AWS KMS and CloudHSM handle the hardware; your key policies and procedures are what the assessor examines.

Treat default storage encryption, such as EBS volume or RDS storage encryption, as a baseline rather than the answer. It is transparent to anyone with access to the running system, so assessors usually treat it like disk-level encryption, and Requirement 3.5.1.2, mandatory since 31 March 2025, allows disk-level or partition-level encryption on its own only for removable media. Plan to render PANs unreadable at field level as well, through tokenisation, truncation, keyed cryptographic hashing (3.5.1.1) or application-level encryption. Better still, do not store PANs at all.

For AWS PCI tokenisation there are two broad routes. Tokens from your payment provider keep PANs out of your AWS accounts altogether, so only the systems that capture the card stay in scope. A token vault you build in AWS takes PANs out of the rest of your estate, but the vault, its KMS keys and anything that can de-tokenise remain in your CDE and must be segmented from everything else.

Do AWS PCI compliance tools prove you are compliant?

No. AWS’s own tools generate useful evidence for AWS PCI compliance, but none of them validates it. Your assessor still tests your controls, processes and records directly:

Why Sovereign Secure

• We are a PCI SSC-approved Qualified Security Assessor (QSA) company, Qualified PIN Assessor (QPA) and Card Production Security Assessor (CPSA), and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.
• Our cloud penetration testing covers AWS segmentation, IAM and workloads, with reports written to the standard an assessor expects.
• External ASV scans are delivered through our PCI SSC Approved Scanning Vendor partner, so your quarterly scans and testing are co-ordinated.
• We are ISO 27001 certified ourselves.

Next step

Tell us how many AWS accounts you run, where card data enters and leaves, and which services it touches. Through our PCI DSS consultancy, we will confirm what is in scope, review your responsibility matrix against the AWS summary and set out the shortest route to validation.