Bird
Raised Fist0
Azurecloud~5 mins

VNet peering for connectivity in Azure - Commands & Configuration

Choose your learning style10 modes available
Introduction
Sometimes you have two separate private networks in the cloud and want them to talk to each other securely and fast. VNet peering connects these networks so resources in one can reach resources in the other without going over the public internet.
When you have two different apps in separate virtual networks that need to share data quickly.
When you want to connect a test environment network to a production network for monitoring.
When you run services in different regions and want them to communicate privately.
When you want to avoid exposing your network traffic to the internet for security reasons.
When you want to simplify network architecture by linking multiple VNets.
Config File - vnet-peering-template.json
vnet-peering-template.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-vnet2')]",
      "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-vnet1')]",
      "properties": {
        "remoteVirtualNetwork": {
          "id": "[resourceId(parameters('resourceGroup'), 'Microsoft.Network/virtualNetworks', parameters('vnet1Name'))]"
        },
        "allowVirtualNetworkAccess": true,
        "allowForwardedTraffic": false,
        "allowGatewayTransit": false,
        "useRemoteGateways": false
      }
    }
  ]
}

This JSON template creates a peering connection between two Azure virtual networks named vnet-eastus and vnet-westus in the resource group example-rg.

Each virtualNetworkPeerings resource defines one side of the peering, allowing both VNets to communicate.

The allowVirtualNetworkAccess set to true enables traffic between the VNets.

Other flags like allowForwardedTraffic, allowGatewayTransit, and useRemoteGateways are set to false for simple peering without gateway sharing or forwarded traffic.

Commands
This command creates a peering from the 'vnet-eastus' virtual network to the 'vnet-westus' virtual network, allowing them to communicate privately.
Terminal
az network vnet peering create --name peer-to-vnet2 --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-vnet2", "name": "peer-to-vnet2", "properties": { "allowVirtualNetworkAccess": true, "allowForwardedTraffic": false, "allowGatewayTransit": false, "remoteVirtualNetwork": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Network/virtualNetworks/vnet-westus" }, "peeringState": "Initiated" }, "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings" }
→
--allow-vnet-access - Allows traffic between the two virtual networks.
This command creates the peering from 'vnet-westus' back to 'vnet-eastus' to complete the two-way connection.
Terminal
az network vnet peering create --name peer-to-vnet1 --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-vnet1", "name": "peer-to-vnet1", "properties": { "allowVirtualNetworkAccess": true, "allowForwardedTraffic": false, "allowGatewayTransit": false, "remoteVirtualNetwork": { "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg/providers/Microsoft.Network/virtualNetworks/vnet-eastus" }, "peeringState": "Initiated" }, "type": "Microsoft.Network/virtualNetworks/virtualNetworkPeerings" }
→
--allow-vnet-access - Allows traffic between the two virtual networks.
This command lists all peering connections for 'vnet-eastus' so you can verify the peering is active.
Terminal
az network vnet peering list --resource-group example-rg --vnet-name vnet-eastus
Expected OutputExpected
[ { "name": "peer-to-vnet2", "properties": { "peeringState": "Connected", "allowVirtualNetworkAccess": true } } ]
This command lists all peering connections for 'vnet-westus' to confirm the two-way peering is established.
Terminal
az network vnet peering list --resource-group example-rg --vnet-name vnet-westus
Expected OutputExpected
[ { "name": "peer-to-vnet1", "properties": { "peeringState": "Connected", "allowVirtualNetworkAccess": true } } ]
Key Concept

If you remember nothing else from this pattern, remember: VNet peering connects two virtual networks so they can communicate privately and directly without using the internet.

Common Mistakes
Creating peering only from one VNet to another but not the reverse.
Peering must be created in both directions to allow two-way communication.
Always create peering from VNet A to VNet B and from VNet B to VNet A.
Not setting the --allow-vnet-access flag when creating peering.
Without this flag, the VNets cannot send traffic to each other even if peering exists.
Include --allow-vnet-access to enable traffic flow between the VNets.
Trying to peer VNets in different subscriptions without proper permissions.
Peering across subscriptions requires permissions on both sides and correct resource IDs.
Ensure you have access to both subscriptions and use full resource IDs when peering.
Summary
Use 'az network vnet peering create' to connect two VNets in both directions.
Verify peering status with 'az network vnet peering list' to ensure connectivity.
Set '--allow-vnet-access' flag to enable traffic between the VNets.

Practice

(1/5)
1. What is the main purpose of Azure VNet peering?
easy
A. To connect two virtual networks for direct communication
B. To create a backup of virtual machines
C. To deploy applications faster
D. To monitor network traffic

Solution

  1. Step 1: Understand VNet peering concept

    VNet peering allows two virtual networks to communicate directly without going through the internet.
  2. Step 2: Identify the main use case

    This direct communication is the primary purpose, enabling resource sharing securely within Azure.
  3. Final Answer:

    To connect two virtual networks for direct communication -> Option A
  4. Quick Check:

    VNet peering = direct network connection [OK]
Hint: VNet peering links networks directly, not backups or monitoring [OK]
Common Mistakes:
  • Confusing peering with VM backup
  • Thinking peering speeds up app deployment
  • Assuming peering is for traffic monitoring
2. Which of the following is the correct way to create a VNet peering in Azure Portal?
easy
A. Create a new VNet with peering enabled by default
B. Create peering from one VNet only
C. Create peering from both VNets involved
D. Enable peering in the subscription settings

Solution

  1. Step 1: Review peering setup requirements

    VNet peering requires configuration from both virtual networks to allow full communication.
  2. Step 2: Identify correct procedure

    Creating peering from both VNets ensures bidirectional connectivity and proper routing.
  3. Final Answer:

    Create peering from both VNets involved -> Option C
  4. Quick Check:

    Peering setup = both sides configured [OK]
Hint: Peering needs setup on both VNets, not just one [OK]
Common Mistakes:
  • Configuring peering only on one VNet
  • Assuming peering is automatic on new VNets
  • Looking for peering in subscription settings
3. Given two VNets, VNetA and VNetB, peered correctly, what happens when a VM in VNetA tries to ping a VM in VNetB?
medium
A. The ping fails because VNets cannot communicate even if peered
B. The ping fails because peering blocks ICMP traffic
C. The ping succeeds only if both VMs are in the same subnet
D. The ping succeeds because peering allows direct communication

Solution

  1. Step 1: Understand VNet peering behavior

    Peering connects VNets so resources can communicate directly, including ping (ICMP) traffic if allowed by NSGs.
  2. Step 2: Analyze the ping scenario

    If no network security group blocks ICMP, ping from VM in VNetA to VM in VNetB will succeed due to peering.
  3. Final Answer:

    The ping succeeds because peering allows direct communication -> Option D
  4. Quick Check:

    Peering enables direct VM communication [OK]
Hint: Peering allows direct traffic unless blocked by security rules [OK]
Common Mistakes:
  • Assuming peering blocks ping by default
  • Thinking VMs must be in same subnet to communicate
  • Believing peering does not enable VNet communication
4. You created VNet peering from VNetA to VNetB but forgot to create peering from VNetB to VNetA. What is the result?
medium
A. Full bidirectional communication between VNets
B. Unidirectional communication from VNetA to VNetB only
C. No communication between VNets
D. Peering automatically completes from both sides

Solution

  1. Step 1: Understand peering directionality

    Peering must be created on both VNets for full bidirectional communication.
  2. Step 2: Analyze partial peering effect

    With peering only from VNetA to VNetB, traffic flows from A to B but not from B to A.
  3. Final Answer:

    Unidirectional communication from VNetA to VNetB only -> Option B
  4. Quick Check:

    One-sided peering = one-way traffic [OK]
Hint: Peering one side = one-way connection only [OK]
Common Mistakes:
  • Assuming peering is automatic both ways
  • Expecting no communication at all
  • Thinking peering creates full connection from one side
5. You have two VNets in different Azure regions and want to enable secure, low-latency communication between them. Which VNet peering type should you use?
hard
A. Global VNet peering
B. Local VNet peering
C. VPN Gateway peering
D. ExpressRoute peering

Solution

  1. Step 1: Identify peering types and their use cases

    Local VNet peering works within the same region; global VNet peering connects VNets across regions.
  2. Step 2: Choose peering for cross-region communication

    Global VNet peering enables secure, low-latency communication between VNets in different Azure regions.
  3. Final Answer:

    Global VNet peering -> Option A
  4. Quick Check:

    Cross-region VNet peering = global peering [OK]
Hint: Use global peering for cross-region VNet connection [OK]
Common Mistakes:
  • Choosing local peering for different regions
  • Confusing VPN Gateway with peering
  • Selecting ExpressRoute which is for on-premises
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard