VNET peering is a great feature for Azure customers and it’s worth taking the time to understand how it works. This blog post will go into detail about what VNET peering is, why you would want to use this capability and some best practices that you should follow when setting up your VNETs for peering.
VNET peering is a great feature for Azure customers and it’s worth taking the time to understand how it works. This blog post will go into detail about what VNET peering is, why you would want to use this capability and some best practices that you should follow when setting up your VNETs for peering.
VNET peering is a feature of Azure that allows you to create a direct connection between two Virtual Networks. This means you can connect virtual machines from different VNETs on the same network domain and they will be able to communicate with each other as if they were connected by a physical or wireless link. The security boundary for your customer’s virtual machines remain in place and the communication between virtual machines from separate VNETs is secure.
VNET peering can be useful if you want to connect two Azure Virtual Networks that are located at different geographical locations of your company’s data centre or local region. You might also use it as a way to test some new services on pre-production environments and then roll them out to production.
VNET peering is not a replacement for ExpressRoute in Azure, it’s just another way of connecting Virtual Networks together if you need this feature. It can also be used as an alternative solution when connecting on-premise VNETs with your Azure resources because the only requirement for using this capability is a VPN Gateway connection.
The process of peering virtual networks is very simple and you can be up and running in a few minutes, however, it’s important to understand the networking implications before enabling this feature on your Azure infrastructure. If you configure VNET Peering properly then there shouldn’t be any problems but if something goes wrong with your configuration then it can lead to some serious problems.
Why Do I need VNET Peering?
There are many reasons why you might want to use VNET peering in Microsoft Azure. For example, you might want to create a connection between two virtual networks that are located in different geographical locations of your data centre because this will allow the Virtual Machines from these VNETs to communicate with each other as if they were connected by a physical or wireless link.
Using VNET peering also allows you to share resources across virtual machines that belong to different VNETs. For example, you might want to share storage resources between virtual machines from separate Azure Virtual Networks and this is just one of the many use cases where it can be useful.
Requirements for VNET Peering
The requirements for VNET peering in Microsoft Azure depend on the type of connection that you want to use. The most popular options include Point-to-Site VPN, ExpressRoute and Site-to-Site VPN connection. Point-to-Site VPN is a good choice if you only want to connect two VNETs and the VMs from these networks can communicate with one another as if they were connected by a physical or wireless link. ExpressRoute is useful when you need to connect on-premise Virtual Networks with your Azure resources and this is because it has no requirement other than a VPN Gateway connection. Optionally, you may also use a Site-to-Site VPN if you want to connect two onsite Virtual Networks but in this case, you need to have a site-to-site VPN connection established between your VNETs.
The requirement for using Point-to-Site VPN is that both Virtual Networks must be located in the same region and peering can not be used with virtual networks that are part of different Azure subscriptions or even belong to different customers. Site-to-Site VPN is also available in most regions of Microsoft Azure but it’s important to mention that VNET peering can not be used with virtual networks that are part of different Azure subscriptions or even belong to different customers.