The content below is taken from the original ( Use Azure ExpressRoute Private Peering & Azure Virtual WAN to Connect Privately to Microsoft 365), to continue reading please visit the site. Remember to respect the Author & Copyright.
Many Office 365 customers want to use Azure ExpressRoute to connect their on-premises network to the Microsoft cloud with a private connection. As you may know, though, Microsoft does not recommend using Azure ExpressRoute with Microsoft Peering to connect to Office 365.
There are several reasons for that, let me point out a few of them:
- Implementing Azure ExpressRoute with Microsoft Peering for Microsoft 365 requires a highly complex routing configuration.
- It requires the use of public IP addresses that customers own for the peering.
- Azure ExpressRoute is normally working against the Microsoft global edge network distribution policy and breaks redundancy, as an ExpressRoute is only deployed within one location.
- Egress costs have a high-cost implication on Azure consumption. When using Microsoft Teams, you will have high egress data.
- Cost and scalability are usually not comparable to premium Internet connections.
You can get an overview of the different ExpressRoute circuits in the chart below, where “Microsoft Edge” describes the edge routers on the Microsoft side of the ExpressRoute circuit:
Why you may want to use Azure ExpressRoute to connect to Microsoft 365
There may be various customer scenarios where you need to use Azure ExpressRoute with Microsoft Peering enabled to connect to Microsoft 365 services. Here are two examples:
- A customer is in an area where regular Internet connections are not available to connect to Microsoft 365, such as China.
- A customer is in a highly-regulated environment.
There is still the option to request Subscription Whitelisting to connect to Microsoft 365 via Azure ExpressRoute, but doing so does not remove the limitations and complexities we’ve highlighted earlier.
However, there’s actually an alternative that enables customers to use Azure ExpressRoute with Microsoft Private Peering all while keeping costs down and enabling redundancy. To accomplish that, we’ll need to use a default behavior from the Microsoft Global Network in combination with some Microsoft services.
Microsoft services traffic is always transported on the Microsoft global network, as explained in the company’s documentation:
Whether connecting from London to Tokyo, or from Washington DC to Los Angeles, network performance is quantified and impacted by things such as latency, jitter, packet loss, and throughput. At Microsoft, we prefer and use direct interconnects as opposed to transit-links, this keeps response traffic symmetric and helps keep hops, peering parties and paths as short and simple as possible.
So, does that mean all traffic when using Microsoft services? Yes, any traffic between data centers, within Microsoft Azure or between Microsoft services such as Virtual Machines, Microsoft 365, Xbox, SQL DBs, Storage, and virtual networks are routed within our global network and never over the public Internet, to ensure optimal performance and integrity.
The technologies required in the solution we mentioned earlier include:
- Azure ExpressRoute Local
- An Azure Virtual WAN secured hub with Azure Firewall or with a managed security network virtual appliance
- A Firewall appliance that is capable of service-based routing on-premises
I’ll be explaining this solution in greater detail in the next segment.
Solution architecture
The architecture in this solution is quite simple: You need to deploy an Azure Virtual WAN Hub with Azure Firewall to make it secure and to use it as an Internet access point.
Then, you’ll need to deploy an Azure Virtual WAN ExpressRoute gateway into the virtual WAN connection, connect your ExpressRoute Local to the gateway, and secure your Internet for that ExpressRoute. Doing so will announce a default route (0.0.0.0/0) to your on-premises infrastructure.
On your on-premises infrastructure, you can now set a static route to point to the gateway. You can also leverage newer software-defined WAN (SDWAN) or Firewall devices to use a service-based routing and only send traffic for Microsoft 365 services to our new Azure Secure Virtual WAN Hub.
The diagram below shows what this architecture looks like:
We still have to deal with the fact that an ExpressRoute circuit is not georedundant as it is only deployed in one Edge co-location. To establish the necessary redundancy, you’ll need to build additional circuits.
Implementing redundancy and global deployment
To implement a highly-available architecture and improve latency for your users, you should distribute additional hubs. I would suggest creating ExpressRoute circuits in different local Azure regions such as Germany Frankfurt and West Europe Amsterdam. Microsoft has a dedicated page where you can find all possible Azure locations, and the company also has detailed documentation explaining how to implement redundancy for Azure ExpressRoute.
You have two options from that point on: The first one is to create two separate circuits connected to two separate Azure Virtual WAN hubs, as shown below.
Another option is to interconnect both Virtual WAN hubs, as shown in the schema below:
In the case of inter-hub connectivity, you need to disable branch-to-branch connectivity within the virtual WAN Hub properties. Branch-to-branch is currently not supported when using ExpressRoute Local, so you need to disable it on the Virtual WAN Hub level.
With that architecture, you will get a private, redundant, and high performant connection to Microsoft 365 Services.
I also want to make you aware that Microsoft announced additional security capabilities integrating network virtual appliances into virtual WANs. You can watch the announcement from Microsoft for that solution on YouTube.
Cost Calculation
In this section, I will provide a short cost calculation for this solution. Please be aware that there are two parts of the ExpressRoute Local Service to take into account:
- The Microsoft Service costs
- The data center and/or network service provider costs.
I can only provide you with the Microsoft part of the calculation, as the data center and network service provider costs can vary a lot.
The redundant solution includes the following components:
- Two Virtual WAN Hubs including Azure Firewall
- Two Virtual WAN gateways for ExpressRoute
- Two Azure ExpressRoute local circuits
- Traffic of around 10 TB per hub per month
| Service type | Description | Estimated monthly cost | Estimated upfront cost |
| Virtual WAN | West Europe, Secured Virtual WAN Hub with Azure Firewall; 730 Deployment hours, 10 GB of data processed; Connections | $1.806,74 | $0,00 |
| Virtual WAN | Germany West Central, Secured Virtual WAN Hub with Azure Firewall; 730 Deployment hours, 10 GB of data processed; Connections | $1.806,74 | $0,00 |
| Azure ExpressRoute | ExpressRoute, Zone 1, Local; 1 Gbps Circuit x 1 circuit | $1.200,00 | $0,00 |
| Azure ExpressRoute | ExpressRoute, Zone 1, Local; 1 Gbps Circuit x 1 circuit | $1.200,00 | $0,00 |
| Support | Included | $0,00 | $0,00 |
| Total | $6.013,48 | $0,00 |
You can check out my cost calculation on Microsoft’s Azure website, feel free to use it as an example for your own calculations.
Conclusion
As you can see, it is still possible to use Azure ExpressRoute to connect privately to Microsoft 365 and other Microsoft Cloud services, but it comes at a price. If you require additional security and don’t want a solution that allows routing through the Internet or other carrier networks, you could leverage that solution.
