<p>I received this answer directly from an AWS Solutions Architect:</p>
<blockquote>
<p>Generally speaking, Route53 uses latency data from AWS
points-of-presence to our end users location over a long-tail period
to determine the fastest path from AWS to their known location.</p>
<p>Because latency measurements are performed and stored over a period of
time, I wouldn’t anticipate Route53 picking up volatile changes in
latency that would lead to a user ‘flip-flopping’ between regions.
From our docs:</p>
<p>&quot;Latency-based routing is based on latency
measurements performed over a period of time, and the measurements
reflect these changes. A request that is routed to the Oregon region
this week might be routed to the Singapore region next week.&quot;</p>
</blockquote>
<p>So while this isn't an exact answer, it does give general insight that is good enough for some determinations.  For example, will we see the user switching back and forth between regions based on some large scale routing issue on the internet backbones?  The answer is no.  This is enough information to not need to worry about synching session information between the two regions in most application use cases, for example.</p>
<p>Hope this helps others.</p>

CC BY-SA 4.0
2023-02-03T21:00:09.120Z
2023-02-03T21:00:09.120Z
Michael Oryl
<p>Does anybody know how frequently one could expect Route 53's latency-based routing data to change for a given user?</p>
<p>For example, if I have Route 53 LBR setup with CloudFront sitting in front of 2 separate regions of my application, and R53 sends my user to the West Coast, how long is that good for?  Another way of putting it is: <em><strong>how sticky is that decision?</strong></em></p>
<p>Do we run the risk of the user being switched a few minutes later to the East Coast even though West Coast is still running, merely because of some minor routing change on the public internet?</p>
<p>Or is the decision more abstract, and rather based on IP ranges rather than directly on the user's actual point to point latency between them and the region's border?  Meaning that the user is sent to the region that &quot;should&quot; have the least latency, but that minor real-time changes in latency will be ignored?</p>

<amazon-web-services><dns><amazon-cloudfront>
How frequently is AWS Route 53 DNS Latency-Based Routing (LBR) recalculated for a given user?
Michael Oryl
# How frequently is AWS Route 53 DNS Latency-Based Routing (LBR) recalculated for a given user?

(Asked by: username_0 on 2023-01-24)

Does anybody know how frequently one could expect Route 53's latency-based routing data to change for a given user?

For example, if I have Route 53 LBR setup with CloudFront sitting in front of 2 separate regions of my application, and R53 sends my user to the West Coast, how long is that good for? Another way of putting it is: ***how sticky is that decision?***

Do we run the risk of the user being switched a few minutes later to the East Coast even though West Coast is still running, merely because of some minor routing change on the public internet?

Or is the decision more abstract, and rather based on IP ranges rather than directly on the user's actual point to point latency between them and the region's border? Meaning that the user is sent to the region that "should" have the least latency, but that minor real-time changes in latency will be ignored?

**Tags:** amazon-web-services, dns, amazon-cloudfront


---

## 1 answers

### Answer by username_0 on 2023-02-03. Score: 0 | Accepted answer

I received this answer directly from an AWS Solutions Architect:

> Generally speaking, Route53 uses latency data from AWS
> points-of-presence to our end users location over a long-tail period
> to determine the fastest path from AWS to their known location.
>
> Because latency measurements are performed and stored over a period of
> time, I wouldn’t anticipate Route53 picking up volatile changes in
> latency that would lead to a user ‘flip-flopping’ between regions.
> From our docs:
>
> "Latency-based routing is based on latency
> measurements performed over a period of time, and the measurements
> reflect these changes. A request that is routed to the Oregon region
> this week might be routed to the Singapore region next week."

So while this isn't an exact answer, it does give general insight that is good enough for some determinations. For example, will we see the user switching back and forth between regions based on some large scale routing issue on the internet backbones? The answer is no. This is enough information to not need to worry about synching session information between the two regions in most application use cases, for example.

Hope this helps others.


---

