Häufig gestellte Fragen zu Azure Front Door (FAQs)

Azure Front Door ist ein cloudbasierter Dienst, der Ihre Anwendungen schneller und zuverlässiger bereitstellt. Es verwendet Layer-7-Lastausgleich, um den Datenverkehr auf mehrere Regionen und Endpunkte zu verteilen. Es bietet auch Dynamic Site Acceleration (DSA) zur Optimierung der Webleistung und Failover nahezu in Echtzeit, um eine hohe Verfügbarkeit zu gewährleisten. Azure Front Door ist ein vollständig verwalteter Dienst, sodass Sie sich keine Gedanken über Skalierung oder Wartung machen müssen.

Azure Front Door und Azure Application Gateway sind beide Lastenausgleichsmodule für HTTP/HTTPS-Datenverkehr, weisen jedoch unterschiedliche Bereiche auf. Front Door ist ein globaler Dienst, der Anforderungen über Regionen hinweg verteilen kann, während Application Gateway ein regionaler Dienst ist, der Anforderungen innerhalb einer Region ausgleichen kann. Azure Front Door funktioniert mit Skalierungseinheiten, Clustern oder Stempeleinheiten, während Azure Application Gateway mit VMs, Containern oder anderen Ressourcen in derselben Skalierungseinheit funktioniert.

Sie können verschiedene Arten von Ursprüngen für Azure Front Door verwenden, z. B.:

• Speicher (Azure Blob, klassisch, statische Websites)
• Clouddienst
• App-Dienst
• Statische Web-App
• API-Verwaltung
• Anwendungs-Gateway
• Öffentliche IP-Adresse
• Azure Spring Apps
• Containerinstanzen
• Container-Anwendungen
• Jeder benutzerdefinierte Hostname mit öffentlichem Zugriff.

Der Ursprung muss über eine öffentliche IP-Adresse oder einen DNS-Hostnamen verfügen, der öffentlich aufgelöst werden kann. Sie können Back-Ends aus verschiedenen Zonen, Regionen oder sogar außerhalb von Azure kombinieren, solange sie öffentlich zugänglich sind.

Azure Front Door ist nicht auf eine Azure-Region beschränkt, sondern wird global ausgeführt. Der einzige Speicherort, den Sie beim Erstellen einer Front Door auswählen müssen, ist der Speicherort der Ressourcengruppe, der bestimmt, wo die Metadaten der Ressourcengruppe gespeichert werden. Das Front Door-Profil ist eine globale Ressource, und seine Konfiguration wird an alle Edge-Standorte weltweit verteilt.

Eine vollständige Liste der Points of Presence (Points of Presence, POPs), die einen globalen Lastenausgleich und die Inhaltsbereitstellung für Azure Front Door ermöglichen, finden Sie unter Azure Front Door POP-Standorte. Diese Liste wird regelmäßig aktualisiert, wenn neue POPs hinzugefügt oder entfernt werden. Sie können auch die Azure Resource Manager-API verwenden, um die aktuelle Liste der POPs programmgesteuert abzufragen.

Azure Front Door ist ein Dienst, der Ihre Anwendung global über mehrere Regionen verteilt. Es verwendet eine gemeinsame Infrastruktur, die von allen Kunden gemeinsam genutzt wird, aber Sie können Ihr eigenes Front Door-Profil anpassen, um die spezifischen Anforderungen Ihrer Anwendung zu konfigurieren. Die Konfigurationen anderer Kunden können sich nicht auf Ihre Front Door-Konfiguration auswirken, die von ihrer Konfiguration isoliert ist.

Front Door sortiert die Routen für Ihre Webanwendung nicht. Stattdessen wählt es die Route, die am besten zur Anforderung passt. Informationen dazu, wie Front Door Anforderungen mit Routen abgleicht, finden Sie unter Zuordnen von Anforderungen zu einer Routingregel durch Front Door.

Um eine optimale Leistung der Front Door-Features sicherzustellen, sollten Sie nur zulassen, dass Datenverkehr, der von Azure Front Door stammt, Ihren Ursprung erreicht. Dies hat zur Folge, dass nicht autorisierte oder böswillige Anforderungen auf die Sicherheits- und Routingrichtlinien von Front Door stoßen und der Zugriff verweigert wird. Informationen zum Sichern Ihres Ursprungs finden Sie unter Sichern des Datenverkehrs zu Azure Front Door-Ursprüngen.

Die Bereitstellungszeit für neue Front Door-Konfigurationen variiert je nach Art der Änderung. In der Regel dauert es zwischen 3 und 20 Minuten, bis die Änderungen an alle unsere Edge-Standorte weltweit übertragen werden.

Aktualisierungen von Routen oder Ursprungsgruppen/Backend-Pools erfolgen nahtlos und verursachen keine Ausfallzeiten (vorausgesetzt, die neue Konfiguration ist korrekt). Zertifikatsaktualisierungen werden ebenfalls atomar durchgeführt, sodass kein Ausfallrisiko besteht.

• Front Door Standard-/Premium- und Azure CDN-Profile können ohne Ausfallzeiten zwischen Ressourcengruppen oder Abonnements verschoben werden. Befolgen Sie diese Anweisungen, um die Verschiebung auszuführen.
• Front Door Classic unterstützt das Verschieben zwischen Ressourcengruppen oder Abonnements nicht. Sie können stattdessen das Classic-Profil auf Standard/Premium migrieren und dann die Verschiebung ausführen.
• Wenn dem Kunden WAF mit Front Door Standard/Premium verknüpft ist, schlägt der Verschiebevorgang fehl. Der Kunde muss die Zuordnung von WAF-Richtlinien zuerst aufheben, verschieben und dann zuordnen.

Azure Front Door ist ein Dienst, der viele Vorteile für Ihre Webanwendungen bietet, z. B. Dynamic Site Acceleration (DSA), mit dem die Leistung und Benutzerfreundlichkeit Ihrer Websites verbessert wird. Azure Front Door verarbeitet auch TLS/SSL-Offloading und End-to-End-TLS, wodurch die Sicherheit und Verschlüsselung Ihres Webdatenverkehrs verbessert wird. Darüber hinaus bietet Azure Front Door Web Application Firewall, cookiebasierte Sitzungsaffinität, URL-pfadbasiertes Routing, kostenlose Zertifikate und die Verwaltung mehrerer Domänen und vieles mehr. Weitere Informationen zu den Features und Funktionen von Azure Front Door finden Sie unter Tarifvergleich.

Azure Front Door unterstützt HTTP, HTTPS und HTTP/2.

Azure Front Door unterstützt das HTTP/2-Protokoll für Clientverbindungen. Für die Kommunikation des Back-End-Pools wird jedoch das HTTP/1.1-Protokoll verwendet. Die HTTP/2-Unterstützung ist standardmäßig aktiviert.

Nein. Derzeit unterstützt Azure Front Door nur HTTP/1.1 vom Edge bis zum Ursprung. Damit gRPC funktioniert, ist HTTP/2 erforderlich.

Sie können Host-, Pfad- und Abfragezeichenfolgenkomponenten einer URL mit Azure Front Door umleiten. Informationen zum Konfigurieren der URL-Umleitung finden Sie unter URL-Umleitung.

Ja. Weitere Informationen finden Sie unter Zugriffsprotokolle auf die Eigenschaft MatchedRulesSetName.

Ja. Weitere Informationen finden Sie unter Reaktion von Microsoft auf DDoS-Angriffe auf HTTP/2.

Azure Front Door unterstützt die Header X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto. Diese Header helfen Front Door, die ursprüngliche Client-IP-Adresse und das Protokoll zu identifizieren. Wenn X-Forwarded-For bereits vorhanden ist, fügt Front Door die Clientsocket-IP-Adresse am Ende der Liste hinzu. Andernfalls wird der Header mit der Client-Socket-IP als Wert erstellt. Für X-Forwarded-Host und X-Forwarded-Proto ersetzt Front Door die vorhandenen Werte durch eigene Werte.

Weitere Informationen finden Sie unter Von Front Door unterstützte HTTP-Header.

Um den (klassischen) Tarif Azure Front Door Standard zu verwenden, benötigen Sie eine öffentliche IP-Adresse oder einen DNS-Namen, der öffentlich aufgelöst werden kann. Diese Anforderung einer öffentlichen IP-Adresse oder eines DNS-Namens, der öffentlich aufgelöst werden kann, ermöglicht Azure Front Door das Weiterleiten von Datenverkehr an Ihre Back-End-Ressourcen. Sie können Azure-Ressourcen wie Application Gateways oder Azure Load Balancer verwenden, um Datenverkehr an Ressourcen in einem virtuellen Netzwerk weiterzuleiten. Wenn Sie den Front Door Premium-Tarif verwenden, können Sie Private Link verwenden, um eine Verbindung mit Ursprüngen hinter einem internen Lastenausgleich mit einem privaten Endpunkt herzustellen. Weitere Informationen finden Sie unter Sichern von Ursprüngen mit Private Link.

Application Gateway hinter Front Door ist in den folgenden Situationen nützlich:

• Sie möchten den Datenverkehr nicht nur global, sondern auch innerhalb Ihres virtuellen Netzwerks ausgleichen. Front Door kann den pfadbasierten Lastenausgleich nur auf globaler Ebene durchführen, Application Gateway jedoch innerhalb Ihres virtuellen Netzwerks.
• Sie benötigen die Funktion "Verbindungsentleerung", die von Front Door nicht unterstützt wird. Application Gateway kann den Verbindungsausgleich für Ihre VMs oder Container aktivieren.
• Sie möchten die gesamte TLS/SSL-Verarbeitung auslagern und nur HTTP-Anforderungen in Ihrem virtuellen Netzwerk verwenden. Application Gateway hinter Front Door kann dieses Setup erreichen.
• Sie möchten die Sitzungsaffinität sowohl auf regionaler als auch auf Serverebene verwenden. Front Door kann den Datenverkehr von einer Benutzersitzung an dasselbe Back-End in einer Region senden, Application Gateway kann ihn jedoch an denselben Server im Back-End senden.

Die Verkettung von zwei CDNs ist im Allgemeinen kein empfohlener Ansatz, er würde funktionieren, hat aber die folgenden Nachteile:

1. Die Beschleunigung der letzten Meile von CDN nutzt die Beibehaltung des Verbindungsstroms mit dem Ursprung und die Suche nach dem optimalen Pfad zum Ursprung, um die besten Ergebnisse zu erzielen. Die Verkettung von zwei CDNs macht in der Regel einige der Vorteile der Beschleunigung auf der letzten Meile zunichte.
2. Sicherheitskontrollen werden beim zweiten CDN weniger effektiv. Client-IP-basierte ACLing funktioniert auf dem zweiten CDN nicht, da das zweite CDN den Ausgangsknoten des ersten CDN als Client-IPs sieht. Die Inhaltsnutzlast wird weiterhin überprüft.
3. Viele Unternehmen können die Komplexität der Fehlerbehebung bei zwei verketteten CDNs nicht bewältigen, und wenn ein Problem auftritt, wird es schwierig herauszufinden, welches CDN das Problem hat.

Um Azure Front Door verwenden zu können, benötigen Sie eine öffentliche VIP oder einen DNS-Namen, auf den öffentlich zugegriffen werden kann. Azure Front Door verwendet die öffentliche IP-Adresse, um den Datenverkehr an Ihren Ursprung weiterzuleiten. Ein gängiges Szenario ist die Bereitstellung eines Azure Load Balancer hinter Front Door. Sie können auch Private Link mit Azure Front Door Premium verwenden, um eine Verbindung mit einem internen Lastenausgleich herzustellen. Weitere Informationen finden Sie unter Aktivieren von Private Link mit dem internen Lastenausgleich.

Azure Front Door und Azure CDN sind zwei Dienste, die eine schnelle und zuverlässige Webbereitstellung für Ihre Anwendungen ermöglichen. Sie sind jedoch nicht miteinander kompatibel, da sie das gleiche Netzwerk von Azure Edge-Websites verwenden, um Inhalte für Ihre Benutzer bereitzustellen. Dieses freigegebene Netzwerk verursacht Konflikte zwischen den Routing- und Caching-Richtlinien. Daher müssen Sie je nach Ihren Leistungs- und Sicherheitsanforderungen entweder Azure Front Door oder Azure CDN für Ihre Anwendung auswählen.

Die Tatsache, dass beide Profile/Endpunkte denselben Azure Edge-POP verwenden, um eingehende Anforderungen zu verarbeiten, führt zu einer Einschränkung, die verhindert, dass Sie ein Azure Front Door-Profil/Endpunkt hinter einem anderen schachteln. Diese Einrichtung würde zu Routingkonflikten und Leistungsproblemen führen. Daher sollten Sie sicherstellen, dass Ihre Azure Front Door-Profile/Endpunkte nicht miteinander verkettet sind, wenn Sie mehrere Profile/Endpunkte für Ihre Anwendungen verwenden müssen.

Die IP-Adresse des Front-End-Anycast von Front Door ist fest und ändert sich möglicherweise nicht, solange Sie Front Door verwenden. Die feste IP-Adresse des Front-End-Anycast von Front Door ist jedoch keine Garantie. Vermeiden Sie es, sich direkt auf die IP zu verlassen. Um bei Änderungen an IP-Adressen auf dem Laufenden zu bleiben und geeignete Maßnahmen zu ergreifen, entwickeln Sie eine Automatisierung, um regelmäßig die neuesten IP-Adressen mithilfe der Service Tag Discovery API oder der JSON-Datei abzurufen.

Azure Front Door ist ein dynamischer Dienst, der Datenverkehr an das beste verfügbare Back-End weiterleitet. Derzeit werden keine statischen oder dedizierten Frontend-Anycast-IPs angeboten.

Azure Front Door verwendet drei Diensttags, um den Datenverkehr zwischen Ihren Clients und Ihren Ursprüngen zu verwalten:

• Das Diensttag AzureFrontDoor.Backend enthält die IP-Adressen, die Front Door für den Zugriff auf Ihre Ursprünge verwendet. Sie können dieses Diensttag anwenden, wenn Sie die Sicherheit für Ihre Ursprünge konfigurieren.
• Das Diensttag AzureFrontDoor.Frontend enthält die IP-Adressen, die Clients verwenden, um Front Door zu erreichen. Sie können das AzureFrontDoor.Frontend Diensttag anwenden, wenn Sie den ausgehenden Datenverkehr steuern möchten, der eine Verbindung mit Diensten hinter Azure Front Door herstellen kann.
• Das Diensttag AzureFrontDoor.FirstParty ist für eine ausgewählte Gruppe von Microsoft-Diensten reserviert, die in Azure Front Door gehostet werden.

Weitere Informationen zu Szenarien mit Azure Front Door-Diensttags finden Sie unter Verfügbare Diensttags. Um bei Änderungen an IP-Adressen auf dem Laufenden zu bleiben und geeignete Maßnahmen zu ergreifen, entwickeln Sie eine Automatisierung, um regelmäßig die neuesten IP-Adressen mithilfe der Service Tag Discovery API oder der JSON-Datei abzurufen.

Eine Ursprungsgruppe ist eine Sammlung von Ursprüngen, die ähnliche Arten von Anforderungen verarbeiten können. Sie benötigen eine andere Ursprungsgruppe für jede Anwendung oder Workload, die unterschiedlich ist.

In einer Ursprungsgruppe erstellen Sie einen Ursprung für jeden Server oder Dienst, der Anforderungen verarbeiten kann. Wenn Ihr Ursprung über einen Lastenausgleich verfügt, z. B. Azure Application Gateway, oder auf einem PaaS gehostet wird, der über einen Lastenausgleich verfügt, verfügt die Ursprungsgruppe nur über einen Ursprung. Ihr Ursprung kümmert sich um das Failover und den Lastenausgleich zwischen Ursprüngen, die Front Door nicht sieht.

Wenn Sie z. B. eine Anwendung in Azure App Service hosten, hängt die Art und Weise, wie Sie Front Door einrichten, davon ab, wie viele Anwendungsinstanzen Sie haben:

• Bereitstellung in einer einzelnen Region: Erstellen Sie eine Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für die App Service-App. Ihre App Service-App kann über Worker hinweg horizontal skaliert werden, aber Front Door erkennt einen Ursprung.
• Aktiv/Passiv-Bereitstellung in mehreren Regionen: Erstellen Sie eine Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für jede App Service-App. Legen Sie die Priorität jedes Ursprungs so fest, dass die Hauptanwendung eine höhere Priorität hat als die Sicherungsanwendung.
• Aktiv/Aktiv-Bereitstellung in mehreren Regionen: Erstellen Sie eine Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für jede App Service-App. Legen Sie die Priorität jedes Ursprungs auf die gleiche fest. Legen Sie die Gewichtung jedes Ursprungs fest, um zu steuern, wie viele Anforderungen an diesen Ursprung gesendet werden.

Weitere Informationen finden Sie unter Ursprünge und Ursprungsgruppen in Azure Front Door.

Azure Front Door ist ein Dienst, der eine schnelle und zuverlässige Webbereitstellung für Ihre Anwendungen ermöglicht. Es bietet Funktionen wie Caching, Load Balancing, Sicherheit und Routing. Sie müssen jedoch einige Timeouts und Grenzwerte beachten, die für Azure Front Door gelten. Zu diesen Zeitüberschreitungen und Grenzwerten gehören die maximale Anforderungsgröße, die maximale Antwortgröße, die maximale Header-Größe, die maximale Anzahl von Headern, die maximale Anzahl von Regeln und die maximale Anzahl von Ursprungsgruppen. Ausführliche Informationen zu diesen Timeouts und Grenzwerten finden Sie in der Azure Front Door-Dokumentation.

Die Konfigurationsaktualisierungen für die meisten Regelsätze sind in weniger als 20 Minuten abgeschlossen. Die Regel wird sofort angewendet, nachdem das Update abgeschlossen ist.

Azure Front Door verfügt über ein Timeout von 5 Sekunden für den Empfang von Headern vom Client. Die Verbindung wird beendet, wenn der Client nach dem Herstellen einer TCP/TLS-Verbindung innerhalb von 5 Sekunden keine Header an Azure Front Door sendet. Dieser Timeoutwert kann nicht konfiguriert werden.

Azure Front Door verfügt über ein HTTP-Keepalive-Timeout von 90 Sekunden. Die Verbindung wird beendet, wenn der Client 90 Sekunden lang keine Daten sendet, was dem HTTP-Keepalive-Timeout für Azure Front Door entspricht. Dieser Timeoutwert kann nicht konfiguriert werden.

Sie können nicht dieselben Domänen für mehr als einen Front Door-Endpunkt verwenden, da Front Door die Route (Protokoll + Host + Pfadkombination) für jede Anforderung unterscheiden muss. Wenn Sie über doppelte Routen über verschiedene Endpunkte verfügen, kann Azure Front Door die Anforderungen nicht ordnungsgemäß verarbeiten.

Derzeit bieten wir nicht die Möglichkeit, Domains ohne Unterbrechung des Dienstes von einem Endpunkt auf einen anderen zu verschieben. Sie müssen eine gewisse Ausfallzeit einplanen, wenn Sie Ihre Domänen zu einem anderen Endpunkt migrieren möchten.

Das Azure Front Door Private Link-Feature ist regionsunabhängig und funktioniert auch dann, wenn Sie eine Region auswählen, die sich von der Region unterscheidet, in der sich Ihr Ursprung befindet. Um eine geringere Latenz zu gewährleisten, sollten Sie in solchen Fällen immer eine Azure-Region auswählen, die Ihrem Ursprung am nächsten liegt, wenn Sie den Azure Front Door Private Link-Endpunkt aktivieren. Wir sind dabei, die Unterstützung für weitere Regionen zu ermöglichen. Sobald eine neue Region unterstützt wird, können Sie diese Anweisungen befolgen, um den Datenverkehr schrittweise in die neue Region zu verlagern.

Azure Front Door ist eine Plattform, die Datenverkehr auf der ganzen Welt verteilt und hochskaliert werden kann, um die Anforderungen Ihrer Anwendung zu erfüllen. Es nutzt den globalen Netzwerk-Edge von Microsoft, um eine globale Lastenausgleichsfunktion bereitzustellen, mit der Sie Ihre gesamte Anwendung oder bestimmte Microservices bei einem Ausfall in andere Regionen oder Clouds umschalten können.

Um Fehler bei der Übermittlung großer Dateien zu vermeiden, stellen Sie sicher, dass Ihr Ursprungsserver den Content-Range Header in die Antwort einschließt und dass der Header-Wert mit der tatsächlichen Größe des Antworttexts übereinstimmt.

Weitere Informationen zum Konfigurieren von Origin und Front Door für die Übermittlung großer Dateien finden Sie unter Bereitstellen großer Dateien.

Domain-Fronting ist eine Netzwerktechnik, die es einem Angreifer ermöglicht, das tatsächliche Ziel einer bösartigen Anfrage zu verbergen, indem er einen anderen Domainnamen im TLS-Handshake und im HTTP-Host-Header verwendet.

Für Azure Front Door (Standard-, Premium- und Classic-Tarif) oder Azure CDN Standard von Microsoft-Ressourcen (klassisch), die nach dem 8. November 2022 erstellt wurden, ist die Domänenfronting-Blockierung aktiviert. Anstatt eine Anforderung mit nicht übereinstimmenden SNI- und Host-Headern zu blockieren, lassen wir die Diskrepanz zu, wenn die beiden Domänen zum selben Abonnement gehören und in den Routen/Routingregeln enthalten sind. Die Durchsetzung der Domain-Fronting-Blockierung beginnt am 22. Januar 2024 für alle bestehenden Domains. Es kann bis zu zwei Wochen dauern, bis die Durchsetzung auf alle Regionen ausgeweitet wird.

Wenn Front Door eine Anforderung aufgrund einer Nichtübereinstimmung blockiert:

• Der Client erhält eine HTTP-Fehlercodeantwort 421 Misdirected Request .
• Azure Front Door zeichnet den Block in den Diagnoseprotokollen unter der Eigenschaft Fehlerinformationen mit dem Wert SSLMismatchedSNI auf.

Weitere Informationen zum Domänenfronting finden Sie unter Sichern unseres Ansatzes für Domänenfronting in Azure und Verbieten von Domänenfronting in Azure Front Door und Azure CDN Standard von Microsoft (klassisch).

Front Door verwendet TLS 1.2 als Mindestversion für alle Profile, die nach September 2019 erstellt wurden.

Sie können TLS 1.2 oder 1.3 mit Azure Front Door verwenden. Weitere Informationen finden Sie im Artikel Azure Front Door End-to-End-TLS.

Azure Front Door-Ressourcen können nicht deaktiviert werden. Sie können nur gelöscht werden. Variable Meter wie Datenübertragung, Datenübertragung und Anforderungen werden nicht berechnet, wenn kein Datenverkehr, aber Grundgebühr berechnet wird, auch wenn kein Datenverkehr vorhanden ist. Die Grundgebühr wird berechnet, bis das Profil gelöscht wird. Für AFD Classic werden WAF-Richtlinien und -Regeln unabhängig von ihrem Status belastet. Selbst wenn Sie eine WAF-Richtlinie oder -Regel deaktivieren, fallen für Sie dennoch Kosten an.

Nein.

Nein.

AFD unterstützt keine dynamische Komprimierung für Inhalte mit mehr als 8 MB. Wenn der Inhalt jedoch bereits vom Ursprung komprimiert wurde, unterstützt Front Door das Bereitstellen von statisch komprimierten Inhalten über 8 MB, solange die Bereichsanforderung unterstützt wird und die Codierung für die segmentweise Übertragung nicht aktiviert ist.

Nein.

Informationen zu Protokollen und anderen Diagnosefunktionen finden Sie unter Überwachen von Metriken und Protokollen für Front Door.

Sie können Diagnoseprotokolle in einem eigenen Speicherkonto speichern und auswählen, wie lange sie aufbewahrt werden sollen. Alternativ können Diagnoseprotokolle an Event Hubs oder Azure Monitor-Protokolle gesendet werden. Weitere Informationen finden Sie unter Azure Front Door-Diagnose.

Um auf die Überwachungsprotokolle von Azure Front Door zuzugreifen, müssen Sie das Portal besuchen. Wählen Sie auf der Menüseite Ihre Front Door aus, und wählen Sie dann Aktivitätsprotokoll aus. Das Aktivitätsprotokoll enthält die Aufzeichnungen der Vorgänge von Azure Front Door.

Sie können Warnungen für Azure Front Door basierend auf Metriken oder Protokollen einrichten. Auf diese Weise können Sie die Leistung und den Zustand Ihrer Front-End-Hosts überwachen.

Informationen zum Erstellen von Warnungen für Azure Front Door Standard und Premium finden Sie unter Konfigurieren von Warnungen.

Verwandte Inhalte

• Erfahren Sie, wie Sie ein Azure Front Door-Profil erstellen.
• Erfahren Sie mehr über die Azure Front Door-Architektur.