PCI DSS Security Maturity Model·AWS v1.0.0
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 App Private subnet · Data tier (CDE) RDS KMS Account-wide logging & detection CloudTrail Config GuardDuty Security Hub Internet ▲ (users)
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 EC2 Amazon RDS AWS WAF AWS KMS AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub

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 Log archive Network / inspection PCI OU (dedicated) CDE workload account CDE in isolated VPC / subnets CDE workload account (2) 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.
  • 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 Transit Gateway AWS Network Firewall Amazon VPC AWS CloudTrail AWS Config Amazon GuardDuty AWS Security Hub AWS KMS