Geolocation Routing Policy
A geolocation routing policy is what you use when you want to route traffic based on the location of your users. Most businesses these days have users all over the world, and they want to serve content to those users as fast as possible. A geolocation routing policy allows you to allocate the resources that serve your traffic based on the location that users' DNS queries originate from.
With geolocation routing, you can localize content and restrict the distribution of content to only the locations in which you are able or allowed to distribute. You can also balance the traffic load across endpoints in a predictable way.
For example, say you have servers in Oregon and New York, and many of your users are in California. A geolocation routing policy might send those California users to your Oregon server so you can serve them content specific to the West Coast of the US.
Learn more about IP Geolocation
Geoproximity Routing Policy
A geoproximity routing policy is what you use when you want to route traffic based on the location of your resources, or shift traffic flow between resources. This policy allows you to direct users to different servers, even though those servers might be further away, using something called a bias.
Take the previous example. Let's say you have servers in Oregon and New York, and users in California, but your New York servers are larger and can handle more traffic than the Oregon servers. You might use a geoproximity routing policy to direct a portion of the California users to the New York server.
Geoproximity routing is like creating a sphere of influence for your resources.
Failover Routing Policy
A failover routing policy allows you to direct users to a particular resource only when that resource is healthy, and provide a backup, or "failover" resource for when the primary resource fails or reaches the maximum load.
To use a failover routing policy, you configure active-passive failover, where one resource (the primary resource) handles all the traffic when it's healthy and the other resource (the secondary resource) only handles traffic when the first resource isn't healthy.
Latency Routing Policy
A latency routing policy is what you would use if you have resources in multiple regions and you want to route traffic to the region that provides the best latency. These days, users expect a blazingly fast internet experience, and any obstacle to providing that experience should be removed.
With latency routing, you can guarantee that your users will always receive content from the server that will provide them with the fastest experience. This will usually be the server closest to them, but not necessarily.
When you configure a latency routing policy, you set up latency records that the router uses to lookup the regions that serve your content and determine the region that will provide the best latency for a given user.
Weighted Routing Policy
A weighted routing policy allows you to send traffic to specific servers, with no consideration for latency or geographic location. You can choose exactly how much traffic is sent to a particular resource, and you have total control over the traffic flow.
There are several reasons you may want to use a weighted routing policy, including partial rollouts of software, load balancing, and load-testing.
Conclusion
If you are using AWS and Route 53 to manage your traffic, all of these routing policies are available and easy to implement. The AWS documentation goes more in-depth into each policy and will walk you through the process of setting each one up and using it to route traffic.
There are a few other types of routing policy that you may want to explore: the simple routing policy, the IP-based routing policy, and the multivalue answer routing policy. All of these policies are outlined in detail in the AWS documentation.
FAQs
What Is Route 53 Geolocation?
AWS Route 53 is a DNS service. A DNS service connects internet traffic to servers that host the resources that makeup websites and online applications. Route 53 is named after Port 53, which handles DNS for both the TCP and UDP traffic requests.
Geolocation is the process of determining a user's location in the world based on information that is available online (such as an IP address.) Route 53 geolocation is a routing policy that serves content to users from AWS servers, based on the location of your users.
What Is Geoproximity AWS?
Geoproximity is an AWS routing policy that allows Route 53 to route traffic to a web server based on the geographic location of the resources that make up a site or online app. Using something called bias, you can optionally increase or decrease the size of a geographic area, serving content to certain users based on the availability of your resources.
As opposed to geolocation, geoproximity does not simply route traffic to the closest server. It allows you to direct users to different servers, for example, because those servers are able to handle a larger traffic load.
What Is Geolocation Routing Policy?
Geolocation routing routes traffic to a web server based on the geographic location from where a DNS query originated. This means that traffic is sent to resources in the same region from where the request was sent. This is useful if you want to serve localized content to users in a particular location.
Frequently Asked Questions
What is the difference between geoproximity and geolocation routing?
Geolocation routing directs traffic based on where a DNS query originates; it routes users to the server in or nearest to their geographic region. Geoproximity routing instead focuses on the location of your resources and lets you apply a bias to expand or shrink each resource's traffic catchment area, so you can send users to a distant server when capacity or business logic requires it.
When should I use geolocation routing over geoproximity?
Use geolocation routing when you need strict, predictable rules based on user location, for example, serving region-specific content to West Coast users or enforcing content licensing restrictions by country. Geolocation is the right choice when the user's physical location is the deciding factor, not your server capacity.
When does geoproximity routing make more sense than geolocation?
Geoproximity is better when you want to shift traffic between regions based on resource availability or load capacity. For instance, you can route California users to a New York server by increasing that server's bias value, even though a closer server exists. This flexibility makes geoproximity useful for load balancing across unevenly distributed infrastructure.
How does the bias setting work in AWS Route 53 geoproximity routing?
Bias adjusts the size of the geographic influence zone around each resource. A positive bias expands a resource's zone so it captures more traffic from farther away; a negative bias shrinks it so less traffic is routed there. Route 53 then routes each request to the resource whose zone the origin falls within, after all bias adjustments are applied.
Does geoproximity routing always send users to the closest server?
No. This is a common misconception. Geoproximity does not guarantee the physically nearest server. Because bias can be tuned per resource, a server further away can be configured to serve a wider area than a closer one. If lowest latency is the only goal, AWS Route 53's latency-based routing policy is a more direct fit.
How do I choose between geolocation and geoproximity when setting up AWS Route 53?
In Route 53, create a geolocation policy when you need deterministic routing by continent, country, or US state. Create a geoproximity policy (available through Traffic Flow) when you want to balance load across resources and need the ability to shift traffic boundaries dynamically using bias. Both policies can be combined with failover or weighted routing for more complex setups.
