Azure

Azure Virtual Network Peering (VNet-Peering)

Overview

VNet Peering verbindet zwei virtuelle Netzwerke so, dass Ressourcen sich gegenseitig mit privaten IP-Adressen erreichen, als lägen sie in einem Netz. Der Verkehr läuft ausschließlich über das Microsoft-Backbone, ohne öffentliches Internet, ohne Gateway und ohne zusätzliche Verschlüsselung. Regionales Peering verbindet VNets in derselben Region, globales Peering über Regionen hinweg.

Peering funktioniert auch zwischen Subscriptions und Entra-Tenants. Neu ist Subnet Peering, bei dem nur ausgewählte Subnetze statt des gesamten Adressraums verbunden werden.

Peering ist nicht transitiv: Sind A und B sowie B und C gepeert, können A und C nicht direkt miteinander sprechen. Hub-and-Spoke-Architekturen lösen das mit einer Firewall oder NVA im Hub, alternativ mit Azure Virtual Network Manager oder Virtual WAN.

How it works

Einrichtung und wichtige Optionen:

  1. Peering wird auf beiden Seiten angelegt (das Portal erledigt beide Richtungen in einem Schritt), die Adressräume dürfen nicht überlappen.
  2. Weitergeleiteten Verkehr zulassen (Allow forwarded traffic) erlaubt Pakete, die nicht aus dem gepeerten VNet selbst stammen, etwa über eine NVA.
  3. Gateway-Transit: Ein Spoke nutzt das VPN- oder ExpressRoute-Gateway im Hub. Ein VNet, das ein Remote-Gateway nutzt, darf kein eigenes Gateway haben.
  4. Benutzerdefinierte Routen lenken Spoke-zu-Spoke-Verkehr über eine Firewall im Hub.
  5. Adressräume gepeerter VNets lassen sich ohne Ausfall erweitern, danach muss das Peering synchronisiert werden.

Azure Virtual Network Manager kann Hub-and-Spoke mit bis zu 1.000 Spokes oder Mesh-Gruppen mit bis zu 3.000 VNets automatisch verwalten.

Benefits

  • Latenz zwischen VMs in regional gepeerten VNets entspricht der innerhalb eines VNets
  • Keine Bandbreitenbegrenzung durch das Peering selbst, maßgeblich ist die VM-Größe
  • Einrichtung ohne Ausfallzeit für bestehende Ressourcen
  • Grundlage für Hub-and-Spoke mit gemeinsam genutzter Firewall und gemeinsamem Gateway

Practical example

Ein Getränkehersteller betreibt ein Hub-VNet mit Azure Firewall und VPN Gateway zur Zentrale sowie drei Spoke-VNets für ERP, Webshop und Entwicklung. Alle Spokes sind mit dem Hub gepeert und nutzen Gateway-Transit. Eine Routentabelle in jedem Spoke schickt den Verkehr zu anderen Spokes und ins Internet über die Firewall. So lässt sich zentral steuern, dass die Entwicklung das ERP nur über freigegebene Ports erreicht.

Things to keep in mind

  • Peering ist nicht transitiv, Spoke-zu-Spoke-Verkehr braucht einen Weg über den Hub
  • Datenverkehr über Peerings wird ein- und ausgehend abgerechnet, bei globalem Peering höher
  • Bei globalem Peering erreichen Clients keine Frontend-IP eines Basic Load Balancers im entfernten VNet
  • Gateway-Transit und Remote-Gateway-Optionen auf beiden Seiten passend setzen
  • Ab etwa zehn VNets Azure Virtual Network Manager oder Virtual WAN prüfen

Licensing & availability

Abrechnung nach ein- und ausgehendem Datenvolumen über das Peering, globales Peering ist teurer als regionales. Bei Gateway-Transit fallen zusätzlich Gateway-Kosten an. Stand: Oktober 2026.

Conclusion

VNet Peering ist der Standard für Verbindungen zwischen Azure-Netzen. Plane Hub-and-Spoke bewusst mit zentraler Firewall und klaren Routen.

Further reading

Related articles