Does data going to M365 count as Internet egress bandwidth in Azure?

I do get asked from time to time from customers if they should account for usage of Microsoft 365 services in an Azure Virtual Desktop environment towards their Internet egress traffic estimations.

Afterall, a new customer deployment may have hundreds or even thousands of users running M365 desktop apps in an Azure Virtual Desktop environment and that could potentially be a lot of egress traffic leaving those hosted desktops from apps like Outlook, Onedrive/Sharepoint sync clients and Teams.

I had seen conflicting reports on this online mostly based on assumptions I suspect but I have never been able to find an official and conclusive answer from Microsoft. I even reached out to a member of the Azure networking product team and was told that it would be just treated as any other Internet traffic.

This didn’t really tally with what I’ve seen previously and I thought this was one of those situations where there is an easy enough way to find out.

The test

The easiest method that I could think of was to just create a virtual machine running a Windows OS and then connect Onedrive to an account. I simply created some test data of 200GB in size and synced this with the Onedrive service. In other words, I uploaded 200GB of data from an Azure virtual machine to Microsoft 365 Onedrive storage. This would bring me over the 100GB free monthly allowance for Internet egress and therefore potentially generate some Internet egress charges.

Here’s the important bit. I deployed my virtual machine in the North Europe region (which is based in Ireland) and the Microsoft tenant that I used for my test was also registered to Ireland. The country you choose here is a choice that you make when you first create your Microsoft customer tenant and this cannot be changed later. This country determines the “default geography” of your tenant which pins your data to a specific geographic region, in my case the European Union region.

Microsoft list the data center locations for each region and in my case these are listed as the following:

European Union

Austria (Vienna), Finland (Helsinki), France (Paris, Marseille), Ireland (Dublin), Netherlands (Amsterdam), Sweden (Gävle, Sandviken, Staffanstorp)

The result

After waiting a few days for the cost management service to receive the usage telemetry the result was that no Internet egress bandwidth had been used and therefore no charges incurred.

This didn’t surprise me a whole lot as I was expecting the Irish data center to most likely be the primary host location for my Onedrive data. This would mean my Azure virtual machine and Onedrive data are effectively hosted in the same region and data transfer between the two service does not egress via the Internet or generate any data transfer chargers for that matter. At least it is not picked up as such by Azure.

I decided to check what would happen if my virtual machine happened to be in a different geography than my tenant, such as one of the US regions.

I just repeated the same test except this time I deployed the virtual machine into one of the Azure regions based in the US and waited for the results.

Sure enough, this did show up as intra-continental data transfer and I was charged accordingly so in this case it counts as Azure to Azure data transfer which is a lot cheaper per gigabyte than Internet egress.

Conclusion

So to answer to the question: Does data going to M365 count as Internet egress bandwidth in Azure?

The answer is: No, but it may count as data transfer to another Azure region.

It really depends on the data locations that you are using for Azure and your tenant’s default geography and large customers can even avail of a multi-geo data location architecture for Microsoft 365 now.

I reported my findings back to the Azure product team and they did in fact confirm the same that “in most cases, traffic from your Azure VNet to Office 365 stays within the region”.

I hope this helps some of you out there who may have also been struggling to find a clear answer on this one.