Azure Virtual Network Peering Connection
Virtual network peering enables you to seamlessly connect two or more Virtual Networks in Azure. The virtual networks appear as one for connectivity purposes. The traffic between virtual machines in peered virtual networks uses the Microsoft backbone infrastructure. Like traffic between virtual machines in the same network, traffic is routed through Microsoft's private network only.
Deployments
50
Made by
Massdriver
Official
Yes
No
Compliance
Clouds
Tags
Azure-Virtual-Network-Peering Operator Guide
Azure Virtual Network Peering enables seamless connectivity between two or more Azure Virtual Networks. Azure Virtual Network Peering is designed to enable network migration, multi-region connectivity, and multi-subscription configurations.
Use Cases
Network Migration
Peering can facilitate a smooth network migration by allowing services to be moved from the old virtual network to the new virtual network over time while maintaining connectivity.
Multi-Region
Azure supports Global Virtual Network Peering, which enables the peering of virtual networks across Azure regions.
Multi-Subscription
Azure Virtual Network Peering supports connectivity across different Azure subscriptions and even across Azure Active Directory tenants.
Design
This bundle is tailored for two scenarios:
- Peering two Virtual Networks, both of which are provisioned by Massdriver and in the same Azure subscription.
- Peering two Virtual Networks, only one of which is provisioned and managed by Massdriver.
Both Virtual Networks in the Same Subscription Provisioned by Massdriver
In this case, both Virtual Networks are managed by
Massdriver and are in the same Azure subscription.
Users should connect both Virtual Networks to the
bundle (one to
accepter
and the other
to requester
). It
doesn’t matter which network is the accepter or
requester; they are functionally equivalent. The
bundle will handle all the necessary configurations,
including establishing the peering connection and
syncing the connection.
Virtual Networks in Separate Subscriptions, or Only One Managed by Massdriver
In this case, the bundle will use the
requester
connection
only. You’ll need to specify additional field for
“Remote Virtual Network ID” to initiate the peering
correctly. No additional manual steps will be
necessary in the Azure portal to complete the
peering process.
Steps to Manually Accept Peering Connection
-
Log into the Azure portal for the
accepter
subscription. - Navigate to the Virtual Network Overview page.
-
Choose
JSON View
in the top right corner. -
Copy the
id
value near the top (without quotes). For example:/subscriptions/123456-1234-1234-1234-12345678/resourceGroups/foo-bar/providers/Microsoft.Network/virtualNetworks/foo-var-vnet
-
Paste the
id
into theRemote Virtual Network ID
field in the bundle and deploy - Navigate to the Virtual Network Peerings page.
- Click on the peering connection.
-
Click
Resync
andSave
.
FAQ
Can my address spaces overlap?
No, they cannot overlap. By default, the Azure Virtual Network bundle uses our Auto-CIDR feature to provision your VNet and using an address space that does not overlap with any other address space for any other VNet in the same subscription. If you are using a custom CIDR, you will need to ensure that the address spaces do not overlap.
If you are peering your VNet to a VNet that is not managed by Massdriver, you’ll need to ensure that the address space for each VNet does not overlap.
I’m trying to peer VNets across subscriptions, but I’m getting an error.
If you are peering VNets across subscriptions, you’ll need to ensure that Microsoft Entra B2B collaboration is configured.
Variable | Type | Description |
---|
| accepter_vnet_id | string | IMPORTANT: Only set this value if you haven’t connected a remote “accepter” VNet to the bundle. If an accepter VNet is connected, this field is ignored and the value will be extracted from the connection. Use this field if the remote VNet isn’t managed by Massdriver or exists in a different subscription than the requester VNet. The CIDRs of the requester and accepter VNets must not overlap. This will require you to resync the peering connection of the accepter VNet manually (instructions in bundle Guide)! |