Azure Front Door foire aux questions (FAQ)

Azure Front Door est un service cloud qui fournit vos applications plus rapidement et de manière plus fiable. Il utilise l’équilibrage de charge de couche 7 pour distribuer le trafic entre plusieurs régions et plusieurs points de terminaison. Il offre également l’accélération de site dynamique (DSA) pour optimiser les performances web et le basculement en quasi temps réel pour garantir la haute disponibilité. Azure Front Door est un service entièrement managé. Vous n'avez donc pas à vous soucier de la mise à l'échelle ou de la maintenance.

Azure Front Door et Azure Application Gateway sont des équilibreurs de charge pour le trafic HTTP/HTTPS, mais ils ont des étendues différentes. Front Door est un service global qui peut distribuer les demandes entre différentes régions, tandis qu’Application Gateway est un service régional qui peut équilibrer les demandes au sein d’une région. Azure Front Door fonctionne avec des unités d’échelle, des clusters ou des unités d’empreinte, tandis qu’Azure Application Gateway fonctionne avec des machines virtuelles, des conteneurs ou d’autres ressources dans la même unité d’échelle.

Vous pouvez utiliser différents types d’origines pour Azure Front Door, par exemple :

• Stockage (Azure Blob, Classic, sites web statiques)
• service en nuage
• Service d'application
• Application web statique
• Gestion des API
• Application Gateway
• Adresse IP publique
• Azure Spring Apps
• Instances de conteneurs
• Applications de conteneur
• Tout nom d’hôte personnalisé avec un accès public.

L’origine doit avoir une adresse IP publique ou un nom d’hôte DNS qui peut être résolu publiquement. Vous pouvez combiner et mettre en correspondance des back-ends à partir de différentes zones, régions ou même en dehors de Azure, tant qu'ils sont accessibles publiquement.

Azure Front Door n'est pas limité à une région Azure, mais fonctionne globalement. Le seul emplacement que vous choisissez lors de la création d’une Porte d’Entrée est celui du groupe de ressources, qui détermine où les métadonnées du groupe sont stockées. Le profil Front Door est une ressource globale et sa configuration est distribuée à tous les emplacements de périphérie du monde.

Pour obtenir la liste complète des points de présence (POP) qui fournissent l’équilibrage de charge global et la distribution de contenu pour Azure Front Door, consultez Azure Front Door emplacements POP. Cette liste est mise à jour régulièrement à mesure que de nouveaux points de présence sont ajoutés ou supprimés. Vous pouvez également utiliser l’API Azure Resource Manager pour interroger par programmation la liste actuelle des POP.

Azure Front Door est un service qui distribue votre application globalement dans plusieurs régions. Il utilise une infrastructure commune que partagent tous ses clients, mais vous pouvez personnaliser votre propre profil Front Door pour configurer les besoins spécifiques de votre application. Les configurations des autres clients ne peuvent pas affecter votre configuration Front Door, qui est isolée des leurs.

Front Door ne trie pas les routes pour votre application web. Au lieu de cela, il choisit la route qui convient le mieux à la requête. Pour découvrir comment Front Door met en correspondance les requêtes avec des routes, consultez Comment Front Door met en correspondance les requêtes avec une règle de routage.

Pour garantir des performances optimales des fonctionnalités de Front Door, n'autorisez que le trafic provenant d'Azure Front Door à atteindre votre point d'origine. Par conséquent, les requêtes non autorisées ou malveillantes sont détectées par les stratégies de sécurité et de routage de Front Door, et l’accès leur est refusé. Pour savoir comment sécuriser vos points de terminaison, consultez Sécuriser le trafic vers les points de terminaison Azure Front Door.

Les délais de propagation de la configuration pour une opération unique de création, de mise à jour, de suppression ou liée au WAF pour les profils Azure Front Door et CDN peuvent prendre jusqu’à 15 minutes par mesure de sécurité supplémentaire. Une seule opération de purge de cache est effectuée en moins de 10 minutes. Des modifications consécutives peuvent prolonger le temps total de déploiement à environ 30 minutes. Chaque mise à jour de configuration, incluant les ajustements du jeu de règles, les modifications de routage, les mises à jour d’origine ou de domaine, et les modifications WAF, est traitée comme une opération globale. Si vous soumettez des opérations supplémentaires alors que la première opération est encore en cours (dans sa fenêtre de ~15 minutes), le système les met en file d’attente et ne commence qu’après la fin de l’opération précédente. Dans ce scénario, la première opération se termine dans les 15 premières minutes, et les modifications suivantes sont traitées dans la fenêtre suivante. Les améliorations de plateforme en cours sont en cours, ce qui permettra de réduire davantage cette période.

Envoyer plusieurs demandes de vidage

Chaque demande de vidage peut inclure jusqu’à 100 URL (combinaison de domaine et de chemin d’accès). Le premier lot est traité et prend effet en environ 10 minutes.

Si vous avez plus de 100 URL à effacer, vous devez attendre et vérifier que le premier lot a été terminé avant de soumettre le suivant. Si vous soumettez une nouvelle demande de purge avant la fin du lot précédent, la requête est rejetée.

Exemple : Purger 256 URLs

1. Envoyez les 100 premières URL dans la demande de vidage initiale.
2. Attendez environ 10 minutes et vérifiez que le premier lot a été réalisé avec succès.
3. Envoyez les URL 101-200 suivantes dans la deuxième requête.
4. Attendez environ 10 minutes que la deuxième série soit terminée.
5. Envoyez les URL 201-256 restantes dans la troisième requête.

Les mises à jour des routes ou des groupes d’origine/pools de back-ends sont transparentes et ne provoquent aucun temps d’arrêt (en supposant que la nouvelle configuration est correcte). Les mises à jour de certificat sont également effectuées atomiquement, il n’y a donc aucun temps d’arrêt.

• Vous pouvez déplacer les profils Front Door Standard/Premium et Azure CDN entre groupes de ressources ou abonnements sans interruption. Pour exécuter le déplacement, suivez ces instructions.
• Azure Front Door (classic) ne supporte pas le déplacement entre groupes de ressources ou abonnements. Vous pouvez plutôt migrer le profil Azure Front Door (classic) vers Standard/Premium puis exécuter le déplacement.
• Si vous associez une politique WAF à Azure Front Door Standard ou Premium, l’opération de déplacement échoue. Vous devez d’abord dissocier la stratégie WAF, effectuer le déplacement, puis réassocier la stratégie.

Azure Front Door offre de nombreux avantages pour vos applications web, tels que l’accélération dynamique des sites (DSA), qui améliore les performances et l’expérience utilisateur de vos sites. Azure Front Door gère également le déchargement TLS/SSL et le TLS de bout en bout, ce qui améliore la sécurité et le chiffrement de votre trafic web. De plus, Azure Front Door propose un pare-feu pour applications web, une affinité de session basée sur les cookies, un routage basé sur les chemins d’URL, des certificats gratuits, une gestion multi-domaines, et bien plus encore. Pour en savoir plus sur les fonctionnalités et capacités d'Azure Front Door, voir comparaison des niveaux.

Azure Front Door prend en charge HTTP, HTTPS et HTTP/2.

Azure Front Door prend en charge le protocole HTTP/2 pour les connexions clientes. Cependant, la communication du pool de back-ends utilise le protocole HTTP/1.1. La prise en charge de HTTP/2 est activée par défaut.

Non. Actuellement, Azure Front Door prend uniquement en charge HTTP/1.1 de la périphérie à l’origine. Pour que gRPC fonctionne, HTTP/2 est nécessaire.

Vous pouvez rediriger les composants d’hôte, de chemin et de chaîne de requête d’une URL avec Azure Front Door. Pour apprendre à configurer la redirection d’URL, voir Redirection URL.

Oui. Consultez la propriété MatchedRulesSetName sous Access Logs.

Oui. Pour plus d’informations, consultez Microsoft réponse aux attaques DDoS contre HTTP/2.

Non. Azure Front Door ne peut pas forcer le trafic client vers un pop spécifique. Les requêtes sont acheminées vers le point de présence le plus proche disponible pour optimiser les performances et la fiabilité. Si vous devez restreindre l’accès par zone géographique, utilisez des règles personnalisées Azure Web Application Firewall (WAF) avec des conditions GeoMatch. Cette approche permet ou bloque les requêtes basées sur le pays/la région du client, mais elle ne redirige pas ces clients vers un autre pop dans un autre pays/région. Par exemple, si vous bloquez le pays/la région A, les demandes des clients dans le pays/la région A sont bloquées, indépendamment du POP qui les aurait servis. Pour plus d’informations, consultez Geo-filtering dans Azure WAF pour Azure Front Door.

Azure Front Door prend en charge les en-têtes X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto. Ces en-têtes aident Front Door à identifier l’adresse IP et le protocole du client d’origine. Si X-Forwarded-For est déjà présent, Front Door ajoute l’adresse IP du socket client à la fin de la liste. Sinon, il crée l’en-tête avec l’adresse IP du socket client comme valeur. Pour X-Forwarded-Host et X-Forwarded-Proto, Front Door remplace les valeurs existantes par ses propres valeurs.

Pour plus d’informations, consultez En-têtes HTTP pris en charge par Front Door.

Pour utiliser Azure Front Door Standard ou Azure Front Door (classique), il vous faut une adresse IP publique ou un nom DNS résoluble publiquement. Cette exigence permet à Azure Front Door de diriger le trafic vers vos ressources backend. Vous pouvez utiliser des ressources Azure telles que les passerelles d'application ou les Azure Load Balancers pour acheminer le trafic vers les ressources d’un réseau virtuel. Si vous utilisez Azure Front Door Premium, vous pouvez utiliser Private Link pour vous connecter à des origines derrière un équilibreur de charge interne via un point de terminaison privé. Pour plus d’informations, consultez Origines sécurisées avec Private Link.

Non. Pour la sécurité, Azure Front Door prend uniquement en charge l’authentification basée sur une identité managée lors de l’accès aux certificats dans Key Vault. Pour plus d’informations, consultez Utilisez les identités managées dans Azure Front Door.

Non. Azure Front Door ne prend actuellement pas en charge l'intégration d'identité managée à Azure Event Hubs.

Non. Azure Front Door ne prend actuellement pas en charge les pages d'erreurs personnalisées.

Application Gateway derrière Front Door est utile dans ces situations :

• Vous souhaitez équilibrer le trafic non seulement au niveau global, mais aussi au sein de votre réseau virtuel. Front Door ne peut effectuer un équilibrage de charge basé sur le chemin qu’au niveau global, mais Application Gateway peut le faire au sein de votre réseau virtuel.
• Vous avez besoin du drainage de connexion, que Front Door ne prend pas en charge. Application Gateway peut activer le drainage de connexion pour vos machines virtuelles ou vos conteneurs.
• Vous souhaitez décharger tous les traitements TLS/SSL et utiliser uniquement des requêtes HTTP dans votre réseau virtuel. Application Gateway derrière Front Door peut mettre en œuvre cette configuration.
• Vous voulez utiliser l’affinité de session à la fois au niveau régional et au niveau du serveur. Front Door peut envoyer le trafic d’une session utilisateur au même back-end d’une région, mais Application Gateway peut l’envoyer au même serveur dans le back-end.

Enchaîner deux CDN n’est généralement pas recommandé. Bien que cela puisse fonctionner, il présente les inconvénients suivants :

1. L’accélération du dernier kilomètre d’un CDN fonctionne en maintenant le flux de connexion avec l’origine et en trouvant le chemin optimal vers l’origine pour obtenir les meilleurs résultats. Le chaînage de deux CDN ensemble annule généralement certains des avantages de l’accélération de la dernière ligne droite.
2. Les contrôles de sécurité sont moins efficaces au deuxième CDN. Le contrôle d’accès basé sur IP client ne fonctionne pas là-bas car le second CDN identifie le nœud de sortie du premier CDN comme IP client. La charge utile de contenu est toujours inspectée.
3. Enchaîner deux CDN augmente la complexité du dépannage. Lorsqu’un problème survient, il peut être difficile de déterminer quel CDN en est la cause.

Pour utiliser Azure Front Door, vous devez disposer d’une adresse IP virtuelle publique ou d’un nom DNS accessible publiquement. Azure Front Door utilise l’adresse IP publique pour acheminer le trafic vers votre origine. Un scénario courant consiste à déployer un Azure Load Balancer derrière Front Door. Vous pouvez également utiliser Private Link avec Azure Front Door Premium pour vous connecter à un équilibreur de charge interne. Pour plus d’informations, consultez comment activer le lien privé avec l’équilibreur de charge interne.

Azure Front Door et Azure CDN sont deux services qui fournissent une livraison web rapide et fiable pour vos applications. Toutefois, ils ne sont pas compatibles les uns avec les autres, car ils partagent le même réseau de sites de périphérie Azure pour fournir du contenu à vos utilisateurs. Ce réseau partagé provoque des conflits entre leurs stratégies de routage et de mise en cache. Par conséquent, vous devez choisir Azure Front Door ou Azure CDN pour votre application, en fonction de vos performances et exigences de sécurité.

Le fait que les deux profils/points de terminaison utilisent le même POP de périphérie Azure pour traiter les requêtes entrantes entraîne une limitation qui vous empêche d’imbriquer un profil/point de terminaison Azure Front Door derrière un autre. Cette configuration provoquerait des conflits de routage et des problèmes de performances. Par conséquent, si vous devez utiliser plusieurs profils/terminaux pour vos applications, vous devez vous assurer que vos profils/terminaux Azure Front Door ne sont pas enchaînés ensemble.

Azure Front Door utilise le routage unicast pour la résolution de noms et aroute les requêtes vers le point optimal de présence (POP). Unicast a remplacé la méthode de routage Anycast que Azure Front Door utilisait auparavant.

Une requête de résolution de nom pour une origine située derrière Azure Front Door aboutit sur le point de terminaison Traffic Manager de Front Door. Les profils Traffic Manager de Front Door consomment de nombreux signaux d’intégrité et de disponibilité provenant des PoP (points de présence) dans le monde entier. Sur la base de ces signaux, l’adresse IP unicast du PoP Front Door optimal est renvoyée. La requête est ensuite envoyée directement à l’adresse IP retournée, qui suit l’architecture de routage Front Door pour renvoyer la réponse à l’utilisateur ou à l’application.

Azure Front Door utilise trois balises de service pour gérer le trafic entre vos clients et vos origines :

• L’étiquette de service AzureFrontDoor.Backend contient la liste des adresses IP que Front Door utilise pour accéder à vos origines. Vous pouvez appliquer cette étiquette de service quand vous configurez la sécurité pour vos origines.
• L’étiquette de service AzureFrontDoor.Frontend contient les adresses IP que les clients utilisent pour atteindre Front Door. Vous pouvez appliquer la balise de service AzureFrontDoor.Frontend lorsque vous souhaitez contrôler le trafic sortant pouvant se connecter aux services derrière Azure Front Door.
• La balise de service AzureFrontDoor.FirstParty est réservée à un groupe de services Microsoft sélectionné hébergé sur Azure Front Door.

Pour plus d’informations sur les scénarios d’étiquettes de service Azure Front Door, consultez balises de service disponibles. Pour rester informé et prendre les mesures appropriées lors de toute modification des adresses IP, développez l’automatisation pour récupérer régulièrement les dernières adresses IP en utilisant le fichier JSON ou l’API Service Tag Discovery.

Un groupe d’origines est une collection d’origines qui peut gérer des types de requêtes similaires. Vous avez besoin d’un groupe d’origine différent pour chaque application ou charge de travail différente.

Dans un groupe d’origines, vous créez une origine pour chaque serveur ou service qui peut traiter des requêtes. Si votre origine a un équilibreur de charge, comme Azure Application Gateway, ou s’il est hébergé sur un PaaS qui a un équilibreur de charge, le groupe d’origine n’a qu’une seule origine. Votre origine s’occupe du basculement et de l’équilibrage de charge entre les origines que Front Door ne voit pas.

Par exemple, si vous hébergez une application sur Azure App Service, la configuration de Front Door dépend du nombre d’instances d’application dont vous disposez :

• Déploiement dans une seule région : créez un seul groupe d’origines. Dans ce groupe d’origine, créez une origine pour l’application App Service. Votre application App Service peut effectuer un scale-out sur les Workers, mais Front Door ne voit qu’une origine.
• Déploiement actif/passif multirégion : créez un seul groupe d’origines. Dans ce groupe d’origines, créez une origine pour chaque application App Service. Définissez la priorité de chaque origine afin que l’application principale ait une priorité supérieure à celle de l’application de sauvegarde.
• Déploiement actif/actif multirégion : créez un seul groupe d’origines. Dans ce groupe d’origines, créez une origine pour chaque application App Service. Configurez la priorité de chaque origine pour qu’elle soit identique. Définissez le poids de chaque origine pour contrôler le nombre de requêtes envoyées à cette origine.

Pour plus d’informations, consultez Origins et groupes d’origines dans Azure Front Door.

Azure Front Door est un service qui fournit une livraison web rapide et fiable pour vos applications. Il offre des fonctionnalités comme la mise en cache, l’équilibrage de charge, la sécurité et le routage. Toutefois, vous devez connaître certains délais d’expiration et limites qui s’appliquent à Azure Front Door. Ces délais d’expiration et limites incluent la taille maximale de la requête, la taille maximale de la réponse, la taille maximale des en-têtes, le nombre maximal d’en-têtes, le nombre maximal de règles et le nombre maximal de groupes d’origines. Vous trouverez les informations détaillées sur ces délais d’expiration et ces limites dans la documentation Azure Front Door.

La plupart des ensembles de règles mettent à jour leur configuration en moins de 15 minutes. La règle s’applique dès la fin de la mise à jour.

Azure Front Door dispose d’un délai de 5 secondes pour recevoir des en-têtes d’un client. Si le client n'envoie pas les en-têtes dans les 5 secondes suivant l'établissement d'une connexion TCP/TLS vers Azure Front Door, la connexion est terminée. Vous ne pouvez pas configurer ce délai d’attente.

Azure Front Door a un délai d’expiration HTTP de 90 secondes. La connexion est interrompue si le client n'envoie pas de données pendant 90 secondes, ce qui correspond au délai d'expiration du keep-alive pour HTTP d'Azure Front Door. Vous ne pouvez pas configurer la valeur de ce délai d’expiration.

Vous ne pouvez pas utiliser les mêmes domaines pour plusieurs points de terminaison Front Door, car Front Door doit avoir une route distincte (la combinaison protocole + hôte + chemin) pour chaque requête. Si vous avez des routes dupliquées sur différents points de terminaison, Azure Front Door ne peut pas traiter correctement les demandes.

Pour l’instant, nous n’offrons pas la possibilité de déplacer des domaines d’un point de terminaison vers un autre sans interruption du service. Vous devez planifier un temps d’arrêt si vous voulez migrer vos domaines vers un autre point de terminaison.

Azure Front Door Private Link est indépendante des régions. Pour la latence la plus faible, sélectionnez la région Azure supportée la plus proche de votre origine lorsque vous activez un point de terminaison Azure Front Door Private Link. Si la région de votre origine n'est pas prise en charge dans la liste des régions prises en charge par Front Door Private Link, sélectionnez la région la plus proche suivante. Le trafic transite du client vers le point de terminaison Azure Front Door Private Link dans la région prise en charge, puis traverse le réseau principal Microsoft jusqu’à votre origine, maintenant la connectivité privée. Cette configuration introduit une latence supplémentaire due au saut réseau supplémentaire entre les régions. Vous pouvez utiliser les statistiques de latence aller-retour du réseau Azure pour déterminer la latence supplémentaire due au choix de la région la plus proche. Lorsqu’une nouvelle région est prise en charge, vous pouvez suivre ces instructions pour déplacer progressivement le trafic vers la nouvelle région.

Azure Front Door est une plateforme qui distribue le trafic à travers le monde et peut évoluer pour répondre aux demandes de votre application. Il utilise le réseau global edge de Microsoft pour fournir un équilibrage de charge global, ce qui vous permet de déplacer toute votre application ou certains microservices vers différentes régions ou clouds en cas de défaillance.

Pour éviter les erreurs lors de la livraison de fichiers volumineux, assurez-vous que votre serveur d’origine inclut l’en-tête Content-Range dans la réponse et que la valeur de l’en-tête correspond à la taille réelle du corps de la réponse.

Vous trouverez plus d’informations sur la configuration de votre origine et de Front Door pour la distribution de grands fichiers dans Distribution de grands fichiers.

Le domain fronting est une technique réseau qui permet à un attaquant de masquer la destination réelle d'une requête malveillante à l'aide d'un autre nom de domaine dans l' établissement d'une liaison TLS et l'en-tête de l'hôte HTTP.

Les ressources Azure Front Door (niveaux Standard, Premium et classique) ou Azure CDN Standard from Microsoft (classic) créées après le 8 novembre 2022 ont le blocage du domain fronting activé. Plutôt que de bloquer une requête avec des en-têtes SNI et hôtes non correspondants, nous permettons cette disparité si les deux domaines appartiennent au même abonnement et sont inclus dans les routes ou les règles de routage. L’application du blocage du front de domaine a commencé le 22 janvier 2024.

Lorsque Front Door bloque une demande en raison d’une incompatibilité :

• Le client reçoit une réponse avec le code d’erreur HTTP 421 Misdirected Request.
• Azure Front Door enregistre le bloc dans les journaux de diagnostic sous la propriété Error Info avec la valeur SSLMismatchedSNI.

Pour plus d’informations sur le fronting de domaine, consultez Sécuriser notre approche du fronting de domaine dans Azure et Interdire le fronting de domaine sur Azure Front Door et Azure CDN Standard de Microsoft (classique).

Front Door utilise TLS 1.2 comme version minimale pour tous les profils créés après septembre 2019.

Vous pouvez choisir d’utiliser TLS 1.2 ou 1.3 avec Azure Front Door. Pour en savoir plus, lisez l’article Azure Front Door TLS de bout en bout.

À compter du 15 août 2025, DigiCert est passé à une nouvelle plateforme de validation de contrôle de domaine open source (DCV) conçue pour améliorer la transparence et la responsabilité dans les processus de validation de domaine. DigiCert ne prend plus en charge le flux de travail DCV legacy CNAME Delegation pour la validation du contrôle de domaine dans les services Azure spécifiés. En savoir plus

La dépréciation a un impact sur les services qui s’appuient sur la validation basée sur CNAME pour l’émission et le renouvellement automatisés des certificats, notamment :

• Azure Front Door (classique)
• Azure CDN de Microsoft (classique)

Azure Front Door (classique) et Azure CDN à partir de Microsoft (classique) :

• À compter du 15 août 2025, il n'y a plus de prise en charge de l'intégration de nouveaux domaines, de la création de nouveaux profils, ni des certificats gérés par Azure.
• À compter du 14 avril 2026, les certificats managés existants sont mis hors service. Tous les certificats gérés existants sont soit migrés par le client ou l’équipe AFD, soit vers la norme Azure Front Door ou premium. Utilisez Azure Front Door Standard ou Premium pour un certificat managé.

Dans la plupart des cas, aucune action n’est requise. Une fois votre profil migré, Azure Front Door tente automatiquement de renouveler votre certificat géré s’il expire dans les 45 jours.

• Si votre domaine est mappé en CNAME à Azure Front Door et répond aux exigences relatives à l’enregistrement CAA et à l’état du domaine, le certificat est automatiquement renouvelé. La rotation automatique s’exécute toutes les 6 à 8 heures et prend environ 24 à 48 heures à être complétée. Si la rotation automatique échoue, l’état de validation du domaine passe à « Validation en attente », et vous pouvez revalider la propriété du domaine pour déclencher manuellement la validation.
• Si votre domaine ne remplit pas ces exigences de validation ou a HTTPS désactivé, l’état du certificat passe en En attente de revalidation, et vous devez revalider la propriété du domaine.

Pour renouveler le certificat sans attendre la rotation automatique, revalidez manuellement la propriété du domaine en utilisant l’une des méthodes suivantes :

• Ajout de l’enregistrement de validation DNS requis à l’étape 3 pour les domaines en attente de validation
• Déclencher la validation manuellement avec PowerShell ou Azure CLI (RefreshValidation).

Vous ne pouvez pas désactiver les ressources d'Azure Front Door. Vous ne pouvez que les supprimer. Les compteurs variables comme le transfert de données en sortie, le transfert de données en entrée et les requêtes ne sont pas facturés en cas de pas de trafic, mais le tarif de base est facturé même s’il n’y a pas de trafic. Les frais de base sont facturés jusqu’à la suppression du profil. Pour Azure Front Door (classique), les politiques et règles WAF sont facturées quel que soit leur statut. Même si vous désactivez une stratégie ou une règle WAF, elle entraîne toujours des coûts qui vous sont facturés.

Non.

Non.

Front Door ne prend pas en charge la compression dynamique pour le contenu de plus de 8 Mo. Cependant, si l’origine compresse déjà le contenu, Front Door supporte la diffusion de contenu compressé statique sur 8 Mo tant que la requête de distance est prise en charge et que l’encodage par transfert en blocs n’est pas activé.

Non.

Pour plus d’informations sur les journaux et autres fonctionnalités de diagnostic, consultez Supervision des métriques et des journaux pour Front Door.

Vous pouvez stocker les journaux de diagnostic dans leur propre compte de stockage et choisir la durée de leur conservation. Vous pouvez également envoyer des journaux de diagnostic vers Event Hubs ou vers les journaux d’Azure Monitor. Pour plus d’informations, consultez Azure Front Door diagnostics.

Pour accéder aux journaux d’audit de Azure Front Door, vous devez visiter le portail. Sélectionnez votre Porte d’entrée dans la page du menu et sélectionnez Journal d’activité. Le journal d’activité vous fournit les enregistrements des opérations de votre Azure Front Door.

Vous pouvez configurer des alertes pour Azure Front Door en fonction des métriques ou journaux d'activité. Vous pouvez ainsi superviser les performances et l’intégrité de vos hôtes front-ends.

Pour savoir comment créer des alertes pour Azure Front Door Standard et Premium, consultez alertes de configuration.

Contenu connexe

• Créer un profil Azure Front Door
• Architecture de routage Azure Front Door