When it comes to deploying a service in Microsoft Azure, we don’t talk much about which region to use. What is a region? Where are they? What are the technical and legal aspects of deploying services in one region instead of another? I’ll try to answer these questions in this article.
Microsoft Azure Regions
Microsoft Azure is a huge network of data centers that are located around the world. The global presence of these data centers provides Microsoft customers the ability to deploy a service anywhere in the world. Maybe a business wants to deploy a website to reach customers in southwest USA or maybe an online media organization needs to distribute content to consumers everywhere with excellent performance. No matter whether you’re working for a small company or a gigantic corporation, you can tap into these services with a low cost of entry and without substantial capital expenditure that makes such projects impossible for those with smaller budgets.
The data centers are grouped into what Microsoft refers to as regions. There are several different regions around the world, which include the following (Source: Microsoft):
- Central US: Iowa
- East US: Virginia
- East US 2: Virginia
- US Gov Iowa: Iowa
- US Gov Virginia: Virginia
- North Central US: Illinois
- South Central US: Texas
- West US: California
- North Europe: Ireland
- West Europe: Netherlands
- East Asia: Hong Kong
- Southeast Asia: Singapore
- Japan East: Saitama Prefecture
- Japan West: Osaka Prefecture
- Brazil South: Sao Paulo State
Is Choosing a Microsoft Azure Region Important?
In short: yes, it is very important. There are a number of factors to consider when choosing a region to deploy your services in:
- Data export and compliance
- Service availability
I’ll discuss the impact of each of these factors in the rest of this article.
Data Export and Compliance
One of the most commonly questions about the cloud has been, “Where will my data be stored?” The numerous Edward Snowden revelations haven’t exactly reduced the frequency of this question. Where you store data might be important, and that’s a subject that is well outside of my scope of expertise. This is pretty simple for those who are operating only in the USA, but if you are in Europe, Asia, or other fragmented continents, then you need to ask the question, “Can I store data in another country?”
If only it was that simple! There are other issues at play, too. The location of the data center might be irrelevant. In reality, it’s actually the ownership of the data center that is important. Microsoft is an American corporation, and just like with Amazon, Google, Facebook, Twitter, and many other American-owned corporations, they are subject the US laws. And unfortunately, the USA believes their laws apply to everyone else. That means the US government can force Microsoft and all the other American-owned hosts to hand over data even if that data is located on the other side of the planet. Microsoft doesn’t like it and is even fighting the US government in the courts over this issue that could cripple US-owned cloud services.
This issue probably doesn’t affect many potential customers and to be honest, I know that many overlook the issue because the cost of cloud services is right. If this issue does affect you, then engineer ways around it. A hybrid cloud model will allow you to run stateless services in the cloud while keeping data on-premises or in a locally-owned public cloud (see Hybrid Connections for Azure websites). This will allow you to make the most of Azure’s economical scale and global presence while checking the compliance boxes if they apply.
Not all Azure services are available in all Azure regions. Obviously you will choose a region that offers the Azure services that you want to use.
The geography of the Internet is not simple. Routes from A to B are rarely in a straight line and usually travel through hubs or contact points between ISPs. The nearest Microsoft Azure region as the crow flies might not actually be the region with the lowest latency, and it is latency that dictates network service performance.
A company called two10degrees has set up a site in Azure that allows you to detect the latency between you and each Azure regions. It’s a fantastic tool that confirmed something that I had suspected. The office where I work is very close to the location of the North Europe region in Dublin, Ireland. However, I suspected that I had slightly better performance with West Europe in The Netherlands. I ran the Azure Speed Test and it confirmed something for me: from time to time, I have significantly lower latency to West Europe (across the Irish Sea, the UK, and then the North Sea) than I do to North Europe (a few miles down the road).
You should try to use the Azure region that is closest to you. Note that Traffic Manager will do this for you if you distribute a service in multiple regions, and you can also increase performance of services while lessening the load on Azure machines by using the Content Delivery Network (CDN).
The cost of services in Azure varies by region. If latency and compliance are not issues then you might choose to deploy services in the cheapest region (probably in the USA). You might even enable CDN if it was something that you were already considering to geo-cache static data to improve global client experience.
In a past life, I worked in the hosting business. I learned that service level agreements aren’t a guarantee — they are a lofty ambition. Anyone who has worked in our business knows that sometimes bad smelly stuff happens. And, yes, the likes of Google, Amazon, and Microsoft have had their issues in the cloud. A way to minimize the impact of a data center or region issue impacting your service availability is to locate those services in multiple regions.
Sometimes those issues occur outside of the data center. I remember one situation where a customer that was located just a few miles from our facility in Dublin complained that we were having an outage. All of our monitoring indicated that we had no issues. After some troubleshooting, our network admins figured out that the customer[s ISP was routing to our facility via Germany. A router in Germany had an issue and that meant that all customers of that ISP could not reach us. If we were using Azure, we might have had a better chance of detecting an issue using Endpoint Monitoring from geo-located monitoring stations.
When I first thought about disaster recovery and geo-dispersed services I thought that this was going to be one seriously complex issue. Azure makes it relatively easy. One can make a website or cloud service available in multiple Microsoft regions with just a few mouse clicks using Traffic Manager. You can create VNet-to-VNet VPNs to share and replicate data, and you can use service level replication to make services highly available. With Azure, even the smallest customer can have the same levels of high availability that previously were only possible for Fortune 100 companies.
Maybe choosing an Azure region isn’t so simple after all? Take some time to consider each of the above points and maybe you’ll opt to use a different region or even deploy services across multiple regions.