Sichere Anbindung von Diensten mit Azure Front Door und Application Gateway

Einführung

Nach der offiziellen Ankündigung am 28.02.2023 über das Ende der V1-SKU des Application Gateways möchte ich in diesem Blog-Beitrag auf die Besonderheiten des V2 Application Gateways eingehen.

Das Azure Application Gateway ist eines der zentralen Bausteine, wenn es darum geht, Web-Workloads in Azure sicher, skalierbar und kontrolliert bereitzustellen. Als Layer-7-Load-Balancer bietet es Funktionen wie TLS-Termination, URL-basiertes Routing, Web Application Firewall (WAF)-Anbindung und die Integration mit diversen Azure-Diensten.

In der Praxis stellt sich jedoch weniger die Frage, was das Application Gateway kann, sondern wie man es in Kombination mit Public- und Private-IPs, anderen Layer-7-Load-Balancing-Lösungen wie Front Door und hohen Security-Anforderungen mit Private Link nutzt.

Aus diesem Grund liegt in diesem Blog-Beitrag der Fokus auf gängigen Deployment-Varianten, der Entscheidung zwischen Public- und Private-Listenern, der Anbindung an Azure Front Door über Private Link sowie der Möglichkeit, das Application Gateway in Sonderfällen vollständig privat ohne Public IP bereitzustellen.

Azure Application Gateway in Kombination mit Azure Front Door

In Enterprise-Szenarien sind die Nutzer der Applikationen selten lediglich in einer einzelnen Region verortet. Um diesem Problem entgegenzuwirken, werden einzelne Ressourcen oder ganze Landing Zones in unterschiedlichen Regionen dupliziert. Als zentraler Einstiegspunkt dient oft eine Azure-Front-Door-Instanz mit einer Web Application Firewall (WAF).

Damit je nach Region des Benutzers die korrekte Azure-Region angesprochen werden kann, lassen sich mehrere Front-Door-Origins in einer Origin Group bündeln, die jeweils auf die Application-Gateway-Instanzen in den einzelnen Regionen verweisen. Diese Verbindung zwischen Front Door und Application Gateway ist in unterschiedliche Varianten möglich, die ich nachfolgend aufzeigen werde.

Variante 1: Weiterleitung zu Public FQDNs

Im nachfolgenden Schaubild sind unterschiedliche Origin Groups dargestellt, welche lediglich die Public-FQDNs der jeweiligen Dienste verwenden. Diese Herangehensweise nutzt Service Tags zur Einschränkung auf Subnet-Ebene sowie die Option Allow Trusted Services für Plattform-Dienste wie Key Vaults, App Services oder Storage Accounts.

Diese Lösung ist ohne besondere Konfigurationen möglich und lässt sich bei weniger strengen Vorgaben umsetzen. Für streng regulierte Enterprise-Szenarien kann diese Lösung jedoch häufig nicht verwendet werden, sodass in den nachfolgenden Varianten zusätzliche Möglichkeiten aufgezeigt werden.

Im Kontext des Application Gateways wird die Verbindung zwischen Front Door und Application Gateway auf einen spezifischen Listener geleitet, der über eine Public IP verfügt. Eine Weiterleitung auf einen Listener mit einer privaten IP ist in diesem Szenario ohne zusätzliche Schritte nicht möglich.

Variante 2: Weiterleitung mit Private Link

Die Verbindung der jeweiligen Front-Door-Origins mit den jeweiligen Diensten ist auch ohne die Verwendung einer Public IP und des damit verbundenen Default-FQDNs möglich. Hierfür können Private-Link-Verbindungen zu einer Vielzahl von Diensten direkt über das Portal oder Terraform eingerichtet werden.

Die direkte Private-Link-Anbindung an vollständig von Azure verwaltete Dienste wie Key Vaults, Storage Accounts, App Services oder Container Apps ist nativ möglich. Für Ressourcen, die in ein delegiertes Subnet innerhalb eines Virtual Networks bereitgestellt werden, existiert ebenfalls eine breite Unterstützung.

Eine Besonderheit bei Diensten wie dem Application Gateway oder dem API Management Service besteht darin, dass nicht wie in der ersten Variante auf die Public IP des jeweiligen Dienstes verwiesen wird, sondern über Private Link direkt auf die private IP im eigenen Virtual Network geroutet wird.

Im Falle des Application Gateways lassen sich Listener sowohl für die Public als auch für die Private IP konfigurieren, die anschließend mittels path-basiertem Routing auf die jeweiligen Applikationen im Virtual Network verweisen. Auch wenn eine Private-Link-Verbindung zwischen Front Door und dem Public-IP-Listener technisch möglich ist, ergibt es in der Praxis mehr Sinn, die Verbindung direkt zwischen der Front-Door-Origin und dem Private-IP-Listener des Application Gateways aufzubauen.

Ein wichtiger Punkt während der Einrichtung ist die Beachtung der offiziellen Konfigurationsanleitung für das Application Gateway. Der Grund dafür ist, dass der Hostname der verwendeten Custom Domain des Application-Gateway-Listeners explizit bereits in Front Door mitgegeben werden muss, damit die Namensauflösung zuverlässig funktioniert.

Für die detaillierte Konfiguration empfehle ich die folgenden hilfreichen Beiträge:

• https://learn.microsoft.com/en-us/azure/application-gateway/private-link-configure?tabs=portal
• https://learn.microsoft.com/en-us/azure/frontdoor/how-to-enable-private-link-application-gateway?pivots=front-door-portal
• https://tech-blog.cloud-config.jp/2025-02-14-azure-frontdoor-privatelink-applicationgateway
• https://ops-today.com/topics-6897/

Zusätzlich möchte ich auf eine Besonderheit des API Management Service eingehen: Die direkte Verbindung zwischen Front Door und API Management wird ausschließlich in der teuersten SKU unterstützt. Insbesondere wenn eine VNet-Integration benötigt wird, ist lediglich das Deployment der Developer- oder Premium-SKU möglich.

Falls jedoch weder die SLOs noch der Durchsatz der Premium-SKU benötigt werden, kann mit der Developer-SKU der Traffic weiterhin vollständig über Private Link bereitgestellt werden. Dazu wird wie in der nachfolgenden Abbildung dargestellt der Traffic von Front Door zum privaten Listener des Application Gateways geleitet. Da sich der Traffic damit bereits im Virtual Network befindet, kann er anschließend zum privaten API Management Service geroutet werden, der in diesem Szenario in einem delegierten Subnet ohne Public IP betrieben wird.

Fazit

Die Kombination aus Azure Front Door und Application Gateway ist nicht für jede Cloud-Umgebung notwendig, bietet jedoch valide Anwendungsfälle, die es zu berücksichtigen gilt. Ich hoffe, ich konnte mit diesem Blog-Beitrag auf relevante Besonderheiten und mögliche Hürden hinweisen. Die verlinkten Ressourcen sollten dich bei der nächsten Implementierung zusätzlich unterstützen.