Regions, availability zones and global infrastructure

When Jordan created a trial account with each of the three big providers, the first question every console asked was where to put things. The answer is a region, and the choice matters more than it seems. It affects how fast the site feels to customers, what the site costs, which services are available, what laws apply to the data, and how well the site survives failures. This lesson explains how the providers build their global infrastructure out of regions, availability zones and edge locations, and how to use that structure to build systems that keep running when parts of it fail.

Data centres at enormous scale

Behind every cloud service are ordinary buildings full of servers, but on a scale that is hard to picture. A single large cloud data centre can hold tens of thousands of servers and draw as much electricity as a small town. The buildings have redundant power feeds from the grid, rooms of batteries, diesel generators with days of fuel, precision cooling, fire suppression, and layers of physical security from fences and guards to biometric locks on the server halls. Providers rarely publish exact locations, and visitors are almost never allowed inside.

Running at this scale changes the economics. Providers design their own servers, network switches and even processor chips, buy electricity under long-term contracts, increasingly from wind, solar and hydro projects, and automate almost every operational task. That scale is why a cloud provider can offer a reliable virtual machine for less than it would cost a small business to run one in its back office. It is also why outages, when they happen, can affect thousands of customers at once.

Regions

A region is a geographic area where a provider operates a cluster of data centres, such as Montreal, Oregon or Frankfurt. Regions are deliberately independent of each other: each has its own power, networking and control systems, so that a failure in one region does not spread to others. Data stays in the region where you put it unless you copy it elsewhere, which is how a customer meets a data residency requirement.

Each provider has dozens of regions. AWS, for example, lists 39 geographic regions, with more announced, and Microsoft Azure and Google Cloud each list several dozen. Region names follow each provider's own conventions, as the table shows for regions that Ridgeline might use.

Several things differ from region to region. Not every service is available in every region; new services usually launch first in the largest regions, such as Northern Virginia, and reach smaller regions later. Prices differ too, often by a noticeable amount, because land, power and taxes cost different amounts in different places. And latency, the time a request takes to travel to the region and back, depends on distance.

Choosing a region

Four questions decide the region for most workloads. First, where are the users? Latency grows with distance, because even in fibre, light covers only about 200 kilometres per millisecond, and real routes are longer than straight lines and pass through routers that add delay. A customer in Kelowna reaches Calgary in roughly 15 milliseconds but a region in Virginia in roughly 70. For a web page that makes dozens of requests, those differences add up to a site that feels quick or sluggish. Second, are there rules about where the data must be? Third, are the services you need available there? Fourth, what does it cost?

For Ridgeline in Kelowna, the candidates are AWS Canada West in Calgary, the closest region of any provider, and the Toronto and Montreal regions of the three providers. All keep data in Canada. Calgary gives the lowest latency for British Columbia and Alberta customers; the eastern regions offer more services at some providers.

# Choose the lowest-latency region that meets the data residency rule
regions = [
    {"name": "Calgary", "country": "Canada", "latency_ms": 15, "has_containers": True},
    {"name": "Toronto", "country": "Canada", "latency_ms": 62, "has_containers": True},
    {"name": "Montreal", "country": "Canada", "latency_ms": 68, "has_containers": True},
    {"name": "Oregon", "country": "United States", "latency_ms": 18, "has_containers": True},
    {"name": "Virginia", "country": "United States", "latency_ms": 71, "has_containers": True},
]

def best_region(regions, country):
    allowed = [r for r in regions if r["country"] == country and r["has_containers"]]
    return min(allowed, key=lambda r: r["latency_ms"])["name"] if allowed else None

print("Best Canadian region:", best_region(regions, "Canada"))
print("Best American region:", best_region(regions, "United States"))

Best Canadian region: Calgary
Best American region: Oregon

regions = [
    {"name": "Calgary", "country": "Canada", "latency_ms": 15, "services": ["vm", "database"]},
    {"name": "Toronto", "country": "Canada", "latency_ms": 62, "services": ["vm", "database", "gpu"]},
    {"name": "Oregon", "country": "United States", "latency_ms": 18, "services": ["vm", "database", "gpu"]},
]

def pick_region(regions, country, needed_service):
    return None

print(pick_region(regions, "Canada", "database"), pick_region(regions, "Canada", "gpu"))

Availability zones

Inside most regions, providers build several availability zones, usually three or more. An availability zone is one or more data centres with independent power, cooling and networking, located far enough from the other zones in the region that a fire, flood or power failure is unlikely to affect two zones at once, but close enough, typically within about 100 kilometres, for fast, low-latency connections between them. The zones in a region are linked by high-speed private fibre, so copying data from one zone to another takes only a millisecond or two.

Availability zones are the main tool for building resilient systems. If Jordan runs the wholesale application on two servers in two different zones, behind a load balancer that sends traffic to whichever servers are healthy, the site keeps working when one zone has a problem. A managed database can keep a synchronized standby copy in a second zone and switch over automatically. Designing across zones is often called a multi-AZ design, and for anything a business depends on, it is the minimum sensible standard.

AWS and Google Cloud build zones into most of their regions and name them with letters, such as ca-central-1a or northamerica-northeast1-b. Microsoft Azure calls them availability zones too, offers them in most of its larger regions, and numbers them 1, 2 and 3. One subtlety catches people out: zone names are assigned per account at some providers, so your zone a may be a different building from another customer's zone a.

Measuring availability

Availability is the share of time a system is working. It is usually written as a decimal or as a number of nines: 99.9 is three nines, 99.99 is four nines. The differences look tiny but are large in practice. Over a 30-day month, three nines allows about 43 minutes of downtime; four nines allows about 4 minutes; two nines, 99, allows more than 7 hours.

Providers publish service level agreements, or SLAs, that promise a level of availability and give service credits, a partial refund on the bill, when they miss it. An SLA is a financial promise, not a guarantee that nothing will break, and the credit is usually small compared with what an outage costs a business. The typical SLA for a single virtual machine is lower than for virtual machines spread across two or more zones, because providers know that spreading across zones really does improve availability.

Two rules let you estimate the availability of a whole system from its parts. When components are in series, so that every one must work, multiply their availabilities: a web server at 0.999 that depends on a database at 0.999 gives about 0.998 overall, lower than either. When components are in parallel, so that any one working is enough, the system fails only if all fail at once: two servers each at 0.99 give 1 minus 0.01 times 0.01, or 0.9999. Redundancy in parallel is how reliable systems are built from imperfect parts.

def series(*parts):
    total = 1.0
    for p in parts:
        total *= p
    return total

def parallel(*parts):
    all_fail = 1.0
    for p in parts:
        all_fail *= (1 - p)
    return 1 - all_fail

def downtime_minutes(availability, days=30):
    return (1 - availability) * days * 24 * 60

one_zone = series(0.995, 0.999)                       # one server, one database
two_zones = series(parallel(0.995, 0.995), 0.9995)    # two servers, multi-AZ database
for name, a in (("one zone", one_zone), ("two zones", two_zones)):
    print(f"{name:<10} availability {a:.5f}, about {downtime_minutes(a):.0f} minutes down a month")

one zone   availability 0.99401, about 259 minutes down a month
two zones  availability 0.99948, about 23 minutes down a month

def series(parts):
    return 1.0

def parallel(parts):
    return 1.0

def monthly_downtime(availability):
    return 0.0

print(series([0.999, 0.999]), parallel([0.99, 0.99]), monthly_downtime(0.999))

Edge locations and content delivery

Regions are few and large; users are everywhere. To get content closer to users, providers also run hundreds of smaller points of presence, often called edge locations, in cities around the world. Edge locations mainly run content delivery networks, or CDNs, which keep cached copies of images, style sheets, scripts and videos close to users so that pages load faster and the origin servers do less work. The providers' CDNs are Amazon CloudFront, Azure Front Door and Google Cloud CDN, and independent companies such as Cloudflare and Akamai run large CDNs too.

Edge locations also host DNS services, such as Amazon Route 53, Azure DNS and Google Cloud DNS, and protection against distributed denial-of-service attacks, which absorb floods of malicious traffic before it reaches the application. Some edge networks can run small pieces of code close to users, for tasks such as redirecting visitors or checking sign-in tokens. For the wholesale site, Jordan plans to put product images and other static files behind a CDN, so that a cafe owner opening the product list on a phone gets the pictures from a nearby edge location rather than from the region.

Designing for failure

Werner Vogels, the chief technology officer of Amazon, is often quoted as saying that everything fails, all the time. At cloud scale, disks, servers, network links and occasionally whole data centres fail every day somewhere. Cloud architecture accepts this and designs around it. The principles are simple to state. Remove single points of failure by running at least two of everything that matters, in different zones. Keep servers interchangeable, so a failed one can be replaced automatically rather than repaired. Keep data in managed services that replicate it. Use health checks so that load balancers stop sending traffic to unhealthy servers. And back up data to a different region, so that even a regional disaster cannot destroy it.

Two numbers describe how much failure a business can accept. The recovery time objective, or RTO, is how long the system can be down before the damage is unacceptable. The recovery point objective, or RPO, is how much data, measured in time, the business can afford to lose. Rosa decided the wholesale site could be down for at most four hours, an RTO of four hours, and could lose at most fifteen minutes of orders, an RPO of fifteen minutes. Those two numbers drove Sam's design: a multi-AZ database with automatic failover and continuous backups, application servers in two zones, and nightly copies of backups to a second region.