PCI DSS Compliance on AWS: Architecture Guide for Fintech

Payment Card Industry Data Security Standard (PCI DSS) compliance is one of the most technically demanding compliance frameworks in fintech. It is also one where AWS provides significant architectural advantages — if you know how to use them.

This guide covers the architecture decisions, AWS service choices, and implementation patterns for building PCI DSS-compliant payment processing infrastructure on AWS. It covers PCI DSS v4.0, which became the active standard in April 2024.

Understanding PCI DSS on AWS

The Shared Responsibility Model for PCI DSS

AWS maintains PCI DSS Level 1 Service Provider certification — the highest certification level. This covers AWS’s physical infrastructure, hypervisors, and managed service security. It does not make your workloads PCI compliant.

Under the shared responsibility model:

AWS is responsible for: Physical security of data centers, hypervisor security, network infrastructure, the security of managed services like RDS and Lambda at the infrastructure level, and maintaining PCI DSS compliance for the AWS platform.

You are responsible for: How you configure AWS services, what you store in them, access controls to your resources, application-level security, encryption configuration (which you control, even for managed services), and all 12 PCI DSS requirements as they apply to your cardholder data environment.

AWS Artifact provides AWS’s PCI DSS Attestation of Compliance (AoC) for download. Your auditor will want this as evidence of your payment processor infrastructure’s compliance. But it is evidence about AWS, not about your implementation.

CDE Scoping: The Most Important Decision

The Cardholder Data Environment (CDE) is the system components, people, and processes that store, process, or transmit cardholder data (CHD) and sensitive authentication data (SAD). Every PCI DSS requirement applies to everything in scope.

Scope reduction is the highest-leverage PCI DSS strategy. The smaller your CDE, the less work to comply, the less surface area to secure, and the less audit effort required.

On AWS, you reduce scope by:

1. Using tokenization — Let your payment processor (Stripe, Braintree, Adyen, Square) handle actual card numbers. Your system receives and stores tokens that represent card numbers, never the actual PANs (Primary Account Numbers). Tokenization removes cardholder data from your environment entirely.

If you use Stripe and never see the raw card number — only a pm_xxx token — you are out of CDE scope for storage of cardholder data. Your scope is limited to the integration point.

2. Network segmentation — Place CDE components in isolated AWS accounts or VPCs, separated from non-CDE systems. PCI requires that cardholder data cannot be accessed from out-of-scope systems, and that CDE traffic is separated from business and general computing traffic.

Using a dedicated AWS account for payment processing isolates CDE resources from every other part of your environment. Cross-account access is explicit and auditable. This is the approach we recommend for most fintech architectures.

3. P2PE and hosted payment pages — Point-to-Point Encryption solutions and hosted payment pages (iframes hosted by the payment processor) can reduce scope further by ensuring card data is encrypted before it enters your network and never reaches your application servers.

The 12 PCI DSS Requirements on AWS

PCI DSS v4.0 organizes 12 requirements into six goals. Here is how each maps to AWS architecture.

Goal 1: Build and Maintain a Secure Network

Requirement 1: Install and maintain network security controls

On AWS, this means:

• VPC network design with CDE components in private subnets, no direct internet access
• Security Groups configured as stateful firewalls — deny by default, allow only necessary traffic on specific ports from specific sources
• Network ACLs as a stateless layer of defense for subnet-level filtering
• AWS Network Firewall for deep packet inspection if required
• No 0.0.0.0/0 inbound rules in Security Groups for CDE resources — every source must be justified

Requirement 2: Apply secure configurations to all system components

• No default passwords anywhere — use Secrets Manager for all credentials
• Disable unnecessary services, protocols, and features
• Systems Manager Patch Manager for automated patching of EC2 instances
• AWS Config rules to detect configuration drift (e.g., restricted-ssh, restricted-common-ports rules)
• IMDSv2 enforced on all EC2 instances (prevent SSRF attacks against instance metadata)

Goal 2: Protect Account Data

Requirement 3: Protect stored account data

• If you store any cardholder data (even tokenized): encryption at rest with AWS KMS customer-managed keys
• S3 Server-Side Encryption with SSE-KMS, no SSE-S3 (you need control over the key)
• RDS encryption enabled from instance creation (cannot be added post-launch without a snapshot migration)
• DynamoDB encryption with KMS
• EBS encryption with KMS for all volumes in the CDE
• No storage of CVV/CVC codes — even in encrypted form (PCI prohibits this after authorization)
• Masking of PANs in logs — use Secrets Manager and Lambda layers to prevent PANs from appearing in CloudWatch Logs

Requirement 4: Protect cardholder data with strong cryptography during transmission

• TLS 1.2+ enforced for all connections — no TLS 1.0 or 1.1
• ACM for certificate management with automatic renewal
• ALB security policies set to ELBSecurityPolicy-TLS13-1-2-2021-06 or newer
• API Gateway TLS enforcement
• VPC endpoints for all AWS service communication — keeps traffic off the public internet within AWS
• PrivateLink for connections between accounts

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect all systems and networks from malicious software

• Amazon Inspector for continuous vulnerability scanning of EC2 instances, ECR container images, and Lambda functions
• Inspector integration with Security Hub for centralized findings
• ECR image scanning enabled for all container repositories (scan on push + continuous scanning)
• Patch Management: Systems Manager Patch Manager with defined patch baselines and maintenance windows

Requirement 6: Develop and maintain secure systems and software

• Automated security testing in CI/CD pipelines: SAST (static analysis), dependency scanning (npm audit, pip audit, dependabot)
• CodeGuru Reviewer for automated code review
• AWS WAF in front of web-facing CDE components: managed rule groups for OWASP Top 10
• WAF rate limiting for protection against credential stuffing and brute force

Goal 4: Implement Strong Access Control Measures

Requirement 7: Restrict access to system components and cardholder data by business need to know

• IAM least privilege: policies grant only specific actions on specific resources
• IAM Access Analyzer to identify unused permissions and overly broad policies
• Resource-based policies on S3 buckets and KMS keys explicitly limiting access
• No wildcard (*) resource specifications in IAM policies for CDE-related resources

Requirement 8: Identify users and authenticate access to system components

• AWS IAM Identity Center (SSO) for human access — no individual IAM users
• MFA required for all console and CLI access
• No long-lived access keys — use IAM roles with STS for programmatic access
• Service accounts use IAM roles, not IAM users with access keys
• CloudTrail records all IAM-related API calls
• Password/credential rotation enforced through Secrets Manager automatic rotation

Requirement 9: Restrict physical access to cardholder data

AWS handles physical access controls under the shared responsibility model. Your obligations: manage logical access to the AWS console and APIs, and ensure personnel with access to CDE systems are appropriately vetted.

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and monitor all access to system components and cardholder data

This is where AWS excels:

• CloudTrail: Enable organization-wide trail with log file validation in a dedicated immutable security account. All API calls logged with identity, time, source IP, and request parameters.
• VPC Flow Logs: Capture all traffic metadata for CDE VPCs and subnets. Store in S3 with lifecycle policy (PCI requires 12-month retention; 3 months online, 9 months archived is common)
• CloudWatch Logs: Application and system logs. Retention set to at least 90 days online, 12 months total
• S3 access logs for all CDE S3 buckets
• RDS audit logging enabled (MySQL: general/audit log; PostgreSQL: pgaudit)
• Log aggregation to a security account with immutable S3 retention (S3 Object Lock COMPLIANCE mode)
• CloudWatch Log Insights for log analysis; Security Hub for findings aggregation

Requirement 11: Test security of systems and networks regularly

• Amazon Inspector: continuous vulnerability assessment
• GuardDuty: continuous threat detection across all CDE accounts
• External penetration testing: PCI DSS requires annual penetration testing by a qualified assessor. AWS provides guidelines for authorizing penetration tests against your AWS environment.
• Internal network scanning: use Inspector or third-party tools
• Intrusion detection: GuardDuty findings integrated with Security Hub and EventBridge for automated response

Goal 6: Maintain an Information Security Policy

Requirement 12: Support information security with organizational policies and programs

This requirement is primarily administrative: documented security policies, risk assessment processes, incident response procedures, employee training, vendor management (agreements with all entities accessing CDE).

On the technical side: ensure all AWS accounts have documented owners, all CDE resources are tagged with data classification, and all security findings have an owner and SLA for remediation.

AWS Architecture for PCI DSS

Recommended Account Structure

Organization Management Account
├── Security Account (centralized CloudTrail, Security Hub, GuardDuty master)
├── Log Archive Account (immutable log storage with S3 Object Lock)
├── CDE Production Account (payment processing workloads)
├── Non-CDE Production Account (all other production workloads)
└── Development/Staging Accounts (no real cardholder data)

Account isolation limits the blast radius of any security incident and makes CDE scoping unambiguous: CDE components are in the CDE account; everything else is out of scope.

CDE Network Architecture

CDE Production Account
├── VPC: 10.0.0.0/16
│   ├── Public Subnet (AZ-a): WAF → ALB only
│   ├── Public Subnet (AZ-b): WAF → ALB only
│   ├── Private Subnet (AZ-a): Payment API, Tokenization Service
│   ├── Private Subnet (AZ-b): Payment API, Tokenization Service
│   └── Data Subnet: RDS Aurora (encrypted), ElastiCache
│
├── Security Groups:
│   ├── alb-sg: inbound 443 from 0.0.0.0/0 (internet-facing)
│   ├── api-sg: inbound 443 from alb-sg only
│   └── db-sg: inbound 5432 from api-sg only
│
└── VPC Endpoints: S3, DynamoDB, Secrets Manager, KMS, CloudWatch Logs, STS
    (no internet access for AWS API calls)

No EC2 instances, Lambda functions, or containers in the CDE have direct internet access. All inbound traffic flows through WAF and ALB. All AWS API calls use VPC endpoints.

Key Management

KMS architecture for PCI DSS:

• Customer-managed keys (CMK) for all CDE data encryption — SSE-KMS, not SSE-S3
• Key policies limiting decryption to specific IAM roles (the payment service role only)
• Key rotation enabled (annual automatic rotation for symmetric keys)
• CloudTrail logging of all KMS API calls — who accessed which key when
• Cross-account key sharing prohibited (each account uses its own CMK)
• Separate CMKs for different data types (database encryption key, S3 data key, logs key)

GuardDuty and Security Hub Configuration

For PCI DSS environments:

• GuardDuty enabled in all accounts with the Security Hub integration
• Security Hub enabled with PCI DSS compliance standard activated — this provides automatic compliance checks mapped to PCI requirements
• EventBridge rules for GuardDuty HIGH and CRITICAL findings → SNS → PagerDuty/Slack + Lambda automated response
• Config Rules conformance pack for PCI DSS
• Security Hub aggregation to the Security account for central visibility

Audit Readiness

Evidence Package Preparation

Your QSA (Qualified Security Assessor) will request evidence for each applicable PCI DSS requirement. Organizing this evidence before the audit saves significant time.

Prepare:

• AWS Config snapshot showing resource configurations at assessment date
• Security Hub compliance report for PCI DSS standard
• IAM policy exports for all CDE-related roles
• CloudTrail evidence of access logging
• KMS key audit (customer-managed, rotation enabled, usage logs)
• VPC Flow Logs sample demonstrating network monitoring
• Inspector reports showing vulnerability scan results
• Patch management records from Systems Manager
• WAF rule configuration and access logs
• Penetration test report from qualified tester

The AWS Artifact Shortcut

Download the AWS PCI DSS AoC from AWS Artifact. This document certifies AWS’s compliance for its infrastructure. Present it to your QSA as evidence for the infrastructure layer. This eliminates the need to audit AWS’s physical security, hypervisor, and network infrastructure — they are already assessed.

Your audit scope is reduced to your configuration and your data handling.

Common PCI DSS Failures on AWS

Not enabling encryption on RDS at creation — RDS encryption cannot be enabled on a running instance. It requires creating an encrypted snapshot and restoring to a new encrypted instance. Teams that skip this create expensive migration work.

Storing CVV codes — PCI DSS Requirement 3.3 prohibits storing CVV/CVC after authorization, even encrypted. This is an automatic critical finding in any PCI audit.

Missing VPC Flow Logs — Requirement 10 mandates logging of all CDE traffic. VPC Flow Logs are the primary mechanism. Organizations that have not enabled them for the CDE have a critical gap.

Shared credentials — Requirement 8 mandates unique identification for each user. Shared service accounts violate this. Use IAM roles with STS assume-role for all service-to-service access.

Inadequate log retention — PCI requires 12 months of log retention with 3 months immediately available for analysis. CloudWatch Logs default retention is unlimited but unmanaged. Set explicit retention policies.

Leaving dev/staging data in scope — If developers have access to real cardholder data in non-production environments, those environments are in scope. Use synthetic data or properly tokenized test data in non-production.

Getting Started

Building PCI DSS-compliant infrastructure on AWS requires both technical expertise and knowledge of the compliance framework. The architecture decisions made at the start — account structure, CDE scoping, encryption key management — are expensive to change later.

For organizations building or certifying AWS fintech applications, our Cloud Compliance Services include PCI DSS gap assessment, CDE architecture design, remediation implementation, and audit readiness support. For broader fintech architecture patterns, see our guide on Building Fintech Applications on AWS.

For the security foundation that underpins PCI compliance, see our AWS Security Consulting service.

Book a Free Compliance Gap Assessment →