Journal · Infrastructure
Where does my website live?
It lives in a building, in a town, with an address, a power supply and a flood risk. Here is how to find out which building, why one copy belongs near your customers, and why another copy must be nowhere near the first.
Ask an owner where their company’s website lives and the honest answer is usually a shrug, or the name of whoever set it up. It is a fair reaction. The question sounds abstract. It is not. Your website lives in a building, in a town, on a machine you could in principle drive to. That building has an address, a power supply, a flood risk and a distance from your customers, and each of those four facts costs or saves you money.
Here is how to find out where yours is, why one copy should be near your customers, and why another copy must be nowhere near the first.
Finding out, in two commands
Start with the name your site answers to and ask what address it resolves to. Then ask that address who owns it.
dig +short www.yourcompany.com
dig +short -x <the address that came back>We ran this on our own site while writing this piece. The address resolves to a machine
whose reverse name is ec2-34-226-39-121.compute-1.amazonaws.com. That is an Amazon
Web Services machine, and compute-1 is AWS’s legacy label for its
us-east-1 region. So this site lives in Northern Virginia, roughly
484 km from our office in Boone. We did not know that from a dashboard. We
asked the network.
The map
Amazon operates four general-purpose regions in the continental United States. A region is not one building; it is a cluster of separate facilities, called availability zones, close enough to work as one system and far enough apart that a single fire or flood should not take all of them. Microsoft and Google run broadly similar footprints, and a great deal of smaller hosting sits inside these same regions, which is why a surprising number of unrelated companies go dark on the same afternoon.
Why one copy should be close
Light in glass travels at about two thirds of its speed in vacuum, which works out near 200,000 km per second. That is the hard limit. Nothing your host can buy moves data faster, because nothing moves faster.
Turn that into a round trip and you get a floor. A request to Northern Virginia and back cannot beat 5 milliseconds from Boone. The same request to Oregon cannot beat 33. In practice you will see one and a half to two times the floor, because fibre does not run in straight lines and every hop costs something.
| Region | Location | City | km | RTT floor | Zones |
|---|---|---|---|---|---|
us-east-1 | N. Virginia | Ashburn, VA | 484 | 5 | 6 |
us-east-2 | Ohio | Columbus, OH | 432 | 4 | 3 |
us-west-1 | N. California | San Jose, CA | 3,556 | 36 | 3 |
us-west-2 | Oregon | Boardman, OR | 3,328 | 33 | 4 |
eu-west-1 | Ireland | Dublin | 5,945 | 59 | 3 |
ap-southeast-2 | Sydney | Sydney | 15,254 | 153 | 3 |
A few dozen milliseconds sounds like nothing. It is nothing, once. The trouble is that a page is not one request. It is the document, then the stylesheet, then the fonts, then the images, then whatever the analytics tag wants, and anything the browser cannot start until the previous thing finished pays the round trip again. Put a shop on the wrong coast and you have added a tax to every asset on every page for every visitor, forever, and no amount of server hardware refunds it.
Why you cannot simply time it
The obvious test is to time a connection to each region. We did, and the result was nonsense, in an instructive way.
| Region | RTT floor | We measured | Verdict |
|---|---|---|---|
| N. Virginia | 5 | 104 | plausible |
| Ohio | 4 | 160 | plausible |
| N. California | 36 | 162 | plausible |
| Oregon | 33 | 109 | plausible |
| Ireland | 59 | 284 | plausible |
| Sydney | 153 | 98 | impossible, answered at an edge |
Sydney answered faster than Northern Virginia. That cannot happen. Sydney is roughly 15,254 km away and the floor alone is 153 ms. What we actually measured was the distance to the nearest edge server fronting that hostname, not the distance to Australia. Large providers answer at the closest point of presence and carry the request onward privately.
If a timing test cannot tell you where your data is, neither can a vendor’s reassuring dashboard. The location of your customer records is a contractual question and a regulatory one. Ask for it in writing, by region name, for the live system and for every backup.
Why another copy must be far
Everything above argues for being close. The second copy exists for the opposite reason.
Availability zones protect against a failed building. They do not protect against a failed region, and regions sit in real places with real weather. Northern Virginia is inland, which helps, but it is one power grid and one set of fibre routes. A backup stored in the same region as the system it protects shares that region’s bad day. It is not a backup. It is a second copy of the same risk.
The rule is unglamorous: serve from the region nearest your customers, and keep at least one restorable copy in a region far enough away that no single storm, grid failure, flood or provider incident can reach both. For a business on the east coast, a west coast or Ohio copy does the job.
A backup that exists is not a backup that works. Confirming a file is present proves it is present. It does not prove it restores. The two most common discoveries, both made at the worst possible moment, are a backup that has silently been writing zero bytes for months, and a backup nobody can restore because the only person who knew the procedure has left.
Restore it. On a schedule. Into somewhere harmless. Write down the date it last worked, and treat a stale date as a failure rather than as an inconvenience.
What this does not prove
Distance is not the only thing that makes a site slow. It is the floor, not the ceiling. We have seen pages where the round trip was a rounding error next to the weight of what the page insisted on downloading. Moving regions fixes the tax; it does not fix the page.
Our numbers are from Boone. The distances are great-circle from one office in western North Carolina. Yours differ, and what matters is distance from your customers rather than from you. If your buyers are in Texas and you are in Vermont, serve Texas.
And the floor is a floor. The millisecond figures are what physics permits, not what you will observe. Treat them as the number you cannot beat, not the number you will get.
Do you know where your customer records are tonight?
Not the marketing site. The orders, the names, the card tokens. If the answer is a vendor name rather than a region, that is worth an hour of somebody’s attention before it becomes worth a week of it.
Request a diagnostic