AWS Architecture Series #6 — Aurora Global Database: The Multi-Region Pattern Teams Get Half Right

Business Challenge

A financial services platform processes transactions in us-east-1. The compliance team requires a documented RTO of under 5 minutes and RPO of under 1 minute for the primary database tier. The platform team sets up Aurora Global Database with a secondary cluster in eu-west-1, runs a DR drill, promotes the secondary in 47 seconds, and files the compliance report. The architecture works.

Six months later, us-east-1 suffers a real 3-hour outage. Under pressure the team reaches for the procedure they rehearsed: detach eu-west-1 from the global cluster and promote it. Transactions resume, the RTO target is met. Then the primary region recovers — and nobody knows what to do next. Detaching is what made eu-west-1 a standalone cluster, so there is nothing left to rejoin: the old primary comes back as its own cluster with a write history that diverged the moment the detach happened. There is no automatic merge and no automatic rejoin. The global cluster stays broken until someone rebuilds it by hand.

The uncomfortable part is that this was avoidable, and not by better runbook discipline. AWS offers two unplanned-failover methods. Managed failover — failover-global-cluster --allow-data-loss — promotes the secondary and then, as soon as the old Region is healthy again, adds it back to the global cluster as a secondary automatically, preserving the topology. Manual failover, the detach-and-promote path, is the one that leaves you rebuilding. AWS recommends managed failover for disaster recovery and positions manual failover as the fallback for when it is unavailable — most commonly because the primary and secondary are running engine versions whose patch levels are not compatible.

The DR plan covered failover. It did not cover failback. This is the gap that makes Aurora Global Database implementations incomplete in most enterprises.

Architecture

Aurora Global Database replicates at the storage layer, not the SQL layer. The primary region maintains a writer instance and optional local readers. Up to five secondary regions each maintain a read-only cluster. Replication is asynchronous but fast — typical lag is under one second because it operates on physical redo log segments, not logical SQL statements.

Endpoint strategy

Applications must never hard-code Aurora cluster endpoints. Instead, Route 53 aliases sit in front of the cluster endpoints. During normal operation, write.db.internal points to the primary cluster writer endpoint. During failover, you update the Route 53 record to point to the promoted secondary. Applications reconnect to the same DNS name — no application config change required.

Read traffic uses a separate read.db.internal record with latency-based routing. EU users are served by the eu-west-1 reader cluster; US users by the us-east-1 reader endpoint. This gives you read scalability and geographic latency reduction without any application awareness of the global topology.

Write forwarding

Aurora Global Database supports write forwarding on secondary clusters. When enabled, write statements issued against the secondary are transparently forwarded to the primary writer. This simplifies application architecture — a single connection string works for both reads and writes in any region — but adds latency to writes from the secondary region (round-trip to primary plus replication lag back). Write forwarding is appropriate for low-volume, non-latency-sensitive writes from the secondary region, not for high-throughput write paths.

Why This Architecture Holds Up

Key Architecture Decisions

Tradeoffs

Terraform Pattern

The key resource is aws_rds_global_cluster — this is the global cluster object that the primary and secondary regional clusters attach to.

# Global cluster object (region-agnostic)
resource "aws_rds_global_cluster" "main" {
  global_cluster_identifier = "platform-global"
  engine                    = "aurora-postgresql"
  engine_version            = "16.4"
  database_name             = "platform"
  storage_encrypted         = true
}

# Primary cluster — us-east-1
resource "aws_rds_cluster" "primary" {
  provider                  = aws.us_east_1
  cluster_identifier        = "platform-primary"
  engine                    = aws_rds_global_cluster.main.engine
  engine_version            = aws_rds_global_cluster.main.engine_version
  global_cluster_identifier = aws_rds_global_cluster.main.id
  database_name             = "platform"
  master_username           = var.db_username
  master_password           = var.db_password
  db_subnet_group_name      = aws_db_subnet_group.primary.name
  vpc_security_group_ids    = [aws_security_group.aurora_primary.id]
  kms_key_id                = aws_kms_key.aurora_primary.arn
  storage_encrypted         = true
  skip_final_snapshot       = false
  final_snapshot_identifier = "platform-primary-final"
}

resource "aws_rds_cluster_instance" "primary_writer" {
  provider             = aws.us_east_1
  identifier           = "platform-primary-writer"
  cluster_identifier   = aws_rds_cluster.primary.id
  instance_class       = "db.r6g.2xlarge"
  engine               = aws_rds_cluster.primary.engine
  engine_version       = aws_rds_cluster.primary.engine_version
  publicly_accessible  = false
}

# Secondary cluster — eu-west-1
resource "aws_rds_cluster" "secondary" {
  provider                  = aws.eu_west_1
  cluster_identifier        = "platform-secondary"
  engine                    = aws_rds_global_cluster.main.engine
  engine_version            = aws_rds_global_cluster.main.engine_version
  global_cluster_identifier = aws_rds_global_cluster.main.id
  db_subnet_group_name      = aws_db_subnet_group.secondary.name
  vpc_security_group_ids    = [aws_security_group.aurora_secondary.id]
  kms_key_id                = aws_kms_key.aurora_secondary.arn
  storage_encrypted         = true
  skip_final_snapshot       = false
  final_snapshot_identifier = "platform-secondary-final"

  depends_on = [aws_rds_cluster_instance.primary_writer]
}

resource "aws_rds_cluster_instance" "secondary_reader" {
  provider             = aws.eu_west_1
  identifier           = "platform-secondary-reader"
  cluster_identifier   = aws_rds_cluster.secondary.id
  instance_class       = "db.r6g.2xlarge"   # match primary writer size
  engine               = aws_rds_cluster.secondary.engine
  engine_version       = aws_rds_cluster.secondary.engine_version
  publicly_accessible  = false
}

# Route 53 write endpoint alias
resource "aws_route53_record" "db_write" {
  zone_id = var.private_zone_id
  name    = "write.db"
  type    = "CNAME"
  ttl     = 30
  records = [aws_rds_cluster.primary.endpoint]
}

Closing Thought

Aurora Global Database solves the hard part of multi-region database architecture: keeping a secondary region current enough to take over production traffic within seconds, not hours. The replication lag target of under one second is not a marketing claim — it reflects the architecture's use of physical storage replication rather than logical query replay.

But the architecture only delivers its promise when the team has practised the full lifecycle. Failover without a tested failback plan is a trap: the drill passes, the compliance report is filed, and the real incident reveals a gap that takes days to close. Build both runbooks, test both paths, and size the secondary to absorb writes from day one — not from the moment a region goes down.

Official AWS Reference

• Using Amazon Aurora Global Database — topology, advantages and limitations
• Using switchover or failover in Aurora Global Database — the managed and manual failover paths, and what each means for failback
• Removing a cluster from an Amazon Aurora global database
• Using write forwarding in an Amazon Aurora global database
• Monitoring an Amazon Aurora global database — AuroraGlobalDBRPOLag and AuroraGlobalDBReplicationLag