Multi-region AWS architecture diagrams: what to duplicate and what to draw once

Start with a horizontal lane above everything for the services that have no region: Route 53, CloudFront, IAM, AWS Organizations, and the WAF web ACL attached to a distribution. Below it, one container per region carrying its real name, eu-west-1 and us-east-1, not primary and secondary, because the names are what appears in the runbook.

One detail belongs on the global lane and is missed constantly: an ACM certificate used to require HTTPS between viewers and CloudFront must be requested or imported in us-east-1 no matter where the workload runs. That requirement is stated under "AWS Region for AWS Certificate Manager" in the CloudFront developer guide page on SSL/TLS certificate requirements, and it is narrower than people remember: a certificate on the origin load balancer can be issued in any region. Drawing both as one certificate is the kind of small lie that costs someone an afternoon during a cutover.

Mirror the request path and the data plane. Do not mirror what only exists once: the CI pipeline, the analytics stack reading from one region, the central logging destination, the internal tooling. Drawing a symmetric picture of an asymmetric system is how teams discover during an incident that the secondary region was never actually complete.

Then draw replication as directed arrows with the mechanism named on them, because each one has a different consistency and failover story. S3 Cross-Region Replication is asynchronous and per bucket. DynamoDB global tables are multi-active and replicate asynchronously, so a read in one region can be behind a write in another. Aurora Global Database replicates to a read-only secondary that must be promoted, which is a manual step in the failover path. ECR replication matters only at deploy time. Those four arrows look identical if you leave them unlabelled and mean four different things.

The question every reader has is what moves traffic. Show the Route 53 record with its routing policy, failover, latency, or weighted, and show the health check that drives it as an edge into that record. If you use Application Recovery Controller routing controls, draw them, because they are the switch a human will flip at three in the morning.

Label the posture explicitly on the canvas: active-active, warm standby, pilot light, or backup and restore. Add the target RTO and RPO as a caption. A diagram that shows two regions but not the posture invites everyone to assume the most optimistic one.

resource "aws_route53_record" "api_primary" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  set_identifier = "eu-west-1"

  failover_routing_policy {
    type = "PRIMARY"
  }

  health_check_id = aws_route53_health_check.eu_west_1.id

  alias {
    name                   = aws_lb.eu_west_1.dns_name
    zone_id                = aws_lb.eu_west_1.zone_id
    evaluate_target_health = true
  }
}

Describe the topology in one sentence and Datadef lays out the region zones, places the services with their real AWS icons, and labels the replication edges. From there the canvas is editable, so the annotations that matter most, posture, RTO, RPO, and what is deliberately not replicated, get added where the reader will see them.

The failure mode specific to multi-region diagrams is asymmetric drift: the secondary region gains a service the diagram never gets, or loses one nobody announced. When both regions are defined in the same Terraform repository, a connected sync regenerates the picture daily and a resource that exists in only one region shows up as exactly that.

The disaster recovery case comes out particularly cleanly, because a standby region is usually gated on a flag rather than deleted. The parse resolves count = var.enable_dr ? 1 : 0 by following the flag into the tfvars of each environment, and a resource whose flag is false keeps its node with the label "not deployed (count 0)" instead of vanishing. A diagram that says the standby stack exists in code and is currently switched off is more useful than one that draws it as live, and much more useful than one that leaves it out. The rest of the loop is in keeping an AWS diagram current.

• Multi-account AWS architecture diagrams
• Diagrams for a Well-Architected review
• Keep an AWS diagram current
• How to draw an AWS architecture diagram