Skip to main content
Datum’s infrastructure footprint is organized into points of presence (PoPs) that are packaged into Regions and Availability Zones (AZs). See our Locations for a visual overview of all PoPs. Each Region represents a specific geographic and network boundary, while each AZ provides independent capacity within that Region. This structure supports predictable latency, fault isolation, and regulatory alignment.

Why a region is a real place

Some clouds hide location behind a single global network, which is simple but leaves you unable to answer basic questions: which city is my traffic and data actually passing through? What laws apply to it? How far away is it from my users? Datum takes the opposite approach: every Region and Availability Zone corresponds to an actual, named place, not an abstract label. When you deploy into us-east-1, that’s a real facility in Ashburn, Virginia — not a logical construct spread invisibly across a continent. This gives you three things:
  • Predictable latency — Regions are grouped by real network distance, so you can reason about how fast your app will respond to users in a given area.
  • Data sovereignty and compliance — because each Region maps to a specific country or jurisdiction, it’s straightforward to keep data and workloads where regulations require.
  • Real choice and control — you pick where things run based on your own requirements (proximity to users, legal residency, avoiding a single point of failure), the same way you would if you were choosing between physical data centers, rather than accepting one big undifferentiated “everywhere.”
Most customers pick a primary Region close to their users or required jurisdiction, then spread work across multiple Availability Zones in that Region for resilience. Some go further and deploy across multiple Regions entirely for extra redundancy or to serve users in more than one part of the world.

Naming convention

Similar to the large public clouds, Datum uses a country-anchored naming format with the following elements: Anchoring to a two-letter country code, rather than a continent, means a region name never leaves you guessing which country it’s in — for example, an “east” region is always clearly in a specific country, so you won’t confuse a US region with a Canadian one the way you might with a broader label like “North America.” For example, here is how we describe the first region and availability zone in the eastern US.
Example: us-east-1a Regions and AZs are defined by distance and policy boundaries.
  • When Points of Presence in the same country are separated by more than about 5 milliseconds round-trip time (RTT), Datum creates a new Region.
  • If multiple PoPs exist in the same metro but operate independently (for example, separate network clusters or facilities), they become separate AZs. Increment the Count value to the next letter.
  • If PoPs are within about 5 milliseconds RTT and part of the same operational domain, they remain in the same Region. Example: us-east-1a, us-east-1b, us-east-1c.
Note: regulatory and export control requirements may restrict or define where data and workloads can reside. These boundaries take precedence over latency-based placement rules.

Regions

Check what’s available to your project

The table above is Datum’s global footprint. What you can deploy into is a narrower, per-project question: Datum represents each usable location as a Location resource, and the ones inside your project’s own control plane are the ones offered to you. datumctl get locations lists them:
Each row is a location you can place work in today. NAME is the identifier you reference elsewhere, and matches the region codes in the table above: us-central-1 is Dallas, us-east-1 is Ashburn. CITY is the airport-style code for the metro it serves. CLASS is the kind of capacity behind it, where datum-managed is Datum’s own footprint.
This list reflects your active project scope. If a location you expect is missing, confirm you are pointed at the right project. See Contexts & scoping.
For the full definition of a location, including its topology, request YAML or JSON:

Region tracing

Visit https://edge.datum.net/ to learn which Datum Region and availability zone you’re reaching via anycast. If you’re using Datum Tunnels, this will be your entrypoint into our network. You can also access our zones and locations programmatically:
Last modified on September 14, 2026