Welcome back readers. In this post I am going to talk about how to communicate across multiple Azure Virtual Networks. I will mostly focus on Azure Virtual Network (VNet) Peering. I will also talk about why you need multiple VNets in the first place and when does this make sense. Also I will briefly talk about the hub and spoke topology. Before I jump into all these details, let me briefly explain what is a virtual network with respect to Microsoft Azure.

Azure Virtual Network – A Quick Introduction

An Azure Virtual Network is an isolated network within the Microsoft Azure cloud. In other words, VNet is the fundamental building block for your private network in Azure. Or in more simpler terms, it is your private network in the cloud.
You can use VNets to provision and manage virtual private networks (VPNs) in Azure. Optionally, link the VNets with other VNets in Azure, or with your on-premises IT infrastructure to create hybrid or cross-premises solutions. You also have control of DNS server settings for VNets, and segmentation of the VNet into subnets.

VNets can be used to –

  • Create a dedicated private cloud-only VNet. As a result, your services and VMs within your VNet can communicate directly and securely with each other in the cloud.
  • Securely extend a data center, by building traditional site-to-site (S2S) VPNs, to securely scale capacity
  • Deploy hybrid clouds by securely connecting cloud-based applications to on-premises systems
Azure Virtual Network Architecture
Source: docs.microsoft.com

The above diagram shows a typical architecture of a virtual Network for n-tier application architecture. The entire virtual network has been subdivided into different subnets. This is based on workloads like web tier that contains the User interface, the Business tier that operates the business logic and data tier that hosts the data source.

The idea to create and bind each group of Virtual machines into different subnet is useful in a way that we can assign one Network Security Group (NSG) to each subnet. Thereby can control the traffic flows between the tiers. For example, an HTTP request from the internet should not directly reach to data tier subnet. We can assign access policy to the NSG of Subnet attached with data tier which only allows incoming requests from business tier subnet.

Now, any other requests trying to reach data tier with any protocol other than business tier will be denied. Similarly, we can assign an access policy on NSG of business tier subnet that the incoming request source IP address should fall in the range of web tier subnet. Additionally, we can also control the traffic requests to the Active Directory by putting that in a separate Subnet inside a Virtual Network.

Why Use Multiple VNets

So the question arises that why would one use multiple VNets? Well, there are several reasons and scenarios. Let’s evaluate a few –

  • Requirement to place VMs in separate Azure locations. VNets in Azure are regional. Therefore, for each VM in separate regions, you need at least one VNet
  • Saving Cost. If you are using a network virtual appliance, the licenses for those can be often expensive. So, one design would be to only have one instance of that Network Virtual Appliance and share its capabilities across multiple VNets. This process is called service chaining
  • Requirement to segment workload. You can create separate VNets, that even use the same IP address spaces, to isolate different workloads from one another
  • Avoiding platform limits. You cannot have more than 2048 VMs in a single VNet. Keep in mind that the limits are per region, per subscription. Therefore you can use multiple subscriptions to increase the limit of resources you can maintain in Azure. You can use a site-to-site VPN, or an ExpressRoute circuit, to connect VNets in different subscriptions
Connecting Multiple VNet: Using VPN Gateways

Before I jump to VNet peering, let me touch upon VPN gateways. A virtual private network, VPN, represents a secure connection over an unsecure medium. Azure site-to-site VPNs and VNet-to-VNet VPNs, use Internet Protocol Security, Internet Key Exchange, IPSec/IKE tunnels. These are industry-standard protocols. The VNet-to-VNet VPN at one time was the only way to link two virtual networks which were in separate Azure regions. Now that’s not a limitation anymore thanks to Global VNet peering.

However, you may have a business case where you do need to create more isolated and administratively separated boundaries between different VNets within the same region or across multiple regions. This can support cross-region geo-redundancy. It will also provide replication in a secure fashion. This is because that channel is not only within the Azure network backbone, but it’s also being protected through a VPN encrypted tunnel. No traffic crosses the public internet and, of course, private IP addressing.

Now there are a couple of things to keep in mind when evaluating the VPN option. Firstly, it has a different pricing model from VNet peering. Establishing a VNet-to-VNet VPN is going to involve a separate VPN gateway in each VNet. Each of those is going to cost. Whereas a peering relationship does not have any cost overhead associated with it. Secondly, and this pertains to peering as well, make sure that your VNet address spaces do not overlap. Whenever I work with my customers, I always stress this point, not only for hybrid cloud but for multiple VNets too. The Global VNet peering option means that we no longer need a VPN gateway for cross region connectivity.

Connecting Multiple VNet: Using VNet Peering

So, what is network peering. Peering is a seamless connection between two Azure virtual networks. And logically, the peered networks appear as one for connectivity purposes. Note that the name resolution does not flow through the peering relationship. This means that we’re going to need to create a private Azure DNS zone as part of our work.

Azure has two types of network peering –

  • Virtual network peering: Connect virtual networks within the same Azure region
  • Global virtual network peering: Connecting virtual networks across Azure regions

Some of the benefits of using virtual network peering, include:

  • Low-latency, high-bandwidth connection between resources in different virtual networks
  • Resources in one virtual network can communicate with resources in a different virtual network
  • Transfer data between virtual networks across Azure subscriptions, Azure Active Directory tenants, deployment models, and Azure regions
  • Peer virtual networks created through the Azure Resource Manager
  • Peer a virtual network created through Resource Manager to one created through the classic deployment model
  • No downtime to resources in either virtual network when creating the peering, or after the peering is created
VNet Peering: Hub and Spoke Topology
Source: docs.microsoft.com

Let’s try and understand the VNet peering through the hub-and-spoke topology. It is a common businesses scenario to have multiple VNets. And those VNets communicate among each other. Let’s take a look at this scenario. Here we have an on-premises network with a physical VPN gateway. In this example we’re using ExpressRoute, but we also could use a site-to-site VPN over the internet. We have a gateway subnet in our hub or transit virtual network that provides the termination of that secure link.

We have a separate management subnet. And we may have a network virtual appliance as well. In this simplified topology, though, we have two spoke networks. We also have a peering relationship between them. The point here is that, you can have a one-to-many relationship between virtual networks. The hub virtual network has 2 peering relationships with Spoke 1 and Spoke 2. We’re keeping things simple here. But understand that you would need to create user-defined routing tables for the Spoke 1 and Spoke 2 subnets. This is required in order to force them to forward traffic into your transit network, through a network virtual appliance. And then through the gateway to on-prem.

To Conclude…

I hope through this post I was able to touch upon the concept of Azure Virtual Network, VNet Peering and touch upon the architecture of a hub and spoke topology. Next, I will post a tutorial on how to configure VNet peering in Microsoft Azure.

Until next time, take care and stay safe.

Also read about Azure DevOps Deployment Patterns.