(Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 1 - (Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 2 - (Part 2) Things that we should consider when the content stored in Azure shouldn't leave a specific country
In this post we will talk about what is happening with data that is transmitted between Azure Regions and on-premises systems.
Context
Nowadays, Microsoft is opening more and more data centers around the glob. Regions like Japan, UK (to be announced), Brasil, Germany, Korea are already in-place or will be in-place soon.
This specific countries have laws that requires for specific industry or data to not leave the country. Especially in health-care industry it is common to have a restriction that patient information to not leave the country in any moment in time. Similar laws are for other industries like banking or data protection.
In this context we need to be aware of this laws, what kind of solutions we propose and what is happening with the content that is transmitted between Azure Regions and on-premises systems.
The main purpose of this article is to cover what is happening with content that is transmitted between Azure Regions and on-premises system and things that we should be aware. Another article will cover about different configuration of our Azure Services that might affect us.
What is happening with our data inside an Azure Region
Assumption: We don't take into account different Azure Service configurations that might move data to another regions. We assume that customer didn't configure the Azure Service to back-up or replicate content in another Azure Regions.
All the data that we store in an Azure Region will remain in that region. The content that it is stored in a specific region will not leave that region. This means that we can store data in UK Azure Region without any kind of problems. The content will not leave UK Azure Region by magic and to be stored in another region like Germany.
If Azure Regions from that region have technical problems, even going down, our content will not leave that specific country - or Azure Paired Region (based on Azure Services configuration).
A very useful table can be found on the following link, that specifies the paired region for each Azure Region - https://azure.microsoft.com/en-us/documentation/articles/best-practices-availability-paired-regions/. As we can see in the above link, Japan East is paired with Japan West, same country just another location. There are some exception, that will be covered by the next article.
What is happening with our data when it is send from/to Azure Region to on-premises systems
This case is generic for any cloud provider and not specific to Azure only.
All the content that is send by wire from an Azure Region to an on-premises system will go through local ISP's (Internet Service Providers), from that specific countries. This means that content will not leave that specific country as long as the on-premises system is in the same country as Azure Region.
The things become a little more complicated when data goes from one ISP provider to another and so on. We can have ISP providers that might detect that the load on a route that leaves that country and comes back on is better than the one that we have in current country. In this case they can decide to use another route. This means that during the transportation, the content will leave the country. This case can happen inside the same ISP, depending on the routes load and how the balancing is done.
A similar thing happens when for example a main route or a big local ISP provider is down and content is redirected through another routes. For example even if we have a dedicated connection, for example between continental Spain and Grand Canary Islands (that is part of Spain), if this is down data might flow through other routes like Egypt or UK (countries are given only as an example). This means that even if we have a dedicated connection, the content might use another route and leave our country.
For this scenarios, you don't have kind of control. If you have enough resources, you can construct your own line between them, but this is expensive. We should remember that at transport level, we don't have any control on how the ISP sends the content and how the routing is done.
Conclusion
As we saw, controlling the data to not leave a specific Azure Region is easily and can be controlled as Azure Services level. At transport level, things are more complicate and there is no way how you can guaranty this without a dedicated line or custom contracts with ISP providers (when possible).
Part 1 - (Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 2 - (Part 2) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 2 - (Part 2) Things that we should consider when the content stored in Azure shouldn't leave a specific country
In this post we will talk about what is happening with data that is transmitted between Azure Regions and on-premises systems.
Context
Nowadays, Microsoft is opening more and more data centers around the glob. Regions like Japan, UK (to be announced), Brasil, Germany, Korea are already in-place or will be in-place soon.
This specific countries have laws that requires for specific industry or data to not leave the country. Especially in health-care industry it is common to have a restriction that patient information to not leave the country in any moment in time. Similar laws are for other industries like banking or data protection.
In this context we need to be aware of this laws, what kind of solutions we propose and what is happening with the content that is transmitted between Azure Regions and on-premises systems.
The main purpose of this article is to cover what is happening with content that is transmitted between Azure Regions and on-premises system and things that we should be aware. Another article will cover about different configuration of our Azure Services that might affect us.
What is happening with our data inside an Azure Region
Assumption: We don't take into account different Azure Service configurations that might move data to another regions. We assume that customer didn't configure the Azure Service to back-up or replicate content in another Azure Regions.
All the data that we store in an Azure Region will remain in that region. The content that it is stored in a specific region will not leave that region. This means that we can store data in UK Azure Region without any kind of problems. The content will not leave UK Azure Region by magic and to be stored in another region like Germany.
If Azure Regions from that region have technical problems, even going down, our content will not leave that specific country - or Azure Paired Region (based on Azure Services configuration).
A very useful table can be found on the following link, that specifies the paired region for each Azure Region - https://azure.microsoft.com/en-us/documentation/articles/best-practices-availability-paired-regions/. As we can see in the above link, Japan East is paired with Japan West, same country just another location. There are some exception, that will be covered by the next article.
What is happening with our data when it is send from/to Azure Region to on-premises systems
This case is generic for any cloud provider and not specific to Azure only.
All the content that is send by wire from an Azure Region to an on-premises system will go through local ISP's (Internet Service Providers), from that specific countries. This means that content will not leave that specific country as long as the on-premises system is in the same country as Azure Region.
The things become a little more complicated when data goes from one ISP provider to another and so on. We can have ISP providers that might detect that the load on a route that leaves that country and comes back on is better than the one that we have in current country. In this case they can decide to use another route. This means that during the transportation, the content will leave the country. This case can happen inside the same ISP, depending on the routes load and how the balancing is done.
A similar thing happens when for example a main route or a big local ISP provider is down and content is redirected through another routes. For example even if we have a dedicated connection, for example between continental Spain and Grand Canary Islands (that is part of Spain), if this is down data might flow through other routes like Egypt or UK (countries are given only as an example). This means that even if we have a dedicated connection, the content might use another route and leave our country.
For this scenarios, you don't have kind of control. If you have enough resources, you can construct your own line between them, but this is expensive. We should remember that at transport level, we don't have any control on how the ISP sends the content and how the routing is done.
Conclusion
As we saw, controlling the data to not leave a specific Azure Region is easily and can be controlled as Azure Services level. At transport level, things are more complicate and there is no way how you can guaranty this without a dedicated line or custom contracts with ISP providers (when possible).
Part 1 - (Part 1) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Part 2 - (Part 2) Things that we should consider when the content stored in Azure shouldn't leave a specific country
Comments
Post a Comment