Hey Microsoft Azure, where is my data?

Before the public cloud was such a prevalent service, I spent most of my days (and evenings) building On-Premises solutions. Ordering racks and servers for those racks, planning to cable, and finally installing and configuring everything was very tangible. You would know exactly where the servers were, and you knew precisely the location of your data. “The data for this service is in the basement of this building,” I would say.

Not so much today. With ubiquitous Internet access, competent replication software and services, and cheap cloud computing, you think you know precisely where your data is. “Why yes, my data is in West Europe datacenter of Azure.. near Amsterdam, I think.”

I’ve had a few customers query me about whether their data is where its supposed to be – and also if there are edge cases, or special cases that they should consider. I wrote this blog post to partially address those questions, but also to allow me to learn more about this topic.

So, where IS my data?

Let’s begin by checking where our data resides in Azure. As you might know, Azure consists of many geographies, such as Europe, Africa, and the United States. These regions – about 66 of them currently – then have one or multiple locations – such as West Europe and North Europe as part of Europe. You can view the current map of the geographies here.

For each region, you have a set of products that are available. Usually – the thinking goes – that all mature regions have all the services Azure has to offer. To verify what services and products are available for a given region, see here.

So, where IS my data? The answer depends on which regions you are currently utilizing. As an example, I’m using West Europe and North Europe for my Azure deployments. My data resides in Ireland and the Netherlands. You can this data residency information here.

As another example, If I’m utilizing just West US, then my data will be in California.

So far, I feel this is all very clear and easy to document – the region you choose to utilize, drives the location of your data. But wait, there’s more.

Azure AD is special

In certain cases, data is also residing outside your chosen region. I’m specifically looking at the EU regions here, together with Azure AD.

Azure AD is one of the key services in Azure deployments, as it hosts all your identities, relevant settings, and licenses. So if we deploy a service in West Europe, where is Azure AD? To look this up, Microsoft has a separate page here, and it’s actually a Power BI report.

You choose geo (or geography, which is the concept of having one or more regions in it), such as Europe, and then select the Azure AD sub-services you’d like to look at. We use ‘All’ as the selection:

It’s a lengthy list, mostly repeating the same locations over and over again. I’ve outlined the outliers in red – Azure AD B2B and Azure AD MFA both utilize services in the US – specifically from Virginia, Washington, Wyoming, and Texas.

But why is this? We’ve specifically desired to use West Europe, for example, yet some of our data might be in the US? Someone might think about GDPR at this point. Further explanation is documented here, and I’m quoting:

Multi-factor authentication using phone calls originate from US datacenters and are routed by global providers
Multi-factor authentication using SMS is routed by global providers.
Multi-factor authentication requests using the Microsoft Authenticator app push notifications that originate from EU datacenters are processed in EU datacenters.
Device vendor-specific services, such as Apple Push Notifications, may be outside Europe.
Multi-factor authentication requests using OATH codes that originate from EU datacenters are validated in the EU.Source

In addition, enterprise applications that are defined in Azure AD have certain settings stored in the US – at all times. Azure AD B2C policy configuration data and Key Containers are also stored in the US. Finally, invitations (and redeem links) to Azure AD B2B are stored in the US. Certain B2B invitation emails might originate from the US.

That feels like plenty of data travels from my EU-based region to the US. Thankfully, this is well documented – but the inherent way how Azure-services are provisioned does not makes this obvious:

In the image above I’ve listed a few of my Azure resource groups, and they are all based in West Europe. But they all also rely someway or another on Azure AD – and certain data of Azure AD might be stored in the US in return.

Some additional information is listed here, and it also lists certain exemptions from the “your data is only the geo you specify” – this includes services such as Azure Sentinel and previews or beta features.

So, I ask you again – where is my data?

According to the documentation provided by Microsoft, your data will reside in the region where you’ve deployed your workloads. But, if you utilize several specific services – of which Azure MFA and Azure AD B2B are worth noting – then you might utilize certain capabilities from US-based Azure locations.

Is this a problem? Yes, if you haven’t recorded and communicated this clearly to your possible (external) users. They might incorrectly assume that all the data they provide – such as personally identifiable information – is stored within the EU. If they receive an Azure AD B2B invitation email that originates from the US, it will pose a possible problem.

I am not a lawyer. Thus I won’t do a disservice to the public to understand how the numerous different legal approaches affect here. But consider it important to map and verify which services you utilize and how they might be storing data outside your region.