Multi Region strategy for API Gateway

Question

If disaster recovery is not a requirement, what would be the best strategy for setting up API Gateway to server global customers. Here are three options that I can think of, not able to land on one.

**Option 1**: Single Edge Optimized API Gateway serving traffic
* Pros: save cost and avoid complexity of data replication (backend is opensearch)
* Cons: Latency? not sure how much edge optimized API will help with latency, as customer will be hitting the API at nearest edge (ssl handshake, etc) and traffic flowing via backbone network. ( Question 1)

**Option 2** Multiple Regional API Gateway with Route53 Latency based routing
* Pros: customers hitting closest API. 
* Cons: Data replication, Cost. Also, since there is no cloud front here, traffic will be flowing via internet to closest region API, lets say we have API deployed in two regions , US and Singapore, would users in Europe see latency , worse than the Option 1, where requests are going to nearest edge location and reaches API via backbone?

**Option 3** Multiple Edge Optimized API Gateway with Route53 Latency based routing
* Pros: customers hitting closest API. Not sure how latency based routing works on an edge optimized endpoint, would it even help, since both endpoints are edge optimized. Not sure how smart is Route53 (Question 2) 
* Cons: Data replication, cost and uncertainty of Latency based routing.

and Finally , one that I can think of could work, but haven't found too many solutions where people implemented.

**Option 4** Multiple Regional API Gateway with single custom Cloudfront on top with cloudfront functions to do the routing.
 * Pros: customers hitting closest edge optimized location and routed to nearest API, this routing will be based on country of origin header from cloudfront. 
 * Cons: Same Data Replication, Cost and predefined list of countries based routing.

I need to spend time and run tests with multiple solutions. But wanted to seek community advise first.

To summarize everything, if cost, complexity and disaster recovery are kept out of discussion, what would be best architecture for API Gateway to avoid  latency issues.

Answer

That's a great question! Obviously there can be several opinions and probably there's no 100% correct answer but i will try to share my opinion - hopefully you find it useful.

I personally would choose between 1 and 4 as route53 routing wouldn't really give you any latency benefits compared to cloudFront not even mentioning caching, SSL termination and other stuff.

Now between 1 and 4 i would have started with 1 (because its cheaper than 4) and see if you happy with the latency in specific regions and for those where you are not getting the expected performance, you would need to follow the approach outlined in option 4.

Answer

Just to add to Alex's answer,

I tested out option 4, landed at a better version of option 4 which is combination of Route53 Latency + CloudFront.

Two API Gateway Regional Endpoints, with Route53 Latency policy.  One CloudFront(with caching disabled) and Route53 API EndPoint as the origin. 
This allow SSL Handshake to happen at CloudFront and request will be routed to nearest regional API.

Answer

This presentation from re:Invent 2019, gives a really good overview of the various scenarios for building a Global application or API. Toward the end there is an architecture that utilizes Global Accelerator to achieve a multi-region, active-active architecture over the AWS private network. It's fairly simple and elegant, but may cost more than other approaches mentioned above.

https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Best_practices_for_building_multi-region,_active-active_serverless_applications_SVS337-R1.pdf

Multi Region strategy for API Gateway

Contenus pertinents