By AzureMDM 
Hello, guys! Welcome back to another chapter on Azure Fundamentals. This is Chapter 7, and this time we will be learning about Azure Physical Infrastructure—things like regions, geographies, data centers, and availability zones. Let’s do it!
Chapter Objectives
Let me start with the chapter objectives. So, what is tested during the exam in the case of Chapter 7? We will be learning about data center regions, region pairs, geographies, availability zones, and the benefits and usage of those core architectural components. This is what is tested during the exam, so you should be able to describe those components but also describe the benefits and how they should be used within your applications.
Also Read: Azure Course Chapter 6 : Public, Private & Hybrid cloud deployment models
Azure Course Chapter 5: IaaS vs PaaS vs SaaS cloud service models
Azure Course Chapter 4 : Consumption-based Model
Azure Course Chapter 3: CapEx vs OpEx and their differences
Azure Course Chapter 2: Principle of economies of scale
Data Centers
So, let me start with data centers.
If you purchase services in Azure, whether it’s SQL Database, web hosting, virtual machines, or one of the many services within Azure, all those services run on a physical infrastructure underneath, on some sort of servers. A physical facility that hosts those servers is a data center. It is used to host a group of network servers. A typical data center has its own power, cooling, and networking infrastructure. So, data centers are the building blocks of global Azure infrastructure. A group of data centers that are connected with each other with high-throughput internet connectivity are called regions, and Microsoft has many regions across the globe of different sizes.
Regions
They can be as small as a single data center, or they can contain multiple ones. But what is most important is that they are globally distributed. For instance, in the United States, you have one in East U.S. and one in West U.S. In Ireland, there’s a North Europe region, and in Singapore, we have the Southeast Asia region. There’s also one in Japan called Japanese, but there are, of course, plenty more regions available. If you start putting a dot for every region available within Azure, we would get over 50 dots on that map, being able to choose from whatever location we want on the planet to be as close to our clients as possible. This is, of course, an important decision for every Azure developer and architect because the closer you are to your clients, the lower the latency between the servers and your clients.
Understanding Regions
When it comes to regions, there are a few additional things that you should understand. First of all, a region is simply a geographical area on the planet that consists of one but usually more data centers, but they need to be connected with a low-latency network—we are talking here about under 2 milliseconds latency between the data centers. Additionally, this is the location for your services. Location is a word that will come up very often when you work with Azure. Whenever you purchase any other service, a location will always be a mandatory field that you will need to fill, and it simply means, to which physical servers on the planet, which region on the planet, should I deploy that service?
But there are also a few very important things to remember. First of all, some of these services are not available in all the regions.
You should always check which region has the services that you need to build your application. But also, there are some services that are called global services. Those services don’t have any specific region and specific location assigned—things like Traffic Manager for DNS routing or Azure Active Directory. But there are a few other examples here.
Additionally, Azure is globally available with over 50 regions available. New regions are being announced and built pretty much every day, so in the future, there might be more than that. Lastly, there are some special regions like government regions for government regulations and partner regions like China regions, where Microsoft is providing the services but doesn’t really manage and run the data centers themselves.
Choosing a Resource Location in Azure
With that said, let me go to the Azure portal to show you how to create a resource and choose a specific location. For that, I will use the menu on the left-hand side where I can choose either the Create a Resource option or go to, for instance, Storage Account—a service that allows me to store files. I will select Storage Account and select Add to create a new Storage Account service. There are many fields that I need to fill in, but the one that I want to show you right now is the Location field.
Location field is what we were talking about. This is the region of Azure on the globe where I will be deploying my service. This is, of course, an important decision—to which region you should deploy—and this should not be taken lightly. You should always take time and consider what options you have here. To help with that decision, there are two portals that I want to show you.
The first one is called Azure Speed Test. This webpage makes a very simple test: it calculates an average latency between your current location and all the available Azure regions. So, let me run it for a couple of minutes to see the closest data centers—the closest Azure regions to my current location, which is Poland.
After about two minutes, the winner is pretty clear: Germany North region is the closest region available to me. But should I choose a data center in Germany North, or maybe I should choose the second best, West Europe? So, if you remember one of the points on my slide—not all of these services are available in all of the regions. This is why Microsoft prepared a second website. This website will list all the available services per region. This site is called Products Available by Region. This is a Microsoft Azure page where you select regions—in this case, I will select West Europe in Europe, but also, I will select Germany North.
So, those are the two regions that I had here, right? Germany North and West Europe. When you select those regions, click on Select All Products, and it will give you a list of all services within Azure and their availability within a specific region. As you can see on the left-hand side, we have West Europe; on the right-hand side, Germany North. If you scroll through this list, you will see that there are plenty more services available within West Europe. So, for me, it’s a pretty easy choice. I should go with West Europe because I want to be sure that my application will be future-proof and it will most likely be able to handle any kind of scenario, especially because West Europe is one of the oldest data centers, one of the oldest regions in Europe.
Availability Zones
Another term that you will learn today is Availability Zone. Availability Zones—if you remember our data center and region infrastructure, we have multiple data centers. They have their own power, cooling, and network infrastructure, and they are connected with super-fast internet. But in a typical scenario, you don’t have control over which data center your services are deployed to. That’s why Availability Zones were created. This is a regional feature where each data center gets a number, a number that represents a grouping of physically separate facilities. Simply put, Availability Zones are designed to protect from data center failures because each Availability Zone has its own power, cooling, and network infrastructure. Whenever there’s a failure in a single data center, the other two will continue working.
Zonal and Zone-Redundant Services
But if you think about it, this is how data centers operate normally. So, how do Availability Zones help here? By introducing this feature, Microsoft also created services and features within services that can take advantage of this information. Those services are split into two categories.
The first ones are zonal services. With zonal services, you can choose to which Availability Zones you are doing the deployment. In the case of virtual machines, now you have a choice. You can create two virtual machines for a highly available environment and specify that the first virtual machine goes to Availability Zone number 1, and the second one goes to Availability Zone number 2 or 3. This way, you ensure that if there’s a data center-level failure, at least one of your virtual machines will continue working. In the classical scenario without Availability Zones, it is possible that your virtual machine, even in a big region, could be deployed to the same data center or even to the same physical server. That’s why zonal services are so good, and Availability Zones allow you to create those highly available applications.
The second type of service is zone-redundant services.
Those services, like SQL Database or Storage Accounts, allow you to take advantage of multiple Availability Zones out of the box. With a simple check of an option, your services will automatically replicate data across multiple Availability Zones and will work in a redundant way. So, for instance, if you’re using a SQL Database and you have the zone-redundant option selected, even if you lose one of those Availability Zones, your database will continue working because there’s still one or two more Availability Zones up. Not all services support Availability Zones, especially zonal services; it’s usually the core infrastructure services like virtual machines or SQL Databases that do support it. There’s also a different pricing model for Availability Zones. In the case of zonal services, you pay more for each virtual machine and you pay for the traffic going between those Availability Zones because usually the traffic between data centers within a region is free, but in the case of Availability Zones, you have to pay for that additional traffic.
In the end, Availability Zones help you create highly available applications by allowing you to deploy your services to multiple Availability Zones or use services that do the redundancy for you automatically. This is a very important tool that you should understand and use in case you want to deploy mission-critical applications.
Region Pairs
Another term is region pairs. Region pairs is a feature that is used for disaster recovery. So, if you need to protect your application from a region-level failure, you use region pairs. What’s important to know is that region pairs are always predefined. Whenever a new region is being created, it is always paired with an existing region within the same geography—meaning same continent. For instance, East U.S. is paired with West U.S., and North Europe is paired with West Europe. There are also rules for those region pairs that apply. For instance, the region pairs are always within the same continent. There are three rules that you should remember:
- Region pairs are within the same continent, and there’s a physical isolation between them, meaning they are usually more than 300 miles apart.
- Platform updates are rolled out sequentially. In case there’s an update for the Azure platform, only one of those two regions gets updated, meaning that the other one will be available in case there’s a failure in the updated one.
- If there’s a region-level failure, Microsoft will prioritize the recovery of at least one region in a pair at a time.
Finally, a few important things to remember:
- Not all services support region pairs.
- Not all services take advantage of them. For example, SQL Database supports it, and Azure Site Recovery supports it as well.
Conclusion
That’s it! Those were the terms that we needed to cover, and this is everything that you need to know about the core architectural components—things like data centers, regions, region pairs, and Availability Zones. Thank you, and see you in the next chapter!