We just had Microsoft Build, and there are a ton of announcements to go through and get up to date on. One of the less “fancy” announcements was for routing preferences, which is currently in preview. You can read the official documentation here.
Routing preferences now allow customers to chose how to handle routing between Azure and their clients using Azure services. It brings forward two BGP routing concepts, cold-potato routing vs hot-potato routing.
In cold-potato routing, the Azure network will handle traffic as long as possible before handing over the packets to another ISP or service provider. This is the default way that traffic works in Azure.
It is important to note that this behaviour occurs on both the ingress traffic and the egress traffic. So, a client in region 2 trying to access an Azure service in region 1 will communicate with the closest point of presence (POP). The rest of the traffic will be handled by Azure.
In hot-potato routing (from the perspective of Azure), the Azure network will handle traffic as little as possible, relying on other networking constructs to do the majority of the “work”.
Technically, this all boils down to how routes are advertised, and how ISPs make decisions on routing traffic between BGP networks.
Adding these type of networking preferences to Azure allows customers to have more control over how traffic flows to and from their Azure services. One benefit that I can see is when customers pair Azure services, such as apps behind application gateways, with 3rd party CDN/WAF providers, such as Imperva. Currently, traffic likely looks like the following.
As you can see from the image above, because Azure is in cold-potato mode, it will advertise routes through all of it’s POPs. The routing from the Imperva standpoint won’t be very complex. It will provide it’s caching/WAF, but you won’t really be using it’s network to get traffic around the globe.
The routing preference documentation makes numerous claims about the benefits of the Microsoft backbone over any others. However, companies may have already invested in other networking constructs, such as 3rd party CDN and WAF providers.
To me, the benefits break down like this:
This service is currently in preview, so you will need to check the docs to see if the service/region combination you want to use is supported. You can review the docs here to get started configuring a VM with routing preferences via powershell. It would be interesting to compare latencies/etc across the two methods.