Configure and manage virtual networks in Azure

📘Microsoft Certified: Azure Administrator Associate (AZ-104)

Virtual Network (VNet) Peering in Azure allows two or more VNets to communicate with each other privately through the Azure backbone network. It creates a low-latency, high-bandwidth connection between VNets, almost as if they were part of the same network.

This is commonly used in IT environments when different applications, departments, workloads, or environments need to communicate securely—for example:

A database VNet communicating with an application VNet
A production VNet connecting to a monitoring VNet
A central hub VNet serving shared services for multiple spoke VNets

For the AZ-104 exam, it is important to understand what VNet peering is, how to configure it, its requirements, its limitations, and common networking scenarios.

1. Types of VNet Peering

Azure supports four types:

1.1 Intra-region VNet Peering (VNet Peering)

Connects VNets within the same Azure region (e.g., East US → East US).
Uses Azure backbone and provides very fast connectivity.

1.2 Global VNet Peering

Connects VNets across different regions (e.g., East US → West Europe).
Still uses Azure backbone (not the public Internet).

1.3 VNet Peering with Hub-and-Spoke Architecture

A common IT design where:
- One VNet (Hub) contains shared services like firewalls, DNS, identity services.
- Other VNets (Spokes) connect to the hub through peering.
Often used for enterprise-grade onboarding, security appliances, or workloads separation.

1.4 Peering between VNets in different Azure subscriptions

Supported as long as:
- Subscriptions are under the same Azure AD tenant, OR
- You have permission to create peerings.

2. Requirements for Virtual Network Peering

Before creating VNet peering, you must ensure the following (common exam-tested points):

✔ Unique address spaces

VNets cannot overlap in IP address ranges.
For example:
VNet A: 10.0.0.0/16
VNet B: 10.0.0.0/16 → ❌ Overlap
VNet B: 10.1.0.0/16 → ✔ Valid

✔ Correct permissions

You must have:

Network Contributor role (minimum)
Or Owner on both VNets

✔ Both peers must accept the peering

Peering has two sides:

A → B
B → A
Both must be configured unless “Use remote gateways” is enabled.

3. Peering Settings and Their Meaning

During configuration, Azure provides several important options. These are heavily tested in AZ-104.

3.1 “Allow virtual network access”

Enables traffic to flow between VNets.
Default: Enabled

If disabled, VNets are peered but cannot communicate.

3.2 “Allow forwarded traffic”

Used when traffic is routed through a virtual appliance (such as:

Azure Firewall
NVA (Network Virtual Appliance)
Firewall appliance in the Hub

Enable this if the VNet has custom routing or traffic inspection.

3.3 “Allow gateway transit / Use remote gateway”

Critical for hub-and-spoke networks.

Gateway Transit allows:

Spoke VNet to use the Hub VNet’s VPN Gateway
Avoids creating multiple gateways (saves cost)

Rules:

Hub VNet → Enable Allow gateway transit
Spoke VNet → Enable Use remote gateway

You cannot have “Use remote gateway” enabled if the spoke VNet already has its own gateway.

4. Steps to Configure VNet Peering (Portal)

Step 1: Go to VNet A

Open Azure Portal → Virtual Networks → Select VNet A

Step 2: Select “Peerings”

Click + Add

Step 3: Configure the peering from VNet A → VNet B

Enter:

Peering name
Remote VNet name (VNet B)
Peering options (gateway, forwarded traffic, etc.)

Step 4: Create the peering

Azure automatically prompts VNet B to create the second peering connection.

Step 5: Confirm the status

Expected status: Connected

5. VNet Peering Limitations

Important for exam preparation:

❌ Cannot peer VNets with overlapping IP ranges

Critical requirement.

❌ No transitive routing

Example:

VNet A peered with VNet B
VNet B peered with VNet C
A cannot automatically reach C

To achieve transitive routing, organizations use:

Azure Firewall
NVA
Hub-and-Spoke model
Route tables

❌ You cannot use remote gateway in both peerings

Only one side can use the remote gateway.

6. Security and Traffic Considerations

✔ Traffic between peered VNets remains within Azure backbone

Not exposed to Internet.

✔ No need for VPN

Peering is a direct internal connection.

✔ NSGs still apply

Network Security Groups work independently on each VNet and subnet.
Just because two VNets are peered does not mean all traffic is allowed; the NSG rules must permit it.

✔ Can use custom route tables (UDRs)

To direct traffic through appliances (firewalls, monitoring tools).

7. Billing for VNet Peering

Charges apply for:

Data transfer between VNets
Azure charges differently for Inbound vs Outbound traffic
Global peering is more expensive than same-region peering

Exam readiness tip: expect questions related to peering cost differences across regions.

8. Exam-Focused Scenarios to Understand

Scenario 1: Two VNets need private, fast, internal communication

Solution: VNet Peering

Scenario 2: Want a spoke VNet to use Hub VNet’s VPN Gateway

Solution:

Hub: Allow gateway transit
Spoke: Use remote gateway

Scenario 3: VNets have overlapping address spaces

Solution:
Recreate VNets with non-overlapping ranges (peering not possible)

Scenario 4: Need traffic from Spoke → Hub → Another Spoke

Solution:
Use Azure Firewall or NVA because:

Peering is not transitive

Scenario 5: Two VNets in two different subscriptions

Solution:
Supported if permissions exist.

9. Common Troubleshooting Tips (Exam-relevant)

Problem: Peering connection stuck in “Initiated” state

Cause: The remote side does not have a matching peering connection.
Fix: Create the second peering.

Problem: Resources cannot communicate even after peering

Check:

NSG rules
Route tables
DNS configuration

Problem: Cannot enable “Use remote gateway”

Common cause:

The VNet already has its own gateway
The other VNet is not configured to allow gateway transit

Summary for Exam (Key Points to Memorize)

Peering connects VNets through Azure backbone; no VPN needed.
VNets must not overlap in IP address ranges.
Peering is non-transitive.
Gateway transit:
- Hub = Allow gateway transit
- Spoke = Use remote gateway
NSGs and UDRs still apply across peered VNets.
Global peering works across Azure regions.
Two-way peering must be established for a connection to become active.