Case Study
PCI DSS Compliance on AWS: Fintech Payment Processor Migration in 12 Weeks
Migrated a payment processing platform to AWS with PCI DSS Level 1 compliance architecture — tokenization, network segmentation, WAF, Shield, and automated evidence collection — in 12 weeks.
## Challenge: Self-Hosted Payment Infrastructure with Growing Compliance Debt A fintech startup processing $2.8 billion in annual payment volume had built its original infrastructure in a colocation facility: bare metal servers, self-managed PostgreSQL, a custom payment gateway, and a homegrown tokenization service. The architecture worked when the company processed $400M/year. At $2.8B, it was a liability. **PCI DSS compliance was becoming untenable.** The annual QSA audit had stretched to 8 weeks of intensive preparation — pulling two engineers off product work to reconstruct 12 months of access logs, firewall change records, and patch histories. The QSA had flagged persistent findings around network segmentation, key management lifecycle, and vendor remote access controls that were costing the company a qualified security assessor escalation to full Level 1 compliance review. **The architecture could not scale.** Peak payment volume during promotional events was causing processing delays. Adding capacity meant ordering hardware, waiting 6-8 weeks for delivery and rack installation, and manual configuration. The company's growth trajectory made this procurement model impossible. **The security posture was opaque.** Without centralized logging, the security team had no unified view of access events across payment systems. When a penetration test flagged a misconfigured firewall rule that had been open for 11 months, it was the security team's first awareness of the rule's existence. ## Solution: PCI DSS Scoped AWS Migration with Tokenization at the Perimeter The migration strategy centered on a single architectural decision that made everything else tractable: push tokenization to the perimeter, before cardholder data enters the application tier. This approach — using AWS services at the network edge to intercept and tokenize PANs before they reach application servers — is the most effective way to reduce PCI scope on AWS. ### Cardholder Data Environment Scope Reduction PCI DSS scope is defined by where cardholder data (Primary Account Numbers, CVVs, expiration dates) flows, is stored, and is processed. Every system in the cardholder data environment (CDE) must meet PCI requirements. Reducing scope reduces compliance cost. The architecture achieves 70% scope reduction through three mechanisms: **Payment tokenization at ingestion.** The payment form on the client's website uses a JavaScript library that sends card data directly to a PCI-compliant tokenization provider (Basis Theory), not to the client's servers. The client's application receives a token, not a PAN. This takes the client's application servers entirely out of CDE scope. **Network segmentation.** The remaining CDE — the payment processing Lambda functions that call card network APIs with tokens, the PostgreSQL database storing transaction records, and the key management systems — is isolated in dedicated private subnets with no internet path. Security group rules are explicit allowlist-only; no 0.0.0.0/0 inbound rules exist anywhere in the CDE. **Dedicated CDE AWS account.** The payment processing workload runs in its own AWS account, isolated from development, staging, and business applications. Cross-account access to the CDE account requires explicit IAM role assumption with MFA, and every assumption is logged to CloudTrail. ### AWS WAF and Shield for Card-Present Attack Surface The payment API endpoints — the remaining internet-facing surface — are protected by: **AWS WAF with PCI-relevant managed rules:** The AWS Managed Rules for Known Bad Inputs and the Bot Control managed rule group block common card-testing attacks (low-value authorization probes used to validate stolen cards). Custom rules rate-limit authorization attempts per IP to 10 per minute, matching the behavior of legitimate payment flows while blocking automated carding attacks. **AWS Shield Standard** provides always-on DDoS mitigation for the payment API. The payment API availability SLA is 99.99% — Shield Standard's automatic detection and mitigation of infrastructure-layer DDoS attacks is a baseline requirement, not an upgrade. **WAF logging to S3** provides PCI requirement 10 compliance (audit trail of access to network resources and cardholder data) for the API layer. Log retention is 12 months in S3 with lifecycle transition to Glacier after 90 days — meeting PCI's 12-month accessibility requirement. ### Cryptographic Key Management The original colo architecture used a single hardware security module (HSM) for all cryptographic operations. The migration replaces this with AWS KMS using customer-managed keys, providing: - **Key rotation** — automatic annual rotation configured on all CMKs, with CloudTrail recording every key usage event - **Key access audit trail** — every Decrypt, GenerateDataKey, and Encrypt API call is logged, providing the cryptographic access audit trail required by PCI DSS Requirement 3 - **Key hierarchy** — separate CMKs for payment transaction encryption, audit log encryption, and database encryption, allowing independent key policies and rotation schedules AWS KMS is FIPS 140-2 validated and appears on the list of PCI DSS-compliant key management services. The QSA accepted KMS as the key management control without additional compensating controls. ### Automated Compliance Evidence Collection The compliance automation that most reduced audit preparation time: **AWS Config with PCI DSS conformance pack** — a managed set of Config rules that maps to PCI DSS requirements. Non-compliant resources are flagged within 15 minutes. The Config dashboard provides point-in-time compliance status that QSA reviewers can access directly, eliminating manual evidence compilation for configuration control questions. **AWS CloudTrail with Lake integration** — all API activity across the CDE account is stored in CloudTrail Lake with SQL-queryable access. During the QSA audit, reviewers ran direct queries against CloudTrail Lake to answer questions like "Show all IAM role assumptions by third-party vendor accounts in the last 12 months" — queries that previously required 2 engineers working for a week to reconstruct from log archives. **Amazon Inspector continuous vulnerability scanning** — EC2 and Lambda function vulnerability assessments run continuously, providing the automated vulnerability scanning required by PCI DSS Requirement 6. Inspector findings are reported to Security Hub, where they're triaged against the 30-day remediation SLA for high-severity findings. ## Results: PCI DSS Level 1 Architecture, 70% Scope Reduction, QSA Audit in 4 Days The migration completed in 12 weeks. The first QSA audit of the new AWS architecture took 4 days, down from 8 weeks. The scope reduction — taking the application tier out of CDE — was the primary driver: fewer systems in scope means fewer controls to evidence, fewer interviews to conduct, and fewer findings to remediate. **WAF effectiveness.** The payment API receives approximately 40,000 requests per day, of which 12,000-15,000 are blocked by WAF rules. Bot Control identifies the majority as automated carding attacks — a volume that would have overwhelmed the previous manual-intervention-based response. No successful card-testing attacks have occurred since launch. **Operational improvement.** The cloud-native architecture reduced payment processing infrastructure costs by 34% despite higher volume — auto-scaling Lambda functions eliminate idle capacity, and the multi-AZ RDS Aurora instance replaced two dedicated standby servers in the colo facility. **QSA relationship.** The QSA firm that had flagged persistent findings in the colo architecture issued a clean Report on Compliance for the AWS architecture. The automated evidence collection, network segmentation, and key management documentation were described as "the cleanest CDE we've reviewed for a company at this volume." --- _This case study describes a composite engagement based on anonymized client work. All identifying details have been removed or modified._
Challenge: Self-Hosted Payment Infrastructure with Growing Compliance Debt
A fintech startup processing $2.8 billion in annual payment volume had built its original infrastructure in a colocation facility: bare metal servers, self-managed PostgreSQL, a custom payment gateway, and a homegrown tokenization service. The architecture worked when the company processed $400M/year. At $2.8B, it was a liability.
PCI DSS compliance was becoming untenable. The annual QSA audit had stretched to 8 weeks of intensive preparation — pulling two engineers off product work to reconstruct 12 months of access logs, firewall change records, and patch histories. The QSA had flagged persistent findings around network segmentation, key management lifecycle, and vendor remote access controls that were costing the company a qualified security assessor escalation to full Level 1 compliance review.
The architecture could not scale. Peak payment volume during promotional events was causing processing delays. Adding capacity meant ordering hardware, waiting 6-8 weeks for delivery and rack installation, and manual configuration. The company’s growth trajectory made this procurement model impossible.
The security posture was opaque. Without centralized logging, the security team had no unified view of access events across payment systems. When a penetration test flagged a misconfigured firewall rule that had been open for 11 months, it was the security team’s first awareness of the rule’s existence.
Solution: PCI DSS Scoped AWS Migration with Tokenization at the Perimeter
The migration strategy centered on a single architectural decision that made everything else tractable: push tokenization to the perimeter, before cardholder data enters the application tier. This approach — using AWS services at the network edge to intercept and tokenize PANs before they reach application servers — is the most effective way to reduce PCI scope on AWS.
Cardholder Data Environment Scope Reduction
PCI DSS scope is defined by where cardholder data (Primary Account Numbers, CVVs, expiration dates) flows, is stored, and is processed. Every system in the cardholder data environment (CDE) must meet PCI requirements. Reducing scope reduces compliance cost.
The architecture achieves 70% scope reduction through three mechanisms:
Payment tokenization at ingestion. The payment form on the client’s website uses a JavaScript library that sends card data directly to a PCI-compliant tokenization provider (Basis Theory), not to the client’s servers. The client’s application receives a token, not a PAN. This takes the client’s application servers entirely out of CDE scope.
Network segmentation. The remaining CDE — the payment processing Lambda functions that call card network APIs with tokens, the PostgreSQL database storing transaction records, and the key management systems — is isolated in dedicated private subnets with no internet path. Security group rules are explicit allowlist-only; no 0.0.0.0/0 inbound rules exist anywhere in the CDE.
Dedicated CDE AWS account. The payment processing workload runs in its own AWS account, isolated from development, staging, and business applications. Cross-account access to the CDE account requires explicit IAM role assumption with MFA, and every assumption is logged to CloudTrail.
AWS WAF and Shield for Card-Present Attack Surface
The payment API endpoints — the remaining internet-facing surface — are protected by:
AWS WAF with PCI-relevant managed rules: The AWS Managed Rules for Known Bad Inputs and the Bot Control managed rule group block common card-testing attacks (low-value authorization probes used to validate stolen cards). Custom rules rate-limit authorization attempts per IP to 10 per minute, matching the behavior of legitimate payment flows while blocking automated carding attacks.
AWS Shield Standard provides always-on DDoS mitigation for the payment API. The payment API availability SLA is 99.99% — Shield Standard’s automatic detection and mitigation of infrastructure-layer DDoS attacks is a baseline requirement, not an upgrade.
WAF logging to S3 provides PCI requirement 10 compliance (audit trail of access to network resources and cardholder data) for the API layer. Log retention is 12 months in S3 with lifecycle transition to Glacier after 90 days — meeting PCI’s 12-month accessibility requirement.
Cryptographic Key Management
The original colo architecture used a single hardware security module (HSM) for all cryptographic operations. The migration replaces this with AWS KMS using customer-managed keys, providing:
- Key rotation — automatic annual rotation configured on all CMKs, with CloudTrail recording every key usage event
- Key access audit trail — every Decrypt, GenerateDataKey, and Encrypt API call is logged, providing the cryptographic access audit trail required by PCI DSS Requirement 3
- Key hierarchy — separate CMKs for payment transaction encryption, audit log encryption, and database encryption, allowing independent key policies and rotation schedules
AWS KMS is FIPS 140-2 validated and appears on the list of PCI DSS-compliant key management services. The QSA accepted KMS as the key management control without additional compensating controls.
Automated Compliance Evidence Collection
The compliance automation that most reduced audit preparation time:
AWS Config with PCI DSS conformance pack — a managed set of Config rules that maps to PCI DSS requirements. Non-compliant resources are flagged within 15 minutes. The Config dashboard provides point-in-time compliance status that QSA reviewers can access directly, eliminating manual evidence compilation for configuration control questions.
AWS CloudTrail with Lake integration — all API activity across the CDE account is stored in CloudTrail Lake with SQL-queryable access. During the QSA audit, reviewers ran direct queries against CloudTrail Lake to answer questions like “Show all IAM role assumptions by third-party vendor accounts in the last 12 months” — queries that previously required 2 engineers working for a week to reconstruct from log archives.
Amazon Inspector continuous vulnerability scanning — EC2 and Lambda function vulnerability assessments run continuously, providing the automated vulnerability scanning required by PCI DSS Requirement 6. Inspector findings are reported to Security Hub, where they’re triaged against the 30-day remediation SLA for high-severity findings.
Results: PCI DSS Level 1 Architecture, 70% Scope Reduction, QSA Audit in 4 Days
The migration completed in 12 weeks. The first QSA audit of the new AWS architecture took 4 days, down from 8 weeks. The scope reduction — taking the application tier out of CDE — was the primary driver: fewer systems in scope means fewer controls to evidence, fewer interviews to conduct, and fewer findings to remediate.
WAF effectiveness. The payment API receives approximately 40,000 requests per day, of which 12,000-15,000 are blocked by WAF rules. Bot Control identifies the majority as automated carding attacks — a volume that would have overwhelmed the previous manual-intervention-based response. No successful card-testing attacks have occurred since launch.
Operational improvement. The cloud-native architecture reduced payment processing infrastructure costs by 34% despite higher volume — auto-scaling Lambda functions eliminate idle capacity, and the multi-AZ RDS Aurora instance replaced two dedicated standby servers in the colo facility.
QSA relationship. The QSA firm that had flagged persistent findings in the colo architecture issued a clean Report on Compliance for the AWS architecture. The automated evidence collection, network segmentation, and key management documentation were described as “the cleanest CDE we’ve reviewed for a company at this volume.”
This case study describes a composite engagement based on anonymized client work. All identifying details have been removed or modified.
Results
Achieve PCI DSS Compliance on AWS
We architect PCI DSS-compliant payment environments on AWS that reduce your cardholder data scope and automate evidence collection for annual audits.