3 Interesting Facts About Microsoft Azure Regions and Availability Zones

Azure is the second-largest cloud platform provider globally, only second to AWS. So, it makes sense that IT pros want to learn as much about Azure as possible. While there is plenty of online training to help you learn Azure, it seldom includes information that the most curious among us want to know.

So today, we have three interesting things to know about Microsoft Azure regions and availability zones. You never know when this knowledge could come in handy as you train for certification or work with Azure on a daily basis.

1. Azure Regions Come in Pairs

The biggest reason that Microsoft deploys Azure in pairs is for redundancy. Of course, that was an easy and predictable answer, but that still doesn’t explain why Microsoft does this.

Production systems need redundancy. These systems are designed to handle a specific capacity 24 hours a day. These systems don’t get evenings and weekends off. That’s a lot to ask from our IT systems and admins.

Yet, we demand this kind of usage from our systems all the time. One of the methods we use to offer this kind of availability is redundancy. Think about it. RAID arrays use redundant drives. Good data centers use redundant battery backups, environmental systems, and even ISP connections. Servers even use redundant power supplies and network connections.

Redundancy means having backups for everything. We aren’t talking about information backups. We are talking about fail-over components for literally everything in IT. Azure and VMWare call this high availability. Of course, both companies extend on the definition of what they consider high availability, but nonetheless that high availability is designed around the idea of redundancy.

Azure deployment endpoints aren’t any different. Azure uses multiple endpoints for redundancy. Of course, IT infrastructure based on the Azure cloud platform could create redundancy by deploying to numerous geographic endpoints, but that defeats the purpose of other Azure features.

For example, some Azure endpoints include data sovereignty as a feature. Other Azure endpoints might handle data and networking specifically to comply with local laws.

You can’t create redundancy while complying with local laws if you only have one deployment endpoint in a single region. This is the reason Microsoft deploys Azure regions in pairs.

2. Even Azure Capacity is Limited

We all think of Azure as being a limitless resource. The fact is that the cloud is nothing more than a remote server farm. Azure still has limited resources, too.

Local data centers are designed around expected capacity. Businesses don’t want to overspend on IT solutions. This is such a concern that technical colleges have classes devoted to understanding total cost of ownership (TCO).

Cloud platforms have made TCO much more complicated to calculate. Well, sort of… Because organizations don’t own their cloud(s), TCO is converted and calculated as other business expenditures. These costs are calculated as services in the same way as an Autodesk or Office 365 subscription.

Because of that, costs can get out of hand quickly. On the other hand, the Azure cloud is so vast that it’s easy to provision more resources to solve a problem. Those resources are limited, though. Microsoft still designs Azure data centers around expected capacity levels.

Shortly after Azure rebranded and launched years ago, Microsoft had capacity issues. As a result, businesses couldn’t provision new resources for their cloud infrastructure because Microsoft didn’t have any more resources to offer.

Of course, Microsoft has since resolved that issue by building out more data centers. Not all Azure data centers are created equally, though. Some regions do not offer the same products as other regions. Other regions that offer redundant Azure products have limited availability of those products. So, capacity is still very much a concern for Azure today, especially with its growth rate.

3. Azure Regions May Be Closer Than They Appear

If you provision Azure resources in Amsterdam, are those resources literally in Amsterdam? The answer may surprise you.

Azure regions are not always physically located in the same area they are labeled as being located in. Let me put your mind at ease by saying this is not an issue, though.

The Azure Amsterdam data center is the perfect example for explaining this. The Azure Amsterdam data center is located about 37 miles (60 Km) north of Amsterdam. Of course, 37 miles means nothing when traveling at the speed of light, though. For the purposes of this fact, we are ignoring that content delivery systems are even a thing.

Traditionally, we would provision cloud resources or servers as close to our audiences as possible. We do this because geographic separation from our software endpoints and customers can impact application responsiveness. Of course, a couple of data calls to a distant server won’t make much of an impact, but tons of data calls repeatedly will severely impact application response times.

That’s because a 37-mile difference, or even a 100-mile difference, won’t really impact application response times at all (providing there are no other extenuating circumstances). Data packets can traverse multiple networks over a 100-mile distance in a fraction of a second. Under ideal conditions, we are talking less than 30 milliseconds of round-trip response times. For distance to affect application response times, you need to be traversing a significant distance (like from another country) or making a ton of data calls that depend on each other.

The point is that Azure uses recognizable landmarks for its regions’ locations so we have a good idea of where applications and services origin points are. For instance, I had no idea Broadalbin is only about five miles north of Amsterdam. If you didn’t either, you most likely had no idea that Broadalbin is above Amsterdam, NY, and not the Amsterdam located in the Netherlands. That’s why Azure uses recognizable cities located close to their data centers to signify where they are located — we'll have a clear idea of where we are provisioning Azure resources.

Last but not Least: Data Sovereignty and Owning Your Data

Wouldn’t it be nice if you had complete control over your data? In some countries, you do. Different localities have different rules and regulations based on data. For example, data collected or generated for a Chinese citizen must be stored on a server in China. France has similar laws and regulations as well. Likewise, some cloud resources designed for government or military use have identical restrictions.

Because of this, some regions in Azure have complete data sovereignty. These regions are limited, though. You will need to reference Azure documentation to find sovereign data regions since these regions can change.