---
title: "Multi-region disaster recovery for Amazon API Gateway WebSocket APIs"
description: "WebSocket connections for real-time applications like live auctions and collaborative editors are vulnerable to regional outages because each connection is tied to a single AWS Region. A regional failure severs all active connections and loses session state. This post presents an active-passive multi-region disaster recovery pattern that uses Amazon API Gateway WebSocket APIs, Route 53 failover routing, DynamoDB Global Tables for cross-Region state replication, a canary health probe, and client-side reconnection logic. The canary Lambda function tests the endpoint every minute and drives a CloudWatch alarm that triggers a Route 53 health check to mark the primary Region unhealthy. Clients detect connection drops via application-level heartbeat messages and reconnect with exponential backoff and full jitter to avoid thundering herd. After reconnection, clients retrieve the latest application state from the secondary Region’s DynamoDB replica and resume their session automatically."
---

# Multi-region disaster recovery for Amazon API Gateway WebSocket APIs

[AWS](https://yomu.fyi/company/aws) · Shubham Dhoka · Oct 14, 2026

**Type:** Tutorial

## Summary

WebSocket connections for real-time applications like live auctions and collaborative editors are vulnerable to regional outages because each connection is tied to a single AWS Region. A regional failure severs all active connections and loses session state. This post presents an active-passive multi-region disaster recovery pattern that uses Amazon API Gateway WebSocket APIs, Route 53 failover routing, DynamoDB Global Tables for cross-Region state replication, a canary health probe, and client-side reconnection logic. The canary Lambda function tests the endpoint every minute and drives a CloudWatch alarm that triggers a Route 53 health check to mark the primary Region unhealthy. Clients detect connection drops via application-level heartbeat messages and reconnect with exponential backoff and full jitter to avoid thundering herd. After reconnection, clients retrieve the latest application state from the secondary Region’s DynamoDB replica and resume their session automatically.

## Context

Real-time applications relying on persistent WebSocket connections face a unique challenge during regional outages: connections are bound to a single region and state is lost. Traditional single-region deployments cannot restore sessions automatically. This pattern addresses that by decoupling connection from state and automating failover.

## Approach / What changed

Active-passive multi-region architecture using Amazon API Gateway WebSocket APIs, Route 53 DNS failover, DynamoDB Global Tables for state replication, a canary health probe driven by EventBridge and CloudWatch, and client-side reconnection with heartbeat and exponential backoff with full jitter.

## Takeaways

- The canary health probe opens a WebSocket connection to the endpoint every minute, sends a heartbeat, and publishes the result as a custom CloudWatch metric to drive failover detection.
- Exponential backoff with full jitter prevents a thundering herd during reconnection by randomizing the delay within doubling intervals, spreading retries over time.
- State is stored in DynamoDB Global Tables, which replicates asynchronously to the secondary Region typically within a second, but writes immediately before a failure may be lost.

## FAQ

### How does the client detect a broken WebSocket connection?

The client uses an application-level heartbeat mechanism. It sends a lightweight message at regular intervals (e.g., every 30 seconds) and expects an acknowledgment (e.g., 'pong') within a timeout (e.g., 35 seconds). If no acknowledgment is received, the connection is considered broken.

### What happens to application state during failover?

Application state is stored in DynamoDB Global Tables, which replicates asynchronously to the secondary Region. During failover, the client reconnects and sends a getState message to retrieve the latest state from the secondary Region's DynamoDB replica. Writes that occur immediately before the failure may not be replicated.

### How long does failover detection take?

The canary probes every minute, and the CloudWatch alarm fires after two consecutive failures, so failover detection takes about two minutes. After DNS propagation completes, the next client reconnection attempt reaches the secondary Region.

**Tags:** [API Gateway](https://yomu.fyi/topic/api-gateway), [Disaster Recovery](https://yomu.fyi/topic/disaster-recovery), [DNS](https://yomu.fyi/topic/dns), [DynamoDB](https://yomu.fyi/topic/dynamodb), [Real-time](https://yomu.fyi/topic/real-time)

- Source: [AWS](https://aws.amazon.com/blogs/architecture/multi-region-disaster-recovery-for-amazon-api-gateway-websocket-apis)
- Source URL: https://aws.amazon.com/blogs/architecture/multi-region-disaster-recovery-for-amazon-api-gateway-websocket-apis
- Ingested by Yomu: 2026-10-14T15:00:12.511Z

[Read original post](https://aws.amazon.com/blogs/architecture/multi-region-disaster-recovery-for-amazon-api-gateway-websocket-apis)