AWS Multi-Region High Availability Architecture Diagram

Most AWS multi-region architecture diagrams fail the same way: two identical boxes labeled us-east-1 and eu-west-1, side by side, with nothing between them. It looks like high availability, but it answers none of the questions a reviewer or an on-call engineer will ask. Where do writes go? Which way does data replicate? What moves traffic when a region degrades, and who or what decides? This post covers what the diagram has to show, how active-active and active-passive designs differ on paper, and how to draw it in Archboard starting from a free example.

What an AWS multi-region architecture diagram must show

Read the diagram top to bottom, the way a request travels.

1. Global entry: Route 53 and CloudFront

• Amazon Route 53 sits above both regions, not inside one. Put the routing policy on the edge label: failover (primary and secondary records tied to health checks), latency-based (send each user to the region with the lowest latency) or weighted. Draw the health checks as well, because failover routing only works if they exist.
• Amazon CloudFront sits in front of the regional origins. If you use an origin group with origin failover, draw both origins and mark which one is primary. CloudFront origin failover applies to GET, HEAD and OPTIONS requests, so writes still need their own path.

2. Regional entry: Application Load Balancer

An ALB is a regional resource that spans the Availability Zones you enable for it. Draw one per region, inside the region boundary, with targets in at least two AZs.

3. Compute across Availability Zones

Amazon ECS services, Amazon EKS node groups or EC2 Auto Scaling groups, whichever runs your application, drawn across two or three AZ frames. The diagram should make one point clear: losing an AZ is handled inside the region, and losing a region is handled by the global layer.

4. The data layer, with arrows

This is where most diagrams go quiet. Each data store has its own replication model, and the arrow direction is the whole story.

Add a note that S3 replication rules apply to new objects; objects that existed before the rule need S3 Batch Replication. Someone will ask.

5. Secrets and configuration

AWS Secrets Manager can replicate a secret to other regions, and AWS KMS supports multi-Region keys. Systems Manager Parameter Store is regional. Draw where each region reads its secrets and configuration from. A failover that works until the application cannot decrypt its database password is not a failover.

6. Observability and the control plane

Show what detects a failure and what acts on it: Route 53 health checks, CloudWatch alarms in each region, synthetic canaries, and a cross-region dashboard. If failover is triggered by Amazon Application Recovery Controller (ARC) routing controls or by a runbook, put that on the diagram too. The AWS Well-Architected Reliability Pillar advises relying on data plane operations rather than control plane changes during recovery. Health-check-driven DNS failover is an example of the first kind, and the diagram is the right place to show which one you depend on.

Active-active vs active-passive

AWS describes four disaster recovery strategies. Three of them run something in a second region, and each one changes what the diagram must say.

The numbers are yours to set. Write your RTO and RPO targets on the canvas next to the strategy, so the diagram and the business requirement can be checked against each other.

Active-active is not automatically better. It removes the promotion step, but it forces you to decide how each data store handles concurrent writes. With Aurora Global Database, only one region writes at a time, so an active-active design built on it still has a single write region. Draw that honestly.

Make the failover path explicit

Use three edge styles and say so in a legend:

• Request path: solid arrows from users through DNS, CDN, ALB and compute.
• Replication: dashed arrows between data stores, labeled with direction and mode (async, multi-active).
• Failover: a separate, labeled path showing where traffic goes when the primary region is unhealthy.

Then number the failover sequence in a note on the canvas:

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

If a step is manual, say who runs it. If a step depends on a control plane API, mark it.

Common mistakes

• One region drawn twice with no data flow. Two copies of the same stack without replication arrows say nothing about recovery.
• Hiding the control plane. Health checks, routing controls and runbooks decide whether failover happens. Leave them off and the diagram describes a system that cannot fail over.
• No failover arrows. The request path in normal operation is half the story.
• Global services drawn inside a region. Route 53 and CloudFront are global; drawing them inside one region frame implies a dependency that is not there, or hides one that is.
• No AZs. Region-level redundancy does not replace AZ-level redundancy; show both.
• Forgotten state. Caches, queues and session stores are regional too. Show where they live and what happens to them.

Build it in Archboard

In Archboard you build this with Cloud and Network pack nodes: first-class nodes with ports that you label with the AWS service names, so every box shows both its role and the exact service. Here is how to build the diagram.

1. Study the free template. Open /examples/multi-region-cloud-ha. It shows a CDN, a dual-region load balancer, compute and a managed database across regions. Use it as your reference, or copy it into your workspace with Use this example, then extend it with the layers above.
2. Create the region and AZ boundaries. Add two Cloud pack Region frames labeled us-east-1 (primary) and eu-west-1 (secondary). Inside each, add Core Frame elements for the AZs.
3. Add the global layer above the regions. Network pack Internet for users, Network pack DNS labeled Route 53 (failover routing), and Cloud pack CDN labeled CloudFront.
4. Fill each region. Cloud pack Cloud LB labeled ALB, Compute nodes in each AZ frame labeled ECS service or EC2 Auto Scaling group (or a Kubernetes Cluster node for EKS), Managed DB nodes labeled Aurora (writer) and Aurora (secondary, read-only), another for DynamoDB global table, and Object Storage labeled S3.
5. Connect ports and label every edge. Request path, replication direction and mode, failover path. Use the edge labels for the routing policy and replication type.
6. Add the control plane and notes. Core Box nodes for Secrets Manager, CloudWatch and health checks; a Note with the numbered failover sequence; a Markdown block with your RTO and RPO targets and the strategy you chose.

Count your nodes before you start: a full two-region map usually goes past the Free plan's 15 diagram nodes per diagram (notes and text count separately, up to 150), so Pro is the natural fit, with unlimited nodes, embedding in your docs site and PDF export. More patterns are on the cloud use case page.

FAQ

Can I use official AWS icons in Archboard? Archboard's typed Cloud and Network nodes are vendor-neutral, but you can add AWS logos with the Core Icon node, which searches Iconify (for example logos:aws-route53), or upload the official AWS Architecture Icons as images. Label each node with the AWS service name, such as Route 53 or Aurora Global Database, and the diagram reads clearly to anyone who knows AWS.

Should I draw both regions and AZs? Yes. AZs show how you survive a zone failure, regions show how you survive a regional one. They are different failure modes and different mechanisms.

Active-active or active-passive? Start from your RTO and RPO targets and your data model. If your main database has a single writer region, active-passive (pilot light or warm standby) is often the simpler and more truthful design. Write the decision on the diagram.

How do I share it? Export SVG or PNG (watermarked on Free), share a public link, or embed it in your docs on Pro.

Start free — one seat, no credit card