If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
- Microsoft Azure – The Network Operating System of the Future, Today (Part 1) – Why You Should Care
- Microsoft Azure – The Network Operating System of the Future, Today (Part 2) – Dedicated WAN Connectivity with ExpressRoute
- Microsoft Azure – The Network Operating System of the Future, Today (Part 3) – Multi-Site VPN and VNet-to-VNet Connectivity
In Part 3 of our series on what’s new in Microsoft Azure networking, we talked about the site to site VPN capability and how that enables you to connect multiple on-premises sites to an Azure Virtual Network.
In that previous article, you learned that you can now connect not just one, but multiple on-premises sites to an Azure Virtual Network. This solved a big problem for us. Prior to these new capabilities, if you wanted multiple on-premises sites to reach your Azure Virtual Network, you had two choices:
- Make the resources on the Azure Virtual Network available to the Internet so that all your sites could reach those resources through their local Internet connections, or
- Route all requests to Azure Virtual Network situated resources through the single VPN gateway connecting to your Azure Virtual Network.
The first option isn’t a viable one if you don’t want to expose your Azure Virtual Network located resources to the Internet at large. The second option feels somewhat cobbled together, since you have to force Azure Virtual Network destined traffic through your corporate network, which has the potential to add many needless options to reach the intended destination. The addition of multiple gateways fixed that problem and for that we are all thankful.
However (there’s always a “however,” isn’t there?), all of our network routing hopes and dreams are not fulfilled by multiple site to site VPN gateways. There is another networking routing problem that you can run into that might drive you as crazy as the single VPN gateway scenario. That problem relates to how traffic between Azure Virtual Networks (VNets) is routed between those networks.
The VNet to VNet dilemma
Before the recent updates, if you had two Azure Virtual Networks and you wanted resources on each of the Azure Virtual Networks to communicate with each other, you had two options:
- You could route traffic over the Internet, or
- You could route traffic back to the on-premises network and forward it to the destination Azure Virtual Network.
Routing traffic over the Internet
The first option might be a viable solution if you are talking about all public intended network services. However, that’s a pretty unlikely scenario because we’re generally talking about front-end/back-end communications, and you definitely don’t want to make those back-end resources available directly from the Internet.
For example, suppose on one Azure Virtual Network you have some web front-ends that act as part of a multi-tiered line of business application. You want to put those web front-ends on a dedicated Azure Virtual Network because you want that Azure Virtual Network to essentially act as an Internet access DMZ. No problem; you configure the web front-ends in the Azure Virtual Network as endpoints and allow the web traffic to reach them from any system located on the Internet.
The next step is to get information back to the back-ends. The back-end is most likely an application tier that executes some business logic and probably has to reach back to a database tier. You don’t want the application and database tiers on the same Azure Virtual Network for the same reason you don’t put those systems on an on-premises DMZ network. You don’t want to expose that information between the web tier and the back-end tier to the Internet for a number of security reasons. Thus, it looks as if the first option isn’t going to work in most cases.
Forwarding traffic through the on-premises network to the Azure VNet
Luckily, the second option – routing traffic back to the on-premises network and forwarding it to the destination Azure Virtual Network – is a secure option. Here’s what you need to do in order to implement it:
- Create a site to site VPN to both of the Azure Virtual Networks. One of the site to site VPNs will be connected to the front-end web tier and the second site to site connection will be connected to the application tier.
- When a client system connects to the web tier, information gathered by any of the web front-ends is sent to the application tier for processing. In order to do that, it sends the information back through the site to site connection to the on-premises gateway. The on-premises gateway then routes that information back through a second site to site connection that connects to the application tier’s Azure Virtual Network.
- When the application tier sends its response back to the web tier, it sends it back through the site to site connection to the on-premises VPN gateway and then the on-premises VPN gateway forwards the response back to the web tier through the site to site VPN that connects the on-premises gateway to the Azure Virtual Network that hosts the web tier.
Hmm. If you’re thinking that’s an awful lot of forwarding, you’re right. And with all those hops requiring looping-back through the on-premises VPN gateway, you know that you’re going to introduce an inordinate amount of latency, which could have a major negative impact on applications that are latency sensitive.
What was the solution to this problem? The solution was to put the front end and back end tiers on the same Azure Virtual Network and just trust that nothing bad would happen in the event that the web tier servers were compromised. While that was a solution, basing a strategy on the “cross your fingers and pray” model isn’t generally known as a fast track to success.
VNet to VNet connectivity to the rescue
Fast forward to today. This sticky problem is now solved with a new feature included in Microsoft Azure that’s called, appropriately enough, VNet to VNet connectivity. That means that now, if you want resources on different Azure Virtual Networks to communicate with each other, they can do that by communicating directly with one another. There’s no need to put that traffic over the Internet or to loop it back through the on-premises VPN gateway.
The Azure Virtual Networks that you want to connect can be in the same Azure datacenter, or you can create the connections between Azure Virtual Networks that are located in different Azure datacenters in the same region or even in different regions. For example, you might want to put one tier in North America and another in one of the European datacenters. You can do that. Not only that, but you can connect Azure Virtual Networks across multiple subscriptions, including subscriptions that are owned and operated by different companies.
The Azure Virtual Network fabric is very fast, so these communications are going to be high speed connections. That’s going to make it feel as if you’re transferring data across your own datacenter or maybe a hosting site where you have multiple racks that you own.
Before you get too excited and rush out to do this, though, there’s something you need to know. All traffic moving out of your Azure Virtual Network (outbound or “egress” traffic) is charged in the same way as outbound traffic from your Azure Virtual Network to the Internet (or to the Internet and back to your on-premises VPN gateway). With that said, traffic costs are so relatively low, so you probably won’t need to worry too much, but you do need to be aware of this and make sure you do some traffic modeling to get an idea of the potential costs, if for no other reason than you don’t want to be surprised by the bill.
Factors to consider
Of course, every solution has its caveats, as well as some unexpected fringe benefits. Some other factors to consider if you’re planning to connect Azure Virtual Networks to one another over the Azure network fabric include the following:
- While Azure can provide for geo-replicated storage, you can configure multiple Azure Virtual Networks to create a geo-replicated synchronization system. Think of SQL always-on availability. You can stretch your SQL Always-on Availability groups across Azure Virtual Networks located on different continents.
- Remember that whereas it’s possible to create standalone virtual machines that aren’t located on an Azure Virtual Network, VNet to VNet connectivity is not going to work if you don’t put those virtual machines on an Azure Virtual Network.
- The VPN gateways that are used to connect the Azure Virtual Networks together need to be static routing gateways. It’s also possible to have a single Azure Virtual Network connect to your on-premises VPN gateway and a VPN gateway on another Azure Virtual Network. However, in order for that to work, you need the VPN gateway you’re using on-premises to support dynamic routing and the VPN gateways on the Azure Virtual Networks to support dynamic routing. If you currently have a site to site VPN running between the Azure Virtual Network and on-premises and it’s configured as a static gateway, you’re going to have to fix that.
- The maximum number of site to site VPNs that you can create to any site (on-premises or to another Azure Virtual Network) is 10.
- Sorry, you can have only one tunnel. You can’t create redundant tunnels to support high availability (yet). While not available now, given the rapid pace of Azure development, I think it’s only a matter of time before this is supported, as it’s a key enterprise requirement to have redundancy at the network layer.
- If you’re publishing load balanced endpoints, all of the load balanced endpoints need to be on the same Azure Virtual Network. You can’t put some of those load balanced endpoints on one Azure Virtual Network and some on another Azure Virtual Network. In other words, the load balancing algorithm for a cluster of load balanced endpoints won’t stretch across Azure Virtual Networks.
- The Azure VPN gateway is going to have to process all the traffic to and from all of the on-premises and Azure Virtual Networks that are connected to it. Unfortunately, you don’t have any visibility into the Azure VPN gateway to do the kind of performance monitoring you might like to do, so you’ll have to find some other means to determine whether you’re bumping up any kind of traffic jams.
Summary
Prior to the recent updates to Microsoft Azure, the inability to connect Azure Virtual Networks directly to one another led to some workarounds that were less than satisfying and in many cases represented deployment blockers. With the introduction of Azure Virtual Network to Azure Virtual Network connectivity, you can now connect Azure Virtual Networks that belong to the same subscription, to different subscriptions, and even to different organizations. This solves a lot of security and performance issues. In the next installment in this series, we’ll continue to talk about some of the networking improvements in Microsoft Azure. See you then! -Deb and Tom.
If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
- Microsoft Azure – The Network Operating System of the Future, Today (Part 1) – Why You Should Care
- Microsoft Azure – The Network Operating System of the Future, Today (Part 2) – Dedicated WAN Connectivity with ExpressRoute
- Microsoft Azure – The Network Operating System of the Future, Today (Part 3) – Multi-Site VPN and VNet-to-VNet Connectivity
