I have a lambda-backed api gateway that i deployed in two regions. These two API's are totally identical. I have two different URL's like

*.execute-api.us-east-1.amazonaws.com *.execute-api.eu-west-1.amazonaws.com

My idea was defining the same custom domains in two regions and using Route53 geolocation feature, serving the api from the nearest region to the user. But, after defining the custom URL in one region, when I try to define in the second region I get an error saying that this domain is already defined in another cloudfront distribution.

Is this a bug or which strategy can i follow to multi-region deployment of API Gateway.


  • It's not a bug -- there's an ambiguity created if the same domain name is configured on multiple CloudFront distributions, because the incoming Host: header is used by CloudFront to determine which distribution's configuration should be used to process the request. So, the behavior is by design, and the question will be how to work around it. (I'll see what I can come up with.) You essentially want to use geo/latency routing to serve requests from the nearest API Gateway deployment based on the requester's location, using a single Internet-accessible hostname. Is that right? – Michael - sqlbot Oct 23 '15 at 20:47
  • Exactly this is what I want, routing users to the nearest deployment. Still I could not find a solution. Currently I only have two different URL's with same functionality. How to combine them under a single URL.. Do not know. – Çağatay Gürtürk Oct 24 '15 at 12:15
  • i'd also love an answer. i've been trying to figure this out myself and have been coming up empty. there doesn't seem to be a way to achieve this with a custom hostname, which makes api gateway of limited usefulness right now. – Cory Mawhorter Jan 3 '16 at 8:09

Unfortunately, this is not currently possible. The primarily blocker here is CloudFront. MikeD@AWS provides the info on their forums:

When you create a custom domain name it creates an associated CloudFront distribution for the domain name and CloudFront enforces global uniqueness on the domain name.

If a CloudFront distribution with the domain name already exists, then the CreateCloudFrontDistribution will fail and API Gateway will return an error without saving the domain name or allowing you to define it's associated API(s).

Thus, there is currently (Jun 29, 2016) no way to get API Gateway in multiple regions to handle the same domain name.

AWS has no update on providing the needful since confirming existence of an open feature request on July 4, 2016. AWS Form thread for updates


The way we have somewhat solved this is to actually front it by cloudfront. Then in cloudfront you add both end points as origins.

  • 3
    How does that work? CloudFront will always choose the origin with the highest priority behavior, not the closest. So if they both have the same content, you will always be serving data from the origin with the behavior that has the highest precedence and nothing from the the other origin. – Dave Stern Nov 3 '16 at 14:21

I have a couple of ideas.

CloudFront as has been said above, you can't load balance with CloudFront. So your options would seem to be

  1. Use a single origin with CloudFront. Latency of 85ms between the US East and West Coasts isn't so bad. Compared with the latency between where I live (New Zealand) and the USA of up to 250ms it's fairly small.
  2. Remove CloudFront, use Route 53 latency based routing to directly hit the API gateway. With this you could use as many regions as you like - add one in Sydney / Asia if you have customers down there.
  • 2 doesn't seem to be possible – Jonathan Sep 28 '17 at 16:09
  • @Jonathan could you expand on "not possible" please? And any alternate ideas? I've never used API Gateway so it's quite possible I don't fully understand how it works. – Tim Sep 28 '17 at 16:30
  • Just ran into it myself, I built pretty much what you've described with an API Gateway instance in every region and even created the latency based records to each instance in each region, but I've found that any CNAME you create to an apigateway url doesn't work (not sure why), the only way to reference it would seem to be as a cloudfront distribution (for which the only valid record is an A record Alias in Route53) – Jonathan Sep 28 '17 at 16:34
  • I've thought it through however and I think creating cloudfront distributions for each apigateway instance might be the simplest solution, since latency based routing checks the latency between the 1) User's location and 2) Upstream server (apigateway) in the record. Therefore I'm thinking if an apigateway cloudfront distribution in us-east-1 has lower latency to London (user) as compared to a distribution in Singapore then latency based routing will prefer the us-east-1 distribution, the user's request will hit the closest cloudfront pop and pass through to the origin apigateway in us-east-1 – Jonathan Sep 28 '17 at 16:38
  • It sounds to me like you have a better answer than mine. Perhaps you could create a new answer that could provide better guidance to others who run into the same problem? – Tim Sep 28 '17 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.