How choose cloud region
The first question that a new customers have, once chosen to adopt cloud computing technologies is “On which region my workload should run?”
It seems a commonplace and simple question but behind the scenes there are important reasonings that must be considered to avoid further problem once the production workload will be implemented on cloud computing technlogies.
This exercise is equivalent for all cloud provider and can be applied indepdendetly of any specific technolgies.
First, what is a region?
A region is a specific geographical location where you can run your resources, like Virtual Machine, Database, PaaS, etc.. Each region has one or more zones, sometime called Avaliablity Zones (on AWS and Azure) that represent a fisical data center inside a region. (https://cloud.google.com/compute/docs/regions-zones/).
Choose a region implies that you can use one or all datacenter in that region. Any cloud provider suggest that all the architecture should leverage on multiple Availability Zones, in order to achieve fault tolerance about your application.
What the are the principle behind the choose of a region?
The first thing that you should answer are “What are the requirements of my Cloud Infrastructure?
Do I have legal requirements?
Do I have performance requirements?
Do I have cost requirements?
Do I have technical requirements/limitation?
Do I have all of them?
Basically the driver about the selection of a region are presented below. The order is not related to the importance that each sentese has because it’s depends on the specific requirement that each customer has.
Below I will try to anwser to all this questions, but the choose of a specific region dependes about the intersection of your requirements.
- Choose the location nearest your customers
- Choose the region based on your legal prerequisites
- Choose the region near your existing workload to reduce latency
- Choose the less expensive region
- Choose the region on which are presents the services that I would like to use
Now let’s examinate each point with pros and cons.
1. Choose the location nearest your customers
This is an elementary consideration but putting the cloud resources near the customers can improve performance and user experience.
Imagine that your customers are based on US, why in this scenario do I should use cloud resources in Europe? Also, if my customers are based on North US, the choose of a region like North Virginia, Oregon, etc.. could improve user experience.
This is an important consideration but it is not striclty mandatory, considering that up to now multiple cloud provider offers solutions to improve the user experience about system hosted in differente regions (like Content Delivery Network that replicated most visited contents across multiple edges, near to the customers).
If I should classify this point, from my point of view, this requirement is in the middle between cost and legal requirements.
2. Choose the region based on your legal prerequisites
This is becoming the most important requisite, especially with the introduction of GDPR in Europre countries. Imagine that you have an e-commerce website with users sensible information. If your country imposes that the users data must leverage on your country, you must restrict the choose based on the available one in your geographic area (e.g. if you are an European citizens and the customers data are about european citizens you must keep the users data on Europe regions, like Paris, Berlin, Frankfurt,..).
In my personal classification, if you need to manage customers data, this is the first prerequisites that you need to consider to avoid legal problems.
3. Choose the region near your existing workload to reduce latency
Imagine that you have an existing private infrastructure (or public on Cloud) that need to be connected with your new Cloud infrastructure. In this scenario, maybe low latency is a key about the success of your workload. There are a lot of techniques that can interconnect an existing infrastructure with a Cloud infrastructure, like VPC Peering, Express Route, AWS Direct Connect, etc..
Following my classification this is a key if you have an existing workload and you need low latency.
4. Choose the less expensive region
Most of all Cloud architect follow the main customer directive answering to the question “On which region should I spend less?”
This is sincerely the main goal of who pay the Cloud infrastructure but a solution architect must consider all the previous point in order to avoid that spend less on the Services and the resources means spend more about penalty, infrastructure rebuild due to low performance, etc..
On my personal classification, be careful about cost saving considering all the ringing bells around you :)
5. Choose the region on which are presents the services that I would like to use
The last point that should not be underestimated is consider a region on which the services that I would like to use are present.
It seems a banal assertion but on all Cloud provider the services and the feature are announced with different time frame on each region. This could depend on single data center availability (e.g. not all the VMs instance type are presents on all the regions) or simply because the functionality is born recently and not yet deployed on all regions.
This is an important point especially if you are choosing the cloud to use specific services.
I shown the main reasonings behind the choose of a Cloud region.
As you can see, everything is stricly related to the constraint that each project has, but this is a first point of discussion in order to open you mind about possible reasons behing the scene.
About the author
My Name is Emiliano Angieri and I’m a Cloud engineer expert with passion for all cloud applications and best practicies.
I’m AWS SysOps Certified.
Do you need support about development of new cloud infrastructure, cloud migration, help or clarifications?
Do you need help about costs on your existing cloud infrastructure?
Follow me on linkedin https://www.linkedin.com/in/emiliano-angieri-49908478/ or ask me a question to email@example.com.