Data Centers, Cloud Regions and Edge: Where Latency Lives

Quick answer: a data center is a facility housing servers, storage and network equipment. A cloud region is a named geographic area where a cloud provider runs a cluster of data centers, usually split into several availability zones, and an edge location is a smaller site placed nearer to users. For latency, the most important fact is simple: the round trip to a server is set mainly by the distance and the routes between you and the building it sits in. Faster processors inside that building help far less than moving the workload, or the user's traffic, closer together.

What is a data center?

A data center is a purpose-built building (or part of one) with racks of servers, redundant power, cooling, fire protection, physical security and many network connections. Smaller organisations rent space in a shared facility, which is called colocation, while large operators build their own. What matters for latency is not the building's size but where it is and which networks it connects to.

Data centers cluster in a few kinds of places. Some sit in large cities with dense fibre, such as Frankfurt, London, Amsterdam, Ashburn (Virginia), Tokyo or Singapore, because many networks meet there. Others sit in cheaper areas with plentiful power and cooling. A site in the second kind of place can be excellent for batch jobs but a poor choice for services that need low latency to many users.

How do cloud regions and availability zones work?

Large cloud providers organise capacity in layers:

• Region: a geographic area such as a metropolitan area or part of a country. You choose a region when you create a virtual machine, a database or a storage bucket. Regions are independent of each other, and data does not move between them unless you configure it to.
• Availability zone (AZ): one or more data centers inside a region, with separate power, cooling and network feeds, close enough to each other that data can be written to several zones at once. Most regions have at least two, commonly three.
• Edge or local locations: smaller sites in many more cities. They host CDN caches, DNS, or limited compute, and let traffic enter the provider's network early (see CDN and anycast).

Names and details differ between providers, so check your provider's documentation for what exactly a region or zone means for them. The principle that follows from the physical layout is the same everywhere: communication inside one zone is fastest, between zones in one region is almost as fast, and between regions is limited by distance.

Typical latency inside and between data centers

These are broad figures for round-trip time (RTT). Actual values depend on provider, route and time of day.

Path	Typical RTT	What dominates
Two servers in the same rack or same data hall	Roughly 0.05 to 0.5 ms	Switching and software stack
Two availability zones in one region	Often about 0.5 to 2 ms, sometimes a few ms	Tens of km of fibre plus equipment
Two regions in the same country	Roughly 10 to 40 ms	Fibre distance
US east coast to US west coast	Roughly 60 to 80 ms	About 4,000 km straight line, longer in fibre
US east coast to western Europe	Roughly 70 to 100 ms	Transatlantic cables
Western Europe to Singapore or east Asia	Roughly 150 to 250 ms	Long routes via the Middle East or around continents
Western Europe or US west coast to Australia	Roughly 140 to 300 ms	Very long cable paths

All of these obey the rule of about 1 ms of RTT per 100 km of fibre path, plus the extra for real routes being longer than a straight line. The underlying physics is covered in undersea cables and the speed of light.

Why does server location matter so much?

A single user action often triggers many sequential round trips: DNS, TCP, TLS, the request, and then, behind the scenes, calls from the web server to the database or other services. If your user is 100 ms from the web server and the web server is 100 ms from the database, a page that makes five sequential database queries pays 500 ms of internal waiting on top of the user's own 100 ms. Putting the database in the same region as the application removes most of that. This is the most common cloud latency mistake: placing components in different regions for convenience.

For users, location is simply the first term in every handshake. As shown in what is latency, a fresh HTTPS request can need three round trips before the first byte, so each 10 ms of distance costs about 30 ms to the first byte. See TTFB and web performance and latency for websites and APIs for more on that.

What is the edge, and when is it worth it?

The word edge is used loosely. It can mean CDN sites that cache content, small compute sites run by cloud or telecom providers, or hardware inside a shop or factory. The common idea is "closer to the user than a big region". Edge locations are more numerous but smaller and less uniform.

Edge is worth it when the work can be done with local data, when the user waits for the result, and when round trips to a central region would be a visible part of that wait. Examples: serving cached pages and images, terminating TLS near users, checking authentication tokens, redirecting or personalising simple responses, and filtering abusive traffic. It is not a cure when the request needs data that lives in one central database anyway; then the edge location still has to make the long trip, and the saving shrinks to connection setup. Note also that moving compute to the edge but keeping the database central can make things slower if the edge code makes several sequential database calls across the distance.

How does your traffic actually reach a data center?

You do not connect to a data center directly. Your packets travel through your home or mobile network, your ISP, possibly transit providers, and then into the network that hosts the server. How many networks lie between you and the data center, and whether they exchange traffic directly, strongly affects latency. Places where many networks interconnect are called internet exchange points (IXPs). Hosting at or near one, or using a provider that peers widely, shortens paths (see routing, BGP and peering).

Large cloud providers also run private backbones. When you connect to a service via a nearby entry point, the traffic may travel most of the distance over the provider's own network rather than over the public internet. Whether this is lower in latency than the public route varies by provider and route; sometimes it is more direct and sometimes it is roughly equal. Measuring is the only reliable way to know.

How to choose a region (a practical method)

1. List where the users and dependencies are. Note the cities or countries with the most users, and any other systems your service must talk to, such as payment providers or partner APIs.
2. Shortlist two to four candidate regions near the centre of that demand, in cities with good connectivity.
3. Measure round trips from real user networks. Use a public test endpoint or a small static file in each region and time it from where your users are. A browser-based test such as the free latency test can add your own endpoints as custom destinations (see choosing destinations and custom destinations), and each viewer's results show what that location really sees.
4. Weigh non-latency factors. Price, service availability, data residency law and the provider's capacity can outweigh a 10 ms difference.
5. Keep tightly coupled parts together. Application, cache and database should usually share a region and often a zone, and cross-zone traffic should be limited to what resilience needs.
6. Use a CDN in front for cacheable content, so the region choice mainly affects uncacheable requests (see CDN and anycast).

Worked examples

Example 1: Single region for a global audience

A small SaaS product runs everything in one region on the US east coast. Users in New York see about 10 ms RTT, users in London about 75 ms, users in Sydney about 220 ms. The first byte of an uncached page for Sydney costs about 3 × 220 = 660 ms before server time, compared with 3 × 10 = 30 ms for New York. Adding a CDN lets Sydney's static assets load in about 3 × 15 = 45 ms, but the main HTML still takes the long trip. To fix that, the team would consider a second region in Asia-Pacific, with the database replicated.

Example 2: A chatty app and a split database

An application in Frankfurt calls a database in Dublin, about 1,100 km away. With a route of around 1,500 km of fibre, the RTT is about 15 to 25 ms. A page that runs 20 sequential queries spends 300 to 500 ms waiting on the database. Moving the database to Frankfurt cuts each call to about 1 ms, and the same 20 queries take roughly 20 ms. The code is unchanged; only the distance is.

Example 3: Synchronous replication across zones

A database confirms each write only after two zones have stored it, and the zones are 1 ms RTT apart, so each write takes about 1 ms longer. Across two regions that are 80 ms apart, the same method would add about 80 ms to every write, which is why cross-region replication is usually asynchronous and accepts a short delay in copying data.

Common mistakes and myths

• "The cloud is everywhere, so location does not matter." Your workload runs in a specific building, and distance applies to it like any other server.
• Choosing a region by price alone and then discovering users on another continent are slow.
• Splitting an application across regions so that internal calls cross the ocean.
• Assuming the edge is a full copy of the backend. Edge locations often hold only caches or limited compute.
• Judging by the map. The straight-line distance underestimates the real route, and two cities close together can have poor connectivity between their networks.
• Treating a provider's published region latency tables as promises. They are measurements at a point in time and vary.
• Expecting a faster server type to cut network latency. More CPU shortens processing, not propagation.

What to do next

Decide where your users and dependencies are, then measure instead of guessing. Use the free latency test or the live monitor to watch round trips to several destinations over time and see how they differ by location. To learn why cities far apart cannot be close in milliseconds, read undersea cables and the speed of light. For the delivery side, continue with CDN and anycast, and for step-by-step website measurements, see latency for websites and APIs.