Active-active multi-region platform at 50 million users

A Tier-1 retail bank serving 50 million customers across the United States and the European Union required a complete re-architecture of its core digital banking platform. The existing infrastructure - a single active region in us-east-1 with a manual warm-standby in us-west-2 - could no longer meet the institution's regulatory obligations, availability targets, or geographic scale requirements.

Three converging pressures forced the transformation. First, the EU Data Protection Authority issued a formal finding that customer data belonging to EU residents was being processed and stored on US-based infrastructure without an adequate transfer mechanism, creating material GDPR exposure under Articles 44-49. Second, the platform's 99.87% measured availability translated to over 11 hours of annual downtime, directly affecting customer-facing payments and account access and triggering OCC and EBA regulatory scrutiny. Third, the existing architecture could not serve 50 million users: peak transaction loads during US market open and EU settlement windows caused cascading throttling events that no amount of vertical scaling could resolve.

This case study documents the design, regulatory alignment, and production outcomes of a purpose-built active-active platform spanning five AWS regions, segmented into two legally and technically isolated data planes - one for US-regulated data and one for EU-regulated data - with no cross-jurisdiction replication of personally identifiable information.

The institution and scale

The client is a publicly traded multinational retail bank with chartered operations in the United States (OCC-regulated national bank) and five EU member states - Ireland, Germany, France, the Netherlands, and Spain - operating under the EBA's Digital Operational Resilience Act (DORA) requirements. At project initiation, the platform served 50.2 million registered customers: 32 million in the US and 18 million in the EU.

Daily platform activity included 9.4 million mobile and web banking sessions, 6.1 million payment transactions (ACH, SEPA, RTP, and card authorizations), and 850,000 account servicing operations. Peak TPS during overlapping US pre-market and EU settlement hours reached 124,000 - a load the legacy architecture had never been designed to absorb.

Regulatory and compliance failures of the legacy architecture

The DPA finding was the triggering event. EU customer data - including name, date of birth, IBAN, transaction history, and behavioral analytics - was stored in an Aurora PostgreSQL cluster in us-east-1 with a read replica in eu-west-1 used purely for read performance. Under the Schrems II ruling and the subsequent DPA audit, this configuration was found to be an unauthorized international transfer of personal data, as the EU Standard Contractual Clauses in place had not been supplemented with the technical safeguards required following the invalidation of Privacy Shield.

Three additional regulatory gaps were identified during the same audit period:

• Right to erasure (Article 17 GDPR): No reliable mechanism existed to purge EU customer data from all infrastructure tiers - read replicas, DynamoDB streams, CloudWatch Logs, S3 access logs, and CloudFront edge caches - within the 30-day regulatory window.
• Data minimization (Article 5(1)(c) GDPR): The shared telemetry pipeline shipped EU customer identifiers and behavioral data (session IDs, IP addresses, transaction amounts) to a Datadog organization hosted in the US, creating a secondary unauthorized transfer.
• Breach notification (Article 33 GDPR): A 2023 credential-stuffing incident had taken 94 hours to confirm scope and notify the DPA - far exceeding the 72-hour deadline.

The defining architectural decision was the complete separation of the platform into two independent data planes with no cross-jurisdiction data flows for personal information. This differs sharply from a conventional multi-region active-active design where Global Tables or Aurora Global Database replicate data freely across all regions: in this architecture, replication boundaries are a regulatory constraint enforced at the infrastructure layer, not a configuration option.

The two planes share only non-personal operational telemetry (infrastructure metrics, availability signals, and synthetic canary results). They do not share databases, message queues, application secrets, IAM roles, KMS keys, or VPC network paths. Each plane is operated as a logically and physically independent platform.

A Control Plane layer sits above both data planes handling only non-personal configuration data: feature flags, routing policy, circuit breaker state, and synthetic health check results. The Control Plane stores no customer data and is scoped to us-east-1 with replication to eu-west-1, using DynamoDB Global Tables for its own configuration state.

User routing and geographic determination

Route 53 latency-based routing is the primary traffic distribution mechanism within each plane. Plane assignment - determining whether a request should be served by the US or EU plane - is handled at the AWS Global Accelerator layer using:

• IP geolocation: Requests originating from EU IP space are routed to the EU plane's Global Accelerator endpoint. US IP space routes to the US plane.
• Authenticated session binding: Once a customer authenticates, their session is cryptographically bound to the correct data plane via a signed JWT claim (data-plane: us | eu) that all downstream services validate before processing. A US customer travelling to Europe continues to be served by the US plane.
• Account residency override: For customers with accounts in both jurisdictions, the account opening jurisdiction determines data plane assignment. The application layer enforces this at the service boundary.

Cluster topology

Each of the five regions runs a dedicated Amazon EKS cluster (Kubernetes 1.30, managed node groups) with worker nodes distributed across three Availability Zones. The US plane operates two active clusters; the EU plane operates three. All five clusters receive live traffic simultaneously - no cluster is a standby.

Node group composition per cluster is split by workload type:

• Transaction processing nodes: r7g.4xlarge (Graviton3, memory-optimized) - on-demand, 3 per AZ minimum. Run payment processing, fraud scoring, and account mutation services. Over-provisioned by 35% to absorb a full AZ failure without scaling lag.
• API gateway and session nodes: c7g.2xlarge (Graviton3, compute-optimized) - 50% on-demand / 50% Spot, managed by Karpenter with topology spread constraints. Stateless: authentication, API routing, session validation.
• Batch and analytics nodes: m7g.8xlarge - Spot-only, isolated node group with node taints. Cross-contamination of batch workloads is prevented by mandatory node selectors enforced via OPA Gatekeeper admission policies.

Karpenter replaced the legacy Cluster Autoscaler across all five clusters. During the 2024 Black Friday peak, the EU plane scaled from 847 to 1,340 nodes across three clusters in under 8 minutes to absorb a 3.4× traffic surge from EU e-commerce payment volumes.

Workload isolation and data plane enforcement

OPA Gatekeeper is deployed on all five clusters with a custom constraint set that enforces data plane isolation at the Kubernetes level. Every Pod, Deployment, and Job must carry the label data-plane: us or data-plane: eu. Gatekeeper policies reject any workload that attempts to run without this label or that references secrets, ConfigMaps, or service accounts tagged to a different data plane.

Cilium network policies prevent EU-plane namespaces from establishing TCP connections to US-plane service endpoints and vice versa. This is a defense-in-depth layer - the primary enforcement is at the IAM and KMS boundary described in the data layer section.

GitOps, deployment, and change control

ArgoCD manages continuous delivery across all five clusters from a single monorepo. EU-cluster ApplicationSets carry an additional annotation requiring sign-off from the bank's EU Data Protection Officer for any change that modifies data access patterns, encryption configuration, or telemetry pipelines - enforced via a custom ArgoCD webhook that checks a DPO-approval label on the Git commit before syncing.

Deployments use Argo Rollouts with a canary strategy (5% → 25% → 100%) gated on automated analysis of error rate, transaction success rate, P99 latency, and GDPR-specific metrics (data residency assertion failures, encryption key access anomalies). A canary failure in any single EU cluster triggers rollback in that cluster only.

The fundamental constraint: jurisdiction-scoped replication

DynamoDB Global Tables is the primary transactional data store - but its configuration is deliberately more constrained than a default Global Tables setup. In a standard deployment, any region added to the replication set receives a complete copy of all data. For this banking platform, that model is legally impermissible. The solution uses separate Global Tables configurations per data plane:

• US Global Table: Replicates between us-east-1 and us-west-2 only. Contains all transaction records, account state, session data, and customer profile data for US-resident customers.
• EU Global Table: Replicates between eu-west-1, eu-central-1, and eu-west-2 only. Contains all data for EU-resident and UK-resident customers.
• Control Plane Global Table: Replicates across all five regions but contains only non-personal configuration data - feature flags, routing rules, circuit breaker state, and synthetic health check results.

Data model for active-active with GDPR requirements

Immutable transaction records

Payment and account transaction records are modeled as immutable events (event sourcing pattern). Once written to DynamoDB, a transaction is never updated or deleted in the operational store - eliminating write conflicts and enabling straightforward audit trail reconstruction. For GDPR right-to-erasure compliance, personal data fields (counterparty name, remittance reference, beneficiary details) are stored encrypted with a per-customer data key derived from a customer-specific KMS CMK. To fulfill an erasure request, the customer's CMK is scheduled for deletion - rendering all encrypted field values permanently unreadable without physically deleting DynamoDB items (which would disrupt financial audit trails required under EU banking regulation).

Customer profile and PII handling

Customer profile records are stored in a separate EU Profile Table with field-level encryption applied to every PII attribute. Each PII field is encrypted with a field-specific data key wrapped by the customer's CMK, allowing selective decryption: a customer service agent querying account balance does not trigger decryption of address or identification fields their role does not require.

A pseudonymization system assigns every EU customer a platform-internal UUID (the Customer Reference ID, or CRI) used throughout transaction and analytics systems. The mapping table between CRI and real identity is stored only in the EU plane and is itself encrypted with a separate KMS key accessible only to the identity resolution service.

Conflict resolution strategy

DynamoDB Global Tables uses last-writer-wins (LWW) conflict resolution. For a banking platform processing 124,000 peak TPS, naive LWW could theoretically cause financial data loss if two regions concurrently update the same account balance. This risk is mitigated through:

• Optimistic concurrency: All account balance mutations use a conditional expression checking the current version attribute. A version mismatch returns ConditionalCheckFailedException, which the application treats as a concurrency signal and retries with re-read.
• Write affinity routing: For a given customer account, all write traffic is consistently routed to the same region using a hash of the account number modulo the number of active regions, making same-item concurrent writes from multiple regions extremely rare.
• Idempotency guarantees: Every write carries a ULID-based idempotency key stored with a 48-hour TTL. Duplicate submissions are detected and short-circuited before reaching the DynamoDB write path.

Aurora Global Database for relational data

Regulatory reference data, credit assessment records, compliance audit logs, and KYC documentation metadata are stored in Aurora PostgreSQL 16 via Aurora Global Database - one instance per data plane, with the writer in the primary region and read replicas in secondary regions.

Aurora Global Database maintains a single writer region per plane, which adds approximately 18ms of write-forwarding latency from eu-central-1 to eu-west-1. For EU payment processing where PSD2 Strong Customer Authentication requires sub-second end-to-end response times, the SCA flow reads from the local Aurora read replica and writes the SCA outcome to DynamoDB rather than Aurora - keeping the latency-sensitive path off the write-forwarding route.

GDPR right to erasure - technical implementation

The right to erasure (Article 17) implementation uses a purpose-built orchestration system called the Data Subject Rights Engine (DSRE). When a verified erasure request is received:

• Step 1 - KMS key scheduling: The customer's primary CMK and all derived field-level encryption keys are scheduled for deletion with a 7-day waiting period. The customer account is suspended during this window.
• Step 2 - Active store pseudonymization: DynamoDB profile records have PII fields overwritten with a tombstone value. The encrypted-at-rest field values become unreadable once the KMS key is deleted.
• Step 3 - Derivative store sweep: An automated Step Functions workflow purges customer data from S3 (statement PDFs, KYC document scans), CloudWatch Logs, Kinesis stream retention, Aurora audit logs, and OpenSearch behavioral analytics indices.
• Step 4 - Edge and cache invalidation: CloudFront cache invalidations are issued for customer-specific signed URLs. API Gateway cache entries are purged. ElastiCache Redis sessions are deleted.
• Step 5 - Confirmation and audit trail: A DPA-auditable erasure certificate is generated, signed by the DSRE service's signing key, and stored in a dedicated immutable S3 bucket (Object Lock, COMPLIANCE mode, 10-year retention) explicitly excluded from the erasure sweep.

End-to-end completion time for a full erasure across all data stores averaged 18 hours in production testing - well within the 30-day regulatory window.

The following table maps the key GDPR articles applicable to this banking platform to the specific technical controls implemented in the EU data plane architecture.

The GDPR telemetry problem

Conventional observability practice routes all telemetry to a single vendor for unified visibility. For this architecture, doing so for EU customer data would constitute an unauthorized international transfer - most US-headquartered observability vendors process and store telemetry data in the US by default, even if they offer EU data residency options that often exclude certain product features.

The architecture uses a two-Datadog-organization model:

• US Datadog organization: Hosted in Datadog's US1 region. Receives all telemetry from the US data plane, including customer behavioral metrics, transaction traces with customer identifiers, and full-resolution log data.
• EU Datadog organization: Hosted in Datadog's EU1 region (Frankfurt). Receives all telemetry from the EU data plane. Customer identifiers in traces and logs are tokenized at the OpenTelemetry Collector layer before leaving the EU plane - no raw customer identifiers enter this org.
• Shared availability dashboard: A read-only aggregated view of infrastructure health signals (HTTP 5xx rates, queue depths, DynamoDB consumed capacity, EKS node health) is federated into a cross-org Datadog dashboard. These signals contain no personal data.

GDPR-compliant log and trace processing

OpenTelemetry Collectors running as DaemonSets in the EU clusters apply a custom processor pipeline before exporting to Datadog EU:

• PII scrubbing: Regular expression-based redaction of IBAN patterns, email addresses, mobile numbers, and EU national ID formats from log message fields.
• Customer ID tokenization: The CRI present in traces is replaced with a session-scoped pseudonym generated by a tokenization service within the EU plane. The tokenization mapping has a 24-hour TTL, enabling troubleshooting within a session while preventing long-term re-identification.
• IP address truncation: Source IP addresses are truncated to /24 for IPv4 and /48 for IPv6 before leaving the EU OTel collector, consistent with EDPB guidance on IP addresses as personal data.

Incident detection and the 72-hour clock

Article 33's 72-hour breach notification requirement demanded significant improvement over the previous 94-hour detection-to-notification process. The new pipeline:

• GuardDuty with custom threat intelligence feeds specific to banking-sector attack patterns is enabled across all five regions, with findings federated to AWS Security Hub.
• A custom Lambda monitors Security Hub findings and categorizes them by potential personal data scope. Any finding touching EU-plane resources triggers an immediate PagerDuty alert to the DPO's escalation group with a pre-populated GDPR impact assessment form.
• The DSRE system includes a scope assessment mode that - given a set of potentially compromised service identifiers - automatically queries DynamoDB and Aurora audit logs to determine which customer records may have been exposed.
• Pre-drafted DPA notification templates for all five EU member states are stored in the incident response runbook, requiring only scope-specific fields to be completed before submission.

In the one security incident tested against this process (a simulated credential-stuffing attack during a GameDay exercise), the DPA notification was ready for legal review within 31 hours of initial detection.

VPC architecture and cross-plane isolation

Each of the five regions has a dedicated VPC owned by its respective AWS account. There are no VPC peering connections, Transit Gateway attachments, or AWS PrivateLink endpoints that cross the account boundary - enforced by AWS Config rules that alert on any such resource created in either account.

Within each data plane, regions are connected via AWS Transit Gateway for internal service communication. Transit Gateway route tables are scoped to the data plane's region set: the US Transit Gateway contains only us-east-1 and us-west-2; the EU Transit Gateway contains only eu-west-1, eu-central-1, and eu-west-2.

TLS and certificate management

All inter-service communication uses mutual TLS enforced by the Envoy service mesh deployed via AWS App Mesh. Certificates are issued by private Certificate Authorities managed by AWS Private CA, with separate CA hierarchies for the US and EU planes. The EU CA is hosted in eu-west-1 and its private key material never leaves the EU AWS KMS boundary - a technical guarantee that EU service certificates cannot be forged by US-plane infrastructure.

DNS and global routing

Route 53 serves three distinct functions in this architecture. Plane routing (US vs. EU) is handled by AWS Global Accelerator with geo-restriction policies. Within-plane latency routing distributes traffic across two US or three EU regions using Route 53 latency records with synthetic transaction health checks against each regional ALB endpoint. A Route 53 private hosted zone in each region handles intra-cluster service discovery, eliminating external DNS dependency for internal calls.

Automated failover within a data plane

Within each data plane, failover is fully automated. Route 53 health checks evaluate the synthetic transaction endpoint every 30 seconds. Failure of two consecutive checks removes the affected region from the latency routing pool. Each region is provisioned at 60% of normal plane-wide load, meaning any single-region failure leaves 120% of required capacity across survivors - a 20% headroom buffer above normal load.

DynamoDB Global Tables replication within the plane continues unaffected by a region failure. When the failed region recovers, Global Tables automatically resynchronizes, applying writes made during the outage via the DynamoDB Streams-based replication mechanism.

Cross-plane isolation during failures

A failure in the EU plane does not trigger any automatic actions in the US plane. The planes are independently operable and independently monitorable. There is no cross-plane circuit breaker, no cross-plane traffic rerouting, and no cross-plane data replication that could be affected. This isolation was intentional: cross-plane coupling introduces the risk that a US-plane action could cause US customer data to be written to EU infrastructure - creating a GDPR violation at the moment the on-call team is already under the most pressure.

DORA compliance and operational resilience testing

The EU Digital Operational Resilience Act (DORA), applicable from 17 January 2025, requires financial entities to conduct comprehensive ICT risk management including regular resilience testing. The platform's testing program includes:

• Monthly GameDays: A full region is removed from the EU plane's Route 53 pool during business hours to validate traffic absorption and observability alerting. A separate US GameDay runs the same month.
• Quarterly AWS FIS exercises: Scenarios simulating AZ-level failures, DynamoDB throttling, EKS control plane degradation, and KMS key access interruption are run quarterly.
• Annual TLPT: The Threat Led Penetration Testing required under DORA is conducted by an external provider with controlled production access.
• Monthly erasure SLA testing: The DSRE erasure workflow is triggered against a synthetic test customer record monthly to validate the 30-day SLA and confirm all 14 data store types are correctly swept.

Availability and resilience

GDPR and regulatory compliance

Performance

Data sovereignty is an architecture constraint, not a configuration

The most important shift was treating data residency as a hard architectural boundary - enforced at the IAM, KMS, networking, and observability layers - rather than a configuration option or a policy documented in a runbook. A policy that says "do not replicate EU data to the US" is a GDPR violation waiting to happen. An architecture where a US-account IAM role physically cannot write to an EU-account DynamoDB table is a technical guarantee.

This required restructuring the AWS account strategy mid-project. The original plan was a single-account model with resource-level IAM policies. After the first architecture review with the DPO and external GDPR counsel, this was rejected: a misconfigured IAM policy in a shared account could expose EU data, and the blast radius would be the entire platform. The cost of separate accounts is real, but it is the correct trade-off for regulated financial services.

The telemetry blind spot

The EU Datadog organization initially had significantly less observability coverage than the US organization because PII scrubbing was applied too aggressively, stripping fields useful for debugging that were incorrectly classified as personal data by the regex pipeline. Three weeks after EU production launch, a subtle payment processing bug took 4 hours to diagnose because the customer session ID - being tokenized - was needed to correlate traces across two services. The resolution was to refine the tokenization approach: the session pseudonym is now consistent within a 24-hour window, enabling trace correlation without long-term re-identification, and the scrubbing regex was tuned against real log samples rather than synthetic test cases.

DORA and GDPR have overlapping but distinct requirements

DORA's operational resilience requirements overlap significantly with the reliability practices the team had already implemented. However, DORA's incident reporting requirements for ICT-related incidents affecting financial services are distinct from GDPR's breach notification requirements - different triggers, timelines, and reporting targets (national competent authorities rather than DPAs). Maintaining two separate incident classification trees and two escalation paths added complexity but was necessary to avoid conflating the two regimes during an actual incident.

Testing the erasure pipeline before it is needed

The DSRE right-to-erasure pipeline was not fully end-to-end tested until 8 weeks before the EU production launch, at which point it was discovered that CloudFront access logs - containing truncated account numbers in the URI path for statement downloads - were being archived to an S3 bucket not included in the erasure sweep. The fix was straightforward but the discovery was uncomfortably late. The recommendation: map every data store that touches customer data before writing a line of erasure code, and test erasure against a synthetic customer record in each environment from the beginning of the build.