In this lesson, we're going to explore the benefits and usage of regions and region pairs. If we go ahead and look at the actual criteria, remember the skills assessed, we're now diving into these describe Azure core services, describing the core architectural components, and then over the next series of videos, we're actually going to dive into all of these different aspects. around regions, availability zones, resource groups, subscriptions, management groups, and the Azure Resource Manager. So they're all the components that we're going to dive into through the next series of lessons.
Now, I've used the term region before, and I talked about the idea that, well, there's multiple data centers that make up Azure. Again, there's no such thing as the cloud. It's just someone else's PC.
So I can think Azure as a service is comprised of lots and lots of physical data centers distributed around the world. And I can think there's lots of these. Now these are grouped into that concept of a region.
So I can think about, well, let's say for example these particular data centers are in a particular region. For example, this might be East US. Now the definition of that region is a latency envelope.
So I basically think of it as the region is defined as a two millisecond round trip latency envelope. Latency is the time something takes. The bits on the wire don't travel instantly.
Light is fast, but it's not instant. So the time it takes, the further I am between systems, the longer it takes to send out a request and get the response back. So that's the latency.
So a two millisecond round trip latency window means any data centers in the same region can't be more than it takes for the data to go out and come back. Two millisecond is that boundary. So that means they all sit within a certain physical distance.
And we can see those regions. I showed the map before. So if we jump back over and go and look at our map, as part of the global infrastructure here, I've done the 2D version. We can see there are regions. There's that kind of East US I was talking about.
There's also East US 2, Canada Central, North Central, South Central, Brazil South, UK South, all over the world. We have these various regions. Now, I'm talking primarily about the idea that, well, there's this single Azure cloud. The reality is there's actually multiple Azure environments.
For the most part, we're going to engage with the commercial, just regular Azure cloud. But the reality is there are actually some separate sovereign clouds. There are certain requirements where there needs to be both logical and physical isolation for, for example, US government.
They have their own sets of data centres, their own Azure AD sets of infrastructure. They're segregated. Germany has a sovereign cloud.
China has a sovereign cloud. So while we think about Azure, we are typically using the regular commercial Azure cloud. But there are also other clouds.
We can see these. So if we was to open up a terminal window, this is just in this case I'm using PowerShell. I can actually do a get AZ environment.
You don't need to know this command. This is just going to show me all of the different Azure environments that I can see. And here we see exactly what I was talking about. There's the idea that, well, there's a US government Azure cloud. There's a German Azure cloud.
And there is a China Azure cloud. Then there's the regular Azure cloud that most of us will actually be using. And they each use different endpoints for Azure Resource Manager to interact with.
And they have their own Azure AD identities as well. Now I'm connected to the regular Azure cloud. And so I can see there are various regions.
I can do get AZ location and list it as a table. there are certain regions that are part of that particular environment i.e azure cloud that i am connected to so i can see all of these different locations are available just as part of that regular Azure cloud. Now, you'll notice there are things like China I'm not seeing here.
I'm not seeing the sovereign Germany clouds. I see some German locations, but they're actually part of the Azure regular commercial. I'm not seeing the US government locations either. So there are these special environments and there are these special regions, but for the most part, we don't need to worry about that. There are the regions that we can use.
as part of our regular subscription. Now, why do we have multiple regions? And there are actually multiple reasons. I mentioned light, the speed of light before.
And the further I am from something, well, the longer the bits of data take to go out and to get a response back. So I may think about, well, I want to have services close to maybe me as a company, if it's offering a service to my company, or maybe to my customers. And so the whole idea here is, maybe this is, let's say, West US. I want to have instances of my service in multiple regions, so that, hey, if I have users, if I'm a user on the East Coast of the US, hey, I'll use the service that's in East US.
If I have users on the West Coast, well, then they would use the instance on the West Coast. If I had users in Europe, if I had users in Australia, I could deploy services to those different regions so they're close to whoever's consuming it, so they get a great experience. Yes, someone on the West Coast could access a service on the East Coast or one in Europe, but that distance means they'll get a high latency and therefore not a great performance.
So by having all of these regions in Azure... I as the provider can choose to put my services that make the most sense so they can get a great experience. Now there may also be regulatory reasons.
I may be in a certain industry that requires maybe the data to stay within a certain geography. Well, by having all of these regions throughout the world, if I'm operating in Europe for example, I can make sure I only deploy my services to regions in Europe. So I can meet any data sovereignty requirements.
That's why there's a special German cloud, for example, a special China cloud, because they have some very strict data sovereignty requirements. So I can actually completely separate those away. So by having all of these regions, I, as a customer of Azure, can pick which regions I deploy to, to meet any data sovereignty or regulatory requirements there may be. Additionally, I can think, well, Yes, there's different data centers, but because that latency window, they're all within a certain distance. There could be some natural disaster.
Now, Microsoft are very careful about where it picks to put data centers. They consider fault lines. They consider floodplains, all of these different aspects.
But natural disasters could still happen. So I will want to deploy to multiple regions to support, for example, a natural disaster. I would pick regions that are hundreds of miles apart.
So now what I could have is I could have my service running, and then maybe for disaster recovery if this something happens, I could fail over, or maybe I can have it running in both of them and balance between them. But I deploy to multiple regions to give me resiliency. if there is some regional level failure. So those are some of the key reasons we use multiple regions.
I want to be close to my customers, they get a great experience. There might be regulatory reasons and also for resiliency purposes. So we can really think about, hey, there's performance. There might be regulatory.
And I can also think about DR resiliency. So I'd pick multiple regions to impact. Now that last point about DR and resiliency is actually super important. You never want to just deploy to one region.
And when I use a certain service, I may get the choice. If I'm using, for example, a managed database offering, I can pick, hey, I want an asynchronous read replica in that region or that region or multiple regions. But for some services, there's just a built-in replication to another region, and regions are actually paired. So Microsoft, on its own set of services, has a built-in pairing that I cannot change. And some services use that.
For example, Azure Storage, if I do the geo-redundant data, it's replicating to the paired region. Azure Key Vault replicates to the paired region. And we can see those pairings. So if we jump over...
Microsoft has all of this documented in the Azure Cross-Region Replication Pairings document here. And I can see the regional pairings. And the key point you're going to notice about these is with the exception of Brazil South.
So this is the one exception right here. Brazil South replicates the South Central US. That's because at the time Brazil only had one region. So it had to replicate to the next closest, which was South Central US.
For all of the other pairs, the pairings are always in the same geopolitical boundary. So I'm not replicating outside of any particular political or data sovereignty area. So it's keeping that within there. China replicates to China, Europe to Europe, France to France, Germany to Germany.
et cetera, et cetera. They're all paired in the same geopolitical boundary. Additionally, They're also paired in such a way that they are hundreds of miles apart. That's a key point.
I don't want to use regions that are super close to each other. For example, I wouldn't want to be using East US and East US 2 for my disaster recovery because they're fairly close. If there was some kind of natural disaster, well could it impact both regions? So these pairings, yes they're in the same regulatory boundaries. But ideally, they're hundreds of miles apart to help give us that protection.
So that's a key point of all of these. We want that resiliency from them. Additionally, Azure actually uses those pairings for a couple of other purposes.
If we think about, well, if there is a large-scale outage, let's pretend, for example, East US and West US are paired. They're not exactly, but let's say those are. When it's trying to bring services back up, it will make sure when it's doing that bringing back of service, it will prioritise a particular region from the pairings to try and get one of them back up as quick as possible to get things serviced as fast as they can. Additionally, when it's rolling out updates to its fabric, it won't roll out updates at the same time to the regional pairs.
That's to avoid the chance that, hey, they're introducing a problem as part of an update. They want to introduce the problem to the primary and kind of the DR region. So it will stagger them.
It will deploy it to one of the pairs. And then once it's successful, then it would go ahead and deploy it to the other pair as well. So regional pairings, hey, they're critical as part of our resiliency.
But Azure also uses them as part of its resiliency and helps protect you as part of those kind of staged. updates as well.