This sample shows an active-passive disaster-recovery setup across two AWS regions. All users are served from us-east-1; us-west-2 keeps a small warm copy of the application and a continuously replicated database. If the primary region fails its health check, DNS sends users to the secondary. The diagram makes the routing rule, the replication links and the standby capacity explicit.
It is an architecture (topology) diagram. UML covers software structure and behaviour; topology diagrams are the standard companion notation for infrastructure and resilience.
1. The diagram
DNS decides. Route 53 holds two records for the same name with a failover routing policy: PRIMARY points at the us-east-1 load balancer, SECONDARY at us-west-2.
Health check. Route 53 health checkers probe /health in the primary region from several locations. While it passes, only the primary record is returned; the endpoint should check the database too, not just the web server.
Data follows. Aurora Global Database replicates storage to the secondary region asynchronously, usually under a second behind. S3 Cross-Region Replication copies uploaded objects. The secondary app tier runs at reduced size so it is warm, not cold.
The two numbers on the right are the point of the whole picture: RTO (how long until service is back) is minutes because DNS and scaling take time; RPO (how much data can be lost) is seconds because replication is asynchronous.
2. How to read it
Solid green means live; grey dashed means waiting. Check that every stateful box in the active region has a green dashed replication arrow to its twin, and that the passive side has enough capacity, or a fast enough scaling policy, to take full load.
3. Variant: after a regional failover
The "after" picture is what the runbook should match. The health check fails, Route 53 starts answering with the secondary record (clients pick it up once the record's TTL expires, so keep it short, such as 60 seconds), the Aurora secondary is promoted to writer, and the Auto Scaling group grows from 2 to 6 instances. Writes that had not replicated yet are lost: that is the RPO made visible. Failing back is a separate, planned operation.
4. Pros, cons, and when to use
Pros
Puts RTO and RPO next to the mechanism that determines them.
Shows exactly which components are duplicated and which are not.
Before and after views double as a failover runbook and game-day checklist.
Easy for auditors and business owners to understand.
Highlights the DNS TTL and health-check path, which are often forgotten.
Cons
Shows the intended design, not whether failover has actually been tested.
Hides the order of steps and who triggers them (use an activity diagram for the runbook).
Secrets, certificates, IAM and quotas in the second region are easy to leave off the picture.
Can give false confidence about replication lag under heavy load.
When to use
Disaster-recovery design and reviews, compliance evidence.
Planning game days and comparing pilot light, warm standby and active-active.
When not to use
Single-region high availability (an Availability Zone diagram is enough).
Active-active systems with conflict resolution, which need a data-flow or sequence view.