Regional recovery design
Size the recovery region for the work it must accept
A standby that handles health checks may still be too small for production traffic. Include cold caches, queued work and provisioning time in the capacity plan.
In this article
Define the required recovery service
Decide whether the recovery region must support every feature immediately or an explicit essential subset. A degraded mode can be reasonable if the business understands it and the application enforces it safely.
State expected traffic and background work for that mode. Do not size only from the average quiet period if incidents can occur during a busy window.
Include integrations whose retries may arrive together after service returns.
Measure the cold path
The target may start with empty caches, unused connection pools and a backlog of work. Measure source load and latency under those conditions.
A warm steady-state benchmark can understate the capacity needed immediately after failover. Protect databases and external services from a sudden burst of misses and retries.
Test scaling time and the resource availability assumptions behind it. Capacity that can theoretically be requested is not identical to capacity already ready to serve.
Compare standby strategies using evidence
Keeping more resources active can reduce activation work but increases ongoing cost. A smaller standby may be economical when its measured scale-up and recovery time meet the requirement.
Use current provider prices for an actual estimate and include replication, storage, transfer and operational maintenance. Avoid comparing compute bills alone.
Also account for the engineering complexity of multiple active writers if that model is proposed. Lower apparent failover time can come with a much harder data-consistency problem.
Keep readiness current
Revisit capacity after significant traffic growth or architectural change. A standby sized for last year's service can remain green while becoming inadequate.
Run representative recovery load tests at a cadence suited to the service and record the supported throughput and limitations.
The cost decision should connect spend to a demonstrated recovery capability. A second region is valuable when it can carry the required work under failure conditions, not simply because its resources appear in the inventory.
Include backlog in the recovery load
Consider an illustrative queue with 60,000 waiting jobs when service returns. If new work arrives at 100 jobs per second and workers safely complete 150, only 50 jobs per second reduce the backlog. Clearing it takes about 20 minutes, excluding interruptions. Sizing from the worker's total completion rate would produce a misleading estimate. Include downstream limits and the user-facing urgency of those jobs when deciding whether more capacity is useful.
Primary sources
AWS: disaster recovery strategiesReferences checked 11 September 2026.