Regionsübergreifender Lastenausgleich mit Traffic Manager, Azure Firewall und Application Gateway

Diese Architektur ist für globale Anwendungen mit Internetzugriff gedacht, die HTTP(S)- und Nicht-HTTP(S)-Protokolle verwenden. Sie bietet den DNS-basierten Lastenausgleich, zwei Arten des regionalen Lastenausgleichs und globales Peering virtueller Netzwerke, um eine Hochverfügbarkeitsarchitektur zu schaffen, die einem regionalen Ausfall standhält. Die Überprüfung von Datenverkehr wird sowohl von Azure Web Application Firewall (WAF) als auch von Azure Firewall bereitgestellt.

Hinweise zur Architektur

Die Architektur in diesem Dokument lässt sich problemlos auf ein virtuelles Hub-and-Spoke-Netzwerkdesign erweitern, bei dem sich die Azure Firewall im Hubnetzwerk und das Anwendungsgateway entweder auch im Hubnetzwerk oder in einem Spoke befindet. Wenn das Anwendungsgateway im Hub bereitgestellt wird, sollten Sie dennoch mehrere Anwendungsgateways für jeweils eine bestimmte Gruppe von Anwendungen verwenden, um RBAC-Konflikte zu vermeiden und das Erreichen von Anwendungsgateway-Grenzwerten zu verhindern (siehe Anwendungsgateway-Grenzwerte).

In einer Virtual WAN-Umgebung können Anwendungsgateways nicht im Hub bereitgestellt, sondern müssen in virtuellen Spoke-Netzwerken installiert werden.

Die vorgeschlagene Architektur setzt auf eine doppelte Überprüfung von Webinhalten durch eine Web Application Firewall (basierend auf Application Gateway) vor Azure Firewall. Es gibt andere Optionen, die in Firewall und Application Gateway für virtuelle Netzwerke dokumentiert sind, aber diese Option ist die flexibelste und umfassendste: Sie macht die IP-Adresse des Clients im HTTP-Header „X-Forwarded-For“ für die Endanwendung verfügbar, bietet End-to-End-Verschlüsselung und verhindert, dass Clients die WAF beim Zugriff auf die Anwendung umgehen.

Wenn nur Webanwendungen verfügbar gemacht werden (keine Nicht-HTTP(S)-Anwendungen), und die doppelte Überprüfung dieses Webdatenverkehrs durch WAF und Azure Firewall nicht erforderlich ist, wäre Azure Front Door eine bessere Lösung als Traffic Manager für den globalen Lastenausgleich. Front Door ist ein Layer 7-Lastenausgleich für HTTP(S)-Inhalte, der auch Zwischenspeichern, Datenverkehrsbeschleunigung, SSL/TLS-Abschluss, Zertifikatverwaltung, Integritätstests und andere Funktionen bietet. Application Gateway bietet jedoch eine bessere Integration in Azure Firewall für mehrschichtigen Schutzansatz.

Eingehende HTTP(S)-Datenverkehrsflüsse

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Azure Traffic Manager verwendet DNS-basiertes Routing, um einen Lastausgleich für den eingehenden Datenverkehr in den beiden Regionen vorzunehmen. Traffic Manager löst DNS-Abfragen für die Anwendung zu den öffentlichen IP-Adressen der Azure Application Gateway-Endpunkte auf. Die öffentlichen Endpunkte der Anwendungsgateways dienen als Back-End-Endpunkte von Traffic Manager für HTTP(S)-Datenverkehr. Traffic Manager löst DNS-Abfragen mithilfe verschiedener Routingmethoden auf. Der Browser stellt eine direkte Verbindung mit dem Endpunkt her. Traffic Manager sieht den HTTP(S)-Datenverkehr nicht.

2. Die Anwendungsgateways, die über Verfügbarkeitszonen hinweg bereitgestellt werden, empfangen HTTP(S)-Datenverkehr vom Browser, und Web Application Firewall Premium überprüft den Datenverkehr, um Webangriffe zu erkennen. Die Anwendungsgateways senden Datenverkehr an ihr Back-End, den internen Lastenausgleich für die Front-End-VMs. Für diesen spezifischen Flow ist der interne Lastenausgleich vor den Webservern nicht unbedingt erforderlich, da Application Gateway diesen Lastenausgleich auch selbst durchführen könnte. Es ist jedoch aus Gründen der Konsistenz mit dem Flow für Nicht-HTTP(S)-Anwendungen enthalten.

3. Der Datenverkehr zwischen dem Anwendungsgateway und dem internen Front-End-Lastenausgleich wird von Azure Firewall Premium über benutzerdefinierte Routen abgefangen, die auf das Subnetz des Anwendungsgateways angewendet werden. Azure Firewall Premium wendet die TLS-Überprüfung auf den Datenverkehr an, um zusätzliche Sicherheit zu gewährleisten. Die Azure Firewall ist auch zonenredundant. Wenn Azure Firewall eine Bedrohung im Datenverkehr erkennt, werden die Pakete abgelegt. Andernfalls leitet Azure Firewall den Datenverkehr nach erfolgreicher Überprüfung an den internen Lastenausgleich der Zielwebebene weiter.

4. Die Webebene ist die erste Ebene der dreistufigen Anwendung. Sie enthält die Benutzeroberfläche und parst auch Benutzerinteraktionen. Der Lastenausgleich der Webebene verteilt sich auf alle drei Verfügbarkeitszonen und verteilt den Datenverkehr an jeden der drei Webebenen-VMs.

5. Die VMs der Webebene sind auf alle drei Verfügbarkeitszonen verteilt und kommunizieren über einen dedizierten internen Lastenausgleich mit der Geschäftsebene.

6. Die Geschäftsebene verarbeitet die Interaktionen der Benutzer und bestimmt die nächsten Schritte. Sie befindet sich zwischen der Web- und der Datenebene. Der interne Lastenausgleich auf Geschäftsebene verteilt Datenverkehr an die VMs der Geschäftsebene über die drei Verfügbarkeitszonen hinweg. Der Lastenausgleich auf Geschäftsebene ist wie der auf Webebene zonenredundant.

7. Die VMs der Geschäftsebene sind auf die Verfügbarkeitszonen verteilt und leiten Datenverkehr an den Verfügbarkeitsgruppenlistener der Datenbanken weiter.

8. Die Datenschicht speichert die Anwendungsdaten in der Regel in einer Datenbank, in einem Objektspeicher oder in einer Dateifreigabe. Diese Architektur umfasst SQL Server-Instanzen auf VMs, die auf drei Verfügbarkeitszonen verteilt sind. Sie befinden sich in der Verfügbarkeitsgruppe und verwenden einen verteilten Netzwerknamen (DNN, Distributed Network Name), um den Datenverkehr für den Lastenausgleich an den Verfügbarkeitsgruppenlistener weiterzuleiten.

Eingehende Nicht-HTTP(S)-Datenverkehrsflüsse

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Azure Traffic Manager verwendet DNS-basiertes Routing, um einen Lastausgleich für den eingehenden Datenverkehr in den beiden Regionen vorzunehmen. Traffic Manager löst DNS-Abfragen für die Anwendung zu den öffentlichen IP-Adressen der Azure-Endpunkte auf. Die öffentlichen Endpunkte der Application Firewall dienen als Back-End-Endpunkte von Traffic Manager für Nicht-HTTP(S)-Datenverkehr. Traffic Manager löst DNS-Abfragen mithilfe verschiedener Routingmethoden auf. Der Browser stellt eine direkte Verbindung mit dem Endpunkt her. Traffic Manager sieht den HTTP(S)-Datenverkehr nicht.

2. Azure Firewall Premium ist zonenredundant und überprüft den eingehenden Datenverkehr auf Sicherheitsrisiken. Wenn Azure Firewall eine Bedrohung im Datenverkehr erkennt, werden die Pakete abgelegt. Andernfalls leitet Azure Firewall nach erfolgreicher Überprüfung den Datenverkehr an den internen Lastenausgleich auf Webebene weiter, der die Zielnetzwerkadressübersetzung (Destination Network Address Translation, DNAT) für die eingehenden Pakete ausführt.

3. Die Webebene ist die erste Ebene der dreistufigen Anwendung. Sie enthält die Benutzeroberfläche und parst auch Benutzerinteraktionen. Der Lastenausgleich der Webebene verteilt sich auf alle drei Verfügbarkeitszonen und verteilt den Datenverkehr an jeden der drei Webebenen-VMs.

4. Die VMs der Webebene sind auf alle drei Verfügbarkeitszonen verteilt und kommunizieren über einen dedizierten internen Lastenausgleich mit der Geschäftsebene.

5. Die Geschäftsebene verarbeitet die Interaktionen der Benutzer und bestimmt die nächsten Schritte. Sie befindet sich zwischen der Web- und der Datenebene. Der interne Lastenausgleich auf Geschäftsebene verteilt Datenverkehr an die VMs der Geschäftsebene über die drei Verfügbarkeitszonen hinweg. Der Lastenausgleich auf Geschäftsebene ist wie der auf Webebene zonenredundant.

6. Die VMs der Geschäftsebene sind auf die Verfügbarkeitszonen verteilt und leiten Datenverkehr an den Verfügbarkeitsgruppenlistener der Datenbanken weiter.

7. Die Datenschicht speichert die Anwendungsdaten in der Regel in einer Datenbank, in einem Objektspeicher oder in einer Dateifreigabe. Diese Architektur umfasst SQL Server-Instanzen auf VMs, die auf drei Verfügbarkeitszonen verteilt sind. Sie befinden sich in der Verfügbarkeitsgruppe und verwenden einen verteilten Netzwerknamen (DNN, Distributed Network Name), um den Datenverkehr für den Lastenausgleich an den Verfügbarkeitsgruppenlistener weiterzuleiten.

Ausgehende Datenverkehrsflüsse (alle Protokolle)

Ausgehende Datenverkehrsflüsse für VM-Patchupdates oder andere Verbindungen mit dem Internet werden von den Workload-VMs über benutzerdefinierte Routen an Azure Firewall übertragen. Azure Firewall erzwingt Konnektivitätsregeln mithilfe von Webkategorien sowie Netzwerk- und Anwendungsregeln, um zu verhindern, dass Workloads auf unangemessene Inhalte zugreifen oder Datenexfiltrationsszenarien entstehen können.

Komponenten

• Azure Firewall ist eine cloudbasierte, von Microsoft verwaltete Firewall der nächsten Generation, die umfassende Paketüberprüfungen für Datenverkehrsflüsse von Norden nach Süden sowie von Osten nach Westen bietet. Die Lösung kann auf Verfügbarkeitszonen verteilt werden und bietet automatische Skalierung, um Änderungen hinsichtlich der Anwendungsnachfrage zu bewältigen.
• Azure Application Gateway ist ein Layer 7-Lastenausgleich mit optionaler Web Application Firewall-Funktionalität (WAF). Die v2-SKU von Application Gateway unterstützt Verfügbarkeitszonenredundanz und wird für die meisten Szenarien empfohlen. Application Gateway umfasst eine konfigurierbare horizontale automatische Skalierung, sodass diese Lösung automatisch auf Änderungen hinsichtlich der Anwendungsnachfrage reagieren kann.
• Azure Traffic Manager ist ein DNS-basierter globaler Lastenausgleich, der Datenverkehr auf Dienste in den globalen Azure-Regionen verteilt und gleichzeitig für Hochverfügbarkeit und kurze Reaktionszeiten sorgt. Weitere Informationen finden Sie im Abschnitt Traffic Manager-Konfiguration.
• Azure Load Balancer ist ein Lastenausgleich auf Schicht 4. Ein zonenredundanter Lastenausgleich verteilt bei einem Ausfall einer Verfügbarkeitszone weiterhin Datenverkehr an die verbleibenden Zonen.
• Azure DDoS Protection verfügt über erweiterte Features zum Schutz vor verteilten Denial-of-Service-Angriffen (DDoS).
• Azure DNS ist ein Hostingdienst für DNS-Domänen. Er ermöglicht eine Namensauflösung mithilfe der Microsoft Azure-Infrastruktur. Durch das Hosten Ihrer Domänen in Azure können Sie Ihre DNS-Einträge mithilfe der gleichen Anmeldeinformationen, APIs, Tools und Abrechnung wie für die anderen Azure-Dienste verwalten.
• Private Azure DNS-Zonen sind ein Feature von Azure DNS. Azure DNS Private Zones bietet Namensauflösung in einem virtuellen Netzwerk und zwischen virtuellen Netzwerken. Die in einer privaten DNS-Zone enthaltenen Einträge sind nicht aus dem Internet auflösbar. Die DNS-Auflösung für eine private DNS-Zone funktioniert nur aus virtuellen Netzwerken, die damit verknüpft sind.
• Azure Virtual Machines sind bedarfsorientierte, skalierbare Computingressourcen, die Ihnen die Flexibilität der Virtualisierung bieten, aber die Wartungsanforderungen physischer Hardware beseitigen. Als Betriebssysteme stehen Windows und Linux zur Auswahl. Bestimmte Komponenten der Anwendungen können durch Azure-Platform-as-a-Service-Ressourcen ersetzt werden (z. B. die Datenbank und die Front-End-Ebene), die Architektur würde sich jedoch nicht wesentlich verändern, wenn Private Link und App Service VNET-Integration verwendet werden, um diese PaaS-Dienste in das virtuelle Netzwerk zu bringen.
• Azure Virtual Machine Scale Sets ist eine automatisierte VM-Skalierung mit Lastenausgleich, die die Verwaltung Ihrer Anwendungen vereinfacht und die Verfügbarkeit erhöht.
• Mit SQL Server auf Azure-VMs können Sie Vollversionen von SQL Server in der Cloud nutzen, ohne lokale Hardware verwalten zu müssen.
• Azure Virtual Network ist ein sicheres privates Netzwerk in der Cloud. Es kann VMs untereinander, mit dem Internet und mit standortübergreifenden Netzwerken verbinden.
• Benutzerdefinierte Routen sind ein Mechanismus zum Überschreiben des Standardroutings in virtuellen Netzwerken. In diesem Szenario werden sie verwendet, um zu erzwingen, dass eingehende und ausgehende Datenverkehrsflüsse die Azure Firewall durchlaufen.

Details zur Lösung

Traffic Manager – Wir haben Traffic Manager so konfiguriert, dass das Leistungsrouting verwendet wird. Er leitet den Datenverkehr an den Endpunkt weiter, der die geringste Latenz für den*die Benutzer*in aufweist. Traffic Manager passt den Lastenausgleichsalgorithmus automatisch an Änderungen der Endpunktwartezeit an. Traffic Manager führt ein automatisches Failover durch, wenn es zu einem regionalen Ausfall kommt. Er verwendet das Prioritätsrouting und regelmäßige Integritätsprüfungen, um zu ermitteln, wohin Datenverkehr geleitet werden soll.

Verfügbarkeitszonen – Die Architektur verwendet drei Verfügbarkeitszonen. Die Zonen erstellen eine Hochverfügbarkeitsarchitektur für die Anwendungsgateways, internen Lastenausgleichsmodule und VMs in jeder Region. Bei einem Zonenausfall würden die verbleibenden Verfügbarkeitszonen in dieser Region die Last übernehmen, was kein regionales Failover auslösen würde.

Application Gateway: Während Traffic Manager einen DNS-basierten regionalen Lastenausgleich bietet, gewährt Ihnen Application Gateway viele der gleichen Funktionen wie Azure Front Door, jedoch auf regionaler Ebene. Dazu gehören:

• Web Application Firewall (WAF)
• TLS-Abschluss (Transport Layer Security)
• Pfadbasiertes Routing
• Cookiebasierte Sitzungsaffinität

Azure Firewall: Azure Firewall Premium bietet Netzwerksicherheit für generische Anwendungen (Web- und Nicht-Webdatenverkehr) und untersucht drei Arten von Flows in dieser Architektur:

• Eingehende HTTP(S)-Flows aus dem Anwendungsgateway werden mit Azure Firewall Premium TLS-Überprüfung geschützt.
• Eingehende Nicht-HTTP(S)-Flows aus dem öffentlichen Internet werden mit den restlichen Azure Firewall Premium-Features überprüft.
• Ausgehende Flows aus Azure Virtual Machines werden von Azure Firewall überprüft, um die Datenexfiltration und den Zugriff auf verbotene Websites und Anwendungen zu verhindern.

Peering virtueller Netzwerke: Peering zwischen Regionen wird auch als „globales Peering virtueller Netzwerke“ bezeichnet. Es bietet eine geringe Latenz sowie Datenreplikation mit hoher Bandbreite zwischen Regionen. Sie können mithilfe dieses globalen Peerings Daten zwischen Azure-Abonnements, Microsoft Entra-Mandanten und Bereitstellungsmodellen übertragen. In der Hub-Spoke-Umgebung wären Peerings virtueller Netzwerke zwischen Hub- und Spoke-Netzwerken vorhanden.

Empfehlungen

Die folgenden Empfehlungen entsprechen den Prinzipien des Azure Well-Architected Framework (WAF). Die WAF-Prinzipien sind Grundsätze, die dazu beitragen, die Qualität der Cloudworkloads zu gewährleisten. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Regionen – Verwenden Sie mindestens zwei Azure-Regionen für die Hochverfügbarkeit. Sie können Ihre Anwendung in mehreren Azure-Regionen wahlweise in aktiv/passiver oder aktiv/aktiver Konfiguration bereitstellen. Wenn Sie mehrere Regionen verwenden, hilft dies dabei, Anwendungsdowntimes zu vermeiden, wenn ein Subsystem der Anwendung fehlschlägt.

• Traffic Manager führt automatisch ein Failover zur zweiten Region durch, wenn die erste Region fehlschlägt.
• Bei der Auswahl der für Ihre Bedürfnisse am besten geeigneten Regionen müssen technische und rechtliche Erwägungen sowie die Unterstützung durch die Verfügbarkeitszonen berücksichtigt werden.

Regionspaare – Verwenden Sie Regionspaare, um die größtmögliche Resilienz zu erhalten. Stellen Sie sicher, dass beide Regionspaare alle Azure-Dienste unterstützen, die Ihre Anwendung benötigt (siehe Dienste nach Region). Dies sind zwei Vorteile von Regionspaaren:

• Geplante Azure-Updates werden nacheinander in den Regionspaaren eingeführt, um Downtimes und das Risiko von Anwendungsausfällen zu minimieren.
• Die Daten befinden sich aus steuerlichen und rechtlichen Gründen weiterhin im selben Gebiet wie ihr Paar (mit Ausnahme von Brasilien, Süden).

Verfügbarkeitszonen: Verwenden Sie mehrere Verfügbarkeitszonen, um Ihre Application Gateway-, Azure Firewall-, Azure Load Balancer- und Anwendungsschichten zu unterstützen, wenn diese verfügbar sind.

Automatische Application Gateway-Skalierung und -Instanzen: Konfigurieren Sie Application Gateway mit mindestens zwei Instanzen, um Ausfallzeiten zu vermeiden, und nutzen Sie die automatische Skalierung, um eine dynamische Anpassung für sich ändernde Anforderungen an die Anwendungskapazität bereitzustellen.

Weitere Informationen finden Sie unter

• Regionen und Verfügbarkeitszonen in Azure
• Business Continuity & Disaster Recovery (BCDR): Azure-Regionspaare.

Globales Routing

Globale Routingmethode: Verwenden Sie die Routingmethode für den Datenverkehr, die die Anforderungen Ihrer Kunden am besten erfüllt. Traffic Manager unterstützt mehrere Methoden für das Datenverkehrsrouting, um Datenverkehr deterministisch an die verschiedenen Dienstendpunkte weiterzuleiten.

Geschachtelte Konfiguration: Verwenden Sie Traffic Manager in einer geschachtelten Konfiguration, wenn Sie auf präzisere Einstellungen angewiesen sind, um beispielsweise ein bevorzugtes Failover innerhalb einer Region auszuwählen.

Weitere Informationen finden Sie unter

• Konfigurieren der leistungsorientierten Routingmethode für Datenverkehr
• Traffic Manager-Routingmethoden

Globale Datenverkehrsansicht

Verwenden Sie die Datenverkehrsansicht im Traffic Manager, um Datenverkehrsmuster und Latenzmetriken anzuzeigen. Mit der Datenverkehrsansicht können Sie Ihre Speicherexpansion in neue Azure-Regionen planen.

Weitere Informationen finden Sie unter Traffic Manager Datenverkehrsansicht.

Application Gateway

Verwenden Sie die Application Gateway-SKU (Version 2), um automatisch und direkt Resilienz gewährleisten zu können.

• Die Application Gateway-SKU (Version 2) stellt automatisch sicher, dass neue Instanzen in Fehlerdomänen und Updatedomänen erzeugt werden. Wenn Sie die Zonenredundanz ausgewählt haben, werden die neuesten Instanzen ebenfalls in Verfügbarkeitszonen erzeugt, um Fehlertoleranz zu gewährleisten.

• Die Application Gateway v1-SKU unterstützt Hochverfügbarkeitsszenarien, wenn mindestens zwei Instanzen bereitgestellt wurden. Azure verteilt diese Instanzen auf Update- und Fehlerdomänen, um sicherzustellen, dass die Instanzen nicht gleichzeitig ausfallen. Die v1-SKU unterstützt Skalierbarkeit durch Hinzufügen mehrerer Instanzen des gleichen Gateways, um die Last zu teilen.

Application Gateway muss dem Zertifizierungsstellenzertifikat von Azure Firewall vertrauen.

Azure Firewall

Der Premium-Tarif von Azure Firewall ist für dieses Design erforderlich, um die TLS-Überprüfung bereitzustellen. Azure Firewall fängt die TLS-Sitzungen zwischen Application Gateway und den VMs der Webebene ab, die eigene Zertifikate generieren, und überprüft außerdem ausgehende Datenverkehrsflüsse aus den virtuellen Netzwerken in das öffentliche Internet. Weitere Informationen zu diesem Design finden Sie unter Zero Trust-Netzwerk für Webanwendungen mit Azure Firewall und Application Gateway.

Empfehlungen für Integritätstests

Hier finden Sie einige Empfehlungen für Integritätsüberprüfungen in Traffic Manager, Application Gateway und Load Balancer.

Traffic Manager

Endpunktintegrität: Erstellen Sie einen Endpunkt, der die Gesamtintegrität der Anwendung meldet. Traffic Manager verwendet einen HTTP(S)-Test, um die Verfügbarkeit jeder Region zu überwachen. Der Test prüft auf eine HTTP 200-Antwort für einen angegebenen URL-Pfad. Verwenden Sie den Endpunkt, den Sie für den Integritätstest erstellt haben. Andernfalls meldet der Test eventuell einen fehlerfreien Endpunkt, obwohl wichtige Teile der Anwendung fehlerhaft sind.

Weitere Informationen finden Sie unter Überwachungsmuster für den Integritätsendpunkt.

Failoververzögerung: Traffic Manager verfügt über Failoververzögerung. Die folgenden Faktoren bestimmen die Dauer der Verzögerung:

• Prüfintervalle: Wie oft der Test die Integrität des Endpunkts überprüft
• Zulässige Anzahl von Fehlern: Wie viele Fehler der Test zulässt, bevor der Endpunkt als fehlerhaft eingestuft wird
• Testtimeout: Wie lange es dauert, bis Traffic Manager den Endpunkt als fehlerhaft einstuft
• Gültigkeitsdauer (TTL): DNS-Server müssen die zwischengespeicherten DNS-Einträge für die IP-Adresse aktualisieren. Die benötigte Zeit hängt von der DNS-Gültigkeitsdauer ab. Die Standardgültigkeitsdauer beträgt 300 Sekunden (5 Minuten), Sie können diesen Wert aber bei der Erstellung des Traffic Manager-Profils anpassen.

Weitere Informationen finden Sie unter Traffic Manager-Überwachung.

Application Gateway und Load Balancer

Machen Sie sich mit den Richtlinien für Integritätstests von Application Gateway und Load Balancer vertraut, um sicherzustellen, dass Sie die Integrität Ihrer VMs kennen. Hier finden Sie eine kurze Übersicht:

• Application Gateway verwendet immer einen HTTP-Test.

• Load Balancer kann entweder HTTP oder TCP auswerten. Verwenden Sie einen HTTP-Test, wenn auf einer VM ein HTTP-Server ausgeführt wird. Verwenden Sie TCP für alles andere.

• HTTP-Tests senden eine HTTP GET-Anforderung an einen angegebenen Pfad und lauschen auf eine HTTP 200-Antwort. Bei diesem Pfad kann es sich um den Stammpfad („/“) oder einen Endpunkt zur Integritätsüberwachung handeln, der benutzerdefinierte Logik zum Überprüfen der Integrität der Anwendung implementiert.

• Der Endpunkt muss anonyme HTTP-Anforderungen zulassen. Kann eine Instanz bei einem Test nicht innerhalb des jeweiligen Timeoutzeitraums erreicht werden, beendet Application Gateway oder Load Balancer das Senden von Datenverkehr an die betreffende VM. Der Test wird fortgesetzt. und die VM wird an den Back-End-Pool zurückgegeben, wenn sie wieder verfügbar wird.

Weitere Informationen finden Sie unter

• Lastenausgleichs-Integritätstests
• Systemüberwachung des Anwendungsgateways – Übersicht
• Muster für Überwachung der Integrität von Endpunkten

Optimaler Betrieb

Ressourcengruppen: Verwenden Sie Ressourcengruppen, um Azure-Ressourcen nach Lebensdauer, Besitzer und anderen Merkmalen zu verwalten.

Peering virtueller Netzwerke: Durch das Peering virtueller Netzwerke können Sie mehrere virtuelle Netzwerke in Azure nahtlos verbinden. Die virtuellen Netzwerke werden für Verbindungszwecke als einzelnes Element angezeigt. Der Datenverkehr zwischen virtuellen Computern in virtuellen Netzwerken mit Peering erfolgt über die Microsoft-Backboneinfrastruktur. Stellen Sie sicher, dass sich die Adressräume der virtuellen Netzwerke nicht überlappen.

Virtuelles Netzwerk und Subnetze: Erstellen Sie ein separates Subnetz für jede Ebene Ihres Subnetzes. Sie sollten VMs und Ressourcen wie Application Gateway und Load Balancer in einem virtuellen Netzwerk mit Subnetzen bereitstellen.

Sicherheit

Web Application Firewall: Die WAF-Funktionalität von Azure Application Gateway erkennt und verhindert Angriffe auf HTTP-Ebene, z. B. SQL-Einschleusung (SQL injection, SQLi) oder Cross-Site Scripting (CSS).

Firewall der nächsten Generation: Azure Firewall Premium bietet eine zusätzliche Verteidigungsebene, indem Inhalte auf Nicht-Web-Angriffe überprüft werden, z. B. schädliche Dateien, die über HTTP(S) oder ein anderes Protokoll hochgeladen werden.

End-to-End-Verschlüsselung: Der Datenverkehr wird beim Durchlaufen des Azure-Netzwerks stets verschlüsselt. Sowohl Application Gateway als auch Azure Firewall verschlüsseln den Datenverkehr, bevor er an das entsprechende Back-End-System gesendet wird.

Distributed Denial of Service (DDoS): Verwenden Sie Azure DDoS-Netzwerkschutz für einen höheren DDoS-Schutz als den von Azure unterstützten grundlegenden Schutz.

Netzwerksicherheitsgruppen (Network Security Groups, NSGs): Verwenden Sie NSGs, um den Netzwerkdatenverkehr im virtuellen Netzwerk zu beschränken. In der hier gezeigten Drei-Schichten-Architektur akzeptiert die Datenschicht beispielsweise keinen Datenverkehr vom Web-Front-End, sondern nur von der Geschäftsschicht. Nur die Geschäftsebene kann direkt mit der Datenbankebene kommunizieren. Die Datenbankebene sollte den gesamten eingehenden Datenverkehr bis auf das Geschäftsebenensubnetz blockieren, um diese Regel zu erzwingen.

1. Lassen Sie eingehenden Datenverkehr aus dem Subnetz der Geschäftsebene zu.
2. Lassen Sie außerdem eingehenden Datenverkehr aus dem Datenbankebenen-Subnetz selbst zu. Diese Regel ermöglicht die Kommunikation zwischen den Datenbank-VMs. Die Datenbankreplikation und das Failover erfordern diese Regel.
3. Verweigern Sie den gesamten eingehenden Datenverkehr aus dem virtuellen Netzwerk, indem Sie das Tag „VirtualNetwork“ in der Regel verwenden, um die in den Standard-NSG-Regeln enthaltene Zulassungsanweisung zu überschreiben.

Erstellen Sie Regel 3 mit einer niedrigeren Priorität (höhere Zahl) als die ersten Regeln.

Sie können Diensttags verwenden, um Netzwerkzugriffssteuerungen in Netzwerksicherheitsgruppen oder in der Azure Firewall zu definieren.

Weitere Informationen finden Sie unter Konfiguration der Application Gateway-Infrastruktur.

Kostenoptimierung

Weitere Informationen finden Sie unter

• Preise des Lastenausgleichs
• Preise für virtuelle Netzwerke
• Preise für Application Gateway
• Auswählen der richtigen Azure Firewall SKU, die Ihre Anforderungen am besten erfüllt
• Traffic Manager – Preise
• Preisrechner

Effiziente Leistung

VM-Skalierungsgruppen: Verwenden Sie Virtual Machine Scale Sets, um die Skalierbarkeit Ihrer VMs zu automatisieren. VM-Skalierungsgruppen sind für alle Windows- und Linux-VM-Größen verfügbar. Es werden nur die bereitgestellten VMs und die zugrunde liegenden Infrastrukturressourcen in Rechnung gestellt. Es fallen keine zusätzlichen Gebühren an. Die Vorteile von VM-Skalierungsgruppen sind:

• Einfaches Erstellen und Verwalten mehrerer VMs
• Hochverfügbarkeit und Anwendungsresilienz
• Automatisierte Skalierung als Ressourcenbedarfsänderungen

Weitere Informationen finden Sie unter Was sind Skalierungsgruppen für virtuelle Computer?.

Nächste Schritte

Weitere Referenzarchitekturen, bei denen dieselben Technologien zum Einsatz kommen, finden Sie unter:

• n-schichtige Anwendung für mehrere Regionen
• AKS-Baseline für Cluster in mehreren Regionen