Global Footprint & Placement

An edge location can terminate the connection and TLS, serve a cached response, issue a redirect, and make a cheap decision from the request itself. The authoritative dataset, durable writes and heavy computation still travel back to the region.

A region is an independent geographic deployment unit; the availability zones inside it are separate facilities with their own power, cooling and network paths, a metro hop apart. The zone boundary isolates a facility failure, the region boundary isolates everything larger.

Distance fixes a round-trip floor: light in fibre travels about 200,000 km per second and real paths are longer than the map, so a far continent costs roughly a tenth of a second per round trip. Bigger machines and more instances cannot shorten it.

Connection setup costs several round trips before any request bytes move. Terminating nearby pays those against the short hop, while the forwarded request crosses the long distance once over a connection the edge already holds warm.

Availability is published per service; parity is decided per feature. A region can run an earlier generation of the same managed service, missing an option, a tier, an integration or a size that the architecture was built on, while still answering to the same name.

Very little spreads by itself. A service sold as regional often keeps its data redundant across zones inside the region as part of the service, while anything created as an instance is pinned to the zone it was created in until you declare a second one.

Residency is a placement duty: every copy of the records sits inside the named jurisdiction. Sovereignty is wider — the data must be subject only to that jurisdiction's law, so key custody and who can be compelled to grant access both matter.

By deploying it there. Build the second region from the same description as the first and let every gap surface as a failed request, then record what was refused, what provisioned differently, and what you accepted. A table of service names proves nothing.

A region is a physical build-out, so capabilities ship on a staged rollout: racks, dependent services and trained operators arrive one region at a time. Smaller and newer regions get a capability last, and some never get it.

The meter is the same everywhere the service is offered; only the rate per unit is set per region, reflecting local power, land, tax, transit and hardware supply. It should break a tie between otherwise acceptable regions, not pull a workload away from its users.

It removes requests it can answer itself - a shared cached response, a redirect, a rejected malformed call. Everything personalised, transactional or freshly computed is forwarded, so the region must still be sized for that arrival rate.

The second region's day-one defaults. Ceilings on how much of a resource an account may hold are scoped per region, so every increase ever granted applies where it was granted. A barely used region still sits at the numbers it was opened with.

A cross-zone hop costs a metro round trip — propagation over the physical distance plus switching, typically well under a few milliseconds. The floor is distance and cannot be tuned away; the damage comes from chattiness, one request paying that hop many times.

Because most resources and the endpoints that list them are scoped to one region: the call is answered by that region's own management plane, which knows nothing about another region's resources. Only a small set of platform services is genuinely global.

Copying the backup far away serves recovery from the loss of the whole originating region, which no copy inside that region can. It breaks residency, because a readable copy of regulated records now sits outside the jurisdiction the contract names.

The first region optimises for the people using the product; the second optimises for independence from the first and for being able to run there at all. Distance stops being only a cost and becomes partly the point, while service availability, quota and the residency obligation become hard entry conditions.

Connection termination, a cheap token check, a redirect and a repeat of an identical popular result can move. The index, the ranking that reads it and any write path cannot - so measure setup, crossing and region service time first.

Log lines, traces and metric labels routinely carry record identifiers and payload fragments, and management metadata carries names and tags teams fill with customer detail. Aggregating any of it outside the jurisdiction puts a readable derivative of the records there.

Draw it as explicit rungs — stored copies, then backups, then telemetry, then operator access, then key custody — decide which rung the company sells per data class, price each rung's operational cost, and publish what is deliberately not covered.

Each location sees only its own traffic, so an exact shared count needs the locations to agree - and agreeing costs the round trip the tier existed to avoid. Exact, durable counting belongs in a region.

It changes the job, not just the machines. An older generation typically offers less device memory and a slower interconnect, so the same work needs a smaller slice per device, more machines, more cross-machine traffic, and a longer wall clock at a different cost per unit of work.

They share the region around them: its own management plane and service endpoints, the metro environment, the jurisdiction it sits in, and platform changes that land on a region as a unit. That makes the region a failure boundary of its own.

Because sovereignty is about reach, not only location. A person outside the jurisdiction who can view or export the records is a border crossing that leaves no copy behind, and it is the exposure a location inventory cannot see.

Weigh the one-time cost of moving — bytes charged on the way out, engineering time, a cutover window and its risk — against the recurring harm of staying. Then consider the cheaper answers: move only the latency-sensitive path, or place new growth differently and leave the existing store alone.