VNet Peering and Service Endpoints

Resources in different Azure VNets cannot communicate with each other by default — even if they are in the same Azure region. However, large organisations often have multiple VNets: separate VNets for development, staging, and production, or different VNets for different departments. VNet Peering connects two VNets directly through Microsoft's private backbone network, enabling resources in both VNets to communicate as if they were in the same network — without any traffic traversing the public internet or requiring a VPN gateway.

VNet Peering is a non-transitive connection: if VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot communicate with VNet C unless you create a separate peering between A and C. Peering links are bidirectional but must be configured on both sides — creating a peering from A to B does not automatically create one from B to A. Once both sides are configured, traffic between the peered VNets uses the Azure backbone with low latency and high bandwidth, comparable to inter-subnet communication within a single VNet.

VNet Peering has two scope options: Local VNet Peering connects two VNets in the same Azure region. Traffic stays within the region and incurs a small per-GB transfer fee. Global VNet Peering connects two VNets in different Azure regions, routed over Microsoft's global backbone. This enables resources in East US to communicate privately with resources in West Europe without traversing the public internet. Global peering has a slightly higher transfer cost than local peering, but is still significantly cheaper and more reliable than routing through a VPN.

A common enterprise pattern uses VNet Peering to implement a hub-and-spoke topology. A central hub VNet hosts shared services: Azure Firewall, VPN Gateway, DNS servers, and monitoring. Multiple spoke VNets (one per environment or workload) peer with the hub. By routing all spoke traffic through the hub firewall, the organisation gets centralised security inspection without complex NSG management in each spoke. Since peering is non-transitive, the hub firewall routes traffic between spokes using User-Defined Routes (UDRs).

VNet Peering has one critical requirement: the address spaces of peered VNets must not overlap. If VNet A uses 10.0.0.0/16 and VNet B also uses 10.0.0.0/16, peering fails because Azure cannot route traffic between identical address ranges. This is why planning non-overlapping CIDR ranges for all VNets — and for on-premises networks — before you begin is so important. Changing a VNet's address space after resources are deployed requires recreating the VNet or using the (limited) address space add/remove feature.

Service Endpoints extend the VNet's identity to Azure PaaS services like Azure Storage, Azure SQL Database, Azure Key Vault, and Cosmos DB. When you enable a service endpoint on a subnet, traffic from resources in that subnet to the specified Azure service is routed over the Azure backbone rather than the public internet — even though the service's public IP address is used. The service can then restrict access to only resources within VNets that have the service endpoint enabled, providing a significant security improvement over internet-accessible endpoints.

Service Endpoints and Private Endpoints both provide secure access to Azure PaaS services, but they work differently: Service Endpoint — routes traffic over the Azure backbone but still uses the service's public IP address; the service endpoint exists at the subnet level. Private Endpoint — assigns a private IP from your VNet to the service; the public endpoint can be disabled entirely, making the service truly private. Private Endpoints provide stronger isolation and can also be accessed from on-premises over VPN/ExpressRoute. For the highest security, Private Endpoints are preferred; Service Endpoints are a simpler, lower-cost alternative.

After enabling a Service Endpoint on a subnet, you configure the Azure service to only accept connections from that subnet. For a storage account, this means adding a VNet rule in the storage account's firewall settings. After this change, only VMs in the specified subnet can reach the storage account — all other internet traffic is denied. This is a quick, zero-cost way to significantly improve storage account security compared to leaving it open to all internet traffic, especially for accounts hosting sensitive application data.

VNet Integration (distinct from VNet Peering) allows Azure App Service applications to make outbound calls to resources inside a VNet. Without VNet Integration, an App Service's outbound traffic always exits over the public internet — even when calling resources like Azure SQL or Azure Cache for Redis in the same VNet. With VNet Integration enabled, the app's outbound traffic is routed into the VNet and can reach private resources. This requires a dedicated delegated subnet in the VNet with at least a /28 address space.

Because VNet Peering is non-transitive, connecting more than two VNets requires either direct peering between every pair (O(n²) complexity) or a central routing hub. In a hub-and-spoke model, the hub VNet contains a Network Virtual Appliance (NVA) or Azure Firewall that acts as a transit router between spoke VNets. Each spoke adds a UDR pointing all traffic (0.0.0.0/0 or to specific spoke CIDRs) to the NVA's IP in the hub. The NVA then forwards traffic to the correct destination spoke, effectively providing transitive connectivity through the hub.

Key VNet Peering limitations: Non-overlapping address spaces required — plan CIDR ranges carefully before creating VNets. Non-transitive — peering A-B and B-C does not connect A-C. Cannot resize a VNet's address space if it has active peerings without temporarily deleting them. Gateway transit — spoke VNets can use the VPN or ExpressRoute gateway in the hub VNet by enabling 'Use Remote Gateways' in the peering configuration, but this requires the hub gateway to be created first. Understanding these limitations is important for designing scalable, maintainable multi-VNet architectures.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: VNet Peering connects two VNets over Microsoft's backbone for private, low-latency communication without a VPN, but peering is non-transitive, service endpoints route subnet traffic to Azure PaaS services over the backbone without exposing it to the public internet, and private endpoints are the stronger alternative that assign a private IP to a PaaS service, allowing the public endpoint to be disabled entirely. Next up we explore Azure DNS and Load Balancer essentials.