MyXenApp

Azure Virtual Network (VNET) Peering allows you to connect two or more VNETs privately through the Azure backbone network, enabling low-latency, high-bandwidth communication between resources in different VNETs—without going over the internet.

Regional And Global Peering in Azure

Key Points:

• Traffic flows over Azure’s private backbone, not the public internet.
• Peering can occur across different Azure subscriptions.
• Peering can be: Regional (within the same region) & Global (across different regions)
• Ensure IP address spaces do not overlap between peered VNETs.

Communication between subnets within the same VNET is allowed by default. Azure automatically creates system routes that allow communication between subnets. There’s no need for peering between subnets in the same VNET. All subnets in a single VNET are part of the same IP address space.

NOTE: Use Network Security Groups (NSGs) to block or allow traffic between subnets

However, subnets in different VNETs cannot communicate unless peering is enabled.

Regional Peering Example

Subnet 1 (S 1A) and Subnet 2 (S 2A) within the same VNET (VNET A) can communicate with each other by default. However, they cannot communicate with Subnet 1 (S 1B) or Subnet 2 (S 2B) in a different VNET (VNET B), even if both VNETs are in the same region.

Once peering is enabled, they can communicate over the Azure backbone. This setup is called Regional Peering.

Global Peering Example

• VNET B (US-West)
• VNET C (US-East)

If these are peered, it’s called Global Peering as the VNETs are in different Azure regions. So, now S 1B and S 2B can communicate to S 1C.

Can VNET A communicate with VNET C?

No, VNET A cannot directly communicate with VNET C based on this setup, because:

• VNET A is peered only with VNET B via Regional Peering.
• VNET B is peered with VNET C via Global Peering.
• VNET Peering is not transitive, meaning just because A is peered with B and B is peered with C, A and C cannot communicate unless they have a direct peering relationship.

VPN as an Alternative

You can use a VPN Gateway to enable communication between VNETs or between VNET and on-premises networks.

However:

• Traffic flows through the public internet.
• Higher latency and more complexity.
• Requires a VPN Gateway in each VNET.

Recommendation: Use VNET Peering whenever possible for low latency, security, and cost-efficiency.

Hub-and-Spoke Model (for VPN) To reduce complexity:

• Create Hub VNET.
• Install the VPN Gateway in the Hub.
• Peer spoke VNETs to Hub.
• The Hub can then connect to on-premises.

Example with VPN and HUB -Spoke Architecture

Explanations:

Architecture Explanation

🌐 1. On-Premises Network

• Located outside Azure (your physical or corporate datacenter).
• Has a server: btadc01 with private IP
• Connects to Azure via a Site-to-Site VPN using IPSec IKE tunnel.

If a virtual machine (session host) in AVD environment encounters issues, we can roll back to a previous state using Azure VM snapshots.

Steps to Take a Snapshot

1. Go to Azure Portal → Navigate to Virtual Machines.
2. Select the AVD (session host) you want to snapshot.
3. Under Disks, choose the OS Disk.
4. Click Create Snapshot → Fill in details like name and storage type.
5. Click Review + Create → Create Snapshot.

Created an AVD as a Gold Image to test snapshot rollback. Now, create a folder named ‘Test-snapshot-C-drive” in the C drive of  the Gold Image to check if the data gets deleted after rollback.

Select ->Disk

Now we can see the OS Disk details, please select again disk name to expand the details.

To take the snapshot, select the “Create Snapshot“

Fill the details of Snapshot.

Once snapshot created. Create the disk from snapshot.

Fill the details for disk.

Once disk created. Now, we can create the AVD from the disk.

By default, Image will be select as your disk

Deleted the Original AVD Gold Image after creating Disk and Validated the Test folder is available in C drive.