Azure Front Door vs. Application Gateway: Der Architektur-Showdown 2026

Im Jahr 2026 geht es bei der Architekturdebatte zwischen Azure Front Door (AFD) und Application Gateway nicht mehr um die binäre Wahl „Global vs. Regional“, sondern darum, wo Sie Ihren TLS-Handshake terminieren möchten und wie viel Sie für das Privileg eines Private Link Backhauls zu zahlen bereit sind. Wenn Sie Application Gateways immer noch als primären Edge-Ingress für multiregionale Microservices bereitstellen, überdimensionieren Sie wahrscheinlich Ihre Compute-Kosten und nutzen die massive Anycast-Edge-Kapazität von Microsoft zu wenig.

Die strukturelle Divergenz: Layer 7 am Edge vs. im VNet

Azure Front Door ist ein verteilter, mandantenfähiger Dienst, der an den über 190 Microsoft Points of Presence (PoPs) betrieben wird. Er nutzt Anycast, um den Datenverkehr zum nächstgelegenen Edge-Standort zu leiten. Umgekehrt ist Application Gateway (AppGW) eine verwaltete regionale Ressource, die direkt in Ihr Virtual Network (VNet) injiziert wird. Die Unterscheidung ist entscheidend: AFD beendet TCP/TLS am Edge (was die Round-Trip-Time für den initialen Handshake reduziert), während AppGW dies innerhalb Ihrer spezifischen Azure Region beendet.

Für hochperformante 2026-Workloads ist die „Split-TCP“-Architektur von Front Door der klare Gewinner in Bezug auf die Latenz. Durch die Beendigung des Handshakes näher am Benutzer durchlaufen Pakete Microsofts privates Glasfasernetzwerk vom PoP zum Origin, anstatt dem „Cold Potato“-Routing des öffentlichen Internets zu folgen. Wenn Ihre Benutzer global verteilt sind, ist die Platzierung eines AppGW hinter einer öffentlichen IP ein veraltetes Designmuster, das Jitter und unnötige Latenz einführt.

AFD Premium: Der Tod des Public-Facing Application Gateway?

Die Einführung von Azure Front Door Premium und seine tiefe Integration mit Private Link hat die Entscheidungsmatrix grundlegend verändert. Zuvor bedeutete die „Public IP“-Anforderung von AFD, dass Ihr App Service oder Internal Load Balancer (ILB) die IP-Bereiche von AFD (Service Tags) zulassen musste, was oft eine Compliance-Hürde darstellte.

Mit AFD Premium können Sie nun Private Link verwenden, um sich mit Ihren Backends zu verbinden. Dies bedeutet, dass Ihr Backend – sei es ein ILB für einen AKS-Cluster, ein Storage Account oder eine Reihe von VMs – keinen öffentlichen Endpunkt mehr benötigt. Dies macht das Public-Facing Application Gateway für die meisten Multiregion-Szenarien effektiv obsolet. Warum die Komplexität eines AppGW Scale Set (und seiner quälend langsamen 15-minütigen Bereitstellungszeiten) verwalten, wenn Sie die globale Skalierung von AFD mit einem privaten Tunnel nutzen können?

# Example: Checking Private Link Status for AFD Origin via CLI
az afd origin show \
  --origin-name my-aks-origin \
  --profile-name my-afd-profile \
  --resource-group rg-prod-network \
  --query "privateLinkAlias"

Application Gateway v2: Das letzte Bollwerk des VNet

Wann macht also das Application Gateway v2 im Jahr 2026 tatsächlich Sinn? Es gibt drei spezifische Szenarien, in denen es die überlegene, wenn nicht gar einzige Wahl bleibt:

• Nur interner Lastausgleich: Wenn Ihr Datenverkehr strikt „East-West“ oder „North-South“ von einem On-Premise ExpressRoute/VPN ist, kann AFD ihn nicht berühren. Sie benötigen AppGW für das VNet-interne L7-Routing.
• Benutzerdefinierte WAF-Regeln mit hohen Inspektionsgrenzen: Während AFD WAF leistungsstark ist, ermöglicht AppGW WAF v2 eine granularere Kontrolle über die Inspektion von Request Bodies (standardmäßig bis zu 128 KB, aber in einigen Konfigurationen anpassbar) und spezifische regionale Anforderungen an die Datenresidenz.
• Strikte Mutual TLS (mTLS) Anforderungen: Obwohl AFD mTLS unterstützt, fühlen sich Konfiguration und Zertifikatsverwaltung für komplexes, unternehmensweites mTLS oft „nativer“ und kontrollierbarer auf einer AppGW-Instanz an, wo Sie die vertrauenswürdige Stammzertifizierungsstelle auf Gateway-Ebene verwalten.

Es ist auch erwähnenswert, dass die AppGW v2 „Basic“-SKU (wenn wir die abgespeckten Versionen so nennen können) während Skalierungsereignissen immer noch ein Albtraum für die Performance ist. Bleiben Sie bei Standard_v2 oder WAF_v2 und halten Sie immer eine Mindestkapazität von 2 Einheiten, um die Cold-Start-Penalty zu vermeiden.

Die Mathematik des Ingress: Kosten pro RPS

Sprechen wir über kalte, harte Zahlen. Im Jahr 2026 werden die Kosten für Data Egress und „Request Processing Units“ (RPUs) oder „Capacity Units“ Ihr Budget sprengen, wenn Sie die falsche Wahl treffen. Für eine High-Traffic-Site, die 5.000 Requests Per Second (RPS) verarbeitet:

Azure Front Door (Standard/Premium)

• Grundgebühr: ca. 35 $ (Standard) bis 330 $ (Premium) pro Monat.
• Anfragegebühr: ca. 0,75 $ pro Million Anfragen.
• Datenübertragung: Sie zahlen für ausgehende Daten vom Edge zum Benutzer. Daten vom Azure Origin zum Edge sind 0 $ (dies ist eine massive versteckte Einsparung).

Application Gateway v2

• Fixkosten: ca. 180 $/Monat (WAF_v2).
• Capacity Unit (CU) Kosten: 0,008 $ pro CU-Stunde. 5.000 RPS (angenommen 10 KB durchschnittliche Größe und 2 KB Header) entsprechen in der Regel etwa 10–15 CUs.
• Datenübertragung: Sie zahlen Standard-VNet-Egress-Raten, die für große Volumen erheblich höher sein können als die ermäßigten Raten von AFD.

Fazit: Für hohes Volumen und globalen Datenverkehr ist Front Door fast immer günstiger, da es die Egress-Gebühr „Origin-to-Internet“ eliminiert. Weitere Informationen zur Optimierung Ihrer Cloud-Ausgaben finden Sie in unserem Leitfaden zur Kostenoptimierung für ExpressRoute und Egress.

Fortschrittliche WAF-Strategien: Ratenbegrenzung und Bot-Abwehr

Die WAF auf Front Door Premium ist den regionalen AppGW WAFs um Lichtjahre voraus. Im Jahr 2026 sind automatisierte Bot-Angriffe und DDoS-„Low and Slow“-Angriffe die Norm. AFD Premium enthält Bot Manager Rule Sets, die auf Microsoft Threat Intelligence basieren, welche bekannte „gute Bots“ (Google, Bing) identifiziert und „bösartige Bots“ herausfordert oder blockiert, bevor sie überhaupt Ihre Azure-Region erreichen.

Die Ratenbegrenzung auf AFD ist ebenfalls robuster. Sie können Ratenbegrenzungen basierend auf Client-IP, geografischem Standort oder sogar spezifischen Request Headern definieren. Wenn Sie von einem AppGW-zentrierten Design zu einem AFD-zentrierten Design wechseln, gewinnen Sie die Möglichkeit, den Datenverkehr am Edge zu droppen, wodurch Ihre Backend-Compute-Zyklen (und Autoskalierungskosten) für legitime Benutzer gespart werden.

# Partial ARM Template for AFD Rate Limiting Rule
{
  "name": "RateLimitRule",
  "priority": 100,
  "ruleType": "RateLimitRule",
  "action": "Block",
  "matchConditions": [
    {
      "matchVariable": "RemoteAddr",
      "operator": "IPMatch",
      "negateCondition": false,
      "matchValue": ["0.0.0.0/0"]
    }
  ],
  "rateLimitThreshold": 1000,
  "rateLimitDurationInMinutes": 1
}

Multiregionale Hochverfügbarkeit (DR)

Wenn Sie für echte Hochverfügbarkeit (99,99 %+) entwickeln, ist Application Gateway ein Single-Region-Failure-Point. Obwohl Sie in jeder Region ein AppGW bereitstellen und Azure Traffic Manager (DNS-basiert) davor schalten können, ist dies ein „Poor Man’s“ Global Load Balancing. DNS-basiertes Failover ist anfällig für TTL (Time to Live) Caching, was bedeutet, dass Ihre Benutzer Minuten nach einem Ausfall eine tote Region erreichen könnten.

Azure Front Door verwendet HTTP-Level-Health-Probes und Anycast. Wenn Ihre Region West US 2 ausfällt, leiten die Edge PoPs den Datenverkehr sofort (innerhalb von Sekunden) nach East US oder North Europe um. Es gibt keine DNS-Propagationsverzögerung. Aus diesem Grund ist AFD das Rückgrat von Microsofts eigenen Diensten wie Office 365 und Xbox Live.

Ähnliche Architekturmuster haben wir in unserem Deep Dive über Multi-Region AKS Networking besprochen, wo wir erklären, warum AppGW nur dann hinter AFD liegen sollte, wenn Sie eine spezifische VNet-Injektionsanforderung haben.

Fazit: Die TechLeague-Empfehlung

Im Jahr 2026 ist die Hierarchie der Wahl klar. Wenn Ihre Anwendung öffentlich zugänglich ist, verwenden Sie Azure Front Door Premium. Die Kombination aus Anycast-Latenzreduzierung, Edge WAF und Private Link-Origin-Support macht es zur überlegenen Wahl für Sicherheit und Performance. Verwenden Sie Application Gateway v2 nur als „Backend-Consumer“ für internen Datenverkehr oder wenn Sie eine Altanforderung für spezifische WAF-Rewrites haben, die die AFD-Engine noch nicht unterstützt.

Hören Sie auf, die Cloud wie ein physisches Rechenzentrum zu behandeln. Ihre WAF gehört an die Eingangstür des Internets, nicht in einem Subnetz, 40 ms von Ihren Benutzern entfernt. Für Architekturüberprüfungen oder spezialisierte Schulungen zu diesen Stacks besuchen Sie unsere intensiven Workshops unter techleague.io.

Häufig gestellte Fragen