Bird
Raised Fist0
Azurecloud~5 mins

VNet-to-VNet connectivity in Azure - Commands & Configuration

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
Sometimes you want two separate private networks in Azure to talk to each other securely. VNet-to-VNet connectivity lets you connect these networks so resources in one can reach resources in the other without going over the public internet.
When you have two different teams managing separate networks but want their apps to communicate.
When you want to connect a test network with a production network safely.
When you need to share data between two Azure regions privately.
When you want to connect a network for a web app with another network hosting a database.
When you want to extend your on-premises network through Azure VNets.
Config File - vnet-to-vnet-peering.json
vnet-to-vnet-peering.json
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vnet1Name": {
      "type": "string",
      "defaultValue": "vnet-eastus"
    },
    "vnet2Name": {
      "type": "string",
      "defaultValue": "vnet-westus"
    },
    "resourceGroup": {
      "type": "string",
      "defaultValue": "example-rg"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
      "apiVersion": "2021-05-01",
      "name": "[concat(parameters('vnet1Name'), '/peer-to-westus')]",
      "properties": {
        "remoteVirtualNetwork": {
          "id": "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/virtualNetworks', parameters('vnet2Name'))]"
        },
        "allowVirtualNetworkAccess": true,
        "allowForwardedTraffic": false,
        "allowGatewayTransit": false,
        "useRemoteGateways": false
      }
    },
    {
      "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings",
      "apiVersion": "2021-05-01",
      "name": "[concat(parameters('vnet2Name'), '/peer-to-eastus')]",
      "properties": {
        "remoteVirtualNetwork": {
          "id": "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/virtualNetworks', parameters('vnet1Name'))]"
        },
        "allowVirtualNetworkAccess": true,
        "allowForwardedTraffic": false,
        "allowGatewayTransit": false,
        "useRemoteGateways": false
      }
    }
  ]
}

This JSON is an Azure Resource Manager (ARM) template that creates peering connections between two VNets.

  • vnet1Name and vnet2Name: Names of the two VNets to connect.
  • virtualNetworkPeerings: Resources that define the peering from each VNet to the other.
  • allowVirtualNetworkAccess: Enables traffic between the VNets.

Deploying this template sets up a private link between the two VNets so their resources can communicate securely.

Commands
This command creates a peering from the eastus VNet to the westus VNet, allowing them to communicate privately.
Terminal
az network vnet peering create --name peer-to-westus --resource-group example-rg --vnet-name vnet-eastus --remote-vnet vnet-westus --allow-vnet-access
Expected OutputExpected
{ "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Network/virtualNetworks/vnet-eastus/virtualNetworkPeerings/peer-to-westus", "name": "peer-to-westus", "properties": { "allowVirtualNetworkAccess": true, "peeringState": "Initiated", "remoteVirtualNetwork": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Network/virtualNetworks/vnet-westus" } }, "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings" }
--allow-vnet-access - Allows traffic between the two VNets
This command creates the peering from the westus VNet back to the eastus VNet, completing the two-way connection.
Terminal
az network vnet peering create --name peer-to-eastus --resource-group example-rg --vnet-name vnet-westus --remote-vnet vnet-eastus --allow-vnet-access
Expected OutputExpected
{ "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Network/virtualNetworks/vnet-westus/virtualNetworkPeerings/peer-to-eastus", "name": "peer-to-eastus", "properties": { "allowVirtualNetworkAccess": true, "peeringState": "Initiated", "remoteVirtualNetwork": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Network/virtualNetworks/vnet-eastus" } }, "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings" }
--allow-vnet-access - Allows traffic between the two VNets
This command lists all peerings for the eastus VNet to verify the peering status.
Terminal
az network vnet peering list --resource-group example-rg --vnet-name vnet-eastus
Expected OutputExpected
[ { "name": "peer-to-westus", "peeringState": "Connected", "allowVirtualNetworkAccess": true } ]
This command lists all peerings for the westus VNet to verify the peering status from the other side.
Terminal
az network vnet peering list --resource-group example-rg --vnet-name vnet-westus
Expected OutputExpected
[ { "name": "peer-to-eastus", "peeringState": "Connected", "allowVirtualNetworkAccess": true } ]
Key Concept

If you remember nothing else from this pattern, remember: VNet peering creates a private, secure link between two Azure VNets so their resources can communicate as if on the same network.

Common Mistakes
Creating peering only from one VNet to the other but not the reverse.
Traffic will not flow both ways, so resources cannot communicate properly.
Always create peering from both VNets to each other to enable two-way communication.
Not enabling --allow-vnet-access flag during peering creation.
Without this flag, the VNets cannot send traffic to each other even if peered.
Use --allow-vnet-access to allow traffic between VNets.
Trying to peer VNets with overlapping IP address ranges.
Azure does not allow peering if IP ranges overlap, causing failure.
Ensure VNets have unique, non-overlapping IP address spaces before peering.
Summary
Create VNet peering from the first VNet to the second with traffic allowed.
Create VNet peering from the second VNet back to the first to complete connection.
Verify peering status with listing commands to ensure VNets are connected.

Practice

(1/5)
1. What is the main purpose of VNet-to-VNet peering in Azure?
easy
A. To create a backup of a virtual network
B. To securely connect two virtual networks for resource sharing
C. To connect a virtual network to the internet
D. To increase the size of a single virtual network

Solution

  1. Step 1: Understand VNet-to-VNet peering concept

    VNet-to-VNet peering connects two virtual networks securely to allow communication.
  2. Step 2: Identify the purpose of peering

    It enables resource sharing between VNets without exposing them to the internet.
  3. Final Answer:

    To securely connect two virtual networks for resource sharing -> Option B
  4. Quick Check:

    VNet peering = secure VNet connection [OK]
Hint: Peering connects VNets securely, not to internet or backup [OK]
Common Mistakes:
  • Confusing peering with internet connectivity
  • Thinking peering increases VNet size
  • Assuming peering creates backups
2. Which of the following is the correct way to establish VNet peering between two VNets in Azure?
easy
A. Create peering from VNet1 to VNet2 only
B. Create peering from VNet2 to VNet1 only
C. Create peering from both VNet1 to VNet2 and VNet2 to VNet1
D. No peering needed, VNets connect automatically

Solution

  1. Step 1: Review peering setup requirements

    Peering must be created from both VNets to allow two-way communication.
  2. Step 2: Identify correct peering configuration

    Only creating peering one way does not enable full connectivity.
  3. Final Answer:

    Create peering from both VNet1 to VNet2 and VNet2 to VNet1 -> Option C
  4. Quick Check:

    Two-way peering needed = Create peering from both VNet1 to VNet2 and VNet2 to VNet1 [OK]
Hint: Peering must be two-way for full VNet connectivity [OK]
Common Mistakes:
  • Setting peering only one way
  • Assuming VNets connect automatically
  • Confusing peering with VPN gateways
3. Given two VNets, VNetA and VNetB, with peering configured correctly, what happens if you try to access a VM in VNetB from VNetA?
medium
A. The VM in VNetB is accessible as if on the same network
B. The VM in VNetB is blocked by default firewall rules
C. The VM in VNetB is unreachable without a VPN gateway
D. The VM in VNetB is accessible only via public IP

Solution

  1. Step 1: Understand effect of correct VNet peering

    Peering allows VNets to communicate privately as if on the same network.
  2. Step 2: Analyze access to VM in peered VNet

    VMs can be accessed using private IPs without VPN or public IP.
  3. Final Answer:

    The VM in VNetB is accessible as if on the same network -> Option A
  4. Quick Check:

    Peering enables private access = The VM in VNetB is accessible as if on the same network [OK]
Hint: Peered VNets act like one network for VM access [OK]
Common Mistakes:
  • Thinking VPN gateway is always needed
  • Assuming public IP is required
  • Confusing firewall rules with peering
4. You set up VNet peering from VNet1 to VNet2 but cannot access resources in VNet2 from VNet1. What is the most likely cause?
medium
A. Peering was not created from VNet2 to VNet1
B. VNet1 and VNet2 have overlapping IP address ranges
C. Network Security Groups block traffic between VNets
D. All of the above

Solution

  1. Step 1: Check peering configuration

    Peering must be created both ways; missing one side blocks communication.
  2. Step 2: Verify IP address ranges and security rules

    Overlapping IPs cause routing conflicts; NSGs may block traffic.
  3. Step 3: Combine all issues

    Any of these can cause access failure; all are common mistakes.
  4. Final Answer:

    All of the above -> Option D
  5. Quick Check:

    Multiple causes block access = All of the above [OK]
Hint: Check peering, IP ranges, and NSGs when access fails [OK]
Common Mistakes:
  • Ignoring one-way peering setup
  • Overlapping IP ranges unnoticed
  • Not checking firewall or NSG rules
5. You have two VNets in different Azure regions that need to communicate privately. Which approach is best to enable this with minimal latency and no internet exposure?
hard
A. Use VNet-to-VNet peering with global peering enabled
B. Set up a VPN gateway connection between the VNets
C. Connect VNets via public IP addresses
D. Use ExpressRoute with public peering

Solution

  1. Step 1: Identify connectivity options for cross-region VNets

    Global VNet peering allows private, low-latency connection between VNets in different regions.
  2. Step 2: Compare alternatives

    VPN gateways add latency and complexity; public IPs expose traffic; ExpressRoute public peering is not private.
  3. Step 3: Choose best practice

    Global VNet peering is recommended for private, fast cross-region VNet communication.
  4. Final Answer:

    Use VNet-to-VNet peering with global peering enabled -> Option A
  5. Quick Check:

    Global peering = private, low latency cross-region [OK]
Hint: Global peering connects regions privately with low latency [OK]
Common Mistakes:
  • Using VPN gateways unnecessarily
  • Exposing traffic via public IPs
  • Confusing ExpressRoute public peering with private