Azure

Azure Application Gateway

Allgemeine Infos

Application Gateway verteilt HTTP- und HTTPS-Anfragen innerhalb einer Region anhand von Hostnamen, URL-Pfaden und Regeln auf Backend-Pools aus VMs, Scale Sets, App Services oder beliebigen IP-Adressen. Mit der SKU WAF_v2 schützt die integrierte Azure Web Application Firewall vor typischen Angriffen wie SQL-Injection und Cross-Site-Scripting.

Aktuell sind die SKUs Standard_v2 und WAF_v2 mit Autoskalierung, Zonenredundanz und statischer VIP, dazu eine Basic-SKU in der Vorschau für kleinere Lasten. Application Gateway V1 (Standard und WAF) wurde am 28. April 2026 eingestellt. Microsoft gibt keine Verfügbarkeit mehr zu, blockiert schrittweise den Datenpfad und löscht nicht migrierte V1-Ressourcen nach vorheriger Ankündigung.

Abgrenzung: Azure Front Door arbeitet global am Edge, Application Gateway regional im eigenen VNet. Beide werden oft kombiniert. Azure Load Balancer arbeitet auf Ebene 4 ohne HTTP-Funktionen.

Funktionsweise & Details

Aufbau eines Application Gateway v2:

  1. Eigenes Subnetz im VNet, in dem nur Application Gateways liegen dürfen.
  2. Frontend-IP: öffentlich, privat oder beides, bei v2 immer statisch.
  3. Listener für Port und Hostnamen, Zertifikate idealerweise aus Azure Key Vault über eine Managed Identity.
  4. Routingregeln mit URL-Pfadzuordnung, Weiterleitungen und Header-Umschreibung.
  5. Backend-Einstellungen mit Protokoll, Port, Sitzungsaffinität und Integritätstests.
  6. Optional WAF-Richtlinie mit verwalteten Regelsätzen und eigenen Regeln.

V2 unterstützt zusätzlich gegenseitige TLS-Authentifizierung (mTLS), TCP/TLS-Proxy, Private Link und den Einsatz als Ingress für AKS. Die Abrechnung ist verbrauchsorientiert (feste Gateway-Stunden plus Kapazitätseinheiten).

Vorteile & Nutzen

  • URL- und Host-basiertes Routing erlaubt mehrere Webanwendungen hinter einer IP-Adresse
  • TLS-Offloading entlastet Backend-Server und zentralisiert die Zertifikatsverwaltung in Key Vault
  • Integrierte WAF schützt Webanwendungen ohne zusätzliche Appliance
  • Autoskalierung und Zonenredundanz in v2 fangen Lastspitzen und Zonenausfälle ab

Praxisbeispiel

Ein Hersteller von Industrieöfen betreibt ein Kundenportal und eine Ersatzteil-API auf VMs in Azure, beide bisher hinter einem Application Gateway V1. Nach der Ankündigung der V1-Einstellung migriert die IT mit dem erweiterten Klon-Skript auf WAF_v2, übernimmt die Zertifikate in Key Vault und testet die neue Instanz parallel. Der Verkehr wird per DNS-Umstellung übernommen, das alte Gateway danach gelöscht. Die WAF läuft zunächst im Erkennungsmodus und wird nach Auswertung der Protokolle scharf geschaltet.

Worauf sollte man achten?

  • Noch vorhandene V1-Gateways sofort migrieren, seit 28. April 2026 gibt es weder Support noch SLA, und Microsoft löscht nicht migrierte Ressourcen
  • Das Migrationsskript überträgt nur die Konfiguration, Diagnoseeinstellungen und Verkehrsumstellung musst Du selbst erledigen
  • Subnetz groß genug planen, weil Autoskalierung zusätzliche Instanzen im Subnetz startet
  • WAF-Regeln zuerst im Erkennungsmodus betreiben und Ausnahmen gezielt pflegen
  • Kosten über Kapazitätseinheiten kalkulieren, eine Mindestanzahl an Instanzen erhöht die Grundkosten

Lizenz & Verfügbarkeit

Standard_v2 und WAF_v2 werden nach Gateway-Stunden (Festanteil) und genutzten Kapazitätseinheiten abgerechnet, dazu Datenverkehr. WAF_v2 ist teurer als Standard_v2. Basic-SKU in der Vorschau. Application Gateway V1 eingestellt am 28. April 2026. Stand: Oktober 2026.

Fazit

Application Gateway v2 ist der regionale Einstieg für Webanwendungen in Azure. Wer noch V1 betreibt, hat akuten Handlungsbedarf.

Weiterführende Links

Verwandte Artikel