Freigeben über

Azure Application Gateway-Funktionen

  • Artikel

Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, mit dem Sie eingehenden Datenverkehr für Ihre Webanwendungen verwalten können.

Application Gateway-Konzepte

Hinweis

Für Webworkloads wird dringend empfohlen, den Azure DDoS-Schutz und eine Webanwendungsfirewall zum Schutz vor neuen DDoS-Angriffen zu verwenden. Eine weitere Option besteht darin, Azure Front Door zusammen mit einer Webanwendungsfirewall zu verwenden. Azure Front Door bietet auf Plattformebene Schutz vor DDoS-Angriffen auf Netzwerkebene. Weitere Informationen finden Sie unter Sicherheitsbaseline für Azure-Dienste.

Application Gateway umfasst die folgenden Funktionen:

SSL/TLS-Abschluss (Secure Sockets Layer)

Application Gateway unterstützt die SSL/TLS-Beendigung am Gateway, wonach der Datenverkehr in der Regel unverschlüsselt zu den Back-End-Servern gelangt. Mit diesem Feature können Webserver vom kostspieligen Verschlüsselungs- und Entschlüsselungsaufwand befreit werden. Manchmal ist die unverschlüsselte Kommunikation mit den Servern allerdings keine akzeptable Option. Der Grund hierfür können Sicherheits- oder Complianceanforderungen sein, oder dass die Anwendung nur eine sichere Verbindung akzeptiert. Für Anwendungen dieser Art unterstützt Application Gateway die End-to-End-Verschlüsselung mit SSL/TLS.

Weitere Informationen finden Sie unter Übersicht über SSL-Beendigung und End-to-End-SSL mit Application Gateway.

Automatische Skalierung

Application Gateway Standard_v2 unterstützt automatische Skalierung und kann zentral hoch- oder herunterskalieren, je nach Veränderung der Datenverkehr-Auslastungsmuster. Durch die automatische Skalierung entfällt auch die Notwendigkeit, während des Bereitstellens eine Bereitstellungsgröße oder eine Anzahl von Instanzen auszuwählen.

Weitere Informationen zu den Features von Application Gateway Standard_v2 finden Sie unter Was ist Azure Application Gateway v2?.

Zonenredundanz

Ein Application Gateway Standard_v2 kann sich über mehrere Verfügbarkeitszonen erstrecken und so höhere Fehlerresilienz bieten sowie die Notwendigkeit beseitigen, in jeder Zone separate Application Gateways bereitstellen zu müssen.

Statische VIP

Die Application Gateway Standard_v2-SKU unterstützt ausschließlich den statischen VIP-Typ. Dadurch wird sichergestellt, dass die dem Application Gateway zugeordnete VIP auch über die gesamte Lebensdauer des Application Gateways unverändert bleibt.

Web Application Firewall

Web Application Firewall (WAF) ist ein Dienst, der zentralisierten Schutz Ihrer Webanwendungen vor verbreiteten Exploits und Sicherheitsrisiken bietet. Die WAF basiert auf den Regeln der OWASP-Kernregelsätze (Open Web Application Security Project) der Version 3.1 (nur WAF_v2), 3.0 und 2.2.9.

Webanwendungen sind zunehmend Ziele böswilliger Angriffe, die allgemein bekannte Sicherheitslücken ausnutzen. Zu diesen Sicherheitslücken (Exploits) gehören üblicherweise Angriffe durch Einschleusung von SQL-Befehlen oder Angriffe durch websiteübergreifende Skripts, um nur einige zu nennen. Die Verhinderung solcher Angriffe im Anwendungscode ist oft schwierig und erfordert strenge Wartung, Patching und Überwachung auf vielen Ebenen der Anwendungstopologie. Eine zentrale Web Application Firewall vereinfacht die Sicherheitsverwaltung erheblich und bietet Anwendungsadministratoren einen besseren Schutz vor Bedrohungen und Angriffen. Mit einer WAF-Lösung können Sie ebenfalls schneller auf ein Sicherheitsrisiko reagieren, da eine bekannte Schwachstelle an einem zentralen Ort gepatcht wird, statt jede einzelne Webanwendung separat zu sichern. Vorhandene Anwendungsgateways lassen sich problemlos in ein Anwendungsgateway mit Web Application Firewall konvertieren.

Eine Anleitung zur Verwendung von Azure WAF mit Application Gateway zum Schutz vor DDoS-Angriffen finden Sie unter DDoS-Schutz für Anwendungen . Weitere Informationen finden Sie unter Was ist die Azure Web Application Firewall?.

Eingangscontroller für AKS

Der Application Gateway-Eingangscontroller (Application Gateway Ingress Controller, AGIC) ermöglicht die Verwendung von Application Gateway als Eingang für einen AKS-Cluster (Azure Kubernetes Service).

Der Eingangscontroller wird als Pod im AKS-Cluster ausgeführt, nutzt Kubernetes-Eingangsressourcen und konvertiert sie in eine Application Gateway-Konfiguration, die es dem Gateway ermöglicht, einen Lastenausgleich für den an die Kubernetes-Pods gesendeten Datenverkehr durchzuführen. Der Eingangscontroller unterstützt nur die SKUs „Application Gateway Standard_v2“ und „WAF_v2“.

Weitere Informationen finden Sie unter Was ist der Application Gateway-Eingangscontroller?.

URL-basiertes Routing

Mit dem Routing auf URL-Pfadbasis kann Datenverkehr basierend auf URL-Pfaden von Anforderungen an Back-End-Serverpools weitergeleitet werden. Ein mögliches Szenario ist die Weiterleitung von Anforderungen für unterschiedliche Inhaltstypen an verschiedene Pools.

Beispielsweise werden Anforderungen von http://contoso.com/video/* an VideoServerPool und http://contoso.com/images/* an ImageServerPool weitergeleitet. DefaultServerPool wird ausgewählt, wenn keines der Pfadmuster zutrifft.

Weitere Informationen finden Sie unter Routing auf URL-Pfadbasis – Übersicht.

Hosten mehrerer Websites

Mit Application Gateway können Sie das Routing basierend auf dem Host- oder Domänennamen für mehr als eine Webanwendung auf demselben Anwendungsgateway konfigurieren. Sie können eine effizientere Topologie für Ihre Bereitstellungen konfigurieren, indem Sie einem Anwendungsgateway bis zu 100 Websites hinzufügen. Jede Website kann an ihren eigenen Back-End-Pool weitergeleitet werden. Beispielsweise können die drei Domänen „contoso.com“, „fabrikam.com“ und „adatum.com“ auf die IP-Adresse des Anwendungsgateways verweisen. Sie erstellen drei Listener vom Typ „Mehrere Websites“ und konfigurieren jeden Listener für den jeweiligen Port und die jeweilige Protokolleinstellung.

Anforderungen für http://contoso.com werden an „ContosoServerPool“, Anforderungen für http://fabrikam.com an „FabrikamServerPool“ weitergeleitet usw.

Analog dazu können zwei Unterdomänen der gleichen übergeordneten Domäne in der gleichen Anwendungsgatewaybereitstellung gehostet werden. Beispiele für die Verwendung von untergeordneten Domänen sind http://blog.contoso.com und http://app.contoso.com, die unter nur einer Anwendungsgatewaybereitstellung gehostet werden. Weitere Informationen finden Sie unter Application Gateway – Hosten mehrerer Websites.

Sie können auch Platzhalterhostnamen in einem Listener für mehrere Standorte und bis zu fünf Hostnamen pro Listener definieren. Weitere Informationen finden Sie unter Hostnamen mit Platzhaltern in Listenern.

Umleitung

Ein typisches Szenario vieler Webanwendungen ist die Unterstützung der automatischen Umleitung von HTTP zu HTTPS, um sicherzustellen, dass die gesamte Kommunikation zwischen einer Anwendung und ihren Benutzern über einen verschlüsselten Pfad stattfindet.

In der Vergangenheit haben Sie unter Umständen auch Verfahren wie die Erstellung eines dedizierten Pools verwendet, der den alleinigen Zweck hatte, eingehende HTTP-Anforderungen zu HTTPS umzuleiten. Application Gateway unterstützt die Umleitung von Application Gateway-Datenverkehr. Dies vereinfacht die Anwendungskonfiguration, optimiert die Ressourcennutzung und ermöglicht neue Umleitungsszenarien wie etwa die globale und pfadbasierte Umleitung. Die Application Gateway-Umleitung ist nicht auf HTTP zu HTTPS beschränkt. Vielmehr handelt es sich um einen generischen Umleitungsmechanismus, sodass Sie Umleitungen für jeden Port durchführen können, den Sie mithilfe von Regeln definieren. Auch die Umleitung an eine externe Website wird unterstützt.

Die Application Gateway-Umleitung bietet Folgendes:

  • Globale Umleitung von einem Port zu einem anderen Port über das Gateway. Dies ermöglicht HTTP-zu-HTTPS-Umleitungen auf einer Website.
  • Pfadbasierte Umleitung. Bei dieser Art von Umleitung kann HTTP nur in einem bestimmten Websitebereich zu HTTPS umgeleitet werden – etwa in einem durch /cart/* gekennzeichneten Einkaufswagenbereich.
  • Umleitung an eine externe Website.

Weitere Informationen finden Sie unter Übersicht über die Umleitung in Application Gateway.

Sitzungsaffinität

Das Feature „Cookiebasierte Sitzungsaffinität“ ist hilfreich, wenn eine Benutzersitzung auf dem gleichen Server bleiben soll. Mithilfe von durch das Gateway verwalteten Cookies kann das Application Gateway den weiteren Datenverkehr einer Benutzersitzung zur Verarbeitung an den gleichen Server weiterleiten. Dies ist hilfreich, wenn der Sitzungsstatus für eine Benutzersitzung lokal auf dem Server gespeichert wird.

Weitere Informationen finden Sie unter Funktionsweise von Application Gateway.

WebSocket- und HTTP/2-Datenverkehr

Application Gateway verfügt über native Unterstützung für das WebSocket- und das HTTP/2-Protokoll. Die WebSocket-Unterstützung kann von Benutzern nicht selektiv aktiviert oder deaktiviert werden.

Das WebSocket- und das HTTP/2-Protokoll ermöglichen die Vollduplexkommunikation zwischen einem Server und einem Client über eine TCP-Verbindung mit langer Laufzeit. Dies ermöglicht wiederum mehr Interaktivität bei der Kommunikation zwischen dem Webserver und dem Client, da die Kommunikation auch ohne die bei HTTP-basierten Implementierungen erforderlichen Abfragen bidirektional sein kann. Diese Protokolle zeichnen sich im Vergleich zu HTTP durch einen geringen Mehraufwand aus. Außerdem können sie die gleiche TCP-Verbindung für mehrere Anforderungen/Antworten verwenden, was eine effizientere Ressourcennutzung zur Folge hat. Diese Protokolle sind für die Nutzung der üblichen HTTP-Ports 80 und 443 konzipiert.

Weitere Informationen finden Sie unter WebSocket-Unterstützung und HTTP/2-Unterstützung.

Verbindungsausgleich

Mit dem Verbindungsausgleich können Sie eine korrekte Entfernung von Mitgliedern des Back-End-Pools bei geplanten Dienstupdates oder bei Problemen mit Back-Ends-Integrität erzielen. Diese Einstellung wird über die Back-End-Einstellungaktiviert und während der Regelerstellung auf alle Back-End-Poolmitglieder angewendet. Nach der Aktivierung stellt das Application Gateway sicher, dass alle aus dem Register zu löschenden Instanzen eines Back-End-Pools, keine neuen Anforderungen mehr erhalten, während vorhandene Anforderungen innerhalb eines konfigurierten Zeitlimits abgeschlossen werden können. Es gilt für Fälle, wo die Back-End-Instanzen

  • nach einer Konfigurationsänderung durch einen Benutzer explizit aus dem Back-End-Pool entfernt oder
  • von den Integritätstests als fehlerhaft gemeldet werden

Die einzige Ausnahme ist, wenn aufgrund der gatewayverwalteten Sitzungsaffinität die Anforderungen weiterhin an die aus dem Register löschenden Instanzen über Proxy weitergeleitet werden.

Den Verbindungsausgleich wird auch für WebSocket-Verbindungen berücksichtigt. Den Verbindungsausgleich wird für jede einzelne Aktualisierung des Gateways aufgerufen. Um Verbindungsverluste mit vorhandenen Mitgliedern des Back-End-Pools zu verhindern, müssen Sie den Verbindungsausgleich aktivieren.

Informationen zu Zeitlimits finden Sie unter Back-End-Einstellungskonfiguration.

Benutzerdefinierte Fehlerseiten

Mit Application Gateway können Sie benutzerdefinierte Fehlerseiten erstellen, anstatt Standardfehlerseiten anzuzeigen. Sie können für eine benutzerdefinierte Fehlerseite Ihr eigenes Branding und Layout verwenden.

Weitere Informationen finden Sie unter Benutzerdefinierte Fehler.

Neuschreibung von HTTP-Headern und der URL

HTTP-Header ermöglichen Client und Server das Übergeben von zusätzlichen Informationen mit der Anforderung oder der Antwort. Das Umschreiben dieser HTTP-Header hilft Ihnen, mehrere wichtige Szenarien zu meistern, wie z.B.:

  • Hinzufügen von sicherheitsbezogenen Headerfeldern wie HSTS/X-XSS-Protection.
  • Entfernen von Headerfeldern aus Antworten, die vertrauliche Informationen preisgeben können.
  • Entfernen von Portinformationen aus X-Forwarded-For-Headern.

Application Gateway und die WAF v2-SKU unterstützen das Hinzufügen, Entfernen und Aktualisieren von HTTP-Anforderungs- und -Antwortheadern, während die Anforderungs- und Antwortpakete zwischen dem Client und den Back-End-Pools übertragen werden. Sie können URLs, Abfragezeichenfolgenparameter und den Hostnamen auch erneut generieren. Bei URL Rewrite und beim auf dem URL-Pfad basierenden Routing können Sie wählen, ob Sie Anforderungen anhand des ursprünglichen Pfads oder des erneut generierten Pfads an einen der Back-End-Pools weiterleiten, indem Sie die Option „Pfadzuordnung neu auswerten“ verwenden.

Sie haben auch die Möglichkeit, Bedingungen hinzuzufügen, um sicherzustellen, dass die angegebenen Header oder die URL nur dann erneut generiert werden, wenn bestimmte Bedingungen erfüllt sind. Diese Bedingungen basieren auf den Anforderungs- und Antwortinformationen.

Weitere Informationen finden Sie unter Neuschreibung von HTTP-Headern und der URL.

Dimensionierung

Die Standard_v2-SKU von Application Gateway kann für die automatische Skalierung oder für Bereitstellungen fester Größe konfiguriert werden. Die v2-SKU bietet keine verschiedenen Instanzgrößen. Weitere Informationen zur Leistung und zu den Preisen von v2 finden Sie unter Automatische Skalierung von V2 und Preisgestaltung.

Application Gateway Standard (v1) wird derzeit in drei Größen angeboten: klein, mittel und groß. Kleine Instanzen sind für Entwicklungs- und Testszenarien vorgesehen.

Eine vollständige Liste mit den Einschränkungen von Anwendungsgateways finden Sie unter Application Gateway service limits (Einschränkungen von Application Gateway).

Die folgende Tabelle zeigt den durchschnittlichen Leistungsdurchsatz für jede v1-Application Gateway-Instanz mit aktivierter SSL-Auslagerung:

Durchschnittliche Antwortgröße der Back-End-Seite Klein Medium Groß
6 KB 7,5 MBit/s 13 MBit/s 50 MBit/s
100 KB 35 MBit/s 100 MBit/s 200 MBit/s

Hinweis

Hierbei handelt es sich um ungefähre Werte für den Durchsatz des Anwendungsgateways. Der tatsächliche Durchsatz ist abhängig von verschiedenen Umgebungsdetails wie der durchschnittlichen Seitengröße, dem Speicherort der Back-End-Instanzen und der Verarbeitungszeit für die Seitenbereitstellung. Für genaue Leistungsangaben sollten Sie Ihre eigenen Tests ausführen. Diese Werte dienen nur als Leitfaden für die Kapazitätsplanung.

Funktionsvergleich der Versionen

Einen Vergleich der Features von Application Gateway v1 mit v2 finden Sie unter Was ist Azure Application Gateway v2?.

Nächste Schritte