Azure - Which region should I choose?

This is something that I've been trying to write for more than a year, but I never got any time to assemble my thoughts and put them in writing so that they read more than the ramblings of a cloud guy. I've been working with Azure since forever ago when it was called Azure Service Management; the code name was Red Dog, and scripting and automating were complicated, failed a lot, and went on. I even crashed West Europe with a script I made for doing things in parallel when the system never accepted that.

Azure has grown significantly in recent years. From a couple of regions, it expanded to over 60 regions with multiple hero region pairs and a plethora of new services. For me, choosing a region is easy. I determine the needs, wants, and concerns and then pick the region pair where the customer or I should deploy. That's a wrap. 

This sounds simple; however, many things are considered when choosing. This article summarizes my thinking process when talking with clients and providing them with options.

Be prepared; this will be a lengthy article.

The key elements of the decision are:

• Regulatory compliance and data sovereignty
• Service availability
• Geographical proximity and performance optimization
• Cost efficiency

Let's start, shall we?

Regulatory Compliance and Data Sovereignty

Compliance is significantly complicated by default. For us tech nerds, it's easy, but when compliance auditors and lawyers are added to the mix, everything gets exceptionally tricky. Each Azure geo-pair is bound by specific data protection and privacy laws, such as the European Union's GDPR (General Data Protection Regulation), which imposes stringent data handling rules or the US's FedRAMP and HIPPA.

The list is enormous (and it's a good thing!), and I keep in mind the most significant compliance certifications, and afterwards, I consult Azures Azure compliance documentation | Microsoft Learn

Data sovereignty is another critical factor in the discussion and region picking. Do we care enough about it to influence our decisions, or is it just nice to have? If your client is a government branch, you might care more about data sovereignty than a client who owns a pretzel factory. 

Depending on data requirements, you can tie yourself to a specific region or country, and usually, Germany pops up in the discussion; being from the EU, Germany has been a discussion topic since the Dark Ages, if we start nitpicking. The reality is that when you have a long discussion with the client who doesn't want to deploy outside of Germany, you will find out that it's mostly a preference but not a data sovereignty problem. Unless it's government or a specific compliance offering that only ties to that country, it's never a question of anything.

In some cases, discussions don't lead to anything, and you pick the deployment region as the native country. I did that many times, and the client always asked to be moved out of that region because it differed from what they wanted, forgetting that data sovereignty is an issue.

Yes, it would be a problem if you have a fully EU client and deploy in the US or Asia—otherwise, it would not be much of a problem. 

The key advice in this matter? Depending on the organization, you might have an EU deployment, a US deployment, an Asia deployment, a combination, or all three. Determine what the client wants, check for must-have or future compliance offerings, and go from there. If it's a government client with no Azure deployment in that country and it's a deal breaker to deploy outside, then on-premises solutions are the only way: solutions like Azure Stack, Azure Stack HCI, etc.

Service Availability

In principle, all the regions have the base services you're looking for: VMs, VMSS, App Services, AKS, etc. One of the significant differences between a central region, like West Europe or East US or hero regions as they are called, is that not all VM SKUs are available or exotic GPU SKUs for AI workloads. This can impact the deployment strategy up to a point. When choosing a region to deploy in, you have to consider the availability of the services you will use. While most of the services are available and, in general, new regions are deployed to have 90+% of them available, they still need to get them right now.

The dynamic nature of the Azure platform, characterized by the regular introduction of new services and features, means that the availability of these services varies from region to region.

The only example of service availability that comes to mind right now is Azure Goverment, where services that pop up in Azure Public take around 9+ months to land in those data centres. Case in point: OpenAI GPT models are not in sync at the time of writing this article. 

The recommendation here is to carefully check Azure Products by Region | Microsoft Azure and factor in the service availability in the decision or recommendation.

Geographical Proximity and Performance Optimization

The principle of latency is the time delay before a data transfer begins following instructions for its transfer. Latency plays a crucial role in the user experience. Lower latency correlates to quicker access to applications and data, which is essential for performance enhancement. 

In layperson's terms, the farther you are, the slower it gets. After passing the compliance discussion, you must choose the correct region pair based on the client's needs. This means that you need to identify the client's latency requirements. If the client's market is in the US, there's no point in doing an EU deployment. Even if the client is in the EU, this may counter the previous data residency and compliance point. It still matters regarding deployment as the client can host his data in the EU and have one or two deployment regions, which depends on his customers. You can have the client's data in the EU while serving US customers from US regions. The US is large, so picking regions on the West and East coasts are solid choices.

This would fall into the geostrategy discussion, which extends beyond performance enhancement and includes redundancy and failover capabilities. When the deployment happens, will GeoDR be enabled on the PaaS services? Is the DR region the sister pair of the main region? Is the client aware that deploying in one region doesn't mean DR is automagically happening?

Disaster Recovery and Redundancy

Azure is, by default, built with security, high availability, and disaster recovery through availability zones and region pairs. Starting from this design, you get data replication and backup by default at a datacenter level, from which you benefit. Now, this doesn't mean that the VM that you deploy has its data backed up by default. The underlying storage is backed up and replicated, and the resources you deploy are safe. However, what you deploy inside differs; you must set up backup and HA policies and create disaster recovery procedures and deployments.

With most PaaS offerings, you get a lot of bang for your buck by default, but it also comes with the vendor lock-in part of the story, so tread carefully when you're going down that route. SQL Databases have the possibility of geo-replication with failover groups. CosmosDB has a geo-replication possibility with multi-region support, storage accounts have geo-replication, and the list goes on.

Based on that, the main recommendation is to go with hero regions, create the DR in the region pair and move from there. Also, consider that the sister pair regions will not be the same size as the hero region. For example, North Europe is the sister region of West Europe. Some VM SKUs are unavailable in all the Availability Zones, so when I'm looking at creating the DR AKS cluster in North Europe, I have to modify the Terraform NE template to account for that and deploy to two AZs and not three or even less.

Cost Efficiency

Depending on the region, costs might be higher or lower. For example, West Europe or Sweden Central are in line with other regions and are pretty cheap, depending on who you're asking. Now, if you're looking at more sovereign areas like Germany, the UK or the UAE, then you're going to see a difference in price, sometimes even 30% higher, because those data centres cost more or are jointly maintained. Azure Government is also an excellent example because the prices there are much higher than those of Azure Public because of the added security measures and compliance checks required for those data centers to operate. The level of scrutiny there is much higher than Azure Public. 

Now, does that mean Azure Public is less safe? No, not even close. Specific certifications like FedRAMP or DOD ILS have requirements that must be met; otherwise, you're not qualified. Those requirements are costly, so obviously, the end user ends up paying for that level of extra security. Be glad you don't have to do it yourself. You must go from the virtual infrastructure layer and up rather than hardware and datacenter security.

Pricing Calculator | Microsoft Azure is an excellent tool for balancing cost considerations with performance, compliance, and service availability. Remember that prices depend on the region, taxes, currency conversion rates, and payment plans (PAYG, CSP, EA).

Final thoughts or TLDR

Whether you read the entire article or jumped to the end, the main point is to avoid analysis paralysis or, as my fellow US colleagues say, avoid Bikeshedding - The Decision Lab. While selecting an Azure region is a critical decision that influences cloud deployments' technical performance, regulatory compliance, and cost-effectiveness, it shouldn't be a decision blocker. Other things on the menu should be discussed.

If you should leave with something from this article, take this like this;

Choosing an Azure region comes down to matching your project's needs with the correct location. You must consider things like data laws, what services are available there, how close it is to your users, backup plans for emergencies, and how much it will cost. It's about making an intelligent choice without overthinking it. 

Lastly, when choosing a hero region or a region pair, try not to focus on the normal areas that existed since Azure popped up on the radar; try other regions as they are of next-generation design, have newer SKUs available and are more efficient when compared to the first datacenters that appeared with Azure. West Europe is one of them, try Sweden, you won't regret it :)

That being said, have a great one!