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.
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.
Warning
Do not attempt to use Azure GRS for VM backups or recovery. Instead, use Azure Backup and Azure Site Recovery along with Azure managed disks to support your IaaS workload resiliency.
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.