Partager via

Forum aux questions (FAQ) sur Azure Front Door

Cet article fournit des réponses aux questions les plus fréquemment posées sur les fonctionnalités Azure Front Door. Si vous ne trouvez pas de réponse à votre question ici, vous pouvez nous joindre par le biais des méthodes suivantes (par ordre de priorité) :

  1. La section des commentaires de cet article.

  2. Retours Azure Front Door.

  3. Support Microsoft : pour créer une demande de support, dans le Portail Azure, sous l’onglet Aide, sélectionnez le bouton Aide + support, puis Nouvelle demande de support.

Généralités

Qu’est-ce qu’Azure Front Door ?

Azure Front Door est un service cloud qui délivre vos applications plus rapidement et de façon 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.

Quelle est la différence entre Azure Front Door et Azure Application Gateway ?

Azure Front Door et Azure Application Gateway sont tous deux 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’horodatage, tandis qu’Azure Application Gateway fonctionne avec des machines virtuelles, des conteneurs ou d’autres ressources dans la même unité d’échelle.

Quel type de ressources sont actuellement compatibles comme origines ?

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

  • Stockage (Blob Azure, Classique, 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 de différentes zones et régions, ou même en dehors d’Azure, dès lors qu’ils sont accessibles publiquement.

Dans quelles régions puis-je déployer des services Azure Front Door ?

Azure Front Door n’est pas limité à une région Azure, mais il fonctionne globalement. Le seul emplacement que vous devez choisir quand vous créez une instance Front Door est l’emplacement du groupe de ressources, qui détermine l’endroit où les métadonnées du groupe de ressources 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.

Quels sont les emplacements des points de présence d’Azure Front Door ?

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 Emplacements des points de présence d’Azure Front Door. Cette liste est mise à jour régulièrement à mesure que de nouveaux points de présence sont ajoutés ou supprimés. Vous pouvez aussi utiliser l’API Azure Resource Manager pour interroger par programmation la liste actuelle des points de présence.

Comment Azure Front Door alloue-t-il ses ressources entre différents clients ?

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

Comment Azure Front Door détermine-t-il l’ordre des règles de routage ?

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.

Quelles sont les étapes permettant de restreindre l’accès à mon back-end seulement à Azure Front Door ?

Pour garantir des performances optimales des fonctionnalités de Front Door, vous devez autoriser seulement le trafic provenant d’Azure Front Door à atteindre votre 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 découvrir comment sécuriser votre origine, consultez Sécuriser le trafic vers les origines Azure Front Door.

Quelle est la durée estimée pour le déploiement d’une instance Azure Front Door ? Mon instance Front Door reste-t-elle opérationnelle pendant le processus de mise à jour ?

Les temps de propagation de la configuration pour une opération unique de création, mise à jour, suppression, WAF et vidage de cache pour les profils Azure Front Door et CDN peuvent atteindre jusqu’à 45 minutes pour renforcer la sécurité. Les modifications back-to-back peuvent étendre le temps de déploiement total à environ 90 minutes. Chaque mise à jour de configuration, y compris les règles définies, les modifications de routage, les mises à jour d’origine ou de domaine, et les modifications waf, etc., sont traitées comme une opération globale. Si des opérations supplémentaires sont soumises alors que la première est encore en cours de propagation (au cours de sa fenêtre d'environ 45 minutes), elles sont mises en file d'attente et ne commencent qu'une fois l'opération précédente terminée. Dans ce scénario, la première opération se termine dans les 45 minutes initiales, 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.

Remarque

Les mises à jour de certificat TLS/SSL personnalisées peuvent prendre plus de temps, jusqu’à une heure, pour être déployées globalement.

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 dans un délai d’environ 45 minutes.

Si vous avez plus de 100 URL à vider, vous devez attendre et vérifier que le premier lot se termine (environ 45 minutes) avant d’envoyer le lot suivant. Si vous envoyez une nouvelle demande de vidage avant la fin du lot précédent, la demande sera rejetée.

Exemple : Purger 256 URLs

  1. Envoyez les 100 premières URL dans la demande de vidage initiale.
  2. Attendez environ 45 minutes et vérifiez que le premier lot s’est terminé avec succès.
  3. Envoyez les URL 101-200 suivantes dans la deuxième requête.
  4. Attendez environ 45 minutes pour que le deuxième lot se termine.
  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.

Puis-je déplacer des profils CDN et Front Door entre des groupes de ressources ou des abonnements sans aucun temps d’arrêt ?

  • Les profils de CDN Azure et Front Door Standard/Premium ne peuvent pas être déplacés entre des groupes de ressources ou des abonnements sans temps d’arrêt. Pour exécuter le déplacement, suivez ces instructions.
  • Une instance Front Door Classique ne prend pas en charge les déplacements entre des groupes de ressources ou des abonnements. Vous pouvez migrer à la place le profil Classique vers Standard/Premium, puis exécuter le déplacement.
  • Si le client a un pare-feu d’applications web (WAF) associé à l’instance Front Door Standard/Premium, l’opération de déplacement va échouer. Le client doit d’abord dissocier les stratégies WAF, effectuer le déplacement et l’association.

Caractéristiques et protocoles

Quelles sont les fonctionnalités prises en charge par Azure Front Door ?

Azure Front Door est un service qui offre de nombreux avantages pour vos applications web, comme l’accélération de site dynamique (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 protocole TLS de bout en bout, ce qui améliore la sécurité et le chiffrement de votre trafic web. En outre, Azure Front Door fournit Web Application Firewall, l’affinité de session basée sur les cookies, le routage basé sur le chemin d’URL, des certificats gratuits, la gestion multidomaine, etc. Pour plus d’informations sur les fonctionnalités et les capacités d’Azure Front Door, consultez Comparaison des niveaux.

Quels sont les protocoles pris en charge par Azure Front Door ?

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

Dans quelle mesure Azure Front Door prend-il en charge 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.

Azure Front Door prend-il en charge gRPC ?

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

Azure Front Door prend-il en charge la redirection HTTP vers HTTPS ?

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 découvrir comment configurer la redirection d’URL, reportez-vous à Redirection d’URL.

L’AFD fournit-elle des données de télémétrie pour afficher les processus AFD de règle de moteur de règles pour chaque requête ?

Oui. Reportez-vous à la propriété MatchedRulesSetName sous Access Logs.

AFD fournit-il une protection contre les attaques DDoS « HTTP/2 Rapid Reset » ?

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

Azure Front Door conserve-t-il les en-têtes « x-forwarded-for » ?

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.

Azure Front Door peut-il équilibrer la charge ou router le trafic au sein d’un réseau virtuel ?

Pour utiliser le niveau Standard ou (classique) Azure Front Door, vous avez besoin d’une adresse IP publique ou d’un nom DNS qui peut être résolu publiquement. Cette exigence d’une adresse IP publique ou d’un nom DNS qui peut être résolu publiquement permet à Azure Front Door de router le trafic vers vos ressources back-end. Vous pouvez utiliser des ressources Azure comme des passerelles applicatives ou des équilibreurs de charge Azure pour router le trafic vers les ressources d’un réseau virtuel. Si vous utilisez Front Door niveau Premium, vous pouvez activer Private Link pour vous connecter aux origines derrière un équilibreur de charge interne avec un point de terminaison privé. Pour plus d’informations, consultez Sécuriser l’origine avec Private Link.

Déploiement de Front Door avec d’autres services

Quand dois-je déployer Application Gateway derrière Front Door ?

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.

Puis-je déployer un autre CDN à partir d’un vendeur externe derrière ou devant Front Door ?

Le chaînage de deux CDN n’est pas une approche généralement recommandée. Il fonctionne mais il présente les inconvénients suivants

  1. L’accélération de la dernière ligne droite du CDN utilise le maintien du flux de connexion avec l’origine et la recherche du 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 sur le deuxième CDN. Toute ACL basée sur l’adresse IP d’un client ne fonctionnera pas sur le deuxième CDN, car ce dernier verra le nœud de sortie du premier CDN en tant qu’adresses IP du client. La charge utile de contenu peut toujours être inspectée.
  3. De nombreuses organisations ne peuvent pas gérer la complexité du dépannage de deux CDN chaînés, lors d’un problème, il devient difficile de déterminer le CDN qui rencontre le problème.

Puis-je déployer Azure Load Balancer derrière Front Door ?

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 est de déployer un équilibreur de charge Azure derrière Front Door. Vous pouvez aussi utiliser Private Link avec Azure Front Door Premium pour vous connecter à un équilibreur de charge interne. Si vous souhaitez obtenir plus d’informations, consultez Activer Private Link avec un équilibreur de charge interne.

Est-il possible de configurer Azure CDN derrière mon profil/point de terminaison Front Door ou l’inverse ?

Azure Front Door et Azure CDN sont deux services qui permettent de délivrer vos applications rapidement et de façon fiable via le web. Ils ne sont cependant pas compatibles l’un avec l’autre, car ils partagent le même réseau de sites de périphérie Azure pour délivrer 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 exigences quant aux performances et à la sécurité.

Est-il possible de configurer un profil/point de terminaison Azure Front Door derrière un autre profil/point de terminaison Front Door ou d’une autre façon ?

Le fait que les deux profils/points de terminaison utilisent le même POP en périphérie Azure pour gérer 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, vous devez vous assurer que vos profils/points de terminaison Azure Front Door ne sont pas chaînés ensemble, si vous devez utiliser plusieurs profils/points de terminaison pour vos applications.

Adresses IP et étiquettes de série Front Door

L’adresse IP anycast de mon instance Front Door reste-t-elle la même pendant toute sa durée de vie ?

L’adresse IP du frontend anycast de Front Door est fixe et ne peut pas changer tant que vous utilisez Front Door. Cependant, l’adresse IP fixe du front-end anycast de votre instance Front Door n’est pas une garantie. Évitez de vous baser directement sur l’adresse IP. 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.

Azure Front Door offre-t-il des adresses IP statiques ou dédiées ?

Azure Front Door est un service dynamique qui route le trafic vers le back-end disponible le plus approprié. Il n’offre pas pour l’instance d’adresses IP anycast de front-end statiques ou dédiées.

Quelles sont les étiquettes de service réseau prises en charge par Front Door ?

Azure Front Door utilise trois étiquettes 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 l’étiquette de service AzureFrontDoor.Frontend quand vous voulez contrôler le trafic sortant qui peut se connecter aux services derrière Azure Front Door.
  • L'étiquette de service AzureFrontDoor.FirstParty est réservée à un groupe sélectionné de services Microsoft hébergés sur Azure Front Door.

Pour plus d’informations sur les scénarios des étiquettes de service Azure Front Door, consultez les Étiquettes 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.

Paramétrage

Quelles sont les meilleures pratiques pour créer des origines et des groupes d’origines pour Azure Front Door ?

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’origines 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 que vous avez :

  • 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 Origines et groupes d’origines dans Azure Front Door.

Quelles sont les valeurs par défaut et les valeurs maximales pour les délais d’expiration et les limites d’Azure Front Door ?

Azure Front Door est un service qui permet de délivrer vos applications rapidement et de façon fiable via le web. Il offre des fonctionnalités comme la mise en cache, l’équilibrage de charge, la sécurité et le routage. Cependant, vous devez connaître quelques 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.

Combien de temps faut-il à Azure Front Door pour appliquer une nouvelle règle ajoutée au moteur de règles Front Door ?

Les mises à jour de configuration de la plupart des ensembles de règles sont effectuées en moins de 20 minutes. La règle est appliquée immédiatement après la fin de la mise à jour.

Quelle est la valeur du délai d'expiration de l'en-tête du client vers Azure Front Door ?

Azure Front Door a un délai d'expiration de 5 secondes pour recevoir des en-têtes du client. La connexion est arrêtée si le client n'envoie pas d'en-têtes dans les 5 secondes à Azure Front Door après l'établissement d'une connexion TCP/TLS. Vous ne pouvez pas configurer la valeur de ce délai d’expiration.

Quelle est la valeur du délai d’expiration HTTP pour Azure Front Door ?

Azure Front Door a un délai d’expiration HTTP de 90 secondes. La connexion est arrêtée si le client n’envoie pas de données pendant 90 secondes, qui est le délai d’expiration HTTP pour Azure Front Door. Vous ne pouvez pas configurer la valeur de ce délai d’expiration.

Est-il possible d’utiliser le même domaine pour deux points de terminaison Front Door différents ?

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 en double sur des points de terminaison différents, Azure Front Door ne peut pas traiter les requêtes correctement.

Est-il possible de migrer un domaine d’un point de terminaison Front Door vers un autre point de terminaison Front Door sans temps d’arrêt ?

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.

L’intégration de Private Link Azure Front Door n’est pas prise en charge dans la région où se situe mon origine. Que dois-je faire ?

La fonctionnalité Private Link Azure Front Door (AFD) est indépendante de la région et fonctionne même si vous choisissez une région différente de la région où votre origine est située. Dans ces cas, pour veiller à une latence plus faible, vous devez toujours choisir la région Azure la plus proche de votre origine lorsque vous choisissez d’activer un point de terminaison Private Link Azure Front Door. Nous activons actuellement le support pour d’autres régions. Une fois une nouvelle région pris en charge, vous pouvez suivre ces instructions pour graduellement déplacer le trafic vers la nouvelle région.

Performances

Comment Azure Front Door garantit-il la haute disponibilité et la scalabilité pour ses services ?

Azure Front Door est une plateforme qui distribue le trafic à travers le monde et qui peut effectuer un scale-up pour répondre aux demandes de votre application. Il utilise la périphérie du réseau global de Microsoft pour fournir une fonctionnalité d’équilibrage de charge globale qui vous permet de basculer l’ensemble de votre application ou des microservices spécifiques vers d’autres régions ou clouds en cas de défaillance.

Quelles sont les conditions de mise en cache des réponses avec plage provenant de mon origine ?

Pour éviter les erreurs lors de la distribution de grands fichiers, vérifiez 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.

Configuration TLS

Comment Azure Front Door bloque-t-il le domain fronting ?

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.

Le blocage du domain fronting est activé sur les ressources Azure Front Door (niveau Standard, Premium et Classique) ou Azure CDN Standard créées après le 8 novembre 2022. Au lieu de bloquer une requête avec une indication du nom du serveur en-têtes (SNI) et des en-têtes de l'hôte incompatibles, nous autorisez l'écart si les deux domaines appartiennent au même abonnement et sont inclus dans les itinéraires/règles d’acheminement. L'application du blocage de domain fronting démarre le 22 janvier 2024 pour tous les domaines existants. L'application peut prendre jusqu'à deux semaines pour se propager dans toutes les régions.

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 journalise le blocage dans les journaux de diagnostic sous la propriété Informations d'erreur avec la valeur SSLMismatchedSNI.

Pour plus d'informations sur le domain fronting, consultez Sécurisation de notre approche de domain fronting dans Azure et Interdiction du domain fronting sur Azure Front Door et Azure CDN Standard à partir de Microsoft (classique).

Quelles sont les versions de TLS prises en charge par Azure Front Door ?

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 plus d’informations, consultez l’article TLS de bout en bout pour Azure Front Door.

Dépréciation du flux de travail DigiCert DCV et de la gestion des certificats

Que se passe-t-il avec le flux de travail DCV de délégation CNAME de DigiCert ?

Le 15 août 2025, DigiCert déconseillera le support pour le flux de travail DCV de délégation CNAME hérité. DigiCert passe à une nouvelle plateforme de validation de contrôle de domaine open source (OSS) conçue pour améliorer la transparence et la responsabilité dans les processus de validation de domaine. DigiCert ne prendra plus en charge le flux de travail DCV de délégation CNAME hérité pour la validation du contrôle de domaine dans les services Azure spécifiés. En savoir plus

Quelles références SKU Azure Front Door sont affectées par cette modification ?

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)
  • Cdn Azure de Microsoft (classique)

Que se passera-t-il après le 15 août 2025 ?

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

  • Ne prend plus en charge l’intégration de nouveaux domaines et la création de nouveaux profils.
  • Ne prend plus en charge les certificats gérés par Azure.
  • Les scripts d’automatisation pour ces actions commencent à échouer.
  • Le passage à des certificats managés sur des domaines existants n’est plus autorisé.
  • Les renouvellements émergents de certificats managés ne seront pas possibles en raison de la dépréciation de la validation basée sur CNAME.

Que se passe-t-il pour les certificats managés existants ?

Les certificats managés existants seront automatiquement renouvelés avant le 15 août 2025 et restent valides jusqu’au 14 avril 2026. Toutefois, tout renouvellement requis après le 15 août 2025 ne sera pas possible.

Quelles mesures dois-je entreprendre pour éviter toute interruption de service ?

Azure Front Door (classique)

Cdn Azure de Microsoft (classique)

Facturation

Suis-je facturé pour les ressources Azure Front Door qui sont désactivées ?

Vous ne pouvez pas désactiver les ressources Azure Front Door. Vous pouvez uniquement les supprimer. Les compteurs variables tels que le transfert de données sortant, le transfert de données en réception et les requêtes ne sont pas facturés lorsqu’il n’y a aucun trafic, mais des frais de base sont facturés même s’il n’existe aucun trafic. Les frais de base seront facturés jusqu’à la suppression du profil. Pour AFD Classic, les règles et stratégies WAF sont facturées indépendamment de leur état. 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.

Mise en cache

Est-il possible d’utiliser l’en-tête de demande HTTP comme clé de cache ?

Non.

Front Door prend-il en charge ETag ?

Non.

Est-il possible de prendre en charge la compression pour des tailles de fichier supérieures à 8 Mo ?

AFD ne prend pas en charge la compression dynamique pour un contenu supérieur à 8 Mo. Toutefois, si le contenu est déjà compressé par l’origine, Front Door prend en charge le service de contenu compressé statique sur plus de 8 Mo aussi longtemps que la demande de plage est prise en charge et que le codage de transfert en bloc n’est pas activé.

AFD prend-il en charge le paramétrage d’en-tête d’autorisation dans la requête HTTP si la mise en cache est activée ?

Non.

Diagnostics et journalisation

Quelles sont les métriques et les journaux fournis par Azure Front Door ?

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

Quelle est la durée de rétention des journaux de diagnostic ?

Vous pouvez stocker les journaux de diagnostic dans leur propre compte de stockage et choisir la durée de leur conservation. Les journaux de diagnostic peuvent également être envoyés à Event Hubs ou à des journaux Azure Monitor. Pour découvrir plus d’informations, consultez Diagnostics Azure Front Door.

Quelles sont les étapes à suivre pour accéder aux journaux d’audit d’Azure Front Door ?

Pour accéder aux journaux d’audit d’Azure Front Door, vous devez utiliser le portail. Sélectionnez votre Front Door dans la page de menu, puis cliquez sur Journal d’activité. Le journal d’activité vous fournit les enregistrements de vos opérations Azure Front Door.

Comment puis-je configurer des alertes pour Azure Front Door ?

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

Pour découvrir comment créer des alertes pour Azure Front Door Standard et Premium, consultez Configurer des alertes.

Contenu connexe