Microsoft AZ-700: ExpressRoute & WAN-Konnektivität — Lernleitfaden

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Teil des Microsoft Azure Network Engineer AZ-700 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

ExpressRoute-Grundlagen, Peering-Modelle und SKUs

ExpressRoute bietet eine private Verbindung mit hohem Durchsatz zwischen Ihren lokalen Netzwerken und dem globalen Backbone von Microsoft. Es gibt zwei Bereitstellungsmodelle: von einem Dienstanbieter bereitgestellte Leitungen (Co-Location an einem Austauschpunkt oder über einen Partner) und ExpressRoute Direct, bei dem Sie physische Ports von Microsoft bestellen (geeignet für Szenarien mit 10/100/400 Gbit/s). Die logische Konnektivität zu Azure nutzt Peering: privates Peering für die VNet-Konnektivität, Microsoft-Peering für Azure-Plattform- und PaaS-Endpunkte und (wo unterstützt) öffentliches Peering für Legacy-Migrationen. Designentscheidungen hängen von der Bandbreite, dem geografischen Geltungsbereich und der Skalierung der angekündigten Routen ab. Wählen Sie die Leitungs-SKU basierend auf dem Geltungsbereich und der Routenskalierung anstatt der reinen Bandbreite und kombinieren Sie sie mit einem entsprechend dimensionierten virtuellen Netzwerkgateway oder Virtual WAN-Hub, um die Konnektivität zu terminieren.

• Lokal: Peering ist auf die Metro/Region des Peering-Standorts beschränkt; geringere Kosten und kleinerer Speicherbedarf in der Routingtabelle.
• Standard: Konnektivität zu allen öffentlichen Azure-Regionen in derselben Geografie; mittlere Kosten und Routenskalierung.
• Premium (Add‑on): Erweitert die Reichweite auf alle globalen Regionen und erhöht die Anzahl der unterstützten Routen und VNet-Anbindungen; erforderlich für globale Transit-Topologien und viele per Peering verbundene VNets.

Häufige Fallstricke sind die Annahme, dass ExpressRoute unbegrenzte Routen oder automatisches transitives Routing zwischen VNets bedeutet. Sie müssen explizit die Routenlimits, Peering-Typen und die Notwendigkeit des Premium-Add-Ons für globale Reichweite oder zusätzliche Präfixe bewerten.

Bereitstellungslebenszyklus, erforderliche Artefakte und Konfigurationsdetails

Die Bereitstellung einer ExpressRoute-Leitung ist ein Koordinationsprozess zwischen Ihrem Netzwerkteam und einem Konnektivitätsanbieter. Nachdem Sie die Leitung in Azure erstellt haben, erhalten Sie einen Dienstschlüssel (ServiceKey/Service Key ID), den der Anbieter zur Bereitstellung der physischen Querverbindung verwendet. Wählen Sie beim Erstellen der Leitung den Peering-Standort (Metro/Colocation), die Bandbreite (50 Mbit/s bis zu mehreren Gbit/s je nach Anbieter und Modell) und konfigurieren Sie das Peering (privat und/oder Microsoft) sowie VLAN/Subnetze für BGP. Terminieren Sie die ExpressRoute-Verbindung entweder in einem VNet über ein Virtual Network Gateway (oder in einem Virtual WAN-Hub) oder nutzen Sie ExpressRoute Direct, um sich für sehr hohe Bandbreiten mit dem Microsoft-Edge zu verbinden.

Typische Bereitstellungssequenz:

• ExpressRoute-Leitung erstellen in Azure und den Service Key notieren.
• Service Key mit dem Anbieter teilen und die physische Querverbindung sowie das VLAN koordinieren.
• Peering konfigurieren (privat/Microsoft), BGP-Peer-IPs und ASNs auf beiden Seiten.
• Leitung mit VNet(s) verknüpfen über eine ExpressRoute-Verbindung zu einem virtuellen Netzwerkgateway oder Virtual WAN-Hub und die BGP-Routen validieren.

Achten Sie darauf, die Auswahl der BGP-ASNs, die Router-Peer-IPs, überlappende IP-Adressräume und die benötigte Kapazität der Gateway-SKU im Voraus zu planen.

FastPath, Global Reach, Gateway-SKUs und Leistungsabwägungen

ExpressRoute FastPath reduziert die Latenz und erhöht den Durchsatz, indem der Gateway-Host umgangen wird und Pakete direkt zwischen Ihrem lokalen Gerät und den NICs der VMs/Instanzen auf dem VNet-Datenpfad weitergeleitet werden. Es ist ideal für latenzempfindliche Workloads, hat aber Anforderungen und Einschränkungen: FastPath erfordert privates Peering, eine ExpressRoute-Leitung, die dies unterstützt, und eine SKU für das virtuelle Netzwerkgateway, die FastPath explizit unterstützt (Basic-Gateways werden nicht unterstützt). FastPath beeinflusst auch die Inspektion und den Datenverkehrsfluss: Da Pakete den Gateway-Host umgehen, sehen Sicherheits-Appliances oder zentralisierte Inspektionssysteme, die auf Gateway-gehostetes Hairpinning angewiesen sind, den Datenverkehr möglicherweise nicht, es sei denn, Sie leiten den Verkehr durch inline platzierte NVAs oder über erzwungenes Tunneling.

ExpressRoute Global Reach ermöglicht es Ihnen, zwei oder mehr lokale Standorte über den Microsoft-Backbone miteinander zu verbinden – nützlich, wenn Microsoft den privaten Datenverkehr zwischen Standorten transportieren soll, anstatt ihn über ISP-Verbindungen zu leiten. Um Global Reach zu nutzen, müssen Sie an beiden Standorten ExpressRoute-Leitungen haben, Global Reach auf den Leitungen aktivieren und sicherstellen, dass der Anbieter dies unterstützt. Die Abwägungen zwischen Leistung und Kosten sind einfach: Verwenden Sie ExpressRoute Direct oder mehrere Leitungen mit hoher Bandbreite für Durchsatz und Resilienz; nutzen Sie Standard/Lokal-Leitungen für kostengünstigere Konnektivität nur innerhalb der Metro-Region; und setzen Sie FastPath ein, wo Gewinne im Mikrosekundenbereich wichtig sind, aber akzeptieren Sie Designänderungen bei der NVA-Platzierung und Paketinspektion.

WAN-Architekturmuster: Virtual WAN, VPN vs. ExpressRoute, Routing und häufige Designfallen

Beim Entwurf eines WAN zu Azure kristallisieren sich drei dominante Muster heraus: Hub-and-Spoke unter Verwendung von Virtual Network Gateway(s), Virtual WAN (verwalteter Hub) mit integrierter SD-WAN/Zweigstellenanbindung und eine reine ExpressRoute-Fabric mit VNet-Peering oder Virtual WAN-Anbindungen. Virtual WAN vereinfacht die Anbindung von Zweigstellen und skaliert gut für viele S2S/VPN-Tunnel und SD-WAN-Integrationen, verursacht jedoch höhere laufende Kosten und verwendet das Routing-Modell des Virtual WAN Hubs. Herkömmliche Virtual Network Gateways (VpnGw1/2/3-Familien) sind für eine begrenzte Anzahl von Tunneln kostengünstiger, erfordern aber für transitive Szenarien Gateways pro VNet. ExpressRoute bietet vorhersehbare Latenz und Durchsatz und lässt sich gut mit Virtual WAN kombinieren, wenn Sie sowohl private Backbone-Konnektivität als auch eine verwaltete Aggregation von Zweigstellen benötigen.

Zu den wichtigsten Routing- und Betriebsaspekten, die fehleranfällig sind, gehören überlappende IP-Adressräume zwischen On-Premises und VNets, eine falsche BGP-ASN- oder Peer-IP-Konfiguration (Sie müssen BGP sowohl auf dem Virtual Network Gateway als auch auf Ihrem Customer Edge aktivieren) und unbeabsichtigte UDRs oder NSG-Regeln, die über BGP gelernte Präfixe blockieren. Machen Sie sich außerdem die Routing-Priorität klar: Systemrouten (BGP/verbunden) haben im Allgemeinen Vorrang vor UDRs, es sei denn, Sie konfigurieren Next Hops explizit anders. Stellen Sie sicher, dass Forced Tunneling/Internet-Breakouts und NVA-Inspektionspunkte getestet werden, wenn Sie ExpressRoute und VPN kombinieren, und überprüfen Sie die unterstützten Routenlimits und die Anzahl der VPN-Gateway-Tunnel für die von Ihnen gewählte SKU.

Praktisches Problem: Anwendungsfallszenario

Szenario: Die Contoso Corp hat ein primäres Rechenzentrum in Washington, D.C. und eine bestehende Azure-Präsenz mit VNets in East US und East US 2. Contoso verfügt bereits über eine von einem Provider vermittelte ExpressRoute-Leitung mit Peering am Metro-Standort Ashburn und muss ein zweites Rechenzentrum in Virginia anbinden sowie eine Konnektivität mit geringer Latenz zwischen beiden Rechenzentren und ihren VNets ermöglichen.

Herausforderung: Sie benötigen eine resiliente, latenzarme Konnektivität zwischen den Rechenzentren und Azure, möchten die Exposition gegenüber dem öffentlichen Internet minimieren und benötigen Transit über das Microsoft-Backbone zwischen On-Premises-Standorten, ohne größere Umbauten am On-Premises-Routing vornehmen zu müssen.

Empfohlener Ansatz:

1. Stellen Sie eine zweite ExpressRoute-Leitung am zweiten Rechenzentrum bereit und beauftragen Sie den Provider, das Peering am selben Peering-Standort (Ashburn) einzurichten. Verwenden Sie zunächst eine Standard-Leitung und planen Sie für Premium, falls globale VNet-Erreichbarkeit oder eine erhöhte Routenkapazität erforderlich ist.
2. Stellen Sie dem Provider den Service Key jeder Leitung zur Verfügung, um die Cross-Connects abzuschließen, und aktivieren Sie dann ExpressRoute Global Reach zwischen den beiden Leitungen, damit die On-Premises-Standorte privaten Datenverkehr über das Microsoft-Backbone austauschen können.
3. Stellen Sie das Virtual Network Gateway im Hub-VNet bereit oder aktualisieren Sie es auf eine ExpressRoute-fähige SKU, die FastPath unterstützt (vermeiden Sie Basic); aktivieren Sie privates Peering mit BGP, legen Sie eindeutige lokale ASNs und Peer-IPs fest und geben Sie die On-Premises-Präfixe bekannt.
4. Wenn latenzempfindliche Workloads vorhanden sind, aktivieren Sie ExpressRoute FastPath für die private Peering-Verbindung, nachdem Sie überprüft haben, dass NVAs und Inspektionspfade neu konzipiert wurden, um den umgangenen Gateway-Host zu berücksichtigen.

Begründung: Zwei Leitungen mit Global Reach bieten einen resilienten, privaten Transit über das Microsoft-Backbone zwischen Rechenzentren und Azure, ohne den Datenverkehr dem öffentlichen Internet auszusetzen. Die Aktivierung von FastPath verbessert die Latenz für sensible Datenflüsse, erfordert jedoch Unterstützung durch die Gateway-SKU und Designanpassungen für die Paketinspektion und NVAs.

Alle Domänen · Azure Virtual Network Design →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →