Virtual machine scale sets

In this video we will understand Azure Virtual Machine Scale Sets. These are commonly know by the acronym VMSS (Virtual Machine Scale Set).

What is a Virtual Machine Scale Set (VMSS)

A Virtual Machine Scale Set lets us easily create and manage multiple virtual machines. 

Why do we need a Virtual Machine Scale Set

Let's understand this with a simple example. Consider a typical 3-tier application.

It's very common to have multiple web servers in the web tier and multiple application servers in the business tier. In this example, we have 4 web servers in the web tier and 4 application servers in the business tier. In real-world though, depending on the traffic and demand for your application, you may have many many web servers and application servers in the respective tiers.

Consider GMAIL.com for example. It has over a billion users world-wide. To be able to handle and process all these users requests, I wouldn't be surprised if they have thousands of web servers and business servers.

Now, one important point to keep in mind is, when we have many VMs that run our application, it's important to maintain a consistent configuration. For reliable performance of the application, the VM size, disk configuration, and any software that you install, like your application itself and it's dependencies, should match across all VMs.

Imagine the amount of time and effort it takes to create all these thousands of servers manually, one at a time. It's not only time-consuming, monotonous, and tedious but also error-prone.

This is a perfect scenario for using Virtual Machine Scale Set (VMSS)

Virtual Machine Scale Set (VMSS) - Important points

• A Virtual Machine Scale Set lets us easily create and manage multiple virtual machines.
• All VMs in a scale set are identical, meaning they are created from the same base operating system image and configuration. Obviously, this approach lets us easily manage hundreds of VMs without additional configuration.
• For traffic distribution, an Azure Load Balancer is also deployed along with the virtual machines in a scale set. There is no need to manually create the virtual machines or the load balancer. Just imagine the amount of time it saves.
• Even better, with the auto-scale feature, the number of virtual machines can automatically increase or decrease in response to demand. You can use metric based auto-scaling. There are many metrics from many sources in azure. For example, if the CPU utilization is over 70%, increase the VM instance count by 1. Not just scaling out, we can also auto-scale-in, when the demand subsides. For example, if the CPU utilization falls below 20%, decrease the VM instance count by 1.
• We can also increase or decrease the number of VMs in a scale-set based on a defined schedule. For example, let's say, next week, we are launching a new product or a business lines. So starting next week, we are going to have a heavy peak for 3 days. For this we can define a set schedule. For example, at 9:00 AM on Janury 1 increase the VM instance count to 50 and at 9:00 PM January 3, when our peak ends, bring the instance count back to our baseline configuration. How cool is that.

So, there are 3 ways to increase or decrease VMs in a scale set. Manually through the Azure portal or many of the azure APIs that are available. Auto scale based on metrics or a defined schedule.

 

Azure availability set vs availability zone

In this video we will discuss the difference between availability set and availability zone in Azure.

Update Domains and Fault Domains in an Availability Set

Availability set is a concept with in a datacenter.

The servers in a datacenter are divided into multiple physical and logical groups. The physical grouping is called fault domain and the logical grouping is called update domain.

You can think of each rack of servers with it's own power supply and network switch as one fault domain. So, if there are 10 racks of server in a datacenter, it's like you have 10 different falut domains. Now, you may be thinking, why is such a grouping required. Well, to eliminate single point of failure. 

For example, let's say in a datacenter, we have 100 servers and all these servers are connected by a single power supply and network switch. What if that single power supply or network switch fails? Well, all the 100 servers will fail as well.

So, to eliminate such a single point of failure, each rack of servers has it's own power supply and network switch. Let's say in each rack we have 10 servers. When the power supply or network switch in that rack fails, only the 10 servers in that rack are affected. The rest of the 9 racks i.e the other 90 servers are unaffected.

So, by grouping servers in a datacenter into multiple racks i.e multiple fault domains, we are able to eliminate a single point of failure.

Same idea with update domains. If there are 100 servers in a datacenter, they are logically grouped into 10, 15 or 20 update domains. So the important point to keep in mind is, an update domain is a logical grouping. Why are update domains required? Well, from time to time, server patches and software updates need to be applied. Some updates require servers to be rebooted. Now, we don't want all the servers to be rebooted at the sametime. Only one update domain is rebooted at a time. A rebooted update domain is then given 30 minutes to recover before maintenance is initiated on a different update domain. So, in short, an update domain is a group of servers that can be updated and rebooted at the same time.

An availability set is a concept with in a datacenter and it is made up of multiple fault domains and update domains. In fact, when you create an availability set, you can specify how many fault domains and update domains you want in that availability set. We discussed this in detail in our previous video.

Update Domains and Fault Domains in an Availability Zone

Availability Zone's also have the concept of fault domains and update domains. First, let's understand, what is an availability zone.

Well, an Azure Availability Zone is a unique physical location within an Azure region. Each Availability Zone is made up of one or more datacenters with independent power, cooling, and networking.

Not all Regions have Availability Zones, but regions that do have availability zones, have a minimum of three separate zones.

You can think of each availability zone as a separate fault domain and update domain. So in a given azure region if you have 3 availability zones, then it's like you have 3 fault domains and 3 update domains.

So, for example, if you create three VMs across three availability zones in an Azure region, your VMs are effectively distributed across three fault domains and three update domains. 

If one of the Availability Zones has gone down for some reason, we still have 2 VMs from the rest of the 2 availability zones. 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 2 zones are unaffected.

Now, here is the important bit to keep in mind. The concept of update domain and fault domain is present in both availability set and availability zone. In case of an availability set, a group of servers (physical or logical), physical grouping i.e a rack of servers is a fault domain and logical group of servers is an update domain. In case of an availability zone, each availability zone itself is considered, a separate falut domain and update domain. So in a given azure region if you have 3 availability zones, then it's like you have 3 fault domains and 3 update domains.

Availability SLA with Availability Set and Availability Zone

The following MSDN page has the VM SLA.
https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_9/

Microsoft guarantees only 99.9% SLA i.e connectivity, if you create just a single instance of virtual machine in azure.

If you create 2 or more virtual machines in an availability set, then Microsoft guarantees you will have connectivity to at least one of the virtual machines at least 99.95% of the time.

On the other hand, if you create 2 or more virtual machines across 2 or more availability zones, then Microsoft guarantees you will have connectivity to at least one of the virtual machines at least 99.99% of the time.

Difference between Azure Availability Set and Availability Zone

In short, the following are the 2 main differences between an Availability Set and Availability Zone

An availability set protects your azure resources from failures within data centers where as an availability zone protects from entire datacenter failures.

From the Service Level Agreement (SLA) standpoint, i.e uptime and connectivity - With Availability Set azure offers 99.95% SLA where as with Availability Zone we have 99.99% SLA. So, there we go, with availability zones, Azure offers industry best 99.99% VM uptime SLA.

 

Azure availability set

This is Part 8 of Azure tutorial. In this article, we will understand Azure availability sets with a simple example. Before that let's understand Fault Domains and Update Domains.

Azure Fault Domain

What does an azure dataceneter contain? Well, in simple terms, it contains several racks of servers. Each rack in turn, may contain several servers with it's own power supply and network switch. In reality, server racks are much complicated than this. They may be equipped with redundant power supplies and network switches. However, to keep this example simple, let's just say, a rack contains 15 to 20 physical servers with it's own power supply and network switch.

So you can think, each rack of servers as a separate fault domain. For example, if the power supply or network switch fails in a given rack, only the servers in that rack fails. The rest of the server racks are isolated and unaffected. So you may think of a fault domain as a group of resources that may fail at the same time due to the same root cause. It has a single point of failure. For example, if the power supply fails, all the servers in that rack fails. It is very important we understand the concept of fault domains, because, if we deploy our azure resources like virtual machines for example, in two or more fault domains, they remain available should a failure occur in one of the fault domains.

Azure Update Domain

The server hardware and supporting infrastructure in a datacenter is divided in to multiple fault domains and update domains. An update domain is a group of resources that can be updated and rebooted if required at the same time. From time to time, patches and software updates need to be applied. Some updates require servers to be rebooted. Only one update domain is rebooted at a time. A rebooted update domain is then given 30 minutes to recover before maintenance is initiated on a different update domain. This reduces the downtime to a great extent. So, if you want your azure resources, like virtual machines for example to be available even during the update process, have them deployed across multiple update domians.

Azure Availability Set

An Availability Set is a logical grouping for isolating virtual machine resources from each other. Azure makes sure that the VMs we place in an Availability Set run across multiple physical servers, compute racks, storage units, and network switches. If a hardware or software failure happens, only a subset of our VMs are impacted and our overall solution still stays operational. Availability Sets are essential for building reliable cloud solutions.

Let's say we have a simple two tier web application. On one of the virtual machines, we have a web server and on another virtual machine, we have our database server. Now, to be able to handle and process more requests we have 2 web servers and 2 database servers. In real-world, web applications that have lot of demand, for example Google.com, Gmail.com, and Amazon.com may have many many web servers and database servers. However, to keep our example simple, let's just stick to two web servers and two database servers. The load balancer obviously distributes the incoming traffic between the two web servers.

What may happen if availability sets are not used

Well, all the 4 VMs (i.e the two web servers and two database servers) may end up in the same fault domain or update domain. As a result if there is a software failure or hardware failure like power supply or network switch failure, all your web and databaser servers go down. End result your web application is no longer available. If it's an e-commerce application like amazon.com for example, just imagine the extent of loss to the business every second the system is down.

Use availability sets for high availability

Since we have two tiers - a web tier and a database tier, we create 2 availability sets - one for the web tier and the other for database tier.

In Azure, when creating an availability set, we specify the following

Name

The name of the of the availaility set. It's a common convention to use the prefix "avail" for availability sets

Region

Azure region where we want the resources to be deployed

Fault domains

The number of fault domains you want in the availability set. For example, if you set the fault domains to 3 and you create 3 virtual machines, each of them will be placed in 3 separate fault domains. If there is a fault like a power failuer for example, only one of the server racks is affected. This means only one of you VM is down, but the other 2 vms from the other 2 fault domains are still available. This in turn means, your workload i.e in this case your web application is still available to end users.

What happens if we create a fourth VM with 3 fault domains. Well, it will be placed in one of the 3 fault domains. This means, in one of the 3 fault domains, you will have 2 VMs and the rest 2 will have 1 each.

Update Domains

The number of update domains you want. Let's say, you have 3 VMs deployed across 3 update domains. If an update is installed and a restart is required, only one update domain is restarted at any given time. This means you have the other 2 VMs available from the rest of the 2 update domains.

Availability Sets and Virtual Machine SLA

For all Virtual Machines that have two or more instances deployed in the same Availability Set, Microsoft guarantees, you will have Virtual Machine Connectivity to at least one instance at least 99.95% of the time.

You can't add an existing Virtual Machine to an availability set after it's created. So, if you want a virtual machine in an availability set, it's a decision you have to make at the time of creation, not after it is created.

 

Azure management groups and subscriptions

In our previous 2 articles of this azure tutorial, we discussed Azure resource groups and the benefits they provide. In this article, we will discuss azure management groups and subscriptions.

If there are only a few subscriptions in your organisation, then it's relatively simple to manage them independently. However, in an organisation there are usually many employees and may be, many applications. If all these employees are provided azure subscriptions and if they start creating azure resources at will, it may soon become difficult to control, manage and track who is creating what and eventually the costs may go out of control. So, Azure has four levels of management-scope to organize, secure, manage and track the costs. The following image from MSDN shows the four levels of management-scope and the relationship between them.

Management groups

Management group is at the top of the hierarchy. All subscriptions in a management group automatically inherit the conditions or settings specified at the management group level. So, a management group is like a container for all your subscriptions. Just like how there can be multiple subscriptions, there can also be multiple management groups in an organisation.

The following image is from MSDN, and it shows, how we can build a flexible structure of management groups and subscriptions to organize our resources into a hierarchy for unified policy and access management. 

For whatever reason, let's say, in our organisation, we want to allow azure resources to be created only in the East US region. One easy way to do this is to create such a policy at the IT Management Group level. This policy is then automatically enforced on all the Management Groups and Subscriptions that are descendants of the IT management group. The descendants will not be able to alter this security policy in any way and it is also applicable to all resources under those subscriptions. So, obviously governance becomes much easier.

Management settings like policies and role-based access control can be applied at any of the management levels. The level you select determines how widely the setting is applied. Lower levels inherit settings from higher levels. For example, when you apply a policy to a subscription, that policy is also applied to all resource groups and resources in that subscription. In general, it makes sense to apply critical settings at higher levels and project-specific settings at lower levels.

Subscriptions

A subscription sits under a management group. It associates user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the amount of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.

Resource groups

A resource group, as the name implies, is a group of related azure resources. It is basically a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed. We discussed resource groups in detail in Parts 5 and 6 of this azure tutorial.

Resources

An azure resource is any service instance that you create. For example, virtual machine, Azure sql database, storage account etc.

 

Azure resource group benefits

This is Part 6 of Azure tutorial. In our previous article we discussed Azure Resource Groups. In this article, we will discuss the benefits of Azure Resource Groups. Before we discuss the benefits, let's quickly recap the main and important points of azure resource groups.

Azure resource groups - Imporantant points to remember

1. An azure resource is any service instance that you create. For example, virtual machine, Azure sql database, storage account etc.
2. A resource group, as the name implies, a group of related azure resources.
3. In general, resources in a resource group share the same life cycle, so they can be easily created, deployed, updated, and deleted as a single unit.
4. When you create a resource group, you specify a region. It is this region where the meta-data about the resource group is stored. 
5. However, the resources themselves can be in any azure region. 
6. Resources in one resource group can interact with resources in other resource groups.
7. Each resource must be in one and only one resource group. You cannot have a resource in more than 1 resource group at the sametime.
8. You can move a resource from one resource group to another.
9. You can add or remove a resource from a resource group at any time.
10. You can group resources any way you want. Anyway that makes sense to your oragnisation really - By department, By country, By application, By resource type or a combination of these.

Benefits of Azure Resource Groups

Administration is much easier

Let's understand this with an example. Consider a virtual machine.

When we create a virtual machine in azure several other associated resources like the following are created.

1. a data disk for the virtual machine
2. Public IP address
3. Network interface
4. Network security group
5. Virtual network

Without these resources, an azure virtual machine doesn't work as expected. After you are done with the VM, you may want to delete it to save on cost. However, when you delete the VM the associated resources are not automatically deleted. You have to delete them manually. If you forget to delete 1 or more associated resources, you are unnecessarily paying for those resources that you are not actually using.

On the other hand, if you create a virtual machine in a resource group, all the other associated resources are also created in the same resource group. When we delete the resource group, not just the virtual machine, all it's associated resources are also automatically deleted.

Another example. Let's say, you are creating a web application. To aid this you need several resources like a virtual machine,  storage account, sql database, virtual networks and many other dependant and related services.

Without resource groups, if you have to develop and deploy this application, you have to manually create all these azure resources. That too, you have to create them in the right order. If it's just one time, then it's okay. But in real-world, with every company using agile approach and CI/CD i.e Continuous Integration & Continuous Deployment, applications are deployed several times a day. For example, everytime, a new piece of code is checked-in to the source control, a new build is deployed to the test-environment. So everytime we have to do this, if we have to create all the resources manually, it's not only tedious and time consuimg, but also error-prone. What if you create the resources in the wrong order or even worse what if you forget to create a resource. It gets even more messy and complicated if you have to manage multiple applications and multiple environments

With resource groups, you can group related resources any way you want, may be for example, by application and by deployment environment. This grouping obviously allows you to manage all the resources that belong to a specific application and deployment environment as one unit. You can even automate deployments using Azure Resource Manager Templates. We will discuss Resource Manager Templates in our upcoming videos.

Cost management is easier

In the azure portal, on the cost analysis blade, you can see the cost of running each resource. You can also see the total cost of all the resources in the resource group. When you are done with a set of resources, there is no need for you to delete each resource individually. When you delete a resource group, all the resources in that group are also deleted. This obviously eliminates any possibility of orphaned resources (ghost resources) left running, and as a result running up costs.

 

Azure resource groups

This is Part 5 of Azure Tutorial. In this article we will understand Azure Resources and Resource Groups.

What are Azure Resources

Resources are instances of azure services that you create, like virtual machines, app services, storage accounts, SQL databases, function apps etc. All these are azure services. Everytime you create an instance of a service, you are creating a resource. There are hundereds of azure services.

You can see the complete list of azure services by navigating to https://portal.azure.com/#allservices. You need to login to the azure portal, otherwise it will redirect you to the login page.

On the left you see the service categories like General, Compute, Networking, Storage etc. For example if you want to create a storage account to store your data, click on the Storage category and you will see all the services related to Storage. 

Anytime you create a resource, you also need to specify a resource group.

What is an Azure Resource Group

As the name implies, a Resource Group is a group of azure resources like virtual machines, app services, storage accounts, SQL databases etc. It's a logical container for grouping related azure resources.

Azure Resource Group Example

Let's say we are developing a web application. There are several ways to do this. To keep this example simple, let's just assume we need the following 3 azure resources.

1. Virtual Machine - To host and run our web application
2. Storage Account - To store images, videos and other resources that our web application needs
3. SQL database - To store our application data

Let's say for this example sake we have the following environments. Most organisations have these deployment environments.

1. Development
2. Testing
3. Staging
4. PreProduction
5. Production

Let's say our web application name is PragimTech.com. We might create the following 4 resource groups, one for each environment. 

1. rg-pragimtech-development
2. rg-pragimtech-staging
3. rg-pragimtech-preproduction
4. rg-pragimtech-production

We have the following naming pattern here. The prefix rg stands for resource group.

rg-<applicationName>-<deploymentEnvironment>

Grouping by deployment environment is just one way of grouping. Obviously you can group resources any way you want. Anyway that makes sense to your oragnisation really.

1. By department,
2. By country,
3. By application,
4. By resource type or a
5. Combination of these

In general, resources that share the same deployment lifecycle are grouped, so these resources can be easily provisioned i.e created, deployed, updated, and deleted as a single unit. There are several benefits of grouping resources. We will discuss the benefits of resource groups in our next article.

 

Azure Regions | Paired Regions | Availability Zones

This is Part 4 of Azure tutorial. In our previous 2 videos we discussed Azure Datacenters and Geographies. In this video we will discuss

1. Azure Regions
2. Region Pairs
3. Availability Zones
4. Update Domains
5. Fault Domains,
6. Zonal Services
7. Zone-redundant services.

What is an Azure Datacenter

An Azure data center is a unique physical building that contains thousands of physical servers with it's own power, cooling and networking infrastructure. These data ceneters are located all over the globe. As of November 2020, there are over 160+ Azure datacenters worldwide. It is these dataceneters that are the building blocks of gloabl Azure infrastructure.

What is an Azure Geography

An Azure geography is 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

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 travelling 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 may not be allowed to leave the country. Legally your organisation may be required to store such data in the same country where the operations are being carried out. Again, azure ensures this, by using geographie

So, for example, if you select India as the geography, Azure ensures your data is always stored in India, except for certain global services.

What is an Azure Region

Simply put, an Azure Region is a set of Datacenters that are connected through a dedicated low-latency network. How many datacenters does a region contain. Well, we do not have a fixed number. It varies. There are regions of different sizes. A Region could be made up of just 1 dataceneter or multiple datacenters. The point is, an Azure Region is a group of one or more Azure Datacenters. 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.

What is 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.

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 2 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, beacuse everytime 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. 

What is an Azure Availability Zone

An Azure Availability Zone is a unique physical location within an Azure region. Each Availability Zone is made up of one or more datacenters 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 applications and data from Datacenter failures. With Availability Zones, Azure offers industry best 99.99% VM uptime SLA.

Azure fault domain and update domain

An Availability Zone is a combination of a fault domain and an update domain. For example, if you create three VMs across three zones in an Azure region, your VMs 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 separted from each other, faults from one availability zone are not spread to the other availability zones. Since, in this example, we have 3 availability zones, it's like we have 3 separate fault domains. If there is a fault and Availability Zone 1 is down, we still have our VM available from the rest of the two fault domians i.e 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 2 zones are unaffected. 

In our example, since we have 3 availability zones, the updates will be applied at 3 different times. So even, if the VM from Availability Zone 1 is down, due to the update being applied, we have the rest of the 2 VMs still up and running i.e the VMs in Availability Zones 2 and 3.

Azure Zonal services and Zone-redundant services

If you want to make the best use of availability zones and build high-availability systems, you will have to identify your compute, storage, networking, and data resources within an availability zone and replicate them in the other availability zones. Azure services that support Availability Zones are classified into two categories:

Zonal services - Virtual machine is an example of a zonal service. A zonal service is pinned to a specific availability zone. This means it is only available in the availability zone where it is created. It is not automaically replicated to other availability zones. So, if want to build highly-available systems, identify zonal services, such as a VM for example and replicate them in other availability zones. Other examples of zonal services are managed disks and Standard IP addresses. 

Zone-redundant services - Azure SQL Database 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 paired regions

Azure regional pair, paired regions, or region pair, all these terms are used interchangeably and they refer to the same thing, i.e 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 datacenters. 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 datacenters. So the point is, an Azure region contains one or more datacenters or 3 or more availability zones if enabled.

Most regions in a geography are paired to ensure business continuity and disaster recovery (BCDR). The following are a few examples of azure paired regions. For the complete list of Azure paired regions, please check out the Microsoft official docs.

A regional pair consists of two regions within the same geography. However, there is one exception to this. Brazil South region is paired with South Central US region, which obviously, is outside of Brazil's geography.

Regions are paired by Microsoft

Can I select the regions that I want in a region pair. No, you can't. Regions in a Region Pair are determined by Microsoft. We do not have any control over it. However, you are 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.

Benefits of paired regions

Physical separation between datacenters : When possible, there is at least 300 miles of separation between datacenters in a regional pair, although this isn't practical or possible in all geographies. Physical datacenter separation reduces the likelihood of natural disasters, civil unrest, power outages, or physical network outages affecting both the regions at the sametime. 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 with in a region pair are from the same geography. 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 will still be available from the other region in the region pair.

On the map below you can see the currently available Azure Regions and Availability Zones.

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 will also see them practically in action. So I assure you, you will get quite comfortable with them as we progress through the course.