If I've got CloudFront set up with the origin being an address in Route 53, and geolocation routing for record in Route 53, will Route 53 do the geolocation based on the CloudFront edge location IP or the end user's IP?
The DNS lookup for the origin server is done on the "back side" of CloudFront and will be based on the CloudFront edge location, and can't be used to test the geographic location of the viewer.¹
(Even if this were somehow possible, it still wouldn't work as intended, because CloudFront wouldn't know the appropriate criteria for reusing a cached response for other viewers, who might be in different countries but hitting the same edge location.)
What you can do is select an origin server based on the viewer's country by configuring CloudFront to whitelist the
CloudFront-Viewer-Country request header and then using a Lambda@Edge Origin Request trigger to modify the origin domain name and possibly the
Host header of the request, based on the detected country.
An Origin Request trigger only fires on cache misses, so when there's a cache hit, the trigger doesn't need to fire -- the response is served from the cache. And the response will be the correct one, because whitelisting a header (e.g.
CloudFront-Viewer-Country) means that CloudFront begins treating that header as part of the cache key -- so CloudFront keeps separate/independent cached copies of the same resource, based on the different values it sees for this header, and a cached response will not be served unless that header value matches (or isn't there -- which is a separate cached version). So a cache hit for a given page requires that the
CloudFront-Viewer-Country from the cached response match that from the new request. In short, CloudFront Does The Right Thing™ with regard to the cache, in a configuration like this.
See Example: Using an Origin-Request Trigger to Change the Origin Domain Name Based on the Country Header from the Amazon CloudFront Developer Guide for a simple example of the code for such a trigger. Customize it to match your business rules.
¹It can, however, be used for latency-based routing from CloudFront to the origin server, since latency-based routing is tasked with selecting a DNS response corresponding to a target geographically proximate but not based on geopolitical boundaries. The optimal target in this case would be the one closest to the edge rather than closest to the viewer, although in practice these would very often be the same, since the edge was selected on the front-side based on proximity to the viewer.