How to Architect a Multi-Cloud Solution for Card Payments While Meeting PCI DSS Requirements
The Multi-Cloud PCI DSS Problem Nobody Warns You About
Most teams choosing multi-cloud for card payments make the decision for the right reasons — resilience, vendor independence, regulatory data residency requirements, or existing infrastructure across AWS, GCP, and Azure.
Then they discover that multi-cloud and PCI DSS compliance interact in ways that multiply complexity rather than add it.
A single-cloud PCI DSS implementation is complex. A multi-cloud implementation doesn't just double that complexity — it introduces an entirely new category of problem: how do you maintain consistent compliance posture across cloud environments that each have different native services, different shared responsibility boundaries, different identity models, and different audit tooling?
Multi-cloud PCI DSS compliance requires consistent security controls across all cloud environments, unified identity management rather than separate IAM silos, centralised logging aggregation from all cloud providers, and consistent network segmentation enforcement. Most teams underestimate all four.
This guide covers how to architect card payment infrastructure across AWS, GCP, and Azure while maintaining a coherent, auditable PCI DSS 4.0.1 compliance posture — and what each architecture decision costs you when you get it wrong.
→ Find out what your current payment infrastructure compliance gaps are costing you — free, 60 seconds Run the free Payment Risk Estimator →
The Multi-Cloud PCI DSS Problem Nobody Warns You About
As of March 31, 2025, all requirements of PCI DSS 4.0 are mandatory. This isn't just another version update — it's a fundamental shift in how payment security is managed, especially in the cloud.
The shift that matters most for multi-cloud architectures is the move from point-in-time compliance to continuous monitoring. Under PCI DSS 4.0, you can't pass an annual audit and consider yourself compliant. You need to demonstrate that your controls are continuously enforced — across every environment where cardholder data flows.
In a single-cloud environment, continuous monitoring is achievable with native tooling. In a multi-cloud environment, you need a compliance layer that sits above the cloud providers and aggregates evidence from all of them.
Under v3.2.1, a PCI compliance audit was often a check-the-box exercise. v4.0 introduces the Customised Approach — you aren't just updating controls, you are mapping rigorous new requirements against cloud infrastructure where you don't own the physical hardware.
What this costs without a unified compliance layer:
A QSA audit covering three cloud environments without centralised evidence — three separate sets of logs to collect, three separate IAM configurations to document, three separate network segmentation diagrams to produce. Engineering teams report spending 6-8 weeks preparing documentation for multi-cloud PCI audits. A unified compliance layer reduces that to days.
Emergency PCI remediation when a control drifts in any one of three cloud environments: £15,000-50,000. Multiply by the probability of drift across three environments simultaneously and the risk exposure is significant.
The Shared Responsibility Model Across Three Clouds
The shared responsibility model determines which controls the cloud provider manages and which the organisation must implement itself. Misunderstanding this model is the primary source of PCI DSS compliance gaps in cloud-deployed CDEs.
Each cloud provider draws the shared responsibility boundary differently:
AWS AWS secures the physical infrastructure, hardware, networking, and hypervisor. You secure everything running on top — workloads, data, identity, network configuration, and application security. AWS maintains a list of PCI DSS in-scope services, currently 90+ services. If a service isn't on that list, it cannot be used to process, store, or transmit cardholder data.
GCP GCP frames their model as Shared Fate, implying more active assistance, but the compliance burden remains yours. Unlike AWS's binary "of/in the cloud" distinction, GCP's controls can be more granular. You must explicitly map Requirement 6 (Secure Software Development) to your CI/CD pipelines in Google Cloud Build.
Azure Azure Policy provides built-in PCI DSS v4.0 initiatives. You should be using these to audit your environment automatically against the new standard. Azure's compliance tooling is more prescriptive than AWS or GCP, which is an advantage if you use it — and a false sense of security if you assume it covers everything.
The multi-cloud shared responsibility trap:
Each cloud provider's shared responsibility model is internally consistent. The problem is that your PCI DSS audit covers your entire cardholder data environment — which spans all three providers. Your QSA doesn't audit each cloud provider separately. They audit your organisation's compliance posture as a whole.
Gaps between three different shared responsibility models don't cancel out. They compound.
Cardholder Data Environment Scope in Multi-Cloud
The most important decision in any PCI DSS implementation is scope reduction — minimising the systems that need to be fully compliant. In multi-cloud, this decision is more complex because the CDE boundary crosses cloud provider boundaries.
The three scope patterns for multi-cloud card payments:
Pattern 1: Isolated CDE in Primary Cloud All cardholder data processing happens in a single cloud (typically AWS as the primary). Other clouds receive only tokenised references — never raw card data.
AWS (Primary CDE):
Card data processing, tokenisation vault
PCI DSS full scope
GCP (Secondary):
Tokenised transaction processing
Analytics on tokenised data
Minimal PCI scope
Azure (Tertiary):
Corporate systems
No cardholder data
Out of PCI scope
This is the simplest pattern for PCI compliance but limits the resilience benefit of multi-cloud.
Pattern 2: Distributed CDE with Consistent Controls Cardholder data processed in multiple clouds with consistent security controls enforced across all of them.
All three clouds:
Consistent network segmentation
Unified IAM with no cross-cloud privilege escalation
Centralised log aggregation
Consistent encryption key management
Same controls matrix applied identically
This maximises resilience but requires a compliance layer that spans all three providers. Without that layer, audit preparation becomes a manual, error-prone process across three separate environments.
Pattern 3: Tokenisation Gateway Architecture A dedicated tokenisation service sits in front of all cloud environments. Card data enters once, is tokenised immediately, and only tokens flow to any downstream system.
Tokenisation Gateway (AWS):
Single entry point for all card data
Immediate tokenisation before any processing
Smallest possible CDE — just the gateway
AWS + GCP + Azure:
Process tokens only
Largely out of PCI scope
Standard security controls sufficient
This is architecturally elegant but requires careful design of the tokenisation gateway — it becomes a single point of failure for your entire payment operation.
→ Assess your current PCI DSS scope and compliance posture — free, no login required Run the free Infrastructure Readiness Score →
Identity and Access Management Across Three Clouds
Unified identity management is one of the four requirements for multi-cloud PCI DSS compliance — and one of the most commonly failed.
The problem is that AWS IAM, GCP IAM, and Azure AD are fundamentally different identity systems. They use different permission models, different role structures, and different audit log formats. Engineering teams building multi-cloud payment infrastructure often end up with three separate identity silos — each internally consistent, but with no unified view across all three.
What this means for PCI DSS:
PCI DSS Requirement 8 requires unique identification of every user and every system component accessing cardholder data. In a multi-cloud environment, this means:
No shared service accounts across cloud providers
No IAM roles in one cloud granting access to resources in another without explicit federation
Every agent identity scoped to the specific cloud and specific operations it needs
Unified audit trail covering identity events across all three clouds
The architecture that works:
Identity Federation Layer:
Central identity provider (e.g. Okta, Azure AD as IdP)
SAML/OIDC federation to AWS IAM Identity Center
Workload Identity Federation for GCP
Native Azure AD integration
Per-cloud role structure:
AWS: IAM roles per workload type, session tags for audit
GCP: Service accounts per service, Workload Identity
Azure: Managed identities per service, PIM for privileged access
Centralised audit:
AWS CloudTrail → centralised SIEM
GCP Cloud Audit Logs → same SIEM
Azure Activity Log → same SIEM
Unified query across all three
Common mistake: Using long-lived access keys for cross-cloud service accounts. PCI DSS Requirement 8.6 requires periodic credential rotation — but long-lived keys across multiple cloud environments are operationally difficult to rotate without service disruption. Use short-lived credentials everywhere.
→ Check your agent and service identity architecture against PCI DSS requirements Run the free Agentic Readiness Assessment →
Network Segmentation Across Cloud Providers
Network segmentation is PCI DSS Requirement 1 — and in multi-cloud, it's where most architectures have their most serious gaps.
The goal of network segmentation for PCI DSS is to isolate the cardholder data environment from everything else. Traffic into and out of the CDE should be minimal, controlled, and logged.
In a single cloud, this is achieved with VPCs, security groups, and network ACLs. In multi-cloud, you need equivalent controls in each environment — and you need to ensure that the boundaries between cloud environments are as tightly controlled as the boundaries within them.
Multi-cloud network architecture for PCI DSS:
AWS CDE VPC:
Private subnets for all card data processing
No direct internet access — NAT Gateway only
VPC endpoints for AWS services (no public internet)
Security groups: explicit deny by default
GCP CDE VPC:
Private Google Access for GCP services
VPC Service Controls — prevent data exfiltration
Firewall rules: explicit deny by default
Cloud NAT for outbound only
Azure CDE VNet:
Private endpoints for all Azure services
Network Security Groups: explicit deny by default
Azure Firewall for centralised policy
No public IP addresses on payment services
Cross-cloud connectivity:
Dedicated interconnects — not public internet
AWS Direct Connect + GCP Dedicated Interconnect + Azure ExpressRoute
Or: SD-WAN solution with consistent policy across all three
Encrypted in transit regardless — TLS 1.2 minimum, TLS 1.3 preferred
The segmentation testing requirement in PCI DSS 4.0:
PCI DSS 4.0 requires that network segmentation is tested at least every six months and after any significant change. In multi-cloud, this means testing the boundaries within each cloud AND the boundaries between clouds. Most teams test within each cloud but don't explicitly test cross-cloud boundaries.
What this costs without proper segmentation:
A segmentation failure that allows cardholder data to reach an out-of-scope system doesn't just fail the PCI requirement — it expands your CDE scope retroactively, potentially triggering a full re-audit of every system the data touched.
Encryption Key Management Across Three Clouds
PCI DSS Requirement 3 covers protection of stored cardholder data — and in multi-cloud, encryption key management is one of the most architecturally significant decisions you'll make.
Each cloud has its own key management service:
AWS: KMS — HSM-backed, integrated with 90+ services
GCP: Cloud KMS and Cloud HSM — FIPS 140-2 Level 3
Azure: Key Vault and Managed HSM — FIPS 140-2 Level 3
The two architectural approaches:
Option 1: Cloud-native KMS per environment Each cloud manages its own encryption keys. Simpler to implement. Each cloud's services integrate natively with their own KMS. Audit trail is local to each cloud.
Risk: Key rotation across three separate KMS systems requires separate procedures. If a key is compromised in one cloud, the investigation and remediation is isolated to that cloud — which is actually an advantage.
Option 2: External HSM with cross-cloud integration A single external HSM (Thales, Entrust) manages keys for all three clouds. Each cloud's KMS is configured as a custom key store backed by the external HSM.
Benefit: Single key management policy, single audit trail, single rotation procedure. Risk: The external HSM becomes a single point of failure for all three environments.
For most multi-cloud card payment architectures, Option 1 is correct — cloud-native KMS per environment, with consistent key rotation policies enforced through your compliance layer rather than a shared key management system.
Key rotation policy (enforced consistently across all three clouds):
Card data encryption keys: rotate every 12 months
Key encryption keys: rotate every 12 months
Transit encryption: TLS certificates rotate every 12 months
Rotation documented in centralised audit trail
Centralised Logging and Audit Trail
The leading breach cause in cloud environments is cloud misconfigurations, not provider failures. The only way to detect misconfigurations before they become breaches is comprehensive, centralised logging.
For PCI DSS 4.0, Requirement 10 mandates audit log implementation across your entire CDE. In multi-cloud, this means collecting logs from three separate sources into a single system where they can be queried together.
The logging architecture:
AWS log sources:
CloudTrail (API activity)
VPC Flow Logs (network traffic)
CloudWatch Logs (application and agent logs)
Config (configuration changes)
GCP log sources:
Cloud Audit Logs (Admin Activity, Data Access)
VPC Flow Logs
Cloud Logging (application logs)
Security Command Center findings
Azure log sources:
Activity Log (management operations)
Resource Logs (service-level logs)
Azure Monitor (application logs)
Microsoft Defender for Cloud alerts
Centralised SIEM:
All sources → single aggregation point
Consistent log schema across all three providers
7-year retention for PCI DSS compliance
Real-time alerting on compliance control drift
Unified query capability for audit preparation
The schema consistency problem:
AWS CloudTrail, GCP Cloud Audit Logs, and Azure Activity Log all produce different log formats. When a QSA asks "show me every access to cardholder data across all three environments on March 15th," you need to be able to answer that question with a single query not three separate investigations with three different log formats.
Normalise log formats at ingestion time. Define a common schema for all security-relevant events before you start collecting. Retrofitting log normalisation across three cloud environments after the fact is painful and expensive.
→ Assess your observability and audit trail architecture Run the free Agentic Readiness Assessment →
The Continuous Compliance Layer
Everything above — segmentation, identity, encryption, logging — needs to be continuously monitored. PCI DSS 4.0 has ended the era of point-in-time compliance.
In a single cloud, native tools provide reasonable continuous monitoring coverage. In multi-cloud, you need a compliance layer that aggregates signals from all three environments and provides a unified view of your PCI DSS posture.
What continuous compliance monitoring covers:
Network segmentation:
Automated tests of CDE boundaries — all clouds
Alert on any new network path into CDE
Segmentation test results archived for audit
Identity and access:
Drift detection on IAM roles and policies
Alert on any privilege escalation
Unused credentials flagged for rotation
Encryption:
Key rotation schedule enforced
Alert on unencrypted storage containing card data
TLS certificate expiry monitoring
Configuration:
AWS Config rules — continuous evaluation
GCP Organization Policy constraints
Azure Policy — built-in PCI DSS v4.0 initiative
Alert on any configuration change in CDE
Logging:
Alert on logging gaps — any period where audit trail is incomplete
Log integrity monitoring — detect tampering
Retention policy enforcement
The cost of not having this:
A control that drifts out of configuration at 3am has been non-compliant for hours before anyone notices. At agent payment transaction volumes running continuously, hours of non-compliant execution is a material PCI DSS finding. Emergency remediation: £15,000-50,000.
→ The Sync Your Cloud PCI DSS v4.0.1 Gap Analysis tracks all 63 controls across your infrastructure with continuous drift detection Access with Sync membership →
The Multi-Cloud PCI DSS Architecture Decision Record
Before you go live with multi-cloud card payment processing, your Architecture Decision Records need to answer these questions. A QSA will ask all of them.
Scope:
Which systems in each cloud are in-scope for PCI DSS?
What is the boundary of your CDE in each cloud?
How is tokenisation used to reduce scope?
Identity:
How is every human and system identity that accesses cardholder data uniquely identified?
How are credentials rotated and how is rotation evidenced?
What is the process for revoking access when a person or service is decommissioned?
Network:
What network paths exist into your CDE across all three clouds?
How is cross-cloud connectivity secured and monitored?
When was segmentation last tested and what were the results?
Encryption:
What data is encrypted at rest in each cloud?
How are encryption keys managed and rotated?
What is the process if a key is compromised?
Logging:
What events are logged from each cloud environment?
Where are logs retained and for how long?
How can you query across all three environments for a specific event?
Continuous compliance:
How is control drift detected in each cloud?
What is the escalation process when a control drifts?
How is the continuous compliance posture evidenced for your QSA?
→ The Sync Your Cloud ADR Manager provides structured templates for multi-cloud PCI DSS architecture decisions — built for regulatory scrutiny Access with Sync membership →
The Infrastructure Readiness Checklist for Multi-Cloud Card Payments
Before processing card payments across multiple cloud environments, your architecture should answer yes to each of these:
[ ] CDE scope is explicitly defined and documented in each cloud environment
[ ] Tokenisation reduces cardholder data flow to the minimum necessary
[ ] Unified identity management — no separate IAM silos per cloud
[ ] Network segmentation tested across cloud boundaries, not just within each cloud
[ ] Consistent encryption key management policy enforced across all three providers
[ ] Centralised log aggregation with normalised schema across all cloud sources
[ ] Continuous compliance monitoring with unified drift detection across all environments
[ ] Architecture Decision Records documenting all four key compliance areas
[ ] Cross-cloud connectivity via dedicated interconnects — not public internet
[ ] Segmentation testing scheduled every six months per PCI DSS 4.0 requirement
If any answer is no, you have a compliance gap that a QSA will find — ideally before they do.
Start With What Your Compliance Gaps Are Costing You
Free — no login required:
Calculate Your Payment Infrastructure Risk → 60 seconds. Quantifies your monthly compliance risk exposure based on your payment service count and infrastructure profile.
Run the free Infrastructure Readiness Score → Assess your infrastructure against PCI DSS 4.0 requirements. Find your gaps before your auditor does.
Run the free Agentic Readiness Assessment → 21 questions across agent orchestration, security, compliance, and observability. Scored gap analysis in 15 minutes.
Need architecture support for multi-cloud PCI DSS compliance?
Sync Your Cloud gives engineering teams access to 26 purpose-built tools for payment infrastructure — including the full PCI DSS v4.0.1 Gap Analysis with all 63 controls, the Controls Matrix for mapping controls across your specific infrastructure, and the ADR Manager for documenting multi-cloud compliance decisions.
Connect your AWS account directly for AI-powered analysis of your actual environment against PCI DSS requirements.
Plans from £999/month.
Sync Your Cloud is the infrastructure readiness platform for engineering teams deploying agent-based payment systems. Built on AWS. Validated for payment infrastructure. Supporting multi-cloud deployments on AWS, GCP, and Azure.
