Q: How does the Windows Azure ExpressRoute differ from the current site-to-site VPN solution?

A: Within Windows Azure, virtual networks are created which contain virtual subnets into which virtual machines (VMs) are placed. The high level sequence of operations goes like this:

  1. Create an affinity group in a Windows Azure region.
  2. Create a virtual network in the affinity group.
  3. Create a new cloud service in the affinity group.
  4. Create VMs in the new cloud service and the virtual network/virtual subnet.

 All VMs within a virtual network can communicate even if the VMs are in different cloud services. Prior to ExpressRoute, the only way to connect the Windows Azure virtual network to your on-premises datacenter was through the Site-to-Site (S2S) IPSEC-based VPN gateway, which at time of writing allows a single S2S VPN Gateway for each virtual network to a single datacenter (see screen shot below).

The challenge is that, because only one VPN gateway is supported, if an organization has multiple datacenters, only one can be connected to the Windows Azure virtual network while all other datacenters would have to communicate to the Windows Azure virtual network via the one connected datacenter.

Additionally the maximum possible speed is 100 Mbps, although I tend to see figures closer to 80-90 Mbps.

Another concern is that the communications between on-premises and Windows Azure takes place over the Internet (even those it's encrypted). A Point-to-Site (P2S) technology is also available. However, that only gives a specific machine connectivity to the Windows Azure virtual network and is not a site communication solution.

 

ExpressRoute completely changes this with two different models that both leverage private connections between Windows Azure and your on-premises infrastructure.

The first model is via an Internet Exchange Point (IXP), a point where multiple ISPs such as Verizon and AT&T interconnect their networks. Sometimes they're called a fiber (fibre) hotel.

Windows Azure is now adding direct connections to some IXP partners, which then connect directly into the Windows Azure fabric. At time of writing, Equinix is a partner for this type of connectivity. Organizations can use this in one of two ways:

  • Organizations can place their servers directly at the IXP location (like a hosting location).
  • Organizations can run a fibre connection from their location(s) to the IXP, which then connects to Windows Azure.

Organizations connect to their Windows Azure subscription and can then pick which specific virtual networks should be routable within the subscription.

 

The other model leverages an organization's existing network service provider WAN connectivity. such as Multiprotocol Label Switching (MPLS) , which connects all the locations of an organizations through the MPLS "cloud."

In this model, Windows Azure becomes part of the customer's WAN for seamless connectivity to their subscription, as you can see in the illustration below. AT&T is a partner for this type of connectivity, at time of writing.

 

A key point is none of the ExpressRoute connections are via the public Internet. Only private connections and much higher speeds are available. Different speed options are available for different costs; however, the IXP-based offering will be capable of 10 Gbps connectivity, while the WAN offerings (MPLS) will be capable of 1 Gbps.

Although the number of partners is limited at time of writing, this is expected to grow over time, offering organizations more options to how they connect to Windows Azure from their on-premises environments. Some good information can be found in these Microsoft resources:

Also, the presence of ExpressRoute doesn't mean that Microsoft isn't contining to improve its Site-to-Site VPN solution. The ExpressRoute solution won't be practical for many organizations and they will continue to rely on the Site-to-Site VPN for their connectivity between on-premises and Windows Azure.