PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Reference architectures

Reference architectures

Two reference paths for hosting a PCI DSS cardholder data environment (CDE) on AWS. Each recommendation's detail page shows how the control is implemented in both paths. Start with the single-account 3-tier design for smaller or early-stage environments, and adopt the multi-account design as scale, separation of duties, and scope-reduction needs grow.

Single-account, 3-tier
Best for small teams, proofs of concept, or a single workload where the operational overhead of multiple accounts is not yet justified. All PCI DSS responsibilities are concentrated in one account.
Multi-account with a dedicated PCI OU
Best for organizations with multiple workloads, teams, or environments that need strong separation of duties, blast-radius isolation, and reduced PCI DSS scope. Recommended as the target state for production CDEs at scale.

Single-account, 3-tier

A single AWS account hosting a classic three-tier application (web, application, and data tiers) inside one VPC, with the CDE isolated in dedicated private subnets. The simplest starting point to run a compliant CDE on AWS.

AWS account VPC Public subnet ALB WAF CloudFront Private subnet · App tier (CDE) EC2 SSM Private subnet · Data tier (CDE) RDS KMS Account-wide logging & detection CloudTrail Config GuardDuty Security Hub
Single AWS account with one VPC. Public subnet hosts the load balancer; private subnets host the application and database tiers (the CDE). Guardrails and detection apply account-wide.

When to use

Best for small teams, proofs of concept, or a single workload where the operational overhead of multiple accounts is not yet justified. All PCI DSS responsibilities are concentrated in one account.

Design principles

  • Separate tiers into their own subnets: public (load balancer), private application, and private data.
  • Place the CDE (systems that store, process, or transmit account data) in dedicated private subnets with no direct inbound access from the internet.
  • Control traffic between tiers with per-tier security groups referencing each other, plus restrictive network ACLs.
  • Front public entry points with an Application Load Balancer and AWS WAF; terminate TLS with ACM certificates.
  • Encrypt data at rest with AWS KMS customer managed keys and enable account-wide logging and detection (CloudTrail, Config, GuardDuty, Security Hub).

AWS services

Amazon VPC Elastic Load Balancing Amazon CloudFront Amazon EC2 Amazon RDS Amazon DynamoDB AWS WAF Amazon API Gateway AWS Lambda AWS Certificate Manager AWS Private CA AWS KMS AWS CloudHSM AWS Secrets Manager Amazon Macie AWS Systems Manager EC2 Image Builder AWS Shield Amazon Inspector Amazon ECR AWS CodePipeline AWS CodeBuild Amazon CodeGuru Amazon SES Amazon Route 53 Resolver DNS Firewall AWS Step Functions Amazon EventBridge AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub Amazon Detective AWS Artifact

Multi-account with a dedicated PCI OU

An AWS Organizations landing zone where the CDE lives in workload accounts under a dedicated PCI organizational unit (OU), separated from non-PCI workloads. Centralized security, logging, and network accounts provide guardrails, aggregation, and inspection.

AWS Organizations Shared / foundational accounts Security tooling (delegated admin) Security Hub GuardDuty Config FMS Macie Log archive CloudTrail S3 (WORM) Tamper-resistant central logs Network / inspection Transit GW Network FW Central egress & inspection PCI OU (dedicated) CDE workload account VPC EC2 RDS KMS Secrets Mgr SSM CDE in isolated VPC / subnets CDE workload account (2) VPC ALB WAF Img Builder Additional CDE workloads, same guardrails SCPs applied at the PCI OU enforce guardrails (deny disabling logging/encryption, restrict Regions).
AWS Organizations with a dedicated PCI OU for CDE workload accounts, plus shared security, log-archive, and network accounts. Traffic is inspected centrally; guardrails apply via SCPs.

When to use

Best for organizations with multiple workloads, teams, or environments that need strong separation of duties, blast-radius isolation, and reduced PCI DSS scope. Recommended as the target state for production CDEs at scale.

Design principles

  • Isolate the CDE in dedicated workload accounts under a PCI OU, separate from non-PCI accounts.
  • Use service control policies (SCPs) at the PCI OU to enforce guardrails (e.g. deny disabling logging or encryption, restrict regions).
  • Centralize audit logs in a dedicated log-archive account with restricted, tamper-resistant access.
  • Centralize detection and posture in a security tooling account (GuardDuty, Security Hub, Config aggregator) as delegated administrator.
  • Apply and remediate network protections org-wide from that account with AWS Firewall Manager (security-group, WAF, and Network Firewall policies across the PCI OU).
  • Route and inspect inter-VPC and egress traffic through a central network account (Transit Gateway + AWS Network Firewall).
  • Provision the landing zone and account baselines consistently with AWS Control Tower and infrastructure as code.

AWS services

AWS Organizations AWS Control Tower AWS Firewall Manager AWS Transit Gateway AWS Network Firewall Amazon VPC Amazon CloudFront AWS RAM Amazon API Gateway AWS Lambda Amazon DynamoDB AWS Certificate Manager AWS Private CA AWS Systems Manager EC2 Image Builder AWS Secrets Manager AWS KMS AWS CloudHSM Amazon Macie AWS Shield Amazon Inspector Amazon ECR AWS CodePipeline AWS CodeBuild Amazon CodeGuru Amazon SES Amazon Route 53 Resolver DNS Firewall AWS Step Functions Amazon EventBridge AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub Amazon Detective Amazon OpenSearch Service AWS Artifact