Create a virtual network peering - Resource Manager, different subscriptions and Microsoft Entra tenants
Article
In this tutorial, you learn to create a virtual network peering between virtual networks created through Resource Manager. The virtual networks exist in different subscriptions that may belong to different Microsoft Entra tenants. Peering two virtual networks enables resources in different virtual networks to communicate with each other with the same bandwidth and latency as though the resources were in the same virtual network. Learn more about Virtual network peering.
Depending on whether, the virtual networks are in the same, or different subscriptions the steps to create a virtual network peering are different. Steps to peer networks created with the classic deployment model are different. For more information about deployment models, see Azure deployment model.
Learn how to create a virtual network peering in other scenarios by selecting the scenario from the following table:
A virtual network peering can't be created between two virtual networks deployed through the classic deployment model. If you need to connect virtual networks that were both created through the classic deployment model, you can use an Azure VPN Gateway to connect the virtual networks.
This tutorial peers virtual networks in the same region. You can also peer virtual networks in different supported regions. It's recommended that you familiarize yourself with the peering requirements and constraints before peering virtual networks.
An Azure account with permissions in both subscriptions or an account in each subscription with the proper permissions to create a virtual network peering. For a list of permissions, see Virtual network peering permissions.
To separate the duty of managing the network belonging to each tenant, add the user from each tenant as a guest in the opposite tenant and assign them the Network Contributor role to the virtual network. This procedure applies if the virtual networks are in different subscriptions and Active Directory tenants.
To establish a network peering when you don't intend to separate the duty of managing the network belonging to each tenant, add the user from tenant A as a guest in the opposite tenant. Then, assign them the Network Contributor role to initiate and connect the network peering from each subscription. With these permissions, the user is able to establish the network peering from each subscription.
An Azure account with permissions in both subscriptions or an account in each subscription with the proper permissions to create a virtual network peering. For a list of permissions, see Virtual network peering permissions.
To separate the duty of managing the network belonging to each tenant, add the user from each tenant as a guest in the opposite tenant and assign them the Network Contributor role to the virtual network. This procedure applies if the virtual networks are in different subscriptions and Active Directory tenants.
To establish a network peering when you don't intend to separate the duty of managing the network belonging to each tenant, add the user from tenant A as a guest in the opposite tenant. Then, assign them the Network Contributor role to initiate and connect the network peering from each subscription. With these permissions, the user is able to establish the network peering from each subscription.
Each user must accept the guest user invitation from the opposite Microsoft Entra tenant.
Azure PowerShell installed locally or Azure Cloud Shell.
Sign in to Azure PowerShell and ensure you've selected the subscription with which you want to use this feature. For more information, see Sign in with Azure PowerShell.
Ensure your Az.Network module is 4.3.0 or later. To verify the installed module, use the command Get-InstalledModule -Name "Az.Network". If the module requires an update, use the command Update-Module -Name Az.Network if necessary.
If you choose to install and use PowerShell locally, this article requires the Azure PowerShell module version 5.4.1 or later. Run Get-Module -ListAvailable Az to find the installed version. If you need to upgrade, see Install Azure PowerShell module. If you're running PowerShell locally, you also need to run Connect-AzAccount to create a connection with Azure.
An Azure account with permissions in both subscriptions or an account in each subscription with the proper permissions to create a virtual network peering. For a list of permissions, see Virtual network peering permissions.
To separate the duty of managing the network belonging to each tenant, add the user from each tenant as a guest in the opposite tenant and assign them the Network Contributor role to the virtual network. This procedure applies if the virtual networks are in different subscriptions and Active Directory tenants.
To establish a network peering when you don't intend to separate the duty of managing the network belonging to each tenant, add the user from tenant A as a guest in the opposite tenant. Then, assign them the Network Contributor role to initiate and connect the network peering from each subscription. With these permissions, the user is able to establish the network peering from each subscription.
If you prefer to run CLI reference commands locally, install the Azure CLI. If you're running on Windows or macOS, consider running Azure CLI in a Docker container. For more information, see How to run the Azure CLI in a Docker container.
If you're using a local installation, sign in to the Azure CLI by using the az login command. To finish the authentication process, follow the steps displayed in your terminal. For other sign-in options, see Sign in with the Azure CLI.
When you're prompted, install the Azure CLI extension on first use. For more information about extensions, see Use extensions with the Azure CLI.
Run az version to find the version and dependent libraries that are installed. To upgrade to the latest version, run az upgrade.
This how-to article requires version 2.31.0 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.
In the following steps, learn how to peer virtual networks in different subscriptions and Microsoft Entra tenants.
You can use the same account that has permissions in both subscriptions or you can use separate accounts for each subscription to set up the peering. An account with permissions in both subscriptions can complete all of the steps without signing out and signing in to portal and assigning permissions.
The following resources and account examples are used in the steps in this article:
User account
Resource group
Subscription
Virtual network
user-1
test-rg
subscription-1
vnet-1
user-2
test-rg-2
subscription-2
vnet-2
Create virtual network - vnet-1
Note
If you are using a single account to complete the steps, you can skip the steps for logging out of the portal and assigning another user permissions to the virtual networks.
Azure deploys resources to a subnet within a virtual network, so you need to create a subnet. Create a subnet configuration named subnet-1 with Add-AzVirtualNetworkSubnetConfig:
az group create \
--name test-rg \
--location eastus2
Create the virtual network
Create a virtual network and subnet with az network vnet create. This example creates a subnet-1 virtual network named vnet-1 in the West US 3 location.
A user account in the other subscription that you want to peer with must be added to the network you previously created. If you're using a single account for both subscriptions, you can skip this section.
Use Get-AzADUser to obtain the object ID for user-2.
user-2 is used in this example for the user account. Replace this value with the display name for the user from subscription-2 that you wish to assign permissions to vnet-1. You can skip this step if you're using the same account for both subscriptions.
user-2 is used in this example for the user account. Replace this value with the display name for the user from subscription-2 that you wish to assign permissions to vnet-1. You can skip this step if you're using the same account for both subscriptions.
In the search box a the top of the portal, enter Virtual network. Select Virtual networks in the search results.
Select vnet-1.
In Settings, select Properties.
Copy the information in the Resource ID field and save for the later steps. The resource ID is similar to the following example: /subscriptions/<Subscription Id>/resourceGroups/test-rg/providers/Microsoft.Network/virtualNetworks/vnet-1.
Sign out of the portal as user-1.
The resource ID of vnet-1 is required to set up the peering connection from vnet-2 to vnet-1. Use Get-AzVirtualNetwork to obtain the resource ID for vnet-1.
The resource ID of vnet-1 is required to set up the peering connection from vnet-2 to vnet-1. Use az network vnet show to obtain the resource ID for vnet-1.
vnetidA=$(az network vnet show \
--name vnet-1 \
--resource-group test-rg \
--query id \
--output tsv)
echo $vnetidA
Create virtual network - vnet-2
In this section, you sign in as user-2 and create a virtual network for the peering connection to vnet-1.
Azure deploys resources to a subnet within a virtual network, so you need to create a subnet. Create a subnet configuration named subnet-1 with Add-AzVirtualNetworkSubnetConfig:
az group create \
--name test-rg-2 \
--location eastus2
Create the virtual network
Create a virtual network and subnet with az network vnet create. This example creates a subnet-1 virtual network named vnet-2 in the West US 3 location.
A user account in the other subscription that you want to peer with must be added to the network you previously created. If you're using a single account for both subscriptions, you can skip this section.
Use Get-AzADUser to obtain the object ID for user-1.
user-1 is used in this example for the user account. Replace this value with the display name for the user from subscription-1 that you wish to assign permissions to vnet-2. You can skip this step if you're using the same account for both subscriptions.
user-1 is used in this example for the user account. Replace this value with the display name for the user from subscription-1 that you wish to assign permissions to vnet-2. You can skip this step if you're using the same account for both subscriptions.
Make note of the object ID of user-1 in field id. In this example, it's ee0645cc-e439-4ffc-b956-79577e473969.
vnetid=$(az network vnet show \
--name vnet-2 \
--resource-group test-rg-2 \
--query id \
--output tsv)
az role assignment create \
--assignee ee0645cc-e439-4ffc-b956-79577e473969 \
--role "Network Contributor" \
--scope $vnetid
Obtain resource ID of vnet-2
The resource ID of vnet-2 is required to set up the peering connection from vnet-1 to vnet-2. Use the following steps to obtain the resource ID of vnet-2.
In the search box a the top of the portal, enter Virtual network. Select Virtual networks in the search results.
Select vnet-2.
In Settings, select Properties.
Copy the information in the Resource ID field and save for the later steps. The resource ID is similar to the following example: /subscriptions/<Subscription Id>/resourceGroups/test-rg-2/providers/Microsoft.Network/virtualNetworks/vnet-2.
Sign out of the portal as user-2.
The resource ID of vnet-2 is required to set up the peering connection from vnet-1 to vnet-2. Use Get-AzVirtualNetwork to obtain the resource ID for vnet-2.
The resource ID of vnet-2 is required to set up the peering connection from vnet-1 to vnet-2. Use az network vnet show to obtain the resource ID for vnet-2.
vnetidB=$(az network vnet show \
--name vnet-2 \
--resource-group test-rg-2 \
--query id \
--output tsv)
echo $vnetidB
Create peering connection - vnet-1 to vnet-2
You need the Resource ID for vnet-2 from the previous steps to set up the peering connection.
az network vnet peering list \
--resource-group test-rg-2 \
--vnet-name vnet-2 \
--output table
The peering is successfully established after you see Connected in the Peering status column for both virtual networks in the peering. Any Azure resources you create in either virtual network are now able to communicate with each other through their IP addresses. If you're using subnet-1 Azure name resolution for the virtual networks, the resources in the virtual networks aren't able to resolve names across the virtual networks. If you want to resolve names across virtual networks in a peering, you must create your own DNS server or use Azure DNS.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.