Hyperscalers and Global Infrastructure
Hyperscalers and Global Infrastructure 🌐
Cloud infrastructure has a real geography that shapes application decisions. In this lesson, you will learn to:
- Define hyperscalers and identify the three largest providers
- Distinguish regions, availability zones, and edge locations
- Explain how placement affects speed, legal residency, and resilience
So far you've been thinking about the cloud in the abstract: renting instead of buying, public versus private, what a provider takes off your hands. But when someone asks "where does our application actually run?", the answer has a real address. It sits in a specific building, in a specific country, chosen by someone on purpose. This unit is about who owns those buildings and how they're organised, because those choices quietly decide how fast your application feels, whether it's legal to run where you put it, and what happens when something breaks.
What a Hyperscaler Is, and Who the Big Three Are 🏙️
A hyperscaler is a cloud provider that operates data centres at enormous global scale and can add capacity almost instantly, serving millions of customers from shared infrastructure. The word points at the scale itself: these companies build and run so much hardware that no ordinary business could match it, which is exactly why renting from them makes sense.
The three largest are Amazon Web Services (usually shortened to AWS), Microsoft Azure, and Google Cloud. Each grew out of a company that first had to solve the problem for itself. Amazon needed to run a vast retail operation, Microsoft was already deep inside most companies' desktops and servers, and Google had built extraordinary engineering to run search and video at planetary scale. Each then rented that capability out to everyone else.
It's worth being clear about what "scale" buys you. It isn't just size for its own sake. Because a hyperscaler serves so many customers, it can afford to build spare capacity you can borrow in minutes, keep specialist security and hardware teams you'd never staff yourself, and place buildings in dozens of countries so your users aren't all reaching across an ocean. It also buys hardware and power in volumes that push the unit price down, which is why per-hour rates keep falling.
Regions, Availability Zones, and Edge Locations 📍
Here's the part people find genuinely confusing, so it's worth going slowly. A hyperscaler's global footprint has three nested layers.

A region is a geographic area where a provider operates data centres, and it has a name you'll actually see in a console, such as "Frankfurt," "Paris," or "Northern Virginia." When you create anything in the cloud, you pick a region. That choice puts your application, and your data, in that part of the world.
Inside a region are availability zones. An availability zone is one or more physically separate data centres with their own power supply, cooling, and network connections, close enough to the others in the region for fast communication but far enough apart that a flood, fire, or power failure in one doesn't take down the others. Most regions have at least three. This is the layer people skip, and it's the one that saves you.
Sitting outside that structure are edge locations: many small sites placed near where end users live, which hold cached copies of things like images, videos, and files. They don't run your application. They just shorten the trip for content that doesn't change often.
The nesting is straightforward once you say it aloud: a provider has many regions worldwide, each region contains several availability zones, and each availability zone is one or more real data centres. Edge locations are scattered separately and much more widely, close to users.
- Meredith: So if I put the booking app in the Frankfurt region, that's just one building, right?
- Ryan: No, Frankfurt is the region. Inside it there are several availability zones, and each one is its own data centre with separate power and networking.
- Meredith: Meaning if one loses power, the others keep going?
- Ryan: Exactly. But only if you actually deploy into more than one. Choosing the region alone doesn't do it for you.
Notice that Meredith's instinct is the common one: to hear "region" and picture a single building. The correction matters, because the protection comes from spreading across zones, not from naming a region.
