This chapter covers cross-subscription and cross-region VNet peering in Microsoft Azure, a critical topic for the AZ-104 exam. You will learn how to connect virtual networks across different Azure subscriptions and regions, enabling hybrid network topologies and centralized management. Approximately 10-15% of exam questions in the networking domain touch on VNet peering, including cross-subscription scenarios, and mastery of this topic is essential for designing scalable, secure Azure networks.
Jump to a section
Cross-subscription and cross-region VNet peering is like building international highway bridges between countries. Imagine two countries (Azure subscriptions) that are separate territories with their own customs and border controls (Azure RBAC). To allow traffic to flow between them, you need a bridge (peering connection) that connects specific points on each side (virtual networks). The bridge must be approved by both countries' authorities (both subscription admins must accept the peering). Even though the countries are separate, the bridge allows vehicles (data packets) to travel directly without going through a central hub. However, customs (network security groups) still inspect vehicles at each end, and toll booths (route tables) can redirect traffic. If the countries are far apart (different regions), the bridge is longer but still direct—no need to go through a central airport (hub VNet). The bridge is also transitive? No—if Country A is connected to Country B and Country B to Country C, vehicles from A cannot drive to C without a separate bridge. Each bridge is a point-to-point connection. To enable multi-country travel, you need a central hub country that connects to all others (hub-and-spoke topology). The bridge is also not a tunnel—it's a physical road that appears as if the two countries share a border. The bridge does not charge tolls (no additional cost for data crossing the bridge, only for the bridge itself). But if you want to use someone else's bridge (a third-party subscription), you must get permission from that subscription's admin (allow gateway transit).
What is Cross-Subscription and Cross-Region VNet Peering?
VNet peering is a networking feature that connects two Azure virtual networks (VNets) directly, allowing resources in each VNet to communicate with each other as if they were on the same network. Cross-subscription VNet peering extends this capability to VNets that reside in different Azure subscriptions, which may be within the same Azure Active Directory (Azure AD) tenant or different tenants. Cross-region VNet peering (also known as global VNet peering) connects VNets in different Azure regions, regardless of whether they are in the same or different subscriptions.
Why It Exists
Organizations often have multiple Azure subscriptions for isolation, billing, or management boundaries. For example, a company might have separate subscriptions for development, testing, and production environments. Peering across subscriptions allows these environments to communicate without merging subscriptions or using complex VPN gateways. Cross-region peering enables geographically distributed applications to communicate with low latency and high bandwidth using Microsoft's backbone network, bypassing the public internet.
How It Works Internally
When a VNet peering is established, Azure creates a routing table entry in each VNet's routing infrastructure that directs traffic destined for the peered VNet's address space to the peering connection. This is not a VPN tunnel or a gateway; it is a direct, private connection using the Azure backbone network. For cross-subscription peering, the peering is created between two VNet objects, but the authorization model requires each subscription's admin to approve the peering. The process involves:
Initiation: The admin of the first subscription (VNet A) initiates a peering request to VNet B in the second subscription. This creates a pending peering on VNet A.
Authorization: The admin of the second subscription must accept the peering request. They can do this by navigating to VNet B in the Azure portal and approving the pending peering. Alternatively, the first admin can use a peering authorization token (a GUID) that the second admin uses to accept the peering.
Completion: Once accepted, the peering becomes active. Both VNets must have non-overlapping address spaces. If they overlap, peering fails.
Cross-region peering works similarly but does not require any special authorization beyond the subscription-level permissions. The underlying mechanism is the same: Azure updates the routing tables in each VNet to include routes for the other VNet's address space via the peering connection.
Key Components, Values, Defaults, and Timers
Peering Status: Peering goes through states: Initiated, Connected, Disconnected. Only when both sides are 'Connected' does traffic flow.
Allow Gateway Transit: A boolean setting on the peering. If enabled on a VNet that has a VPN gateway, the peered VNet can use that gateway to connect to on-premises networks. Default is disabled.
Use Remote Gateways: A complementary setting on the other side of the peering. If enabled, the VNet can use the gateway of the peered VNet. Default is disabled.
Address Spaces: Must not overlap. Azure checks this at peering creation time.
Service Endpoints: Not automatically extended across peered VNets. Service endpoints are configured per subnet and are not transitive.
Network Security Groups (NSGs): Apply at subnet or NIC level and are not automatically adjusted by peering. You must configure NSG rules to allow traffic between VNets.
Route Tables (UDRs): Applied at subnet level. If a subnet has a UDR that forces traffic to a network virtual appliance (NVA), that traffic will go through the NVA even if peering exists. Be careful with forced tunneling.
Bandwidth: No additional bandwidth limitations beyond the underlying VNet limits. Peering uses the Azure backbone, which provides high throughput and low latency.
Cost: There is no cost for peering itself, but data transfer across regions incurs standard data transfer charges. Data transfer within the same region is free for peering.
Timers: No specific timers for peering. Peering remains active until explicitly deleted or one of the VNets is deleted.
Configuration and Verification Commands
Using Azure CLI:
# Create peering from VNet1 to VNet2 (cross-subscription)
az network vnet peering create \
--name VNet1-To-VNet2 \
--resource-group RG1 \
--vnet-name VNet1 \
--remote-vnet /subscriptions/SUBSCRIPTION2/resourceGroups/RG2/providers/Microsoft.Network/virtualNetworks/VNet2 \
--allow-vnet-access
# Accept peering on the other side (must be run in subscription2)
az network vnet peering create \
--name VNet2-To-VNet1 \
--resource-group RG2 \
--vnet-name VNet2 \
--remote-vnet /subscriptions/SUBSCRIPTION1/resourceGroups/RG1/providers/Microsoft.Network/virtualNetworks/VNet1 \
--allow-vnet-accessUsing PowerShell:
# Create peering from VNet1 to VNet2
$vnet1 = Get-AzVirtualNetwork -ResourceGroupName RG1 -Name VNet1
$vnet2 = Get-AzVirtualNetwork -ResourceGroupName RG2 -Name VNet2
Add-AzVirtualNetworkPeering -Name VNet1-To-VNet2 -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2.Id
# Accept on the other side
Add-AzVirtualNetworkPeering -Name VNet2-To-VNet1 -VirtualNetwork $vnet2 -RemoteVirtualNetworkId $vnet1.IdVerification:
az network vnet peering list --resource-group RG1 --vnet-name VNet1 --output tableThis shows the peering status. Ensure both are 'Connected'.
How It Interacts with Related Technologies
Azure VPN Gateway: Peering can be combined with VPN gateways using gateway transit. If VNet A has a VPN gateway and allows gateway transit, VNet B (peered to A) can use that gateway to reach on-premises. However, VNet B itself cannot have a gateway if it uses remote gateway transit.
Azure Firewall: Placing an Azure Firewall in a hub VNet and peering spoke VNets to the hub allows traffic inspection. Cross-subscription peering works here as long as the firewall is in the hub subscription.
Private Link: Private endpoints can be accessed across peered VNets if the DNS resolution is configured correctly. Peering does not automatically resolve private DNS zones across subscriptions.
Azure DNS: Custom DNS servers in a peered VNet are not automatically used by the other VNet. DNS settings are per VNet and must be configured separately.
Azure Bastion: Bastion does not support peering. Each VNet needs its own Bastion host.
Load Balancers: Internal load balancers can be accessed across peered VNets if the backend resources are in the same VNet. Peering does not extend the load balancer's scope.
Limitations and Constraints
Transitive Peering: Not supported. If VNet A is peered to VNet B, and VNet B to VNet C, A cannot communicate with C directly. You need a hub-and-spoke topology with a hub VNet that routes traffic.
Overlapping Address Spaces: Peering fails if address spaces overlap. This is a common exam trap.
Classic VNets: Peering is not supported with classic (ASM) VNets. Only Resource Manager VNets.
Cross-Tenant Peering: Supported but requires manual acceptance using a peering authorization token. The token is a GUID that the remote admin uses to accept the peering.
Subscription Limits: By default, you can have up to 500 peerings per VNet. This is a soft limit that can be increased.
Resource Lock: If a resource lock is placed on the VNet resource, peering operations may fail. You must remove the lock first.
Performance Considerations
Peering uses the Azure backbone network, which provides bandwidth up to 10 Gbps or more depending on the VM size. There is no additional latency beyond normal inter-region latency. For cross-region peering, traffic stays on Microsoft's network, avoiding the public internet. This is superior to using VPN gateways for inter-region connectivity.
Security Considerations
Peering does not imply trust. NSGs and firewalls must be configured to allow traffic. By default, peering enables full connectivity between VNets, but you can restrict traffic using NSGs or Azure Firewall. Additionally, you can use service tags in NSG rules to allow traffic from a peered VNet's address space.
Common Scenarios
Hub-and-Spoke: Central hub VNet with shared services (firewall, VPN gateway) peered to multiple spoke VNets in different subscriptions. Spokes cannot peer among themselves.
Multi-Region Deployment: An application deployed in two regions for disaster recovery. Peering the VNets allows database replication and failover traffic.
Acquisition: After acquiring a company, you need to connect their Azure subscription to yours. Cross-subscription peering enables this without migration.
Exam-Relevant Details
Peering Authorization Token: Used for cross-tenant peering. The token is valid for 24 hours. If not used within that time, it expires.
Gateway Transit: Only one VNet in a peering pair can have a gateway. The other VNet uses the remote gateway. Both VNets cannot have gateways.
Service Chaining: You can use UDRs to route traffic through an NVA in a peered VNet. This is only supported if the NVA is in a different VNet than the source. You cannot chain through multiple peerings transitivity.
Delete and Recreate: If you delete a peering, it must be recreated on both sides. There is no automatic re-establishment.
Troubleshooting
Peering shows 'Initiated': The remote side has not accepted. Check permissions and that the remote admin has accepted.
Cannot ping across peering: Check NSG rules, firewall rules, and that the peering status is 'Connected'. Also ensure that the OS firewall on VMs allows ICMP or the specific protocol.
Traffic takes unexpected route: Check UDRs on subnets. If a UDR forces traffic to an NVA, it will override peering.
Plan Address Spaces
Ensure that the VNets you want to peer have non-overlapping address spaces. This is a prerequisite; if they overlap, peering will fail. For example, VNet1 uses 10.0.0.0/16 and VNet2 uses 10.1.0.0/16. Overlap would be if both used 10.0.0.0/24. Also verify that subnets within each VNet do not overlap with the other VNet's address space. Use Azure's 'Check overlapping' feature in the portal or manually verify. This step is critical because overlapping address spaces cannot be changed after peering is created without deleting the peering. On the exam, a common trap is to assume peering works with overlapping addresses, but it does not.
Configure Permissions
For cross-subscription peering, each subscription admin must have the necessary permissions. Specifically, the admin initiating the peering needs 'Network Contributor' role on the source VNet (or at least 'Microsoft.Network/virtualNetworks/peer/action' permission). The admin accepting the peering needs 'Network Contributor' on the target VNet. If the subscriptions are in different Azure AD tenants, use a peering authorization token. The source admin generates the token via Azure CLI or PowerShell, and shares it with the target admin, who then uses it to accept the peering. The token expires after 24 hours. Without proper permissions, the peering request will be rejected. On the exam, you may be asked which role is required—remember 'Network Contributor' or a custom role with the specific action.
Initiate Peering from Source
In the Azure portal, navigate to the source VNet, select 'Peerings', then 'Add'. Provide a name for the peering from source to target. Select the target VNet by resource ID or by selecting from a list (if in the same subscription). For cross-subscription, you must provide the full resource ID of the target VNet. Set 'Allow virtual network access' to Enabled. Optionally, configure 'Allow forwarded traffic' and 'Allow gateway transit' if needed. Click 'Add'. This creates a peering in the 'Initiated' state on the source side. The target side will show a pending peering. The source admin should communicate the peering request to the target admin.
Accept Peering from Target
The target admin must navigate to the target VNet, select 'Peerings', and see the pending peering from the source. They select it and click 'Accept'. Alternatively, they can create a peering from their side pointing to the source VNet's resource ID. Once accepted, the peering status on both sides changes to 'Connected'. If using a peering authorization token, the target admin creates the peering using the token. The token is provided by the source admin. The target admin must enter the token and the source VNet resource ID. After acceptance, traffic can flow between the VNets. Note that the target admin cannot modify the source's peering settings; they only accept or reject.
Verify Connectivity
After the peering is connected, verify that resources in both VNets can communicate. Use tools like ping, tracert, or test-NetConnection. Check that NSGs on subnets and NICs allow traffic between the VNets. For example, if VNet1's subnet has an NSG that blocks inbound from VNet2's address space, traffic will be dropped. Also verify that any custom DNS servers are reachable. Use Azure's 'Connection Troubleshoot' tool in the portal to test connectivity between VMs. If using gateway transit, ensure that the gateway is configured correctly and that 'Use remote gateways' is enabled on the spoke VNet. On the exam, you may be asked to troubleshoot why connectivity fails after peering—common reasons include NSGs, UDRs, or overlapping address spaces.
Configure Advanced Settings
Optionally, configure additional peering settings. 'Allow forwarded traffic' enables traffic from third VNets to flow through this peering, which is useful for NVA scenarios. 'Allow gateway transit' allows the peered VNet to use the gateway in this VNet. 'Use remote gateways' allows this VNet to use the gateway in the peered VNet. Note that only one VNet in the pair can have a gateway. If both have gateways, you cannot enable gateway transit. Also, consider using service chaining with UDRs to route traffic through an NVA. For example, you can create a route in VNet1's subnet that sends traffic to VNet2's address space via an NVA in VNet2. This is done by adding a UDR with next hop type 'Virtual appliance' and the NVA's IP. On the exam, remember that service chaining is only for traffic going out of the VNet, not for inbound traffic.
Enterprise Scenario 1: Multi-Subscription Hub-and-Spoke
A large enterprise has separate Azure subscriptions for each business unit (e.g., HR, Finance, IT). They want to centralize network security and internet access using a hub VNet in the IT subscription that contains an Azure Firewall and a VPN gateway for on-premises connectivity. Each business unit's VNet (spoke) is in its own subscription. They need to connect all spoke VNets to the hub VNet via cross-subscription peering. The hub VNet has address space 10.0.0.0/16, and each spoke uses a different /16, e.g., HR uses 10.1.0.0/16, Finance uses 10.2.0.0/16. They enable 'Allow gateway transit' on the hub peering so that spokes can use the hub's VPN gateway to reach on-premises. They also enable 'Allow forwarded traffic' on the hub peering to allow spokes to communicate with each other via the hub's Azure Firewall. They configure UDRs in each spoke's subnet to route traffic to other spokes via the hub firewall. This setup works because peering is not transitive, but the hub acts as a router. In production, they must carefully manage NSG rules to allow traffic from hub to spoke and vice versa. Common issues arise when a business unit admin accidentally modifies NSG rules or creates overlapping address spaces during VNet expansion. Monitoring peering status using Azure Monitor alerts is essential to detect when a peering is disconnected (e.g., if a subscription is deleted). Performance is excellent because all traffic stays on Azure backbone, but cross-region peering incurs data transfer costs. Misconfiguration often occurs when someone enables 'Use remote gateways' on the hub side instead of 'Allow gateway transit', breaking spoke connectivity to on-premises.
Enterprise Scenario 2: Cross-Region Disaster Recovery
A SaaS company runs its application in two Azure regions: East US and West Europe. Each region has its own subscription for billing isolation. The application uses Azure SQL Database with geo-replication for disaster recovery. To allow the application tier in West Europe to replicate data to the database in East US, they need network connectivity between the VNets. They create a cross-subscription, cross-region VNet peering between the East US VNet (10.0.0.0/16) and the West Europe VNet (172.16.0.0/16). They ensure address spaces do not overlap. They configure NSGs to allow SQL traffic (port 1433) between the VNets. They also set up private DNS zones for the SQL databases so that the application in West Europe can resolve the database endpoint in East US. In production, they monitor latency and data transfer costs. A common problem is that the SQL geo-replication traffic is high, and they need to ensure that the VNet bandwidth limits (based on VM sizes) are not exceeded. They also use Azure Traffic Manager to route user traffic to the active region. If the peering is accidentally deleted (e.g., by a script that cleans up resources), geo-replication breaks immediately, causing data loss risk. They implement resource locks on the peering objects to prevent accidental deletion. This scenario demonstrates that cross-region peering is often simpler and cheaper than using VPN gateways for inter-region connectivity, but it requires careful planning for DNS and security.
Enterprise Scenario 3: Mergers and Acquisitions
After acquiring a startup, a company needs to integrate the startup's Azure subscription into its own network. The startup's VNet uses address space 10.0.0.0/16, which overlaps with the parent company's existing VNet. Overlapping address spaces prevent peering. The parent company must either re-address the startup's VNet (by creating a new VNet with a non-overlapping address space and migrating resources) or use a VPN gateway with site-to-site VPN and NAT to handle the overlap. Typically, re-addressing is preferred for long-term integration. Once the address space is fixed (e.g., startup uses 10.2.0.0/16), they create cross-subscription peering. They also need to ensure that DNS resolution works across subscriptions. They configure Azure DNS private zones with auto-registration for the parent's VNet and link the startup's VNet to the same private zone. This allows the startup's VMs to resolve the parent's resources by hostname. Common pitfalls include forgetting to update DNS settings after peering and not configuring NSGs to allow cross-subscription traffic. The parent company also sets up Azure Policy to enforce that all new VNets follow a naming convention and address space allocation to avoid future overlaps. This scenario highlights the importance of address space planning in multi-subscription environments.
What AZ-104 Tests on This Topic (Objective 4.1)
The AZ-104 exam specifically tests your ability to configure VNet peering, including cross-subscription and cross-region scenarios. Key objective areas: - Configure VNet peering: Understand the steps to create and accept peering, including cross-subscription and cross-tenant. - Configure gateway transit: Know when to use 'Allow gateway transit' and 'Use remote gateways'. - Troubleshoot peering: Identify common issues like overlapping address spaces, NSG blocks, and peering status. - Understand limitations: Transitive peering not supported, classic VNets not supported, etc.
Common Wrong Answers and Why
'Peering supports transitive routing' – Many candidates think that if VNet A is peered to B, and B to C, then A can talk to C. This is false. Azure VNet peering is non-transitive. The correct answer is to use a hub-and-spoke topology with a hub that routes traffic.
'You can peer VNets with overlapping address spaces if you use gateway transit' – Overlapping address spaces always cause peering to fail. Gateway transit does not resolve overlap. The only solution is to change address spaces or use VPN with NAT.
'Cross-subscription peering requires both subscriptions to be in the same Azure AD tenant' – While easier, it is not required. Cross-tenant peering is supported using a peering authorization token.
'You need to configure NSGs to allow peering traffic' – Peering itself does not require NSGs; it creates routes. However, NSGs can block traffic. The exam may ask why traffic fails despite peering being connected – answer is often NSGs.
'Gateway transit allows both VNets to have gateways' – Only one VNet can have a gateway when using gateway transit. If both have gateways, you cannot enable gateway transit.
Specific Numbers, Values, and Terms
Peering authorization token expires in 24 hours.
Maximum peerings per VNet: 500 (soft limit).
Peering status: Initiated, Connected, Disconnected.
Gateway transit settings: 'Allow gateway transit' on the gateway VNet, 'Use remote gateways' on the spoke VNet.
Service chaining: Use UDR with next hop type 'Virtual appliance' to route through an NVA in a peered VNet.
Cross-tenant peering: Requires token; token is a GUID.
Edge Cases and Exceptions
Resource locks: If a read-only lock is on the VNet, peering operations fail.
Deleted VNet: If one VNet is deleted, the peering on the other side becomes 'Disconnected' and must be recreated.
Azure Policy: Policies that restrict VNet address spaces can cause peering to fail if the remote VNet's address space is not allowed.
Service endpoints: Not automatically extended; you must configure them separately in each VNet.
Azure Bastion: Does not support peering; each VNet needs its own Bastion.
How to Eliminate Wrong Answers
If a question mentions connectivity between three VNets and the answer suggests peering all three in a chain, eliminate it because peering is non-transitive.
If a question says 'peering is connected but cannot ping', look for answers involving NSGs or firewall rules, not peering configuration.
If a question involves cross-tenant peering and the answer says 'both subscriptions must be in same tenant', eliminate it.
If a question involves gateway transit and both VNets have gateways, the answer that allows gateway transit is wrong.
If a question mentions overlapping address spaces, any answer that suggests peering will work is wrong.
VNet peering is non-transitive; each pair of VNets must be peered separately.
Cross-subscription peering requires acceptance by the remote admin; cross-tenant peering uses a token that expires in 24 hours.
Overlapping address spaces prevent peering from being created.
Gateway transit allows a VNet without a gateway to use the gateway of the peered VNet; only one VNet can have a gateway.
NSGs and UDRs are still enforced across peered VNets; configure them to allow traffic.
Service endpoints and private endpoints are not automatically extended across peerings.
Peering status must be 'Connected' on both sides for traffic to flow.
Maximum of 500 peerings per VNet (soft limit).
Cross-region peering uses Azure backbone and incurs data transfer costs.
Classic VNets (ASM) do not support peering.
These come up on the exam all the time. Here's how to tell them apart.
VNet Peering
Direct connection via Azure backbone; no public internet involved.
Lower latency and higher throughput (up to 10 Gbps per VM).
No additional cost for peering itself; only data transfer charges apply.
Supports cross-region and cross-subscription connectivity natively.
Non-transitive; requires hub-and-spoke for multi-VNet connectivity.
VPN Gateway (Site-to-Site)
Encrypted tunnel over public internet (IPsec).
Higher latency and limited throughput (typically up to 1.25 Gbps per VPN gateway SKU).
Cost includes per-hour gateway pricing plus data transfer out.
Requires a gateway in each VNet; can connect on-premises and other clouds.
Supports transitive routing via BGP; can connect multiple sites.
Mistake
VNet peering is transitive across multiple peerings.
Correct
VNet peering is non-transitive. If VNet A is peered to B, and B to C, A cannot communicate with C directly. You must use a hub VNet or additional peerings.
Mistake
You can peer VNets with overlapping address spaces if you use gateway transit.
Correct
Overlapping address spaces prevent peering from being created at all. Gateway transit does not resolve address overlap. You must ensure address spaces are unique.
Mistake
Cross-subscription peering requires both subscriptions to be in the same Azure AD tenant.
Correct
Cross-subscription peering is supported across different Azure AD tenants using a peering authorization token. The token is a GUID that expires in 24 hours.
Mistake
Once peering is established, no further configuration is needed for traffic to flow.
Correct
While peering creates routes, network security groups (NSGs) and firewalls can block traffic. You must configure NSGs to allow traffic between the VNets. Also, DNS resolution may require additional configuration.
Mistake
Gateway transit allows both VNets in a peering to have VPN gateways.
Correct
Only one VNet can have a VPN gateway when using gateway transit. The other VNet uses the remote gateway. If both have gateways, gateway transit cannot be enabled.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, this is called global VNet peering. It connects VNets in different regions directly using the Azure backbone. There is no additional configuration beyond standard peering. Data transfer across regions incurs standard outbound data transfer charges. Note that global peering is not available in Azure Government or China regions.
You can peer VNets in different subscriptions by using the remote VNet's resource ID when creating the peering. The admin of the remote subscription must accept the peering. If the subscriptions are in different Azure AD tenants, you need to use a peering authorization token. Generate the token using Azure CLI or PowerShell, share it with the remote admin, who then uses it to accept the peering. The token expires in 24 hours.
'Allow gateway transit' is configured on the VNet that has a VPN gateway. It allows the peered VNet to use this gateway to connect to on-premises networks. 'Use remote gateways' is configured on the peered VNet that does not have a gateway. It enables that VNet to use the gateway of the first VNet. Both settings must be enabled for gateway transit to work. Only one VNet in the peering can have a gateway.
The most common reasons are: (1) Network Security Groups (NSGs) on the source or destination subnet/NIC are blocking ICMP (ping). (2) The VM's OS firewall is blocking ICMP. (3) There is a User-Defined Route (UDR) that sends traffic to a network virtual appliance (NVA) that is not configured correctly. (4) The VM is not running or has no public IP (though private IP should work). Check NSG rules first, as they are the most frequent cause.
No, VNet peering is only supported between VNets deployed via Azure Resource Manager (ARM). Classic VNets (ASM) cannot be peered. To connect a classic VNet to an ARM VNet, you must use a VPN gateway or migrate the classic VNet to ARM.
Yes, but indirectly. You can use User-Defined Routes (UDRs) to route traffic from a subnet in one VNet to a network virtual appliance (NVA) in a peered VNet. This is called service chaining. The UDR's next hop type must be 'Virtual appliance' and the next hop IP must be the NVA's private IP. However, traffic cannot be chained through multiple peerings; it must go directly to the peered VNet containing the NVA.
If you delete a VNet that has active peerings, the peerings on the other VNet(s) will show a status of 'Disconnected'. The other VNet will still have the peering object, but it will not work. To restore connectivity, you must recreate the peering after recreating the VNet. It is recommended to delete peerings before deleting VNets.
You've just covered Cross-Subscription and Cross-Region VNet Peering — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?