2. Localized network egress as close to the user as possible
To enable your user’s traffic to take full advantage of Microsoft’s global network, ideally, we’d want their traffic to egress locally and thus peer onto Microsoft’s network as quickly and as closely as possible. However, backhauling to a centralized internet egress is common for companies to allow consolidation network pipes and security equipment such as firewalls and proxies. This policy is completely understandable for an organization with many sites to manage, however for SaaS services, local egress becomes more important and it may be time to assess whether the current design for accessing the web, is still valid and optimal as we move to the cloud.
Using a centralized egress for all office locations in a single small/medium sized country is still a valid approach but we would want to ensure the latency to the egress is as short as possible, and if local egress is possible (even if just for Office 365 traffic) then this approach should be investigated for feasibility.
For example, your EMEA corp HQ in London may host the internet egress for all UK sites, and as long as the connectivity to this egress is optimal, and we’ve optimized the connectivity from there to Microsoft’s network, including peering then performance should be excellent.
However, using this egress for the customer’s EMEA sites in Athens, and Lisbon, may see the latency to the egress be higher than optimal and thus a local egress should be considered at these sites. The same goes for larger countries such as the USA.
Take the example below, Contoso has three sites in San Francisco, New York and Head Office in Chicago. The yellow line represents local egress locations and the red line Contoso’s WAN. Contoso has always used a centralized egress in the Chicago office, relying on the WAN to backhaul traffic to this location to go out to the internet.
As Contoso is using its WAN to backhaul Office 365 traffic to its Chicago site to egress, this may cause the San Francisco site to have longer than necessary latency to its services, in this example the active endpoint is on the west coast (Quincy) and as such the traffic from San Francisco has to traverse the WAN to and from Chicago and Microsoft have to traverse to and from there to Quincy.
What may make sense with regards Office 365 traffic is to utilize a local egress on the west coast and use the Head Office site for New York’s egress but ideally, we’d opt for the local egress model per site and allow Microsoft to do the backhaul as shown in the following diagram. As each site has local internet access each site can peer with Microsoft’s network locally and latency is kept low whilst local optimizations can occur.
In summary, getting your traffic out locally is the advised methodology which allows Microsoft to backhaul & optimize from a location close to the user. Some consolidation of egress locations makes logical and financial sense, but care should be taken to ensure unnecessary latency isn’t added by having the egress too far away from the user location. Tools such as psping can be helpful in accurately measuring latency.