A field-service company has a standby region. The application starts, the database replicates and the health check is green. During a switch, however, dispatchers cannot open photographs attached to a job: the files remain in the original region. New staff cannot sign in either, because authentication still depends on that site. The servers have moved. The business has not.
This is a more useful starting point than counting regions. Which work must continue after a site is lost, and what does it depend on? A second application deployment protects only the parts of the workflow that can actually operate independently.
Decide which failure you are covering
Several servers in one region help with individual machine failures. Multiple availability zones extend that protection but do not remove regional dependencies. Multi-region planning addresses a wider event: the primary region is unavailable, or it is no longer safe to operate there.
Define the required service first. Dispatchers may need to assign engineers, while engineers must read jobs and attach documents. Historical reporting might wait. Agree on recovery time and acceptable loss of recent changes: RTO and RPO. These are objectives to demonstrate, not automatic features of a second cloud bill.
Proximity to users is a separate benefit. Regional hosting can improve some journeys without providing a recovery path. A responsive local screen says little about whether a customer can continue working after the authoritative data source fails.
Active-active does not mean unrestricted writes everywhere
With active-passive, one region normally handles the workload. The other may be fully provisioned, running at reduced capacity, or waiting for additional components to be started. Recovery planning must include the time required to obtain capacity and make the entire service usable.
With active-active, both regions serve users during normal operation. That does not require both to update every record independently. Customers may have an assigned write region, or reads may be distributed around a single write path. Data ownership matters more than the topology label.
Consider engineer appointments. If two regions independently see the same slot as available, both may confirm it. The company needs a way to prevent conflicting assignments or a defined product response when connectivity is lost. Conflict handling cannot be deferred until the incident.
The awkward gap contains work already confirmed
Asynchronous replication leaves time between a primary write and its arrival in another region. Failover may therefore expose a copy missing changes already acknowledged to users. Low average replication lag does not prove that the gap stays small under stress.
Synchronous replication provides different guarantees within the selected platform and configuration. It adds coordination latency and makes writes depend on the required participants being reachable. “Fast, always available and conflict-free” is not a sufficient design. AWS's multi-region data guidance discusses these trade-offs.
After switching, the team may need to reconcile appointments, uploaded files and partner confirmations. A booking missing from the recovered database has not necessarily disappeared from the engineer's schedule. Stable operation identities and a way to inspect the external outcome are essential before repeating consequential actions.
Who is allowed to write after the switch?
A broken network connection does not prove the original region has stopped. It may still serve some clients while the standby believes it has failed. A single-writer design needs a mechanism that prevents competing authorities, such as controlled leadership with enforceable write permissions appropriate to the database.
Changing DNS does not establish that boundary. Some clients may retain an old address or an existing connection. Traffic routing and write ownership must move coherently, rather than being treated as unrelated tasks.
There is also a decision to authorise. Automation can execute a recovery procedure, but activation criteria, tolerated data loss and handling of an ambiguous outage need agreement beforehand. Otherwise the first serious discussion happens while dispatchers are already taking jobs over the phone.
Exercise a working journey, not just a landing page
Files, queues, keys, certificates, staff login and partner APIs must all be usable from the recovery region. The mechanism used to switch must not require the failed region to cooperate. This is the focus of AWS's regional dependency review.
For the field-service example, a useful exercise follows an ordinary employee: sign in, inspect an existing job, assign a new one, attach a document and receive the engineer's confirmation. A successful login-page check answers very little about that complete journey.
Then apply the agreed recovery workload. If both regions normally handle their own customers, the survivor needs capacity for whatever additional traffic the recovery plan accepts. An assumption that capacity will appear immediately should be tested against quotas, startup time and downstream limits.
Returning is a separate recovery step
When the original site comes back, its data may be stale. Sending traffic there simply because its servers respond is unsafe. Establish the authoritative state, restore the correct replication direction, reconcile unfinished work and then plan the return. Keeping the new primary for a while may be safer than rushing back to a familiar diagram.
Those exercises, configuration upkeep and checks after significant changes belong in the operating cost. For a small workflow that tolerates a longer interruption, restoration from protected backups may be sufficient. For a critical workflow, accept the multi-region capability against a demonstrated switch and return, not the existence of healthy standby servers.
AWS's operational readiness guidance covers recovery decisions, procedures and testing.