This is Part 4 of Azure Tutorial. In our previous  two videos, we discussed azure data centers and  

geographies. In this video, we'll discuss azure  regions, region pairs, availability zones, update  

domains, fault domains, zonal and zone redundant  services. There's a lot of ground to cover. So,  

let's get cracking. Quick recap first. What  is an azure data center. An azure data center  

is a unique physical building that contains  thousands of physical servers with its own  

power, cooling and networking infrastructure.  These data centers are located all over the globe.  

As of November 2020, there are over 160+ azure  data centers worldwide. It is these data centers  

that are the building blocks of global azure  infrastructure. What is an azure geography?  

Well, it's an area of the world that contains  one or more azure regions. For example, India,  

United States, United Kingdom are a few examples  of azure geographies. Why are azure geographies  

important? Well, for two reasons. First,  let's say all of your customers are in India.  

You don't want to host your application somewhere  in the United States. You don't want every request  

and the associated data traveling around the  world. This causes unnecessary latency, delay and  

hence poor performance. You want your application  and data to be hosted as geographically close to  

your customer base as possible. Since all our  customers are in India, we want to make sure  

our application and data is hosted in India. One  way azure ensures this is by using geographies.  

Another reason is compliance. With regulations  regulated data like financial, health care  

or credit card data for example may not be allowed  to leave the country. Legally, your organization  

is required to store such data in the same country  where the operations are being carried out. Again  

azure ensures this, by using geographies. So,  for example if you select India as the geography,  

azure ensures your data is always stored in  India, except for certain global services. Now,  

what is an azure region? Simply put, an azure  region is a set of data centers and these data  

centers are connected through a dedicated  low latency network. How many data centers  

does a region contain? Well, we do not have fixed  number, it varies. There are regions of different  

sizes. A region could be made up of just one data  center or multiple data centers. The point is,  

an azure region is a group of one or more azure  data centers. As of this course recording,  

azure has 58 regions worldwide. You have the  flexibility to deploy your applications and data  

to any azure region you want. You can even deploy  across multiple regions to deliver cross-region  

resiliency. Now, you might be wondering  what's meant by cross-region resiliency? Well,  

in general resilience is the ability of a software  to react to problems in one of its components and  

still provide the best possible service. So, the  point is, both your software and the underlying  

infrastructure must be resilient. If there is a  problem, the end user should not know about it,  

the request must be handled and processed by  another region. The end user should get the same  

level of service. We can get this resiliency by  deploying our application and data in at least two  

regions. In this example, we have our application  and data deployed in two regions- Region A and  

Region B. If there is a region level failure,  for example, let's say Region A has gone down.  

The azure traffic manager is smart enough to send  all the requests to Region B. The end user gets  

the same response. He does not even know, there  is a region level failure. When Region A is back  

online, the azure traffic manager will distribute  the traffic between both the regions again. Why  

are azure regions important? Well, because every  time we create an azure resource like a virtual  

machine for example, we need to specify the azure  region where we want this resource to be created.  

Let's quickly look at this in action. At the  moment, I am logged into my free azure account.  

Even, you can create a free azure account.  Just search the internet with the search term,  

"Create free azure account". After you log in,  you should be able to create a virtual machine.  

Notice, on this page we have "Region" drop-down  list and within this drop down list we can see  

all the azure regions. So, here we select  the azure region, where we want our virtual  

machine to be created. Now, what is an azure  availability zone? Well, availability zone is  

a unique physical location within an azure region.  Each availability zone is made up of one or more  

data centers with independent power, cooling and  networking. Not all regions have availability  

zones. Regions that support availability zones  have a minimum of three separate zones to ensure  

resiliency. If one of the availability zones  has gone down for some reason, we still have  

our applications and data available from the rest  of the two availability zones. There is a physical  

separation between each availability zone and it  is this separation that protects our application  

and data from data center failures. With  availability zones, azure offers industry best  

99.99% virtual machine uptime SLA. SLA by the way,  stands for Service Level Agreement. Next, let's  

understand "Fault Domains" and "Update Domains".  An availability zone is a combination of a fault  

domain and an update domain. For example, if you  create three virtual machines across three zones  

in an azure region, your virtual machines are  effectively distributed across three fault domains  

and three update domains. For some reason, if  there is a power failure or power surge, equipment  

failure or some other fault in "Availability  Zone 1", only "Availability Zone 1" is affected.  

As the availability zones are physically separated  from each other, faults from one availability zone  

or not spread to the other availability zones.  Since in this example, we have three availability  

zones, it's like we have three separate fault  domains. If there is a fault and "Availability  

Zone 1" is down, we still have our virtual machine  available from the rest of the two fault domains  

that is Availability Zones 2 and 3. Similarly, if  there is an update or a patch to be applied, azure  

schedules these at different times for different  availability zones. So, this means we have just  

one of the availability zones affected while the  update is being applied. The rest of the two zones  

are unaffected. In our example, since we have  three availability zones, the updates will be  

applied at three different times. So, even if the  virtual machine from "Availability Zone 1" is down  

due to the update being applied, we have the rest  of the two virtual machines still up and running,  

that is the VMs in Availability Zones 2 and  3. Zonal and Zone-Redundant Services. Now,  

if you want to make the best use of availability  zones and then build high availability systems,  

you'll have to identify your compute, storage,  networking and data resources within an  

availability zone and then replicate them in  the other availability zones. Azure services  

that support availability zones are classified  into two categories - Zonal Services and  

Zone-Redundant Services. First, let's take a look  at Zonal Services. Virtual Machine is an example  

of a Zonal Service. A zonal service is pinned  to a specific availability zone. This means,  

it's only available in the availability zone where  we created it. It's not automatically replicated  

to other availability zones. So, if you want to  build highly available systems, identify zonal  

services such as a virtual machine for example,  and replicate them in other availability zones.  

Other examples of zonal services are managed  disks and standard IP addresses. Azure SQL  

database on the other hand, is an example of  zone-redundant service. These zone-redundant  

services are automatically replicated by the  azure platform across all availability zones.  

Unlike zonal services, we don't have to replicate  them manually. What are azure paid regions? Well,  

azure "Regional Pair", "Paired Regions" or "Region  Pair", all these terms are used interchangeably  

and they refer to the same thing, that is, a  pair of azure regions. So, in simple terms,  

a regional pair consists of two regions within  the same geography. As you can see from the image,  

at the highest level we have an azure geography.  As we have already discussed, an azure geography  

is an area of the world that contains one  or more azure regions. For example, India,  

United States, Europe, Asia Pacific are a  few examples of azure geographies. An azure  

region is made up of one or more data centers. If  availability zones are enabled, an azure region  

contains a minimum of three availability zones. An  availability zone is made up of one or more data  

centers. So, the point that I'm trying to make is,  an azure region contains one or more data centers  

or three or more availability zones, if  enabled. Most regions in a geography are  

paired to ensure business continuity and disaster  recovery. This is commonly known by the acronym  

BCDR - Business Continuity and Disaster Recovery.  The following are a few examples of azure paid  

regions. For Canada geography, we have Canada  Central paired with Canada East. For China,  

China North with China East. India - Central  India with South India. Japan East with Japan  

West and finally East US with West US. For the  complete list, please check out the Microsoft  

official docs. So, a regional pair consists of  two regions within the same geography. However  

there's one exception to this, Brazil's South  region is paired with South Central US region,  

which obviously is outside of Brazil's geography.  Now, one question you might have at this point is,  

can I select the regions that I want in a region  pair? Well, the answer is NO, you can't. Regions  

in a region pair are determined by Microsoft.  We do not have any control over it. However,  

you're not limited to using just the regions in  one given region pair. You can of course create  

your own business continuity and disaster recovery  solutions by deploying in any number of regions.  

Obviously, if they are deployed across regional  pairs, we will have better business continuity  

and disaster recovery. Now, the benefits of  paid regions. Physical separation between  

data centers. When possible, there is at least  300 miles of separation between data centers  

in a regional pair, although, this isn't practical  or possible in all geographies. Physical data  

center separation reduces the likelihood of  natural disasters, civil unrest, power outages  

or physical network outages affecting both the  regions at the same time. So, for whatever reason,  

if one of the regions is down, we still have  the other region available. Region recovery  

in the event of an outage. If for whatever  reason, several regions world-wide are down,  

azure prioritizes recovery of one region out  of every pair. So, if you want your apps and  

data to be highly available, deploy them in paired  regions. With this setup, if both the regions are  

down, azure prioritizes to recover at least one  region from the pair, so we have our apps and data  

available again soon. If applications are deployed  across regions that are not paired, recovery might  

be delayed. In the worst case, the chosen  regions may be the last two to be recovered.  

Automatic platform provided replication. Some  services such as geo-redundant storage provides  

automatic replication to the paired region. This  is a great benefit. In an event where one of the  

regions go down, you still have the data available  from the other region in the region pair.  

Data residency, compliance and legal requirements.  With the exception of brazil south, regions  

within a region pair are from the same geography.  So, this helps us meet data residency, compliance  

and legal requirements. Sequential system updates.  From time to time patches and software updates  

need to be applied. Regions in a region pair are  never updated simultaneously at the same time.  

They are always applied sequentially. This reduces  the downtime to a great extent, if the planned  

update contains any bugs or logical errors.  Only one region is affected. Our apps and data  

are still available from the other region in  the region pair. On the map right here, you  

can see the currently available azure regions and  availability zones. In this video, we've covered  

quite a bit of ground. So, please don't worry, if  some of the terms and services are a bit confusing  

at the moment. We will be revisiting most of  these, several times as we progress through the  

course. We'll also see them practically in action.  So, I assure you, you will get quite comfortable  

with them as we progress through the course.  That's it in this video. Thank you for listening.