AWS recommends three disaster recovery patterns for architectures spanning AWS Outposts racks and AWS Local Zones: DNS-based failover for simple workloads with higher RTO, active/active load balancing for near-zero downtime at higher cost, and hybrid database replication for balanced RPO/RTO in stateful applications. Each pattern avoids single points of failure by distributing workloads across two Outposts racks or an Outpost rack and a Local Zone.
DNS-based failover for workloads with tolerant recovery time
This approach uses Amazon Route 53 health checks and failover routing to redirect traffic from a primary site in an AWS Outposts rack or Local Zone to a secondary site in another Outposts rack or Local Zone when an outage is detected. It is best suited for stateless or read-heavy workloads where brief downtime during failover is acceptable. The DNS propagation delay typically results in an RTO of 2–5 minutes, with near-zero RPO since data is synchronously replicated to the secondary site.
Implementation requires configuring Route 53 health checks for endpoints in both locations and setting up failover routing policies. The secondary site remains passive until failover is triggered, minimizing ongoing costs but requiring manual or automated validation of recovery procedures. This pattern avoids a single point of failure by ensuring no single location hosts all critical components.
Trade-offs include longer recovery times compared to active/active setups and the need for careful TTL management to balance failover speed with DNS caching behavior. It is ideal for organizations prioritizing cost efficiency over instantaneous recovery, particularly for batch processing or internal tools with relaxed SLAs.
Active/active load balancing for minimal downtime
In this pattern, workloads run simultaneously across two locations—such as two AWS Outposts racks or an Outposts rack and an AWS Local Zone—with traffic distributed via Elastic Load Balancing (ELB) or Amazon CloudFront. Both sites process requests in real time, enabling near-instantaneous failover if one location becomes unavailable. This achieves an RTO of under 30 seconds and near-zero RPO when combined with synchronous data replication.
To implement, deploy identical application stacks in both locations and configure ELB or CloudFront to route traffic based on latency or health checks. Auto Scaling groups ensure capacity can absorb the full load during a failure. Data stores must use synchronous replication (e.g., Amazon RDS with synchronous standby or custom database clustering) to maintain consistency.
The primary trade-off is higher operational cost due to duplicated compute and licensing fees for active workloads in both locations. It also increases complexity in configuration and monitoring, making it best suited for customer-facing applications with strict uptime requirements, such as financial trading platforms or e-commerce storefronts.
Hybrid database replication for balanced RPO and RTO
This approach combines asynchronous database replication with application-level failover to optimize for both recovery point and time objectives. Changes are asynchronously replicated from a primary database in an AWS Outposts rack or Local Zone to a standby in another location, minimizing bandwidth usage while keeping RPO low (typically under 5 minutes). Application failover is triggered via health checks, yielding an RTO of 1–3 minutes.
Implementation involves setting up database replication using tools like AWS DBSync, native database log shipping, or custom change data capture (CDC) pipelines. The application layer must handle potential data divergence during failover, such as by using conflict resolution logic or accepting minor data loss. Read replicas can be promoted to primary upon failure.
Trade-offs include a small but measurable RPO due to replication lag and the need for application-level handling of inconsistent states. It is ideal for workloads that cannot afford active/active costs but require tighter recovery than DNS failover provides, such as SaaS platforms or internal APIs with moderate SLAs.
What to do next
To get started, map your workload’s RTO and RPO requirements to one of these three patterns, then validate failover procedures using AWS Fault Injection Simulator. Begin with DNS-based failover for non-critical systems, then evaluate active/active or hybrid replication as SLAs tighten. Document runbooks and test quarterly to ensure recovery readiness across your hybrid edge footprint.
Source: Planning for disaster recovery using AWS Local Zones and AWS Outposts racks (AWS).
