Configure Route53 latency routing records for the primary API domain so users are automatically routed to the lowest-latency AWS region when a second region becomes active.

Create Route53 health checks pointing to /beak/system/status (or /beak) for each region endpoint. Routing failover requires a healthy health check in the primary region before traffic is shifted.

Route53 failover records should have a TTL of 60 seconds or less. Long TTLs cause extended DNS propagation delays during region failover, increasing MTTR for multi-region incidents.

Write a runbook for the manual DNS failover sequence and perform a controlled test to verify traffic shifts correctly when the primary region health check fails.

Convert spaceduck-main table to a Global Table with replicas in the target secondary region. This enables active-active writes and automatic multi-region replication for the core spaceduck records.

Birth certificate and audit log tables require multi-region replication to maintain compliance and traceability across regions. Add replicas to all five platform tables.

Configure DynamoDB Point-in-Time Recovery (PITR) on all tables and enable on-demand backup copies to be replicated to an S3 bucket in the secondary region for disaster recovery.

Document and test the restore procedure using DynamoDB PITR or S3 backup copies. Establish RTO and RPO targets and confirm a full restore is achievable within the defined window.

Create an origin group with a primary and secondary origin in CloudFront. Configure the failover criteria (HTTP 5xx errors) so that CloudFront automatically routes requests to the secondary origin if the primary fails.

Review the current CloudFront geo-restriction configuration. Confirm that the restriction policy is intentional and compatible with multi-region expansion goals. Document any blocked regions that may affect secondary region traffic routing.

Review both CloudFront distributions (E3HQHA5N284LTS, E1WQP6P5ZWZO5K) for cache TTL settings. Ensure TTLs are appropriate for a multi-region deployment where origin failover requires near-real-time cache invalidation.

Simulate an origin outage and confirm that CloudFront correctly fails over to the secondary origin, serves content from the backup, and recovers automatically when the primary origin is restored.

Package the JWT verification and beak-key auth handler as a Lambda@Edge function. Deploy to us-east-1 (required for @Edge) and associate with the CloudFront distribution's viewer-request event.

Move HTTP redirect rules (e.g., trailing-slash normalisation, legacy URL redirects) to a Lambda@Edge origin-request function to ensure consistent routing behaviour across all CloudFront edge locations.

Lambda@Edge functions require an execution role trusted by both lambda.amazonaws.com and edgelambda.amazonaws.com. Verify the role is correctly configured before deployment.

Benchmark Lambda@Edge functions for cold-start latency at multiple PoPs. Lambda@Edge has stricter limits (1MB code, 10s timeout, 128MB memory for viewer events) than standard Lambda.

Provision a standby Cognito User Pool in the secondary region (e.g., ap-southeast-1) with identical app client configuration, triggers, and attribute schema. Export the pool configuration from us-east-1 as IaC.

Cognito User Pools do not natively replicate between regions. Design a token synchronisation or migration strategy: either use DynamoDB-backed custom auth or export/import user records via the Cognito import job API during failover.

After provisioning the backup pool, verify that all Lambda triggers (pre-sign-up, post-confirmation, pre-token-generation), app clients, and OAuth settings are identical to the primary pool.

Perform a complete signup → verify → login → token refresh flow against the backup pool using test credentials. Confirm all downstream Lambda routes accept tokens from the secondary pool's issuer.