Häufig gestellte Fragen zu Azure Front Door

Azure Front Door ist ein cloudbasierter Dienst, der Ihre Anwendungen schneller und zuverlässiger bereitstellt. Er verwendet den Lastenausgleich der Ebene 7, um Datenverkehr auf mehrere Regionen und Endpunkte zu verteilen. Zudem bietet er Beschleunigung dynamischer Websites (Dynamic Site Acceleration, DSA) zum Optimieren der Webleistung und Failover in Quasi-Echtzeit, um eine hohe Verfügbarkeit sicherzustellen. Azure Front Door ist ein vollständig verwalteter Dienst, sodass Sie sich keine Gedanken über die Skalierung oder Wartung machen müssen.

Azure Front Door ist ein Dienst, der viele Vorteile für Ihre Webanwendungen bietet, z. B. die Beschleunigung dynamischer Websites (DSA), durch die die Leistung und Benutzererfahrung Ihrer Websites verbessert wird. Azure Front Door unterstützt auch TLS/SSL-Abladung und End-to-End-TLS, wodurch die Sicherheit und die Verschlüsselung Ihres Webdatenverkehrs verbessert werden. Azure Front Door bietet zudem Web Application Firewall (WAF), cookiebasierte Sitzungsaffinität, Routing auf URL-Pfadbasis, kostenfreie Zertifikate und Verwaltung mehrerer Domänen sowie weitere Features. Weitere Informationen zu den Features und Funktionen von Azure Front Door finden Sie im Vergleich der Dienstebenen.

Sowohl Azure Front Door als auch Azure Application Gateway sind Lastenausgleichsmodule für HTTP-/HTTPS-Datenverkehr, sie unterscheiden sich jedoch hinsichtlich ihres Anwendungsbereichs. Front Door ist ein globaler Dienst, der Anforderungen auf mehrere Regionen verteilen kann, während Application Gateway ein regionaler Dienst ist, der einen Lastenausgleich für Anforderungen innerhalb einer Region vornehmen kann. Azure Front Door arbeitet mit Skalierungseinheiten, Clustern oder Stempeln, während Azure Application Gateway mit VMs, Containern oder anderen Ressourcen in derselben Skalierungseinheit arbeitet.

In den folgenden Fällen ist die Bereitstellung von Application Gateway hinter Front Door nützlich:

• Sie möchten nicht nur global, sondern auch innerhalb Ihres virtuellen Netzwerks einen Lastenausgleich für den Datenverkehr vornehmen. Front Door kann nur einen pfadbasierten Lastenausgleich auf globaler Ebene vornehmen, Application Gateway ermöglicht jedoch einen Lastenausgleich innerhalb Ihres virtuellen Netzwerks.
• Sie benötigen einen Verbindungsausgleich, der von Front Door nicht unterstützt wird. Application Gateway kann den Verbindungsausgleich für Ihre VMs oder Container ermöglichen.
• Sie möchten die gesamte TLS/SSL-Verarbeitung abladen und nur HTTP-Anforderungen in Ihrem virtuellen Netzwerk verwenden. Dies kann durch Bereitstellen von Application Gateway hinter Front Door erzielt werden.
• Sie möchten die Sitzungsaffinität sowohl auf regionaler Ebene als auch auf Serverebene verwenden. Front Door kann den Datenverkehr von einer Benutzersitzung an dasselbe Back-End in einer Region senden, aber Application Gateway kann den Datenverkehr an denselben Server im Back-End senden.

Das Verketten von zwei CDNs wird im Allgemeinen nicht empfohlen, es würde zwar funktionieren, hätte aber die folgenden Nachteile

1. Für die Beschleunigung auf der letzten Meile des CDN wird die Verbindung mit dem Ursprungsstream aufrechterhalten und ein optimaler Pfad zum Ursprung gesucht, um die besten Ergebnisse zu erzielen. Durch das Verketten von zwei CDNs können in der Regel einige der Vorteile der Beschleunigung auf der letzten Meile nicht genutzt werden.
2. Sicherheitskontrollen sind im zweiten CDN weniger effektiv. Alle auf Client-IP-Adressen basierenden ACLs funktionieren im zweiten CDN nicht, da das zweite CDN den Ausgangsknoten des ersten CDN als Client-IP-Adresse ansieht. Die Inhaltsnutzdaten werden weiterhin überprüft.
3. Viele Organisationen können nicht mit der Komplexität der Problembehandlung von zwei verketteten CDNs umgehen, und bei einem Problem wird es schwierig zu ermitteln, in welchem CDN ein Problem besteht.

Um Azure Front Door zu verwenden, benötigen Sie eine öffentliche virtuelle IP (VIP) oder einen DNS-Namen, der öffentlich zugänglich ist. Azure Front Door verwendet die öffentliche IP-Adresse, um den Datenverkehr an Ihren Ursprung weiterzuleiten. En gängiges Szenario besteht darin, Azure Load Balancer hinter Front Door bereitzustellen. Sie können auch Private Link mit Azure Front Door Premium verwenden, um eine Verbindung mit einem internen Lastenausgleichsursprung herzustellen. Weitere Informationen finden Sie unter Aktivieren von Private Link mit internem Lastenausgleich.

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.

Sie können verschiedene Ursprungstypen für Azure Front Door verwenden, z. B.:

• Speicher (Azure Blob Storage, klassische statische Websites)
• Clouddienst
• App Service
• Statische Web-App
• API Management
• Application Gateway
• Öffentliche IP-Adresse
• Azure Spring Apps
• Container Instances
• Container-Apps
• Beliebige benutzerdefinierte Hostnamen 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, sofern sie öffentlich zugänglich sind.

Azure Front Door ist nicht auf eine Azure-Region beschränkt, sondern arbeitet auf globaler Ebene. Der einzige Speicherort, den Sie beim Erstellen einer Front Door-Instanz angeben müssen, ist der Speicherort der Ressourcengruppe. Dieser bestimmt, wo die Metadaten für die Ressourcengruppe gespeichert werden. Das Front Door-Profil ist eine globale Ressource, und seine Konfiguration wird an alle Edgestandorte weltweit verteilt.

Die vollständige Liste der POPs (Points of Presence), die einen globalen Lastenausgleich und die Inhaltsübermittlung für Azure Front Door bereitstellen, 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 (Application Programming Interface, Anwendungsprogrammierschnittstelle) verwenden, um die aktuelle Liste der POPs programmgesteuert abzufragen.

Azure Front Door ist ein Dienst, der Ihre Anwendung global über mehrere Regionen verteilt. Er verwendet eine gemeinsame Infrastruktur, die von allen Kund*innen gemeinsam genutzt wird. Sie können jedoch Ihr eigenes Front Door-Profil anpassen, um die spezifischen Anforderungen Ihrer Anwendung zu konfigurieren. Ihre Front Door-Konfiguration ist von den Konfigurationen anderer Kund*innen isoliert, sodass diese Ihre Konfiguration nicht beeinträchtigen können.

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.

Front Door sortiert die Routen für Ihre Webanwendung nicht. Stattdessen wird die Route ausgewählt, die am besten für die jeweilige Anforderung geeignet ist. Informationen dazu, wie Front Door Anforderungen Routen zuordnet, finden Sie unter Abgleich von Anforderungen mit Routingregeln durch Front Door.

Um eine optimale Leistung der Front Door-Features sicherzustellen, sollten Sie nur von Azure Front Door stammenden Datenverkehr zu Ihrem Ursprung zulassen. Dadurch wird nicht autorisierten oder schädlichen Anforderungen aufgrund der Sicherheits- und Routingrichtlinien von Front Door der Zugriff verweigert. Informationen zum Schützen Ihres Ursprungs finden Sie unter Sicherer Datenverkehr zu Azure Front Door-Ursprüngen.

Die Front-End-Anycast-IP-Adresse Ihrer Front Door-Instanz ist fest und kann sich nicht ändern, solange Sie Front Door verwenden. Die feste Front-End-Anycast-IP-Adresse Ihrer Front Door-Instanz stellt jedoch keine Garantie dar. Vermeiden Sie es, sich direkt auf die IP-Adresse zu verlassen.

Azure Front Door ist ein dynamischer Dienst, der Datenverkehr an das beste verfügbare Back-End weiterleitet. Er bietet derzeit keine statischen oder dedizierten Front-End-Anycast-IP-Adressen.

Ja. Weitere Informationen finden Sie in der Beschreibung der Eigenschaft MatchedRulesSetName unter Zugriffsprotokoll.

Ja. Weitere Informationen finden Sie im Blogbeitrag zur 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 und das ursprüngliche Protokoll zu identifizieren. Wenn „X-Forwarded-For“ bereits vorhanden ist, fügt Front Door die Client-Socket-IP-Adresse am Ende der Liste hinzu. Andernfalls wird der Header mit der Client-Socket-IP-Adresse als Wert erstellt. Für „X-Forwarded-Host“ und „X-Forwarded-Proto“ ersetzt Front Door die vorhandenen Werte durch seine eigenen Werte.

Weitere Informationen finden Sie unter Protokollunterstützung für HTTP-Header in Azure Front Door.

Der Zeitaufwand für die Bereitstellung neuer Front Door-Konfigurationen variiert je nach Typ der Änderung. In der Regel dauert es 3 bis 20 Minuten, bis die Änderungen an all unsere Edgestandorten weltweit verteilt werden.

Aktualisierungen von Routen oder Ursprungsgruppen/Back-End-Pools usw. erfolgen nahtlos und verursachen keine Downtime (sofern die neue Konfiguration korrekt ist). Zertifikataktualisierungen werden zudem atomisch durchgeführt, sodass kein Ausfallrisiko besteht.

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

• Front Door Standard/Premium- und Azure CDN-Profile können ohne Downtime zwischen Ressourcengruppen oder Abonnements verschoben werden. Führen Sie zum Verschieben die folgenden Anweisungen aus.
• Front Door Classic unterstützt das Verschieben zwischen Ressourcengruppen oder Abonnements nicht. Sie können stattdessen das klassische Profil zu Standard/Premium migrieren und dann die Verschiebung ausführen.
• Wenn ein Kunde Front Door Standard/Premium eine WAF zugeordnet hat, führt die Verschiebung zu einem Fehler. Der Kunde muss zunächst die Zuordnung der WAF-Richtlinien aufheben, anschließend die Verschiebung und dann die Zuordnung ausführen.

Für die Azure Front Door-Dienstebenen „Standard“, „Premium“ oder „Klassisch“ benötigen Sie eine öffentliche IP-Adresse oder einen DNS-Namen, der öffentlich aufgelöst werden kann. Eine öffentliche IP-Adresse oder ein öffentlich auflösbarer DNS-Name ermöglicht es Azure Front Door, Datenverkehr an Back-End-Ressourcen weiterzuleiten. Sie können Azure-Ressourcen wie Application Gateway- oder Azure Load Balancer-Instanzen verwenden, um Datenverkehr an Ressourcen innerhalb eines virtuellen Netzwerks weiterzuleiten. Bei der Front Door-Dienstebene „Premium“ 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 .

Eine Ursprungsgruppe ist eine Sammlung von Ursprüngen, die ähnliche Anforderungstypen verarbeiten können. Für jede Anwendung oder Workload, die sich von anderen unterscheidet, benötigen Sie eine andere Ursprungsgruppe.

Innerhalb einer Ursprungsgruppe erstellen Sie einen Ursprung für jeden Server oder jeden Dienst, der Anforderungen verarbeiten kann. Wenn Ihr Ursprung über einen Lastenausgleich wie Azure Application Gateway verfügt oder in einer PaaS-Instanz (Platform-as-a-Service) mit einem Lastenausgleich gehostet wird, hat die Ursprungsgruppe nur einen Ursprung. Ihr Ursprung übernimmt die Ausführung des Failovers und Lastenausgleichs zwischen Ursprüngen, die für Front Door nicht sichtbar sind.

Wenn Sie beispielsweise eine Anwendung in Azure App Service hosten, hängt die Einrichtung von Front Door davon ab, wie viele Anwendungsinstanzen Sie haben:

• Bereitstellung in einer einzelnen Region: Erstellen Sie eine einzelne Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für die App Service-App. Ihre App Service-App kann über Worker hinweg skaliert werden, aber Front Door sieht einen Ursprung.
• Aktiv/Passiv-Bereitstellung in mehreren Regionen: Erstellen Sie eine einzelne Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für jede App Service-App. Legen Sie die Priorität der einzelnen Ursprünge fest, damit die Hauptanwendung eine höhere Priorität hat als die Sicherungsanwendung.
• Aktiv/Aktiv-Bereitstellung in mehreren Regionen: Erstellen Sie eine einzelne Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für jede App Service-App. Legen Sie für jeden Ursprung die gleiche Priorität 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 bietet. Er bietet Features wie Zwischenspeichern, Lastenausgleich, Sicherheit und Routing. Sie müssen jedoch einige Timeouts und Grenzwerte beachten, die für Azure Front Door gelten. Zu diesen Timeouts und Grenzwerte zählen die maximale Anforderungsgröße, die maximale Antwortgröße, die maximale Headergröße, die maximale Anzahl von Headern, die maximale Anzahl von Regeln und die maximale Anzahl von Ursprungsgruppen. Detaillierte Informationen zu diesen Timeouts und Grenzwerten finden Sie in der Azure Front Door-Dokumentation.

Für die meisten Regelsätze nehmen die Konfigurationsaktualisierungen weniger als 20 Minuten in Anspruch. Die Regel wird direkt nach Abschluss der Aktualisierung angewendet.

Azure Front Door und Azure Content Delivery Network (CDN) sind zwei Dienste, die eine schnelle und zuverlässige Webbereitstellung für Ihre Anwendungen bieten. Sie sind jedoch nicht miteinander kompatibel, da sie dasselbe Netzwerk von Azure-Edge-Websites nutzen, um Inhalte für Ihre Benutzer*innen bereitzustellen. Dieses gemeinsam genutzte Netzwerk verursacht Konflikte zwischen ihren Routing- und Zwischenspeicherungsrichtlinien. Daher müssen Sie je nach Ihren Leistungs- und Sicherheitsanforderungen entweder Azure Front Door oder Azure CDN für Ihre Anwendung verwenden.

Aufgrund der Tatsache, dass beide Profile dieselben Azure-Edge-Websites zum Verarbeiten eingehender Anforderungen verwenden würden, ist es nicht möglich, ein Azure Front Door-Profil hinter einem anderen zu schachteln. Dieses Setup würde Routingkonflikte und Leistungsprobleme verursachen. Wenn Sie mehrere Profile für Ihre Anwendungen verwenden müssen, sollten Sie daher sicherstellen, dass Ihre Azure Front Door-Profile unabhängig und nicht miteinander verkettet sind.

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 zum Herstellen einer Verbindung mit Front Door verwenden. Sie können das Diensttag AzureFrontDoor.Frontend anwenden, wenn Sie den ausgehenden Datenverkehr steuern möchten, der eine Verbindung mit Diensten hinter Azure Front Door herstellen kann.
• Das AzureFrontDoor.FirstParty -Diensttag ist für eine ausgewählte Gruppe von Microsoft-Diensten reserviert, die auf Azure Front Door gehostet werden.

Weitere Informationen zu Szenarien für Azure Front Door-Diensttags finden Sie unter Verfügbare Diensttags.

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

Das HTTP-Keep-Alive-Timeout von Azure Front Door beträgt 90 Sekunden. Die Verbindung wird beendet, wenn der Client 90 Sekunden lang keine Daten sendet (d. h. nach dem HTTP-Keep-Alive-Timeout für Azure Front Door). Dieser Timeoutwert kann nicht konfiguriert werden.

Sie können nicht dieselben Domänen für mehrere Front Door-Endpunkte verwenden, da Front Door zwischen den Routen (Kombination aus Protokoll, Host und Pfad) für jede Anforderung unterscheiden muss. Wenn Sie doppelte Routen für verschiedene Endpunkte haben, kann Azure Front Door die Anforderungen nicht korrekt verarbeiten.

Derzeit bieten wir nicht die Möglichkeit, Domänen ohne Dienstunterbrechung von einem Endpunkt zu einem anderen zu verschieben. Sie müssen etwas Downtime einplanen, wenn Sie Ihre Domänen zu einem anderen Endpunkt migrieren möchten.

Das Private Link-Feature von Azure Front Door 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 in solchen Fällen die Latenz zu verringern, sollten Sie immer eine Azure-Region auswählen, die Ihrem Ursprung am nächsten ist, wenn Sie den Private Link-Endpunkt von Azure Front Door aktivieren. An der Unterstützung für mehrere Regionen wird derzeit gearbeitet. Wenn eine neue Region unterstützt wird, können Sie anhand dieser Anweisungen den Datenverkehr schrittweise in die neue Region übertragen.

Azure Front Door ist eine Plattform, die Datenverkehr weltweit verteilt und entsprechend den Anforderungen Ihrer Anwendung skalieren kann. Sie verwendet den globalen Netzwerkedge von Microsoft, um einen globalen Lastenausgleich bereitzustellen, der es Ihnen ermöglicht, Ihre gesamte Anwendung oder bestimmte Microservices im Fall eines Ausfalls in verschiedene Regionen oder Clouds zu verschieben.

Um Fehler beim Übermitteln großer Dateien zu vermeiden, stellen Sie sicher, dass der Ursprungsserver den Content-Range-Header in der Antwort enthält und dass der Headerwert der tatsächlichen Größe des Antworttexts entspricht.

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

Domänen-Fronting ist eine Technik, mit der Angreifer*innen das tatsächliche Ziel einer schädlichen Anforderung verbergen können, indem sie einen anderen Domänennamen im TLS-Handshake und HTTP-Hostheader verwenden.

Azure Front Door (Standard- und Premium- und Classic-Stufe) oder Azure CDN Standard von Microsoft-Ressourcen (klassisch), die nach dem 8. November 2022 erstellt wurden, verfügen über aktivierte Domänen-Fronting-Blockierung. Anstatt eine Anforderung mit nicht übereinstimmenden SNI- und Hostheadern zu blockieren, lassen wir die Diskrepanz zu, wenn die beiden Domänen zum gleichen Abonnement gehören und in den Routen/Routingregeln enthalten sind. Das Erzwingen der Domänen-Fronting-Blockierung beginnt am 22. Januar 2024 für alle vorhandenen Domänen. Die Durchsetzung kann bis zu zwei Wochen erfordern, um sich an alle Regionen zu verteilen.

Wenn Front Door eine Anforderung aufgrund eines Konflikts blockiert, geschieht Folgendes:

• Der Client empfängt eine Antwort mit dem HTTP-Fehlercode 421 Misdirected Request.
• Azure Front Door protokolliert den Block in den Diagnoseprotokollen unter der Eigenschaft Fehlerinformationen mit dem Wert SSLMismatchedSNI.

Weitere Informationen zum Fronting von Domänen finden Sie unter Sichern unseres Ansatzes zur Domänen-Fronting innerhalb von Azure und Verbieten von Domänen-Fronting auf 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.0, 1.1, 1.2 oder 1.3 mit Azure Front Door verwenden. Weitere Informationen finden Sie im Artikel End-to-End-TLS mit Azure Front Door.

Azure Front Door ist ein Dienst, der eine schnelle und sichere Webbereitstellung bietet. Sie können definieren, wie Ihr Webdatenverkehr über mehrere Regionen und Endpunkte weitergeleitet und optimiert wird. Für Azure Front Door-Ressourcen (z. B. Front Door-Profile und Routingregeln) fallen nur Kosten an, wenn sie aktiviert sind. WAF-Richtlinien und -Regeln (Web Application Firewall) werden jedoch unabhängig von ihrem Status abgerechnet. Selbst wenn Sie eine WAF-Richtlinie oder -Regel deaktivieren, entstehen für Sie weiterhin Kosten.

Nein

Nein

AFD unterstützt keine dynamische Komprimierung für Inhalte, die größer als 8 MB sind. Wenn der Inhalt jedoch bereits am Ursprung komprimiert wurde, unterstützt Front Door die Bereitstellung statisch komprimierter Inhalte von mehr als 8 MB, sofern die Bereichsanforderung unterstützt wird und die Blockübertragungscodierung 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 im zugehörigen Speicherkonto speichern und festlegen, wie lange sie beibehalten werden sollen. Alternativ können Diagnoseprotokolle auch 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 in der Menüseite Ihre Front Door-Instanz und dann die Option Aktivitätsprotokoll aus. Das Aktivitätsprotokoll enthält die Datensätze zu den Vorgängen Ihrer Azure Front Door-Instanz.

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

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

Nächste Schritte

• Erfahren Sie, wie Sie ein Azure Front Door-Profil erstellen.
• Machen Sie sich mit der Azure Front Door-Architektur vertraut.