DR design of API gateway Edge optimized

For a warm standby disaster recovery setup with API Gateway, you'll need to implement a more comprehensive approach than simply replicating your Edge Optimized API Gateway with the same custom domain.

In a warm standby DR strategy for API Gateway with a custom domain, you should:

1. Deploy your API Gateway in both your primary and secondary (DR) regions with the same custom domain configuration.

2. Use Amazon Route 53 to set up DNS failover between regions. This requires:

• Configuring primary and secondary failover records in Route 53 for your custom domain
• The primary record points to your API Gateway endpoint in the primary region
• The secondary record points to your API Gateway endpoint in the DR region

3. Implement health checks to control the failover mechanism. You can use:

• Custom Route 53 health checks for your API Gateway APIs
• CloudWatch alarms to help control DNS failover

4. For your warm standby approach, ensure your secondary region has:

• A fully functional but potentially scaled-down copy of your production environment
• All necessary resources provisioned and ready to handle traffic
• Regular replication of data and configuration from the primary region

This approach allows you to maintain your custom domain across regions and enables automatic or operator-initiated failover without requiring clients to change API endpoints. The warm standby strategy provides a recovery time objective (RTO) of minutes, which is faster than backup-restore or pilot light approaches but less expensive than a multi-site active/active configuration.

Remember that Edge Optimized API Gateways are designed for global clients accessing APIs hosted in a single region. For true multi-region resilience, you'll need to rely on Route 53's DNS failover capabilities to route traffic to your secondary region when needed.
Sources
Implementing multi-Region failover for Amazon API Gateway | AWS Compute Blog
Configure custom health checks for DNS failover for an API Gateway API - Amazon API Gateway
Defining your DR strategy - AWS Prescriptive Guidance

Hi there! Great question about implementing DR with Edge Optimized API Gateway. This is a common scenario that many customers face, and there's an important consideration about custom domains that will shape your approach.

The Core Challenge Edge Optimized API Gateway custom domains are globally unique resources that can't be replicated across regions the way you're planning. But don't worry - there's a proven pattern that actually works better for DR scenarios!

Recommended Solution: DNS-Based Failover Here's the most straightforward approach that works well for most customers:

Architecture Overview

Primary Region (Production):

Keep your existing Edge Optimized API Gateway with custom domain Example: api.yourcompany.com → us-east-1

DR Region (Standby):

• Deploy a Regional API Gateway (not Edge Optimized)
• Use the same custom domain name Example: api.yourcompany.com → us-west-2

Failover Mechanism:

• Route 53 health checks monitor your primary endpoint
• Automatic DNS failover redirects traffic to DR region when issues are detected

NOTE: Why Regional for DR? Regional API Gateway endpoints actually fail over faster than Edge Optimized ones, making them perfect for your DR region.

Getting This Set Up

Step 1: Prepare Your DR Region

• Set up your Regional API Gateway in your chosen DR region with identical stage configurations to your primary. The Regional endpoint will provide faster failover times compared to Edge Optimized.

Step 2: Handle SSL Certificates

• Request ACM certificates in both regions for your custom domain
• Consider wildcard certificates (*.yourcompany.com) for flexibility
• Set up automatic renewal to avoid certificate expiration issues

Step 3: Configure DNS Failover

• Create Route 53 health checks to monitor your primary API Gateway endpoint
• Set up weighted or failover routing policies
• Configure health check alarms in CloudWatch for proactive monitoring

Step 4: Sync Your Backend Services Ensure your backend infrastructure is ready in the DR region:

• Lambda functions: Deploy identical functions in DR region
• Databases: Set up RDS Cross-Region replication or DynamoDB Global Tables
• Static assets: Configure S3 Cross-Region Replication

What to Expect: RTO & RPO

Recovery Time (RTO):

• DNS propagation: 30-300 seconds
• Plus your application startup time
• Total: Typically under 5 minutes for warm standby

Recovery Point (RPO):

• Depends on your data
• Replication strategy
• AWS managed services typically provide 1-15 minute replication lag

Testing Your DR Setup:

• Regularly test failover by temporarily failing health checks
• Verify all backend services are accessible from DR region
• Document and practice your failback procedures

Automated Monitoring:

• API Gateway 4XX/5XX error rates
• Response latency metrics
• Route 53 health check status
• Cross-region replication lag

Cost Considerations For your warm standby approach:

• Configure Auto Scaling to scale up during actual failover events
• Consider Reserved Instances for predictable DR infrastructure costs
• API Gateway Regional endpoints have the same pricing as Edge Optimized

References for Implementation:

• API Gateway Custom Domains: https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html
• Route 53 DNS Failover: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
• RDS Cross-Region Backups: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CrossRegionAutomatedBackups.html
• DynamoDB Global Tables: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html