Azure Front Door veelgestelde vragen (FAQ)

Azure Front Door is een cloudservice die uw toepassingen sneller en betrouwbaarder levert. Het maakt gebruik van laag 7 load balancing om verkeer over meerdere regio's en eindpunten te verdelen. Het biedt ook dynamische siteversnelling (DSA) om de webprestaties te optimaliseren en bijna realtime failover om hoge beschikbaarheid te garanderen. Azure Front Door is een volledig beheerde service, dus u hoeft zich geen zorgen te maken over schalen of onderhoud.

Azure Front Door en Azure Application Gateway zijn beide load balancers voor HTTP/HTTPS-verkeer, maar ze hebben verschillende toepassingsgebieden. Front Door is een wereldwijde service die aanvragen over regio's kan distribueren, terwijl Application Gateway een regionale service is die aanvragen binnen een regio kan balanceren. Azure Front Door werkt met schaaleenheden, clusters of stamp units, terwijl Azure Application Gateway werkt met VM's, containers of andere resources in dezelfde schaaleenheid.

U kunt verschillende soorten origins gebruiken voor Azure Front Door, zoals:

• Opslag (Azure Blob, Klassiek, Statische websites)
• Cloud-dienst
• App-dienst
• Statische web-app
• API-beheer
• Application Gateway
• Openbaar IP-adres
• Azure Spring Apps
• Containerinstanties
• Container-toepassingen
• Elke aangepaste hostnaam met openbare toegang.

De oorsprong moet een openbaar IP-adres of een DNS-hostnaam hebben die openbaar kan worden opgelost. U kunt back-ends uit verschillende zones, regio's of zelfs buiten Azure combineren en vergelijken, zolang ze openbaar toegankelijk zijn.

Azure Front Door is niet beperkt tot een Azure regio, maar werkt wereldwijd. De enige locatie die je kiest wanneer je een Front Door aanmaakt, is de locatie van de resourcegroep, die bepaalt waar de metadata van de resourcegroep wordt opgeslagen. Het Front Door-profiel is een wereldwijde bron en de configuratie ervan wordt gedistribueerd naar alle edge-locaties wereldwijd.

Zie Azure Front Door POP-locaties voor een volledige lijst met aanwezigheidspunten die wereldwijde taakverdeling en contentlevering bieden voor Azure Front Door. Deze lijst wordt regelmatig bijgewerkt als er nieuwe POP's worden toegevoegd of verwijderd. U kunt ook de Azure Resource Manager-API gebruiken om programmatisch een query uit te voeren op de huidige lijst met POP's.

Azure Front Door is een service die uw toepassing wereldwijd over meerdere regio's distribueert. Het gebruikt een gemeenschappelijke infrastructuur die al zijn klanten delen, maar je kunt je eigen Front Door-profiel aanpassen om de specifieke eisen van je applicatie te configureren. De configuraties van andere klanten kunnen geen invloed hebben op uw voordeurconfiguratie, die geïsoleerd is van die van hen.

Front Door sorteert de routes voor je webapplicatie niet. In plaats daarvan kiest het de route die het beste bij de vraag past. Zie Hoe Front Door aanvragen koppelt aan een routeringsregel voor meer informatie over hoe Front Door aanvragen aan routes koppelt.

Om optimale prestaties van de functies van Front Door te garanderen, staat u alleen verkeer toe dat afkomstig is van Azure Front Door om uw origin te bereiken. Als gevolg hiervan komen ongeautoriseerde of kwaadwillige verzoeken in aanraking met het beveiligings- en routeringsbeleid van Front Door en wordt de toegang geweigerd. Zie Secure traffic to Azure Front Door origins voor meer informatie over het beveiligen van uw oorsprong.

De configuratiepropagatietijden voor één enkele aanmaken, update, verwijderen of WAF-operatie voor Azure Front Door- en CDN-profielen kunnen tot 15 minuten duren voor extra veiligheid. Een enkele cache-purge-operatie wordt binnen 10 minuten voltooid. Opeenvolgende wijzigingen kunnen de totale uitroltijd verlengen tot ongeveer 30 minuten. Elke configuratie-update, inclusief aanpassingen van regelsets, routingwijzigingen, oorsprong- of domeinupdates en WAF-aanpassingen, wordt behandeld als een globale operatie. Als je extra bewerkingen inlevert terwijl de eerste bewerking nog in gang is (binnen het ~15-minutenvenster), zet het systeem deze in de wachtrij en begint pas nadat de voorgaande bewerking is voltooid. In dit scenario wordt de eerste bewerking binnen de eerste 15 minuten voltooid, en worden de volgende wijzigingen verwerkt in het volgende venster. Er worden doorlopende platformverbeteringen uitgevoerd die deze tijd verder zullen verminderen.

Meerdere opschoningsaanvragen verzenden

Elke opschoningsaanvraag kan maximaal 100 URL's bevatten (combinatie van domein en pad). De eerste batch wordt verwerkt en werkt binnen ongeveer 10 minuten.

Als je meer dan 100 URL's moet verwijderen, moet je wachten en controleren of de eerste batch is afgerond voordat je de volgende batch indient. Als je een nieuw opruimverzoek indient voordat de vorige batch is afgerond, wordt het verzoek afgewezen.

Voorbeeld: 256 URL's leegmaken

1. Verzend de eerste 100 URL's in de eerste opschoningsaanvraag.
2. Wacht ongeveer 10 minuten en controleer of de eerste batch succesvol is afgerond.
3. Verzend de volgende 101-200 URL's in de tweede aanvraag.
4. Wacht ongeveer 10 minuten tot de tweede batch klaar is.
5. Verzend de resterende 201-256 URL's in de derde aanvraag.

Updates voor routes of oorsprongsgroepen/back-endpools zijn naadloos en veroorzaken geen downtime (ervan uitgaande dat de nieuwe configuratie correct is). Certificaatupdates worden ook atomisch uitgevoerd, dus er is geen downtime.

• Je kunt Front Door Standard/Premium en Azure CDN-profielen verplaatsen tussen resourcegroepen of abonnementen zonder downtime. Volg deze instructies om de verplaatsing uit te voeren.
• Azure Front Door (classic) ondersteunt geen overgang tussen resourcegroepen of abonnementen. Je kunt in plaats daarvan het Azure Front Door (classic) profiel migreren naar Standard/Premium en vervolgens de verhuizing uitvoeren.
• Als je een WAF-polis koppelt aan Azure Front Door Standard of Premium, mislukt de verplaatsingsoperatie. Je moet eerst het WAF-beleid loskoppelen, de verhuizing voltooien en daarna het beleid opnieuw koppelen.

Azure Front Door biedt veel voordelen voor uw webapplicaties, zoals dynamische siteversnelling (DSA), die de prestaties en gebruikerservaring van uw sites verbetert. Azure Front Door verzorgt ook TLS/SSL-offloading en end-to-end TLS, wat de beveiliging en encryptie van je webverkeer verbetert. Daarnaast biedt Azure Front Door een webapplicatiefirewall, cookie-gebaseerde sessieaffiniteit, URL-pad-gebaseerde routering, gratis certificaten, beheer van meerdere domeinen en meer. Zie tiervergelijking voor meer informatie over de functies en mogelijkheden van Azure Front Door.

Azure Front Door ondersteunt HTTP, HTTPS en HTTP/2.

Azure Front Door ondersteunt het HTTP/2-protocol voor clientverbindingen. De communicatie van de back-endpool maakt echter gebruik van het HTTP/1.1-protocol. HTTP/2-ondersteuning is standaard ingeschakeld.

Nee. Momenteel ondersteunt Azure Front Door alleen HTTP/1.1 van de rand naar de oorsprong. Om gRPC te laten werken, is HTTP/2 vereist.

U kunt host-, pad- en queryreeksonderdelen van een URL omleiden met Azure Front Door. Om te leren hoe je URL-omleiding configureert, zie URL-omleiding.

Ja. Zie het MatchedRulesSetName eigendom onder Toegangslogboeken.

Ja. Zie Microsoft-reactie op DDoS-aanvallen tegen HTTP/2 voor meer informatie.

Nee. Azure Front Door kan clientverkeer niet afdwingen naar een specifieke POP. Aanvragen worden doorgestuurd naar de dichtstbijzijnde beschikbare edge-locatie voor prestaties en betrouwbaarheid. Als u de toegang per geografie wilt beperken, gebruikt u aangepaste regels voor Azure Web Application Firewall (WAF) met GeoMatch voorwaarden. Met deze benadering kunnen aanvragen op basis van het land/de regio van de client worden toegestaan of geblokkeerd, maar deze clients worden niet omgeleid naar een andere POP in een ander land/andere regio. Als u bijvoorbeeld land/regio A blokkeert, worden verzoeken van klanten in land/regio A geblokkeerd, ongeacht welke POP ze zou hebben bediend. Zie Geo-filtering in Azure WAF voor Azure Front Door voor meer informatie.

Azure Front Door ondersteunt de headers X-Forwarded-For, X-Forwarded-Host en X-Forwarded-Proto. Deze headers helpen Front Door bij het identificeren van het oorspronkelijke IP-adres en protocol van de client. Als X-Forwarded-For al aanwezig is, voegt Front Door het IP-adres van de clientsocket toe aan het einde van de lijst. Anders wordt de header gemaakt met het IP-adres van de clientsocket als waarde. Voor X-Forwarded-Host en X-Forwarded-Proto vervangt Front Door de bestaande waarden door zijn eigen waarden.

Zie Ondersteunde HTTP-headers voor Front Door voor meer informatie.

Om Azure Front Door Standard of Azure Front Door (classic) te gebruiken, heb je een publiek IP-adres of een publiek oplosbare DNS-naam nodig. Deze eis stelt Azure Front Door in staat om verkeer naar je backend-resources te routeren. U kunt Azure resources zoals Application Gateways of Azure Load Balancers gebruiken om verkeer naar resources in een virtueel netwerk te routeren. Als je Azure Front Door Premium gebruikt, kun je Private Link gebruiken om verbinding te maken met oorsprongen achter een interne load balancer via een privé-endpoint. Zie Secure origins with Private Link voor meer informatie.

Nee. Voor beveiliging ondersteunt Azure Front Door alleen verificatie op basis van beheerde identiteiten bij het openen van certificaten in Key Vault. Zie Beheerde identiteiten gebruiken in Azure Front Door voor meer informatie.

Nee. Azure Front Door biedt momenteel geen ondersteuning voor integratie van beheerde identiteiten met Azure Event Hubs.

Nee. Azure Front Door biedt momenteel geen ondersteuning voor aangepaste foutpagina's.

Application Gateway achter Front Door is handig in de volgende situaties:

• U wilt het verkeer niet alleen wereldwijd balanceren, maar ook binnen uw virtuele netwerk. Front Door kan alleen taakverdeling op basis van paden op mondiaal niveau uitvoeren, maar Application Gateway kan dit binnen uw virtuele netwerk doen.
• Je hebt Connection Draining nodig, maar Front Door ondersteunt dit niet. Application Gateway kan Connection Draining inschakelen voor uw VM's of containers.
• U wilt alle TLS/SSL-verwerking ontlasten en alleen HTTP-verzoeken in uw virtuele netwerk gebruiken. Application Gateway achter Front Door kan deze configuratie realiseren.
• U wilt sessieaffiniteit zowel op regionaal als op serverniveau gebruiken. Front Door kan het verkeer van een gebruikerssessie naar dezelfde back-end in een regio verzenden, maar Application Gateway kan het naar dezelfde server in de back-end verzenden.

Het aaneenkoppelen van twee CDN's wordt over het algemeen niet aanbevolen. Hoewel het kan werken, heeft het de volgende nadelen:

1. De last mile versnelling van een CDN werkt door de verbindingsstroom met de oorsprong te behouden en het optimale pad naar de oorsprong te vinden om de beste resultaten te bereiken. Het aan elkaar koppelen van twee CDN's doet doorgaans een deel van de voordelen van acceleratie op de laatste kilometer teniet.
2. Beveiligingsmaatregelen zijn minder effectief bij het tweede CDN. Toegangscontrole op basis van Client IP werkt daar niet, omdat het tweede CDN het exitknooppunt van het eerste CDN als het client IP identificeert. De inhoudslading wordt nog steeds geïnspecteerd.
3. Het koppelen van twee CDN's verhoogt de complexiteit van probleemoplossingen. Wanneer er een probleem ontstaat, kan het moeilijk zijn te bepalen welk CDN het veroorzaakt.

Als u Azure Front Door wilt gebruiken, moet u een openbaar VIP of een DNS-naam hebben die openbaar toegankelijk is. Azure Front Door het openbare IP-adres gebruikt om het verkeer naar uw oorsprong te routeren. Een veelvoorkomend scenario is het implementeren van een Azure Load Balancer achter Front Door. U kunt Private Link ook gebruiken met Azure Front Door Premium om verbinding te maken met een interne load balancer. Zie enable Private Link met interne load balancer voor meer informatie.

Azure Front Door en Azure CDN zijn twee services die snelle en betrouwbare weblevering bieden voor uw toepassingen. Ze zijn echter niet compatibel met elkaar, omdat ze hetzelfde netwerk van Azure edge-sites delen om inhoud aan uw gebruikers te leveren. Dit gedeelde netwerk veroorzaakt conflicten tussen hun routerings- en cachingbeleid. Daarom moet u kiezen voor Azure Front Door of Azure CDN voor uw toepassing, afhankelijk van uw prestatie- en beveiligingsvereisten.

Het feit dat beide profielen/endpoints dezelfde Azure Edge POP gebruiken om binnenkomende verzoeken af te handelen, veroorzaakt een beperking die voorkomt dat je het ene Azure Front Door-profiel/endpoint achter het andere nestt. Deze instelling zou routeringsconflicten en prestatieproblemen veroorzaken. Daarom moet je, als je meerdere profielen/endpoints voor je applicaties moet gebruiken, ervoor zorgen dat je Azure Front Door-profielen/endpoints niet aan elkaar gekoppeld zijn.

Azure Front Door gebruikt unicast-routing voor naamresolutie en stuurt verzoeken naar het optimale point of presence (POP). Unicast verving de Anycast-routeringsmethode die Azure Front Door eerder gebruikte.

Een naamomzettingsaanvraag voor een bron die gebruikmaakt van Azure Front Door komt terecht op het Traffic Manager-eindpunt van Front Door. De Traffic Manager-profielen van Front Door verbruiken talloze status- en beschikbaarheidssignalen van de PoPs wereldwijd. Op basis van deze signalen wordt het unicast-IP-adres van de optimale Front Door PoP geretourneerd. De aanvraag wordt vervolgens rechtstreeks verzonden naar het geretourneerde IP-adres, dat de Front Door-routeringsarchitectuur volgt om het antwoord terug te sturen naar de gebruiker of toepassing.

Azure Front Door gebruikt drie servicetags om het verkeer tussen uw clients en uw oorsprongen te beheren:

• De AzureFrontDoor.Backend-servicetag bevat de IP-adressen die Front Door gebruikt om toegang te krijgen tot uw bronnen. U kunt deze servicetag toepassen wanneer u beveiliging voor uw origins configureert.
• De servicetag AzureFrontDoor.Frontend bevat de IP-adressen die clients gebruiken om Front Door te bereiken. U kunt de servicetag AzureFrontDoor.Frontend toepassen wanneer u het uitgaande verkeer wilt beheren dat verbinding kan maken met services achter Azure Front Door.
• De servicetag AzureFrontDoor.FirstParty is gereserveerd voor een bepaalde groep Microsoft-services gehost op Azure Front Door.

Voor meer informatie over servicetags van Azure Front Door, zie beschikbare servicetags. Om op de hoogte te blijven en passende maatregelen te nemen tijdens wijzigingen in IP-adressen, ontwikkelt u automatisering om regelmatig de nieuwste IP-adressen op te halen met behulp van de Service Tag Discovery API of het JSON-bestand.

Een herkomstgroep is een verzameling oorsprongen die vergelijkbare soorten aanvragen kan verwerken. Voor elke applicatie of workload die anders is, heb je een andere oorsprongsgroep nodig.

In een herkomstgroep maakt u een oorsprong voor elke server of service die aanvragen kan verwerken. Als uw oorsprong een load balancer heeft, zoals Azure Application Gateway, of wordt gehost op een PaaS met een load balancer, heeft de oorspronkelijke groep slechts één oorsprong. Uw herkomstserver zorgt voor failover en loadbalancing tussen origins die Front Door niet ziet.

Als u bijvoorbeeld een toepassing op Azure App Service host, is de wijze waarop u Front Door instelt, afhankelijk van het aantal toepassingsexemplaren dat u hebt:

• Implementatie in één regio: maak één oorsprongsgroep. Maak in die herkomstgroep één oorsprong voor de App Service-app. Uw App Service-app kan worden uitgeschaald naar meerdere werknemers, maar Front Door ziet één oorsprong.
• Actieve/passieve implementatie in meerdere regio's: maak één oorsprongsgroep. Maak in die herkomstgroep een oorsprong voor elke App Service-app. Stel de prioriteit van elke oorsprong zo in dat de hoofdtoepassing een hogere prioriteit heeft dan de back-uptoepassing.
• Actieve/actieve implementatie in meerdere regio's: Maak één originegroep. Maak in die herkomstgroep een oorsprong voor elke App Service-app. Stel de prioriteit van elke oorsprong in op hetzelfde. Stel het gewicht van elke oorsprong in om te bepalen hoeveel verzoeken naar die oorsprong gaan.

Zie Origins en origin-groepen in Azure Front Door voor meer informatie.

Azure Front Door is een service die snelle en betrouwbare weblevering biedt voor uw toepassingen. Het biedt functies zoals caching, load balancing, beveiliging en routering. U moet echter rekening houden met een aantal time-outs en limieten die van toepassing zijn op Azure Front Door. Deze time-outs en limieten omvatten de maximale aanvraaggrootte, de maximale reactiegrootte, de maximale headergrootte, het maximale aantal headers, het maximale aantal regels en het maximale aantal oorsprongsgroepen. U vindt de gedetailleerde informatie over deze time-outs en limieten in de documentatie Azure Front Door.

De meeste regelsets werken hun configuraties in minder dan 15 minuten bij. De regel geldt zodra de update klaar is.

Azure Front Door heeft een time-out van 5 seconden voor het ontvangen van headers van een client. Als de client niet binnen 5 seconden na het opzetten van een TCP/TLS-verbinding met Azure Front Door headers stuurt, wordt de verbinding beëindigd. Je kunt deze time-out niet configureren.

Azure Front Door heeft een HTTP keep-alive time-out van 90 seconden. De verbinding wordt beëindigd als de client gedurende 90 seconden geen gegevens verzendt. Dit is de time-out voor http-keep-alive voor Azure Front Door. U kunt deze time-outwaarde niet configureren.

U kunt dezelfde domeinen niet gebruiken voor meer dan één Front Door-eindpunt, omdat Front Door voor elke aanvraag een onderscheid moet maken tussen de route (protocol + host + pad). Als u dubbele routes hebt voor verschillende eindpunten, kan Azure Front Door de aanvragen niet correct verwerken.

Op dit moment bieden we niet de mogelijkheid om domeinen van het ene eindpunt naar het andere te verplaatsen zonder enige onderbreking van de service. U moet rekening houden met enige downtime als u uw domeinen naar een ander eindpunt wilt migreren.

Azure Front Door Private Link is niet regiogebonden. Voor de laagste latentie selecteer je de ondersteunde Azure regio die het dichtst bij je oorsprong ligt wanneer je een Azure Front Door Private Link-endpoint inschakelt. Als de regio van uw oorsprong niet wordt ondersteund in de lijst met regio's die Front Door Private Link ondersteunt, kiest u de dichtstbijzijnde regio. Verkeer stroomt van de client naar het Azure Front Door Private Link-eindpunt in de ondersteunde regio en doorkruist vervolgens het Microsoft backbone-netwerk naar uw oorsprong, met behoud van privéconnectiviteit. Deze configuratie introduceert extra latentie door de extra netwerksprong tussen regio's. Je kunt statistieken voor de round-trip-latentie van het Azure-netwerk gebruiken om de extra latentie te bepalen als gevolg van de keuze voor de op één na dichtstbijzijnde regio. Wanneer een nieuwe regio wordt ondersteund, kun je deze instructies volgen om het verkeer geleidelijk naar de nieuwe regio te verplaatsen.

Azure Front Door is een platform dat verkeer over de hele wereld distribueert en omhoog kan schalen om te voldoen aan de eisen van uw toepassing. Het gebruikt het globale edge-netwerk van Microsoft om globale load balancing te bieden, waarmee je je volledige applicatie of specifieke microservices naar andere regio's of clouds kunt verplaatsen als er een storing optreedt.

Om fouten te voorkomen bij het leveren van grote bestanden, zorg ervoor dat je originserver de Content-Range header in het antwoord opneemt, en dat de headerwaarde overeenkomt met de werkelijke grootte van de responsbody.

U kunt meer informatie vinden over het configureren van uw originserver en Front Door voor de levering van grote bestanden in Levering van grote bestanden.

Domain fronting is een netwerktechniek waarmee een aanvaller de werkelijke bestemming van een kwaadaardig verzoek kan verbergen door een andere domeinnaam te gebruiken in de TLS-handshake en de HTTP-hostheader.

Azure Front Door (Standard, Premium en classic tier) of Azure CDN Standard van Microsoft (classic) bronnen die na 8 november 2022 zijn aangemaakt, hebben domain fronting blocking ingeschakeld. In plaats van een verzoek te blokkeren met niet overeenkomende SNI- en hostheaders, staan we de discrepantie toe als de twee domeinen tot hetzelfde abonnement behoren en zijn opgenomen in de routes of routeringsregels. De handhaving van het blokkeren van domeinfronten begon op 22 januari 2024.

Wanneer Front Door een aanvraag blokkeert vanwege een niet-overeenkomende aanvraag:

• De client ontvangt een HTTP-foutcodereactie 421 Misdirected Request .
• Azure Front Door registreert het blok in de diagnostische logboeken onder de eigenschap Foutinfo met de waarde SSLMismatchedSNI.

Voor meer informatie over domeinfronting, zie Securing our approach to domain fronting within Azure en Prohibiting domain fronting on Azure Front Door and Azure CDN Standard from Microsoft (classic).

Front Door gebruikt TLS 1.2 als minimumversie voor alle profielen die na september 2019 zijn gemaakt.

U kunt ervoor kiezen om TLS 1.2 of 1.3 te gebruiken met Azure Front Door. Lees het artikel Azure Front Door end-to-end TLS voor meer informatie.

Vanaf 15 augustus 2025 is DigiCert overgestapt op een nieuw OSS-platform (OpenSource Software Domain Control Validation) dat is ontworpen om transparantie en verantwoordelijkheid in domeinvalidatieprocessen te verbeteren. DigiCert ondersteunt niet langer de legacy CNAME Delegation DCV-workflow voor domeincontrolevalidatie in de gespecificeerde Azure-diensten. Meer informatie

De afschaffing is van invloed op services die afhankelijk zijn van CNAME-validatie voor geautomatiseerde certificaatuitgifte en verlenging, waaronder:

• Azure Front Door (klassiek)
• Azure CDN uit Microsoft (klassiek)

Azure Front Door (klassiek) en Azure CDN uit Microsoft (klassiek):

• Met ingang van 15 augustus 2025 is er geen ondersteuning meer voor het onboarding van nieuwe domeinen, het aanmaken van nieuwe profielen of Azure-beheerde certificaten.
• Vanaf 14 april 2026 worden bestaande beheerde certificaten buiten gebruik gesteld. Alle bestaande beheerde certificaten worden door de klant of het AFD-team geïmporteerd naar Azure Front Door-standaard of premium. Gebruik Azure Front Door Standard of Premium voor beheerd certificaat.

In de meeste gevallen is er geen actie vereist. Nadat je profiel is gemigreerd, probeert Azure Front Door automatisch je beheerde certificaat te roteren als het binnen 45 dagen na de vervaldatum is.

• Als je domein CNAME-gekoppeld is aan Azure Front Door en voldoet aan de CAA-record- en domeinstatusvereisten, wordt het certificaat automatisch geroteerd. De automatische roulatietaak wordt elke 6 tot 8 uur uitgevoerd en duurt ongeveer 24 tot 48 uur om te worden voltooid. Als automatische rotatie faalt, verandert de status van domeinvalidatie naar 'Wacht op validatie', en kun je het domeineigendom opnieuw valideren om handmatig validatie te activeren.
• Als je domein niet aan deze validatie-eisen voldoet of HTTPS is uitgeschakeld, verandert de certificaatstatus naar Pending revalidation, en moet je het domeineigendom opnieuw valideren.

Om het certificaat te verlengen zonder te wachten op automatische rotatie, valideer je het domeineigendom handmatig met een van de volgende methoden:

• De vereiste DNS-validatierecord toevoegen volgend op stap 3 voor domeinen in afwachting van validatie
• Validatie handmatig triggeren met PowerShell of Azure CLI (RefreshValidation).

Je kunt Azure Front Door-bronnen niet uitschakelen. Je kunt ze alleen verwijderen. Variabele meters zoals Data Transfer Out, Data Transfer In en Requests worden niet in rekening gebracht als er geen verkeer is, maar de basisvergoeding wordt ook geheven als er geen verkeer is. De basisvergoeding wordt in rekening gebracht totdat het profiel is verwijderd. Voor Azure Front Door (klassiek) worden WAF-beleidsregels en -regels in rekening gebracht, ongeacht hun status. Zelfs als u een WAF-beleid of -regel uitschakelt, brengt dit nog steeds kosten met zich mee.

Nee.

Nee.

Front Door ondersteunt geen dynamische compressie voor content groter dan 8 MB. Als de origin de inhoud echter al comprimeert, ondersteunt Front Door het serveren van statische gecomprimeerde inhoud van meer dan 8 MB, zolang bereikverzoek wordt ondersteund en chunked transfer encoding niet is ingeschakeld.

Nee.

Zie Metrische gegevens en logboeken voor Front Door voor informatie over logboeken en andere diagnostische functies.

U kunt diagnostische logboeken opslaan in hun eigen opslagaccount en kiezen hoe lang u ze wilt bewaren. Alternatief kun je diagnostische logs naar Event Hubs of Azure Monitor-logs sturen. Zie Azure Front Door diagnostics voor meer informatie.

Als u toegang wilt krijgen tot de auditlogboeken van Azure Front Door, moet u de portal bezoeken. Selecteer je Voordeur op de menupagina en selecteer Activiteitenlogboek. Het activiteitenlogboek bevat de records van de bewerkingen van uw Azure Front Door.

U kunt waarschuwingen instellen voor Azure Front Door op basis van metrics of logboeken. Door dit te doen, kunt u de prestaties en gezondheid van uw front-end hosts volgen.

Zie waarschuwingen configureren voor meer informatie over het maken van waarschuwingen voor Azure Front Door Standard en Premium.

Verwante inhoud

• Een Azure Front Door-profiel maken
• Routeringsarchitectuur van Azure Front Door