When you create a resource in Azure, you select which Azure region your resource is created in. There are Azure regions all over the world, but what exactly is a region? I’ll answer that question, but let’s first zoom out a little bit.

Azure regions are created within another boundary called a geography. A geography is defined by the borders of a country, and there are 35 geographies in Azure. There’s a good reason for defining these geographies. Many countries have regulations specifying how data are stored and transmitted, and placing Azure regions within geographies that correspond to countries makes it easier for Microsoft (and you) to apply governance to maintain compliance with those countries.

Within these geographies, you’ll find Azure regions. An Azure region is a physical location within a geography. If you had the physical address of an Azure region, you could drive there. If you had the right credentials, you could enter the gates, walk into the lobby, and get access to the server racks and other infrastructure that make up Azure. The physical buildings in a region that house all of this infrastructure are called datacenters.

Understanding Azure under the hood is an important step towards understanding concepts related to high availability.

Datacenters are designed in a way that helps you ensure high availability of your data and Azure resources. Each datacenter has its own power infrastructure, its own water supply, its own backup generator, and so forth. All data that flow into and out of a datacenter flow over lines that are either owned or leased for Microsoft’s exclusive use. If you deploy your Azure resources and data to multiple datacenters, you’re protected from localized problems (or faults) within one datacenter, and that concept is called fault tolerance.

Fault tolerance can protect you from localized problems, but if a problem occurs on a larger scale (such as a disaster caused by a massive storm), you’ll need another approach to protect your data and resources. To protect you from larger scale events, Microsoft has paired each Azure region with a region pair. If you deploy your data and resources to both regions within a region pair, you’ll be in a better position if a wide-scale event occurs.

While you can deploy to two regions that aren’t defined as region pairs, you get some benefits by choosing region pairs. When Microsoft rolls out updates to Azure, it will do so in a single region in the pair first. Once updates are successfully applied to the first region in the pair, they’ll move on to the next region. This helps you ensure high availability. If an update (or another event) causes a broad impact to Azure services, Microsoft will prioritize resolving that impact in one of the regions in a pair, minimizing the impact to you from the outage. It’s also important to note that region pairs are almost always within the same geography. (The only exception I’m aware of is South Brazil.)

So how do you know which regions are region pairs? You have to check the Microsoft website, and the best page I’ve found to help with this is the Azure Geographies exploration page. From this page, you can explore all the different geographies, the regions within them, and find a wealth of information on each region, including which region is the region pair.

This page also links to the amazing virtual global infrastructure experience where you can explore all of Azure across the globe. There are plenty of links on this page to explore, and one of the most interesting takes you to a virtual tour of an Azure datacenter. I spoke about this tour in a recent training course on O’Reilly. It’s a great way to solidify the fact that an Azure datacenter is a physical entity within an Azure region.

Understanding Azure under the hood is an important step towards understanding concepts related to high availability. Having this framework of knowledge will help you connect the dots as you learn about core cloud concepts.