When should I create resources in regions other than North Central and who should I contact?
Azure is comprised of many regions around the world. Each Azure region has specific characteristics that make choosing which region to use incredibly important.
- Available services: Services that are deployed to each region differ based on various factors. Select a region for your workload that contains your desired service. For more information about the available services in each region, see Products available by region.
- Capacity: Each region has a maximum capacity. While this is typically abstracted away from the end user, it can affect which types of subscriptions are able to deploy which types of services and under what circumstances. This is different that subscription quotas. If you are planning a massive datacenter migration to Azure, you may want to consult with your local Azure field team or account manager to confirm you are able to deploy at the scale necessary.
- Constraints: Certain constraints are placed on the deployment of services in certain regions. For example, some regions are only available as a backup or failover target. Other constraints that are important to note are data sovereignty requirements.
- Sovereignty: Certain regions are dedicated to specific sovereign entities. While all regions are Azure regions, these sovereign regions are completely isolated from the rest of Azure, are not necessarily managed by Microsoft, and may be restricted to certain types of customers. These sovereign regions are:
- Azure China
- Azure Germany (being deprecated in favor of standard nonsovereign Azure regions in Germany)
- Azure US Government
- Note: two regions in Australia are managed by Microsoft, but are provided for the Australian government and its customers and contractors, and therefore carry client constraints similar to the other sovereign clouds.
Networking considerations
Any robust cloud deployment requires a well-considered network that takes into account Azure regions. After considering the above characteristics for which regions to deploy to, the network must be deployed. While an exhaustive discussion on networking is beyond the scope of this article, some considerations must be accounted for:
-
Azure regions are deployed in pairs. In the event of a catastrophic failure of a region, another region within the same geopolitical boundary* is designated as its paired region. Thought should be given to deployment into paired regions as a primary and secondary resiliency strategy. *Azure Brazil is a notable exception whose paired region happens to be US South Central. For more, see Azure paired regions.
- Azure Storage supports Geographically Redundant Storage (GRS) which means three copies of your data are stored within your primary region and three additional copies are stored in the paired region. You cannot change the storage pairing for GRS.
- Services that rely on Azure Storage GRS can take advantage of this paired region capability. To do so, your applications and the network must be oriented to support that.
- If you don't plan to use GRS to support your regional resiliency needs, it is suggested that you do NOT use the paired region as your secondary. In the event of a regional failure, there will be intense pressure on resources in the paired region as resources migrate. Avoiding that pressure can provide you with additional speed during your recovery by recovering to an alternate site.
-
Azure Backup and Azure Site Recovery work in tandem with your network design to facilitate regional resiliency for your IaaS and data backup needs. Make sure the network is optimized so data transfers remain on the Microsoft backbone and use VNet Peering if possible. Some larger organizations with global deployments may instead use ExpressRoute Premium to route traffic between regions which can save regional egress charges.
-
Azure resource groups are regional specific constructs. It is normal, however, for resources within a resource group to span multiple regions. When doing so, it is important to consider that in the event of a regional failure, control plane operations against a resource group will fail in the affected region, even though the resources in other regions (within that resource group) will continue to operate. This can affect both your network design and your resource group design.
-
Many PaaS services within Azure support Service Endpoints or Private Link. Both of these solutions impact your network considerations substantially when considering regional resiliency, migration and governance.
-
Many PaaS services rely on their own regional resiliency solutions. For example, both Azure SQL Database and Cosmos DB allow you to easily replicate to x additional regions. Some services carry no region dependency, like Azure DNS. As you consider which services you will use in your adoption process, make sure to clearly understand the failover capabilities and recovery steps that may be required for each Azure service.
-
In addition to deploying into multiple regions to support disaster recovery, many organizations choose to deploy in an Active-Active pattern so that no failover is necessary. This has the added benefit of providing global load balancing and additional fault tolerance and network performance boosts. To take advantage of this pattern, your applications must support running Active-Active in multiple regions.
Warning
Azure regions are highly available constructs with SLAs applied to the services running in them. However, you should never take a single region dependency on mission-critical applications. Always plan for regional failure and practice recovery and mitigation steps.
How do I create resources in multiple regions?
The provided lab guide instructs end users to create resources in North Central for performance reasons. Should you desire to create resources in another region, please fill out our
web form and we'll assist you in creating a new VNET in another region and peering it to the central UIC hub VNET so that traffic can pass properly through our tunnel into the UIC campus network.