Azure Availability Zones - Simply Explained

0:00 Welcome to the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. Azure runs more than seventy regions, and everyone that supports zones hides at least three separate buildings inside it. Most of us assume that putting an app in the cloud keeps it running no matter what, and that's not how it works. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're breaking down Azure Availability Zones for complete beginners in plain words. By the end, you'll know how zones, availability sets, and region pairs fit together and why. Uptime is a design choice you make. Regions. The big picture. Start with the simplest piece because everything else in this episode sits inside it.

0:40 An Azure region is a group of data centers connected by fast private network links, and it usually sits inside one big city area. Microsoft has more than seventy of these regions around the world. Each one lives inside a geography, which is really just a data residency boundary like the United States or Europe. Picking a region settles two things at once, and both of them matter. It decides how close you sit to the people using your app. Distance adds delay and delay is what makes an app feel sluggish to the person waiting on it. It also decides whether your data is even allowed to live in that spot. Plenty of organizations have strict rules about where customer data can sit, and a few regions exist purely to satisfy those rules. A simple way to hold this is to picture the region as a city, and the geography as the country that city belongs to.

1:22 Location buys you speed and it buys you compliance. And both of those are worth real money to a business. Every geography has at least one region that offers zones. That means there's almost always a way to get this protection close to the people you serve. What location does not do is keep anything running when something inside it breaks. That gap is exactly what the rest of this episode fills in. So when someone asks which region to choose, the honest answer is that it depends on your users, your data rules, and the features the region offers. Get those three right and the rest of your design gets easier. You've already picked the ground you're going to build on inside a region. Availability zones. A region is not one giant building. And that single fact is where availability zones come from.

2:02 Azure takes a region and splits it into separate groups of data centers called Availability Zones. Each zone runs on its own power, its own cooling, and its own network. If one zone loses power, the others keep humming along because nothing critical is shared between them. The distance between zones gets chosen with real care. They usually sit a few kilometers apart and almost always within about one hundred kilometers of each other. That's close enough to talk quickly and far enough apart. That one storm or one local outage is unlikely to hit two of them at the same time. Microsoft aims for a round trip network delay of under roughly two milliseconds between zones, and that number matters. It means you can keep copies of your data in sync across zones without your users ever noticing the effort. Most regions that support zones offer three of them, and a couple offer more, like East US two with four.

2:44 Three turns out to be the sweet spot because you can lose one zone and still have two left to keep your copies in sync. Azure also spreads its own maintenance across zones, updating one zone at a time where it can. Your workload keeps running in the other zones while a single one gets worked on. Now there's a detail here that surprises almost everyone. Your zone one is not necessarily my zone one. Azure maps the physical zones to logical zones for each subscription, and different subscriptions can end up with a different mapping. The zone numbers you see are personal to your account. Two people working in one region can place things in what both call zone one and land in two completely different buildings. That's why you never assume two deployments sit side by side. Just because the numbers match. Those three buildings are also where the uptime promises you've heard about come from, and we'll get to exactly what those numbers mean in a few minutes.

3:28 Why one datacenter isn't enough. A single data center is a single point of failure, and that's the problem. Zones exist to solve everything inside one building shares the same power feed, the same cooling, and the same network gear. One bad event can take all of it down at once. Splitting a region into zones removes that shared dependency. And that's the whole idea. In one sentence, a region with three zones is built so that any one of them can fail without dragging the others down with it. That design is the difference between a small inconvenience and a full outage for the people who depend on it. Zones protect against more than a whole building going dark. They also soak up smaller failures, like a server rack or a cluster giving out inside a zone. In those cases, the rest of your app keeps serving from the healthy zones, while part of the damaged one is still limping along.

4:09 That's a quite a benefit, and it shows up far more often than a dramatic outage ever does, which is why it's easy to underestimate. It's tempting to assume the zones protect you by default, and that assumption is the trap. Just having zones in your region doesn't protect you, because Azure doesn't automatically scatter your resources across them. By default, some resources land in one zone and stay there, which means a single zone failure can still take your app offline. The zones were available the whole time and nobody used them. On top of that, zones don't cover a full region outage and they won't rescue you from a bug in your own code. They solve one problem well, rather than every problem at once. That raises a practical point, because zones only exist in some regions and plenty of workloads run where they don't.

4:49 Availability sets the older tool. Before zones were common, Azure had a different answer to the same problem, and it's still around today. An availability set is a logical grouping of virtual machines that sit inside one data center arranged so they don't all fail together. Azure assigns each machine in the set a fault domain and an update domain. A fault domain is servers that share a power source and a network switch, and a set can spread across up to three of them. An update domain is a group that gets restarted together during maintenance, and a set can hold up to twenty. The logic is simple enough. If one fault domain or one update domain goes down, the other machines keep serving requests while the rest of the set stays untouched. The payoff here is a written promise of ninety nine point nine nine five percent uptime.

5:31 When you run two or more virtual machines inside an availability set. The set itself costs nothing extra. You pay for the machines, not the grouping. The trade off is that machines in a set sit close together, so they talk to each other faster than machines split across zones. That speed helps a lot with chatty workloads that pass data back and forth. The catch is just as real. A data center level failure, like a network outage for the whole building, can still take every machine in the set down at the same time. A quick example makes the whole thing click. So picture two web servers in one availability set. Azure puts them in different fault domains. So a power problem on one rack doesn't touch the other machine. Your site keeps answering while the first one recovers. If you want a clean picture, a set is the rack layout inside one building, while a zone is a whole separate building down the road.

6:14 Sets are still the right answer in regions that don't offer zones at all. That's a detail. Beginners tend to miss when they assume sets are outdated for a first app. The takeaway is that sets are the older, cheaper tool and zones are the stronger one whenever your region offers them. Zonal versus zone redundant services. This next distinction decides whether your app survives a failure, and it's the one that trips people up the most when you use an Azure service. It can be zone redundant or zonal. And those two words mean very different things about who does the work. A zone redundant service spreads your resource across multiple zones for you. Azure copies the data or distributes the workload, watches the zones, and handles the failover automatically. If one zone drops out, you get the resilience without building it yourself. That's why most people reach for the zone.

6:55 Redundant option first picture storage that keeps your files in several zones at once. So a failure in one zone never touches the copy your users are reading. A zonal service works the other way around. You pick one zone and your resource lives there and only there. It's fully isolated from faults in the other zones, and it can be the fastest choice for very chatty workloads. It won't survive losing its own zone unless you build that yourself. A single virtual machine or a public IP address is a good example because it lives exactly where you put it. If that zone fails, the resource goes with it, and you're the one who has to move it. There's a third category worth knowing. Some resources are regional, which means Azure places them wherever it likes, and you get no say in the zone. Those can land in any zone across the region. So an outage in the zone they happen to be sitting in can catch them by surprise.

7:38 And that surprise is exactly why it helps to know which of your resources are regional. The rule of thumb stays short. A resource counts as zone resilient the moment it uses two or more zones. Microsoft's own guidance is to spread production workloads across zones whenever the region supports them. So the useful question about each service you use is whether the service does the spreading for you, or whether you have to do it yourself. If you're not sure which one the service is, the documentation tells you plainly. It's worth checking before you build, because this is one of those choices that's painful to change after the fact. Now that you know who does the work, the next thing to pin down is what each setup actually promises you. The answer comes down to a few numbers that change the whole picture. What the SLA is actually mean. An SLA is Microsoft's written promise about uptime, and each setup you choose earns a different promise.

8:21 These numbers sound like marketing, but they translate into real minutes, so it helps to turn them into something concrete. Run a single virtual machine with premium disks, and you get a promise of ninety nine point nine percent. Run two or more machines in an availability set, and the promise rises to ninety nine point nine five percent. Spread two or more machines across two or more zones, and you reach ninety nine point nine nine percent. The jump from ninety nine point nine percent to ninety nine point nine nine percent, looks tiny on paper, and it isn't in a thirty day month, Ninety nine point nine nine percent allows roughly forty three minutes of downtime, while ninety nine point nine nine percent allows closer to four minutes. That's the difference between a quick blip and a lost afternoon. There's a catch that surprises people if Microsoft misses the promise.

9:02 Your remedy is a service credit, which is money back on your bill. It's not your uptime restored, and it won't bring back the customers who left while your app was down. The SLA is a refund policy rather than a safety net, and that's exactly why you designed for resilience instead of trusting the guarantee to save you. The numbers also depend on your disks, which is a beginner trap worth knowing. A single machine running on cheaper standard disks earns a lower promise than the same machine on premium disks. The storage you pick moves your own uptime target up or down. It also helps to remember that an SLA covers the service IT names and nothing more. A strong promise on one service doesn't automatically protect the other services you've stitched around it. Designing for resilience. Knowing the numbers is one thing and putting them to work is another.

9:44 So here's what that looks like in practice. If your region supports zones, spread your production workload across them and lean on zone redundant services wherever they exist. Put a load balancer in front of your app so traffic shifts to a healthy zone the moment one fails. That combination covers the most common failure of all, which is one zone going dark while the rest of the region is perfectly fine for the things that truly matter. Go wider than one region. Zones protect you from a building or a zone failing, and they do nothing when a whole region has a problem. Mission critical workloads want copies in more than one region. Backups are a separate job from all of this, and it's worth keeping them straight. Redundancy keeps you running while backups let you recover data you lost or deleted, so you still need both. Finally, decide how much downtime you can actually live with, because that number tells you how much design, work, and money the answer deserves.

10:27 A hobby project and a payroll system don't need the same setup, and pretending otherwise wastes money on one end and risks real damage on the other. Start with the promise you need and then choose the tools that get you there. One more habit is worth building early. Test your failover before you need it, because a recovery plan you've never actually tried is just a guess. Dressed up as a plan. The worst time to find the gap is during a real outage. Region pairs. There's one more layer Microsoft builds in, and it's called a region pair. Microsoft pairs some regions with another region, usually one in the same geography. So you have a second home already picked out for you. A pair hands you a few things. Geo redundant storage can copy your data to the paired region automatically. Planned updates are staggered across the pair, so a bad update is less likely to hit both at once.

11:09 If a whole geography ever fails, one region in each pair gets prioritized for recovery. Those are real advantages, and they arrive without you choosing anything at all. But here's the head fake. A paired region is not automatic disaster recovery, and Microsoft says so directly in its own documentation. Deploying to your pair doesn't by itself make you resilient, and the automatic failover for storage only kicks in during truly catastrophic situations. After repeated failed attempts. A pair is a helpful default, and it's not a plan you can rely on. The bigger shift is that many of the newer Azure regions aren't paired at all. They lean on availability zones as their main form of redundancy instead, which tells you where the whole platform is heading. You can build a resilient design with pairs, without pairs, or with a mix of both, as long as you actually design it.

11:50 So treat the pair as a bonus, not a foundation. If your region has a pair, use the storage replication it offers and still build your own plan for the things that matter. If your region has no pair, you haven't lost anything that zones can't cover for you the costs and trade offs. Now for the question every beginner holds in the back of their mind, which is what all of this costs. There's good news. First, Azure stopped charging for data that moves between availability zones in the same region. Letting your zones talk to each other is free. Whether you use private or public addresses. The real cost isn't the zones themselves, it's the copies. Running two or three of everything costs more than running one. And that bill grows with how much resilience you decide you need. The trade off stays honest, more copies mean more uptime and a higher monthly cost, and there's no way around that math.

12:31 A couple of other trade offs are worth naming. Zones are close, but they aren't instant. So a few very chatty workloads prefer to stay inside one zone for speed zone. Redundant services are easier because Microsoft handles the failover, while zonal services hand you control and put the failover work on your plate. Coverage isn't universal either, since not every region has zones, not every service supports them, and some services only offer zone support on specific tiers. So the answer to whether you should bother depends on what the workload is worth to you. And for anything that people actually depend on, the answer is usually yes. The zones, the sets and the pairs are all ways to buy yourself time. And only you can say what that time is worth. A demo that nobody uses can live in one's own forever, and the system that runs the business cannot.

13:13 And the skill is knowing the difference before something breaks. Recap. And one question. So here's the short version. To carry away a region. Is the city. An availability zone is a separate building. Inside it. An availability set spreads your machines across the racks in one building and a region pair is your backup city. The one idea to keep is that uptime is a design choice you make, not a feature you get for free. If you want more breakdowns like this, subscribe to M365 FM before you go, here's my question for you of everything you run today, which piece would actually survive losing a whole building?