The words "geoproximity" and "geolocation" sound similar, but when it comes to routing traffic flow for your web server, they mean two slightly different things.

Geolocation refers to the process of identifying the location of your users by means of digital information that is available on the internet (for example, their IP addresses.) Geoproximity, on the other hand, refers to a specific technique to route traffic to web servers.

In this article, we'll talk about the differences between a geolocation routing policy and a geoproximity routing policy. We'll also look at a couple of other ways to route traffic: a failover routing policy, and a latency routing policy.

Don't reinvent the wheel.
Abstract's APIs are production-ready now.

Abstract's suite of API's are built to save you time. You don't need to be an expert in email validation, IP geolocation, etc. Just focus on writing code that's actually valuable for your app or business, and we'll handle the rest.

Get started for free

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.


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.


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.

Abstract's IP Geolocation API comes with libraries, code snippets, guides, and more.

Get started for free
Abstract's IP Geolocation API comes with libraries, code snippets, guides, and more.
Get started