Azure – Networking – Part 16 – Azure Virtual Network (VNet) peering
I hope you all are doing good 🙂 .Today let’s discuss one more important service ” VNet Peering ” provided by Microsoft Azure. In this article we will go through the basics concept of VNet Peering and will try to keep this article small. In next article we will go through one small use case and will see how to configure a VNet Peering . So Let’s Start 🙂
Tool Installation Articles :
- Configure Azure Command Line Interface ( Azure CLI) On Windows
- Configure PowerShell For Microsoft Azure Az Module On Windows
Previous Azure Series :
- Learn Basics Of Azure Networking In 100 Hours
- Learn Basics Of Microsoft Azure Storage services
- Learn Basic Of Azure Active Directory And Azure Identity And Access Management
- Azure DevOps – Learn at one place
- Learn Basics Of Lift-And-Shift Migration To Azure
If you have missed our previous articles on networking, please check them in following links.
Part 17 – VNet Peering 2 – Hub-spoke VNet topology
Next Article : Part 18 – Azure Traffic Manager 1
Virtual network (VNet) peering :
Virtual network peering enables us to seamlessly communicate with Azure virtual networks. Once peered, the virtual networks appear as one, for connectivity purposes. The traffic among virtual machines in the peered virtual networks is routed through the Microsoft backbone infrastructure, much like traffic is routed between virtual machines in the same virtual network, through private IP addresses only.
VNet Peering Types :
1) Default VNet peering – Connecting VNets within the same Azure region.
2) Global VNet peering – Connecting VNets across Azure regions.
Benefits Of VNet Peering :
- Network traffic between peered virtual networks is private. No public Internet, gateways, or encryption is required in the communication between the virtual networks. Traffic between the virtual networks is kept on the Microsoft backbone network.
- Established a low-latency, high-bandwidth connection between resources in one virtual network with resources in a different virtual network .
- VNet Peering enable to transfer data across Azure subscriptions, deployment models, and across Azure regions.
- Downtime not required to resource in either virtual network configuring the peering.
- Cost and time savings by centralizing services that can be shared by multiple resources residing in different VNet.
Requirements And constraints:
- The virtual networks we are peering must have non-overlapping IP address spaces.
- Resources in one virtual network cannot communicate with the front-end IP address of a Basic internal load balancer in a globally peered virtual network .
- We can’t add address ranges to, or delete address ranges from a virtual network’s address space once a virtual network is peered with another virtual network.
- A peering is established between two virtual networks. Peering is not transitive.
- There is a nominal charge for ingress and egress traffic that utilizes a virtual network peering.
Permissions To Configure VNet Peering:
To configuring one Virtual Network peering, the user account must be assigned to Network Contributor (for RM resource) or Classic Network Contributor (for classic resource). We can also create and assign a custom role, which assigned with following appropriate actions.
CLI Command To Manage VNet Peering :
- az network vnet peering create
- az network vnet peering list
- az network vnet peering show
- az network vnet peering update
- az network vnet peering delete
PowerShell Command To Manage VNet Peering :
Hub and Spoke VNet Peering Use case :
Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Shared services are placed in the hub VNet, while each environment is deployed to a spoke VNet to maintain isolation. We can design each environment as one spoke. Resources under different spokes VNet can communicate with each other, if they are peered with Hub VNet without peering with each other because, Hub VNet has option to forward/ redirect traffics to respected spoke VNet. Also spoke VNet can access to shared services deployed on Hub VNet. So all Spoke VNet can be peer with Hub VNet and share all required services. To maintain security we can put Hub VNet in DMZ zone.
I hope this article gives a basic idea of VNet Peering and in next article we have discussed, how to configure VNet Peering to address one use case. My next article of this series is Part 17 – VNet Peering 2 – Hub-spoke VNet topology .
Next Article : Part 18 – Azure Traffic Manager 1
Keep reading, share your thoughts, experiences. Feel free to contact us to discuss more.
If you have any suggestion / feedback / doubt, you are most welcome. Stay tuned on Knowledge-Junction, will come up with more such articles
Thanks for reading 🙂