AZ-104 — Virtuelle Netzwerke: 75 Übungsfragen

Step 1: Verständnis der Scope-Eigenschaften von ASGs: Application Security Groups sind logische Gruppierungen von NICs/VMs, die innerhalb einer Subscription und Region angelegt werden. Sie vereinfachen NSG-Regeln, weil Sie statt IP-Adressen ASG-Namen verwenden können. Wenn Ihre Umgebung peered VNets in unterschiedlichen Regionen oder Subscriptions hat, können die ASGs nicht automatisch über diese Grenzen hinweg referenzieren – Sie müssen separate ASGs in jeder Scope erstellen.

Step 2: NSG-Regeln und Peering-Interaktion: NSGs können ASGs nur dann referenzieren, wenn beide in derselben Subscription/Region vorhanden sind. Peering stellt L3-Konnektivität zwischen VNets her, ändert aber nicht die Verwaltungs- und Gültigkeitsgrenzen von ASGs. Daher: Peering löst das ASG-Scope-Problem nicht, Sie müssen administrative Maßnahmen ergreifen (ASG-Duplikation oder andere Namenskonventionen), um ein konsistentes Regelwerk zu erhalten.

Step 3: Operationalisieren und pflegen: Legen Sie Prozesse und Automation (ARM/Bicep, IaC) an, um ASGs und NSG-Regeln über mehrere Subscriptions/Regionen zu synchronisieren, und testen Sie die effektive Sicherheitskonfiguration mittels Network Watcher und Sicherheits-Audits. Achten Sie auf Konsistenz bei Namen/Tags, um menschliche Fehler zu reduzieren. Trap: Ein häufiger Trugschluss ist zu glauben, ASGs seien global innerhalb eines Tenants oder würden automatisch über Peering hinweg funktionieren. Das führt zu Fehlkonfigurationen und Sicherheitslücken. Zudem wird gelegentlich angenommen, ASGs könnten NSGs ersetzen — ASGs sind lediglich eine Gruppierung, die NSG-Filter einfacher macht. Warum die falschen Optionen nicht passen: - "ASGs können NICs in peered VNets referenzieren, sodass nur eine ASG pro Tenant nötig ist": Falsch — ASGs sind nicht tenantweit; ihr Scope ist Subscription/Region und sie können NICs außerhalb dieses Geltungsbereichs nicht referenzieren. - "ASGs ersetzen NSGs vollständig und benötigen keine NSG-Regeln mehr": Falsch — ASGs sind eine Ergänzung, keine Alternative; sie vereinfachen NSG-Regeln, aber ohne NSGs existieren keine Traffic-Filtern und -Kontrollen.

Step 1: Prinzip und Voraussetzungen — VNet-Peering ist nicht transitiv und routet standardmäßig nicht Spoke-zu-Spoke-Verkehr über eine dritte VNet-Instanz. Um Zwangsrouting durch eine NVA im Hub zu implementieren, müssen Sie die Routing-Entscheidung in den Spoke-VNets durch User-Defined Routes (UDRs) erzwingen, die als Next Hop die private IP-Adresse der NVA im Hub setzen. Die NVA muss Pakete weiterleiten können (IP-Forwarding auf der NIC aktiv) und Peering-Einstellungen müssen Forwarded Traffic erlauben.

Step 2: Konfiguration und Tradeoffs — Erstellen Sie in jedem Spoke eine Route (z. B. Ziel 10.1.0.0/16 → Next Hop IP 10.0.0.4 [NVA im Hub]). Aktivieren Sie IP forward auf der NVA-NIC, damit das OS/VM Pakete für andere Subnetze annimmt und weiterleitet. In den Peering-Objekten zwischen Hub und Spoke aktivieren Sie Allow forwarded traffic (AllowForwardedTraffic), damit das Peering Forwarding zulässt. Tradeoffs: Zwangsrouting bedeutet erhöhte Latenz und potenziellen Engpass am NVA (Skalierung nötig); zudem komplexere Fehlersuche und Abhängigkeiten vom Hub-NVA. Beachten Sie Kosten für NVA-VMs, und planen Sie Hochverfügbarkeit (Availability Set/Zone oder Scale-Set) ein.

Step 3: Validierung und Betrieb — Testen Sie Spoke-zu-Spoke-Verbindungen und prüfen Sie Pfade mit Network Watcher (IP Flow Verify, Next Hop, Packet Capture). Überwachen Sie NVA-CPU/Netzwerkmetriken, um Skalierungsbedürfnisse zu erkennen. Dokumentieren Sie UDRs/Peering-Konfiguration und rollenbasierten Zugriff, damit Änderungen kontrolliert erfolgen. Trap: Ein häufiger Fehler ist anzunehmen, dass AllowGatewayTransit oder simples Peering bereits Transit oder Traffic-Forwarding durch eine NVA erzwingen. AllowGatewayTransit betrifft die Nutzung von Gateways, nicht das Weiterleiten von Spoke-zu-Spoke-Traffic über eine NVA. Ebenso glauben manche, dass Peering automatisch Forwarding erlaubt — man muss AllowForwardedTraffic aktivieren und IP-Forwarding auf der NVA einstellen. Why each wrong answer fails: - Nur AllowGatewayTransit aktivieren: Falsch, weil AllowGatewayTransit ermöglicht, ein Gateway von einem VNet in einem anderen zu verwenden; es erzwingt kein NVA-basiertes Zwangsrouting zwischen Spokes. - NVA in jedes Spoke replizieren: Funktional korrekt für lokale Inspection, aber operational teuer und führt zu erhöhtem Managementaufwand; außerdem widerspricht es der Vorgabe, das NVA zentral im Hub zu nutzen. - UDRs auf Hub-Gateway und NAT auf Spokes: Falsch, weil UDRs in Spokes auf das Hub-Gateway zeigen würden Traffic zum Gateway leiten, aber für NVA-Inspection müssen Sie explizit auf die NVA-IP routen; NAT auf Spokes löst das Problem nicht sinnvoll und kann Adressierungs- sowie Übersetzungs- und Rückverkehrsprobleme verursachen. Daher ist die Kombination aus UDRs → NVA-IP, IP-Forwarding und AllowForwardedTraffic die korrekte Vorgehensweise.

Step 1: Anforderungen konkretisieren — Es werden zwei Layer-7-Funktionalitäten verlangt: Pfad-basiertes Routing (URL-Pfade leiten zu unterschiedlichen Backend-Pools) und cookie-basierte Session-Persistenz (Affinity basierend auf Cookies). Beide sind typische HTTP/HTTPS-spezifische Anforderungen.

Step 2: Technologieevaluation und Tradeoffs — Application Gateway ist ein Layer-7-Proxy, der genau diese Features bereitstellt: Pfad-basierte Routing-Regeln, multiple Listener, Unterstützung von SSL-Offload und Cookie-based Affinity. Die v2 SKU bietet verbesserte Skalierung und Performance. Ein interner (privater) Application Gateway kann direkt in einem VNet bereitgestellt werden, wodurch der gesamte Traffic intern bleibt. Im Gegensatz dazu bietet der Azure Load Balancer nur Layer-4-Funktionen (TCP/UDP) und kann keine URL-Pfadentscheidungen oder Cookie-Affinity auf HTTP-Ebene verarbeiten (er kann höchstens Source-IP-Affinity anbieten). Azure Front Door bietet Pfad-Routing und Affinity für globale Edge-Szenarien, ist aber ein öffentliches globales Angebot (nicht ideal für rein interne VNet-only Szenarien). Traffic Manager operiert auf DNS-Ebene und kann weder Pfad-basiertes Routing noch cookie-basierte Affinity leisten.

Step 3: Implementierungs- und Betriebsaspekte — Implementieren Sie ein internes Application Gateway v2, legen Sie private Frontend-IP(s) an, konfigurieren Sie HTTPS-Listener (falls gewünscht), definieren Sie Pfad-Sets (/shop -> PoolA, /api -> PoolB), und aktivieren Sie in den Backend-HTTP-Settings die Cookie-based Affinity. Überwachen Sie Performance, WAF-Logs (falls WAF aktiviert) und Verbindungslimits. Berücksichtigen Sie die Kosten im Vergleich zu einem einfachen Load Balancer und mögliche Latenz bei SSL-Offload. Trap: Ein häufiger Irrtum ist zu glauben, dass ein Standard Load Balancer oder Traffic Manager die gleichen Layer-7-Funktionen bieten. Load Balancer arbeitet auf Layer 4 und bietet keine HTTP-Pfad-Logik oder Cookie-Affinity; Traffic Manager ist DNS-basiert und hat keinen Einblick in Pfade oder HTTP-Cookies. Ebenso wird manchmal Front Door als Lösung für interne Anwendungen vorgeschlagen, obwohl es für Edge-Public-Szenarien optimiert ist. Why each wrong answer fails: - Internes Standard Load Balancer: Falsch — LB ist Layer 4, es kann keine URL-Pfade auswerten oder HTTP-Cookies für Session-Affinity verwenden. Es kann nur Port-/IP-basierte Verteilung durchführen. - Azure Front Door: Falsch für dieses Use-Case, weil Front Door ein globales, öffentliches Layer-7-Edge-Angebot ist; es könnte zwar Path-based Routing und Affinity bieten, ist aber nicht für rein interne VNet-Only-Architekturen vorgesehen und würde öffentliche Endpunkte erzeugen. - Azure Traffic Manager kombiniert mit NSGs: Falsch — Traffic Manager funktioniert über DNS-Routing und hat keine Möglichkeit, HTTP-Pfade oder Cookies zu untersuchen; NSGs regeln lediglich Netzwerkzugriffe, nicht Application-Layer-Routing/Affinity. Fazit: Ein internes Application Gateway v2 ist die richtige Wahl, weil es beide geforderten Layer-7-Funktionen bietet und innerhalb eines VNets betrieben werden kann. Planen Sie Skalierung, Logging und Sicherheitsfeatures (WAF) entsprechend Ihren Compliance-Anforderungen.

Step 1: Grundregel für Routing zwischen VNets — Azure verwendet die VNet-Adressbereiche, um Routingtabellen zu erstellen; wenn zwei VNets einander überlappende Adressen haben, kann Azure nicht unterscheiden, welche Zieladresse zu welchem VNet gehört, weshalb Peering verboten ist. Die primäre Voraussetzung für Peering (sowohl regional als auch global) ist daher, dass sich die Adressräume nicht überlappen.

Step 2: Abgrenzung von anderen Anforderungen — Global VNet Peering unterstützt Verbindungen über Regionen hinweg und kann Abonnements-übergreifend betrieben werden; es ist also nicht notwendig, dass beide VNets im selben Abonnement oder in derselben Ressourcengruppe sind. NSGs sind unabhängig vom Peering; unterschiedliche NSGs sind erlaubt und werden lokal pro Subnet ausgewertet.

Step 3: Planung und Praktikabilität — Planen Sie VNets mit ausreichend großem Adressraum (z. B. 10.0.0.0/16 und 10.1.0.0/16 für unterschiedliche VNets) um zukünftige Spokes und Subnetze zu berücksichtigen. Nutzen Sie IPAM/Design-Standards, um Konflikte zu vermeiden. Wenn Overlap vorliegt, müssen Sie Re-IP planen oder VPN/Firewall-basierten NAT einsetzen, was komplex und fehleranfällig ist. Trap: Ein häufiger Fehler ist die Annahme, dass Peering nur innerhalb des gleichen Abonnements möglich ist oder dass NSGs synchronisiert werden müssen. Peering funktioniert abonnementsübergreifend und NSGs sind lokal; RBAC auf Peering-Objekte muss jedoch korrekt gesetzt sein, um Peering zu erstellen. Why each wrong answer fails: - Option 2 (gleiches Abonnement): Falsch — Global Peering unterstützt Abonnements-übergreifend; es ist nicht zwingend, dass beide VNets im selben Abonnement sind. - Option 3 (gleiche Ressourcengruppe): Falsch — Ressourcengruppen sind Verwaltungsgrenzen; Peering ist unabhängig von RGs. - Option 4 (identische NSGs): Falsch — NSGs sind optional und spezifisch für Subnetze/VMs; sie müssen nicht identisch sein und sind keine Voraussetzung für Peering. Fazit: Vermeiden Sie überlappende Adressräume — das ist die entscheidende Voraussetzung für erfolgreiches Global VNet Peering.

Step 1: Anforderungen identifizieren — Die Anforderung ist explizit: verschlüsselte Verbindung über das Internet und keine dedizierte Leitung. Das ist der typische Anwendungsfall für ein Site-to-Site VPN mit Azure VPN Gateway (IPsec/IKE).

Step 2: Lösungsauswahl und Betrieb — Azure VPN Gateway stellt IPsec/IPsec-IKE konforme Tunnels bereit, die verschlüsselt über das Internet geführt werden. Die Einrichtung ist relativ schnell, kostengünstig und eignet sich für Niederlassungen oder temporäre Verbindungen. Beachten Sie Gateway-SKU-Beschränkungen hinsichtlich maximaler Durchsatzraten und Anzahl paralleler Tunnel; für höhere Bandbreite kann eine leistungsfähigere SKU notwendig sein.

Step 3: Tradeoffs und zusätzliche Maßnahmen — VPN über das Internet ist sicher (Verschlüsselung), aber Latenz und Durchsatz sind vom Internetpfad abhängig. Für höhere Vorhersagbarkeit und Bandbreite ist ExpressRoute geeignet (aber das widerspricht der Anforderung "ohne dedizierte Leitung"). Überlegen Sie zusätzliche Sicherheitslayer (z. B. TLS, App-Level Encryption) und Monitoring (Gateway Metrics, Network Performance Monitor) und planen Sie ein Failover (z. B. sekundärer VPN-Tunnel oder ExpressRoute bei kritischen Workloads). Trap: Häufig wird angenommen, ExpressRoute sei verschlüsselt und über das Internet — ExpressRoute bietet eine private Verbindung (kein öffentlicher Internetpfad) und ist nicht automatisch über das Internet verschlüsselt; zudem kostet ExpressRoute und benötigt Provider-Koordination. VNet-Peering liefert keine Anbindung an on-prem und Virtual WAN ohne VPN-Funktion ist nutzlos für verschlüsselte Internet-Verbindungen. Why each wrong answer fails: - ExpressRoute mit Microsoft-Peering — falsch: ExpressRoute ist eine dedizierte private Verbindung (nicht über das öffentliche Internet); Microsoft-Peering ist für Zugriff auf Microsoft-Dienste, aber die Anforderung war keine dedizierte Leitung. - VNet-Peering zwischen dem VNet und dem lokalen Netzwerk — falsch: Peering verbindet Azure-VNets miteinander, nicht Ihr lokales Netzwerk. - Azure Virtual WAN ohne VPN-Funktion — falsch: Virtual WAN kann Hub-and-Spoke für SD-WAN und VPN unterstützen, aber ohne aktivierter VPN-Funktion erfüllt es nicht die Anforderung einer verschlüsselten Internetstrecke. Praxis-Tipp: Wählen Sie für schnelle, verschlüsselte Verbindungen über Internet das Azure VPN Gateway; für stabileren, latenz- und bandbreitenkritischen Verkehr prüfen Sie ExpressRoute oder hybride Designs (ExpressRoute-Primary, VPN-Backup).

Step 1: Verständnis von Gateway‑Transit. In einer Hub‑Spoke‑Topologie wird häufig ein zentrales VPN/ExpressRoute‑Gateway im Hub bereitgestellt. Damit Spoke‑VNets dieses entfernte Gateway nutzen können, müssen Peering‑Optionen korrekt gesetzt werden: der Hub muss Gateway‑Transit erlauben, und der Spoke muss angeben, dass es das entfernte Gateway nutzen soll.

Step 2: Konfiguration der Peering‑Flags. Auf dem Hub‑VNet in der Peering‑Definition muss AllowGatewayTransit aktiviert werden. Auf dem Spoke‑VNet in der Peering‑Definition muss UseRemoteGateways aktiviert werden. Diese Kombination ermöglicht, dass Traffic aus dem Spoke zum Hub geroutet wird und über das Hub‑Gateway das Ziel im entfernten Netzwerk erreicht.

Step 3: Tradeoffs, Deployment und Tests. Verwenden Sie diese Funktion mit Bedacht: Gateway‑Transit erlaubt zentralisierte Kontrolle und kann Kosten sparen, bringt aber auch Abhängigkeiten und potenzielle Bandbreitenengpässe im Hub. Testen Sie Routingpfade, UDRs und Security‑Appliances. Beachten Sie auch Abonnement‑Grenzen: das Hub‑Gateway muss sich in demselben Abonnement wie der Hub‑VNet‑Peer befinden oder entsprechend freigegeben werden. Trap: Ein verbreiteter Irrtum ist, dass AllowGatewayTransit allein ausreicht; tatsächlich müssen beide Seiten korrekt konfiguriert sein (Hub und Spoke). Außerdem verwechseln einige Admins UseRemoteGateways mit AllowForwardedTraffic oder AllowVirtualNetworkAccess – diese haben unterschiedliche Effekte. Warum jede falsche Antwort fehlschlägt: - Option 3 (AllowVirtualNetworkAccess deaktivieren): AllowVirtualNetworkAccess deaktivieren würde die VNet‑zu‑VNet‑Kommunikation unterbinden; es verhindert nicht das Routing zum Gateway und löst nicht das Problem. Es macht das Peering praktisch nutzlos für Direktverkehr. - Option 4 (ASGs über VNets hinweg konfigurieren): ASGs sind auf eine einzelne VNet beschränkt und können nicht über VNets hinweg referenziert werden. ASGs haben nichts mit Gateway‑Transit zu tun und können nicht dazu verwendet werden, Gateway‑Routing zu konfigurieren. Zusätzliche Hinweise: Wenn der Hub mehrere Gateways oder NVAs enthält, prüfen Sie die Notwendigkeit von AllowForwardedTraffic für bestimmte Szenarien mit NVA/Firewalls. Überwachen Sie anschließend das Gateway‑Verhalten, um Engpässe zu vermeiden und Kosten durch Datenübertragungen zwischen Regionen abzuschätzen.

Step 1: Überprüfen der Peering‑Flags. Für VNet‑Peering muss AllowVirtualNetworkAccess (Standard) auf beiden Peerings aktiviert sein, damit VMs in unterschiedlichen VNets routen und direkt kommunizieren können. Wenn diese Option deaktiviert ist, ist das Peering zwar definiert, aber Verkehr zwischen den VNets wird blockiert.

Step 2: NSG‑Regeln prüfen und anpassen. Selbst wenn Peering korrekt konfiguriert ist, können NSGs auf Subnetze oder NICs eingehenden Verkehr blockieren. Sie müssen eine NSG‑Regel erstellen oder anpassen, die eingehende Verbindungen auf TCP 3389 vom Quell‑Subnetz (oder besser: einer ASG, die die Quell‑VMs repräsentiert) zum Ziel‑Subnetz/den Ziel‑NICs erlaubt. Achten Sie auf Priorität und auf ausgehende Regeln auf der Quellseite.

Step 3: Operational Tradeoffs und Tests. Testen Sie nach Änderungen die Verbindung und nutzen Sie Network Watcher‑Verbindungsprüfungen und NSG‑Flow logs. Tradeoffs: Offenere NSG‑Regeln erhöhen Angriffsfläche — daher möglichst nur spezifische ASGs oder IP‑Ranges zulassen und RDP über Bastion oder Just‑In‑Time nutzen. Trap: Eine häufige Fehlannahme ist, dass Peering automatisch alle Ports freischaltet; Peering stellt nur die Route her, aber NSGs oder lokale VM‑Firewalls können Verbindungen blockieren. Ebenso wird UseRemoteGateways oft fälschlich zur Lösung gewählt, obwohl diese Option sich auf das Nutzen des Remote‑Gateways (z. B. VPN Gateway) bezieht, nicht auf einfache VNet‑zu‑VNet‑Kommunikation. Warum jede falsche Antwort fehlschlägt: - Option 3 (UseRemoteGateways): Diese Einstellung erlaubt einer VNet‑Peering‑Seite, das VPN‑Gateway einer entfernten VNet zu verwenden (gateway transit). Sie ist für direkte VNet‑zu‑VNet‑Kommunikation über Peering nicht erforderlich und kann sogar falsch sein, wenn kein Gateway geteilt werden soll. - Option 4 (Public‑IP‑Whitelist und Internetzugang): Über das öffentliche Internet zu gehen erzeugt Sicherheits‑ und Latenzprobleme; es ist unnötig, wenn Peering möglich ist. Außerdem würde es die Umgebung exponieren und ist nicht geeignet für sicheres internes RDP. Hinweis: Achten Sie zusätzlich auf lokale Windows‑Firewall‑Einstellungen und mögliche UDRs, die Traffic umleiten könnten. Für sichere Administration empfiehlt sich Azure Bastion oder Just‑In‑Time‑Zugriff über Azure Security Center statt dauerhafter globaler RDP‑Öffnung.

Step 1: Anforderungen prüfen — Produktionsumgebung verlangt SLA, statische virtuelle IP (VIP) im VNet, Unterstützung für TCP/UDP Protokolle und Skalierbarkeit. Interner Zugriff (keine öffentliche IP) ist gefordert.

Step 2: Optionen bewerten — Basic Load Balancer ist für Test-/Kleinumgebungen gedacht, hat keine SLA, geringere Skalierbarkeit und Einschränkungen (z.B. Backend‑Poolgrößen, Limitierungen bei Verfügbarkeitszonen). Standard Internal Load Balancer (Standard SKU) unterstützt interne VIPs, bietet SLA, verbessertes Monitoring, größere Backend‑Pools und Zonen‑Redundanz. Application Gateway ist Layer‑7 und für HTTP/S gedacht — es kann intern betrieben werden, ist aber für Layer‑4 TCP/UDP und allgemeine Protokolle nicht optimiert. Azure Traffic Manager ist DNS‑basiertes Traffic‑Routing und nicht geeignet für internen L4‑Loadbalancing.

Step 3: Betrieb & Tradeoffs — Standard ILB bietet robuste Betriebsmerkmale: Integration mit NSGs, bessere DDoS‑Standards, eignet sich für stateful und stateless Dienste die TCP/UDP benötigen. Allerdings erfordert Standard genauere NSG/Routing-Konfigurationen und verfügt über andere Kosten-/Skalierungsprofile als Basic. Wenn HTTP‑Layer‑Steuerung und WAF benötigt würden, wäre Application Gateway relevant, aber für generische TCP/UDP‑Services ist Standard ILB die richtige Wahl. Trap: Ein häufiger Fehler ist zu glauben, dass Basic-LB für interne Dienste ausreichend ist; viele Admins unterschätzen Produktionslimits (keine SLA). Außerdem gibt es Missverständnisse in Bezug auf NSG‑Anwendung: RBAC oder Identity sind hier weniger relevant, aber Netzwerkregel‑Fehler (z.B. zu strenge NSGs) können den ILB‑Traffic blockieren. Governance/Tags und Subscription‑Grenzen dürfen die Auswahl nicht beeinflussen, aber Limits müssen geprüft werden. Why each wrong answer fails: - Basic Load Balancer: Falsch — keine Produktions‑SLA, eingeschränkte Skalierbarkeit und Limits für Backend‑Pools; nicht empfohlen für kritische Produktionsdienste. - Application Gateway: Falsch — ist ein Layer‑7‑Gateway (HTTP/HTTPS) mit anderen Fähigkeiten; nicht optimal für generische TCP/UDP‑Workloads. - Azure Traffic Manager: Falsch — DNS‑basierte globale Verteilung, kein interner L4‑Loadbalancer, keine direkte VIP/Zielnetzwerk‑Einbindung innerhalb des VNet. Fazit: Für internen, protokollunabhängigen, skalierbaren Produktions-LB mit SLA ist der Standard Internal Load Balancer die richtige Wahl.

Step 1: Anforderungen gegen Produkte abgleichen — URL-basiertes Routing, TLS-Offloading, WAF und Cookie-basierte Affinity sind klassische Layer-7-Funktionalitäten. Application Gateway (insbesondere v2) ist ein Layer-7 Load Balancer, der all diese Anforderungen direkt unterstützt: URL-basiertes Routing zur gezielten Weiterleitung von Pfaden, integrierte WAF-Policies, TLS-Terminierung/Offload und Cookie-basiertes Session Affinity (cookie-based affinity).

Step 2: Vor- und Nachteile abwägen — Application Gateway ermöglicht detaillierte Routingregeln und Sicherheitskontrollen nahe bei den Backends; es kann innerhalb eines VNets in Subnetzen platziert werden und hat enge Integration mit NSGs/UDRs. Nachteile: Kosten sind höher im Vergleich zu einfachem Layer-4-LB; Latenz etwas höher als bei reinem Layer-4-LB. Für globale, edge‑optimierte Szenarien könnten Sie Azure Front Door ergänzend einsetzen, aber Front Door ist eher ein globaler CDN/Layer-7-Service und hat andere Charakteristika.

Step 3: Betriebsaspekte und Implementierung — Planen Sie Subnet (dedicated ApplicationGateway-Subnet), prüfen Sie Zertifikatsverwaltung (Key Vault-Integration möglich), konfigurieren Sie WAF-Regeln und erstellen Sie Backend-Pools (VMs, VMSS, NICs oder IPs). Testen Sie Affinity und Health-Probes, sowie Logs in Azure Monitor/WAF-Logs für Detektion und Tuning. Trap: Ein häufiger Fehler ist, Layer-4- und Layer-7-Produkte zu vermischen: Azure Load Balancer ist großartig für TCP/UDP-Load-Balancing und niedrige Latenz, unterstützt aber kein URL-basiertes Routing und keine WAF; Admins wählen es oft versehentlich wegen Performance-Anforderungen, obwohl Applikation-Level-Features gebraucht werden. Warum die falschen Antworten scheitern: - Antwort 2 (Load Balancer): Azure Load Balancer operiert auf Layer 4; es bietet keine URL-basierten Regeln, kein TLS-Offload (TLS bleibt an den Backends) und keine integrierte WAF. Session-Affinity beim Standard-LB ist auf 5-tuple oder SourceIP möglich, aber keine Layer-7 Cookie-Affinity. - Antwort 3 (Front Door): Azure Front Door ist ein globales Layer-7-Service, das TLS, WAF und URL-Routing bietet, jedoch ist es primär als globaler Edge-Load-Balancer/CDN für öffentlich zugängliche Anwendungen gedacht. Für interne VNet-interne Routing- und VNet-Platzierung ist Application Gateway die passendere Lösung. - Antwort 4 (Traffic Manager): Traffic Manager ist DNS-basiertes Routing auf globaler Ebene und bietet keine WAF oder TLS-Offload; URL-basiertes Routing in der Weise wie Application Gateway kann Traffic Manager nicht durchführen. Kurz: Für interne VNet-Platzierung mit URL-Routing, TLS-Offload, WAF und Cookie-Affinity ist Application Gateway die geeignete Wahl.

Step 1: Anforderungen klären – Die Verbindung soll verschlüsselt sein, über das öffentliche Internet laufen, schnell bereitstellbar sein und keine physische Leitung erfordern. Das passt typischerweise zu einem Site‑to‑Site IPsec VPN zwischen Ihrem lokalen VPN‑Gateway und dem Azure VPN‑Gateway.

Step 2: Abwägungen und Betrieb – Site‑to‑Site VPN ist schnell einzurichten, kostengünstig und verschlüsselt (IPsec/IKE). Es eignet sich für Standard‑Produktion oder Backups, hat jedoch höhere Latenzen und stark schwankende Durchsätze im Vergleich zu physischen Verbindungen wie ExpressRoute. ExpressRoute bietet keine native Verschlüsselung über das Private Peering (bei Bedarf muss Verschlüsselung höherer Schicht konfiguriert werden) und benötigt eine dedizierte Leitung, was Zeit und Kosten erhöht. Point‑to‑Site ist für einzelne Clients gedacht, nicht für gesamte Standorte. Azure Firewall ist eine Paket‑/Anwendungs‑Firewall, keine Site‑to‑Site‑Konnektivitätslösung.

Step 3: Umsetzung – Erstellen Sie ein Azure VPN Gateway (VNet‑Gateway) mit geeigneter SKU (z. B. VpnGw1/2/3) für benötigte Durchsatzanforderungen, konfigurieren Sie auf Ihrer Seite ein kompatibles VPN‑Gateway/Router mit IPsec/IKE, richten Sie BGP ein, falls dynamisches Routing gewünscht ist, und testen Sie Verbindung und Durchsatz. Berücksichtigen Sie Redundanz und SLA (aktive/aktive oder aktive/standby Konfiguration abhängig von SKU). Trap: Ein häufiger Fehler ist zu glauben, dass ExpressRoute immer die bessere Wahl ist; wenn schnelle Implementierung, Verschlüsselung über Internet und keine dedizierte Leitung gefordert sind, ist Site‑to‑Site VPN oftmals passender. Außerdem wird manchmal Point‑to‑Site verwechselt – dieses ist nur für einzelne Workstation‑Verbindungen geeignet. Why each wrong answer fails: ExpressRoute: Bietet dedizierte Leitungen, benötigt oft Provider‑Setup und bietet keine native IPsec‑Verschlüsselung über das private Peering; nicht die schnelle, rein‑internetbasierte Verschlüsselungsoption. Point‑to‑Site VPN: Für einzelne Benutzer/Clients gedacht, nicht für ganze Standorte. Azure Firewall: Ist eine Sicherheitslösung zur Inspektion/Filterung, keine Standort‑zu‑Standort VPN‑Konnektivität.

Step 1: Grundprinzip verstehen — Azure VNet-Peering stellt eine private Layer-3-Verbindung zwischen zwei VNets her, aber diese Verbindungen sind nicht transitive. Das bedeutet: wenn A<->B und B<->C gepeert sind, erlaubt das nicht automatisch Verkehr von A nach C über B. Für Kommunikation zwischen A und C brauchen Sie entweder ein Direkt-Peering A<->C oder ein Architekturmuster, das Transit explizit unterstützt (z. B. Hub-&-Spoke mit einem zentralen Hub-VNet, das als Gateway fungiert oder Azure Virtual WAN/Transit Gateway-Lösungen).

Step 2: Optionen abwägen — Direkte Peerings sind einfach und performant, eignen sich aber nicht bei vielen VNets (Skalierbarkeits- und Verwaltungsaufwand). Ein Hub-&-Spoke-Modell mit einem zentralen Gateway ist in großen Umgebungen sinnvoll, weil es zentrales Sicherheits- und Monitoringmanagement ermöglicht. Azure Virtual WAN oder ExpressRoute können bei globalen, komplexen Anforderungen die bessere Wahl sein.

Step 3: Umsetzung und Trade-offs — Bei direktem Peering sind Latenz und Durchsatz optimal, aber Anzahl der Peerings steigt quadratisch mit Anzahl der VNets. Hub-&-Spoke reduziert Peerings, erfordert aber ein Gateway und ggf. zusätzliche Kosten; Gateway-basiertes Routing verursacht oft höhere Latenz und Bandbreitenkosten. Entscheiden Sie anhand Anzahl VNets, Sicherheitsanforderungen und Kosten. Trap: Eine häufige Fehlannahme ist, dass Peering wie ein Router funktioniert und Routen automatisch transitive weiterleitet. Peering propagiert Routen nicht transitive; Entwickler übersehen das oft bei Multi-Subscription-Designs. Warum die falschen Antworten scheitern: - Antwort 2 (UseRemoteGateways auf VNet-B): UseRemoteGateways erlaubt einem VNet, das remote Gateway eines gepeerten VNet zu verwenden (z. B. Spoke nutzt Hub-Gateway). Es implementiert jedoch keine Transitivität zwischen zwei unterschiedlichen Peering-Verbindungen (A->B->C) und funktioniert nur im Kontext eines Gateways, nicht für generisches Transit. - Antwort 3 (UDR in VNet-B über Peering): UDRs können Next Hops wie virtuelle Appliances oder Internet/Gateway referenzieren, aber sie können nicht als Next Hop "Peering zu einem anderen VNet" verwenden, um transitive Weiterleitung über Peering zu erreichen. Peering ist eine Azure-kontrollierte Verbindung; UDR kann diese nicht als Router-Hop erzwingen. - Antwort 4 (globale Peering-Option): Global VNet Peering erlaubt Peering über Regionen hinweg, verbessert aber nicht die Transitivität; es erlaubt nur Cross-Region-Peering direkt zwischen zwei VNets. Es löst nicht das transitive Routing-Problem zwischen A-B-C. Kurz: Implementieren Sie direkte Peerings oder ein Hub-&-Spoke/Gateway-Transit-Design abhängig von Skalierung, Kosten und Sicherheitsanforderungen.

Step 1: Anforderungen analysieren — Budgetbegrenzung, mehrere kleine Niederlassungen, verschlüsselte Verbindung über das Internet: Ein Site-to-Site (S2S) VPN ist in solchen Fällen die pragmatische, kosteneffiziente Lösung. Es bietet IPsec/IKE Verschlüsselung, ist schnell bereitzustellen und skalierbar für viele Standorte (ggf. über Hub-and-Spoke oder Virtual WAN).

Step 2: Technische Umsetzung und Gründe für Route-based + BGP — Route-based VPN-Gateways unterstützen dynamisches Routing und Multipath/Redundanz (z. B. mehrere Tunnels), weshalb sie gegenüber policy-based VPNs flexibler sind. BGP erlaubt automatisches Austauschen von Routen zwischen On-premise und Azure, erleichtert Failover und reduziert Fehler bei manueller Routenpflege. Bei kleinen Standorten ist der Durchsatz oft ausreichend und Kosten deutlich geringer als für ExpressRoute.

Step 3: Betriebs- und Sicherheitsaspekte — Überwachen Sie Tunnel-Performance mit Network Watcher und sichern Sie VPN-Shared-Keys, verwenden Sie starke Verschlüsselung (z. B. AES256), prüfen Sie NAT-Traversal-Einstellungen und planen Sie redundante Internet-Provider oder VPN-Tunnel für hohe Verfügbarkeit. Governance: Definieren Sie RBAC für Netzwerkadministratoren, dokumentieren Sie VPN-Konfigurationen und speichern Sie Konfigurationsschnipsel in einem sicheren Repository. Trap: Ein verbreiteter Irrtum ist, dass alle VPNs gleichwertig sind; policy-basierte VPNs sind limitiert und nicht ideal für Multi-Site/BGP-Setups. Außerdem wird oft fälschlich angenommen, dass VNet-Peering oder Azure Virtual WAN alleine die On-prem-Konnektivität ersetzen können. Warum jede falsche Antwort fehlschlägt: Antwort 1 (ExpressRoute pro Zweigstelle): Teuer und Overkill für kleine Standorte; ExpressRoute ist für hohe Bandbreiten und SLAs gedacht und nicht kosteneffizient für viele kleine Niederlassungen. Antwort 3 (VNet-Peering): VNet-Peering verbindet nur Azure-VNets und stellt keine Verbindung zwischen On-prem und Azure her. Antwort 4 (Virtual WAN ohne VPN Gateways): Virtual WAN ist ein nützliches Framework für zentrales Routing, benötigt aber Gateways/Verbindungen (z. B. VPN oder ExpressRoute) für On-prem Konnektivität; nur Virtual WAN ohne Gateways stellt keine Verbindung her. Fazit: S2S VPN mit route-based Konfiguration und BGP ist die angemessene Wahl für verschlüsselte, kosteneffiziente Verbindung kleiner Zweigstellen über das Internet.