Microsoft Azure is generally available in over 30 regions around the world. Each region is home to a vast array of servers hosted within 1 or more datacenters.. This is something that’s very apparent in Azure; especially since you need to choose a specific Azure region to host services in. However, something that’s not quite as apparent is the concept of Azure Region Pairs. Specific Azure regions are paired together. This article explains what Azure Region Pairs are, and the benefits that come within them.

What are Azure Region Pairs?

Microsoft operates Azure Regions all over the world. Each Azure Region is strategically placed within a specific geography, and almost all the Azure Regions are located within the same general geography as at least 1 other Region; it’s pair. The only exception to this is the Brazil South region currently, which is the only Azure Region in Brazil.


The Azure Region Pairs are more than just a visual concept to think about with Azure Regions. The Azure Region pairs are connected directly together and offer multiple benefits when utilized together in the same distributed or redundant system. Before we get into these benefits of Azure Region Pairs, let’s first discuss the Azure Regions and Datacenters in further details.

Azure Regions in a Pair have direct connections which bring additional benefits to use them together.

The geographic disparity of Azure Regions is important. Global distribution of Azure Regions is strategic according to geography. There are many factors involved in their placement; from geo-political to internet latency for large population centers. However, Azure Region pairs have another big consideration that defines where they are placed.

Each Azure Region in a pair are always located greater than 300 miles apart when possible. This is to isolate each region in the pair from being affected by the same regional disasters that could take one of the regions down. These disasters could be earthquakes, hurricanes, tornados, fires, or some other natural or man-made disaster.

Each Azure Region in a pair are always located greater than 300 miles apart when possible.

Since each Azure Region in an Azure Region Pair are directly connected to each other and the are far enough apart to be isolated from regional disasters, it is recommended by Microsoft that when replicating data or interacting with services across regions that you use Region Pairs.

While you could use more geographically dispersed Azure Regions for replication, redundancy, and more, there are a number of benefits Azure Region Pairs provide. Next, let’s discuss the benefits of Azure Region Pairs.

What are the Azure Region pairs?

Before we get into the benefits of Azure Region Pairs, let’s cover what Azure Regions are paired. At the time of writing this article, the below graphic shows the current1 Azure Region Pairs.


The Brazil South regions pair is the South Central US region, but South Central US is paired with North Central US. This is the only odd pairing; all other region pairs are more logical.

When setting up services like SQL Database Geo-Replication and other services, the Azure Portal will guide you by telling you the “recommended” Azure Region. This will always be the Azure Region Pair, so you don’t need to memorize the above list.

What are the benefits to Azure Region Pairs?

Some of the benefits to Azure Region Pairs were touched on above, but let’s dig in to the benefits even further. There are a number of benefits that add to the base of geographic isolation.

Data Residency

The location of data stored within a geography can be very important. There are geo-political, tax, law enforcement jurisdiction, compliance, or other reason that an enterprise may require all their data to be located within the bounds of a certain country. This is the main reason why both regions in Azure Region Pairs are located within the same geographic region; most often within the same country.

Azure System Update Isolation

Microsoft maintains a huge amount of software and infrastructure that runs and automates the Azure datacenters. When rolling out updates to this “backbone” system, Microsoft will update a single region in the pair first. Then they will validate the update before moving on to the next region in the pair. This sequential updating of the Azure Regions in a pair ensures minimal downtime in the event of bugs or logical failures caused by an update. By using Azure Region Pairs for replication and redundancy will ensure your applications and services are not adversely affected by a rare bad update event.

Region Recovery Order

In the event of a massive Azure outage, each Azure Region Pair has a single region that is prioritized over the other for recovery. Systems deployed across multiple Azure Regions within a pair are guaranteed to have an Azure Region that will be recovered with high priority.

Platform-provided Replication

There are some services within Microsoft Azure that provide automatic geo-redundant storage. These services will do this by utilizing the paired region automatically.

Physical Isolation

Each Azure Region within a pair is physically / geographically located at least 300 miles apart where possible. This helps isolate the pair so that a regional disaster (earthquake, hurricane, fire, riot, power outage, etc.) affects only a single region within the pair.



Posted by Chris Pietschmann

Chris is a Microsoft MVP and has nearly 20 years of experience building enterprise systems both in the cloud and on-premises. He is also a Microsoft Certified Azure Solutions Architect and developer, a Microsoft Certified Trainer (MCT), and Cloud Advocate. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.


  1. […] Azure Region Pairs Explained (Chris Pietschmann) […]


  2. Don’t believe that statement around ingress/egress bandwidth at no charge between region pairs is correct.
    Is data transfer between Azure services located in two regions charged?
    Yes. Outbound data transfer is charged at the normal rate and inbound data transfer is free.


    1. Hi Chris – there currently isn’t any guidance in place to that effect that I am aware of; the only current option to eliminate bandwidth costs between regions is with ExpressRoute deployed to a region within that geo;
      “Once connected to an ExpressRoute location, users can connect to other regions in the same geo without the need for the premium add-on, and at no additional cost over existing plan charges. For example, in the US, customers can send or retrieve data to/from any Azure region in the US without the need to pay an additional fee on top of their existing plan charges. Similarly, once connected to an ExpressRoute location in Europe, customers can send or retrieve data to/from any Azure region in Europe without the need to pay an additional fee on top of their existing plan charges.”

      If you are aware of any publicly accessible statements or advice to this effect, please let me know and I can re-check internally – please use andrew.allen [AT]

      Thanks Chris – keep up the good work on the site!


    2. I’m working on getting further clarity on Egress and will be updating the article shortly to better reflect charges. Thanks!


      1. Hussain Mohammed March 29, 2019 at 11:58 am

        Hi Chris, I am just wondering If one of my Databricks uses storage redundancy in different regions then Is it possible to change that? I don’t want a DR Databricks procedure but I need to understand if some resource created automatically in databricks is in another region and I don’t have the option to change that. Could not find a clear answer.

      2. Chris Pietschmann May 13, 2019 at 5:45 pm

        I’m not familiar if there’s a way to tell Azure Databricks to create managed resources in a specific region. You should try asking this question on or other forums. Sorry I couldn’t be of more help.

    3. Alright, I updated the article to remove the Egress part about Azure Region Pairs since I couldn’t find references to back it up. It seems that the pricing of Egress between Azure Regions and Zones is a little confusing. I may write up an article to explain it. Thanks for the fact checking!


  3. […] Azure Region Pairs Explained (Chris Pietschmann) […]


  4. Pairs being > 300 miles apart seems very unlikely for the UK.


  5. This statement: “Each Azure Region in a pair are always located greater than 300 miles apart” is not true. As Microsoft’s own page on paired regions states, “When possible, Azure prefers at least 300 miles of separation between datacenters in a regional pair, although this isn’t practical or possible in all geographies.”

    Here’s a fairly prominent counterexample: the UK South region is in London, and is paired with the UK West region in Cardiff, and these are only 150 miles apart.

    The UK is small enough that with a carefully chosen centre, a 300 mile radius is very nearly enough to encompass the whole of the mainland. (Put the centre on the coast somewhere near the Lake District. and you can get very nearly everything in aside from the various islands which require a rather larger net.) That said, you could in principle fit two data centres into the UK with a 300 mile separation, but the place is small enough that this constraint would mean that neither data centre would be particularly near the areas that are likely to use Azure most. In practice, distribution of population and (probably of more relevant to Azure data centre location) high-tech industry means that you’re going to want one data centre in or near London, and that’s where the UK South one is. To locate a second one 300 miles away would put it either in Scotland, or at the very North-Eastern-most corner of England (I’m ignoring the possibility of underwater data centres). Berwick upon Tweed isn’t a major tech centre, so that rules out the latter. There is considerable high-tech industry in Scotland, but evidently Microsoft has determined that it’s not yet time for an Azure data centre in that region.


    1. Thanks for the clarification! It seems UK is an exception to this rule. I updated the wording of the article. 🙂


  6. […] commanded to implement ASR in Paired Region (Well Described), In this article I used East US and East US2 because my subscription was not […]


  7. […] So I set up two Windows 2016 D4s v3 instances, one in Central US and one in East US 2, which are paired regions. […]


  8. Is it possible to get a dedicated bandwidth between these paired regions ?


    1. Chris Pietschmann March 25, 2019 at 11:19 pm

      What are you trying to do that you want “dedicated bandwidth between” region pairs?


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.