Questions fréquentes (FAQ) sur 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.

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.

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.

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.

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 la conservation du flux de connexion avec l’origine et la recherche de chemin d’accès 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. Tout adresse IP cliente basée sur ACLing ne fonctionne pas sur le deuxième CDN car celui-ci voit le nœud de sortie du premier CDN comme des adresses IP clientes. La charge utile de contenu peut toujours être inspectée.
3. Plusieurs organisations ne peuvent pas gérer la complexité de la résolution des problèmes de deux CDN chaînés et, quand un problème se produit, il devient difficile de déterminer le CDN rencontrant le problème.

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.

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.

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

• Stockage (Blob Azure, Classique, Sites web statiques)
• service cloud
• App Service
• Application web statique
• Gestion des API
• Application Gateway
• Adresse IP publique
• Azure Spring Apps
• Container Instances
• 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.

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.

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.

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.

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.

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, 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.

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.

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.

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

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

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.

La durée du déploiement des nouvelles configurations Front Door varie en fonction du type de modification. En règle générale, il faut entre 3 et 20 minutes pour que les modifications se propagent à tous nos emplacements de périphérie dans le monde.

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 des certificats sont également effectuées de façon atomique : il n’y a donc pas de risque de panne.

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.

• 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.

Pour utiliser le niveau Azure Front Door Standard, Premium ou (classique), 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.

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.

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.

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.

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é.

Le fait que les deux profils utiliseraient les mêmes sites de périphérie Azure pour gérer les requêtes entrantes entraîne cette limitation, qui vous empêche d’imbriquer un profil 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 vérifier que vos profils Azure Front Door sont indépendants et non chaînés les uns aux autres si vous devez utiliser plusieurs profils pour vos applications.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.0, 1.1, 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.

Azure Front Door est un service qui permet une distribution web rapide et sécurisée. Il vous permet de définir comment votre trafic web est routé, et comment il est optimisé entre plusieurs régions et points de terminaison. Les ressources Azure Front Door, comme les profils Front Door et les règles de routage, sont facturées seulement quand elles sont activées. Cependant, les stratégies et les règles de pare-feu d’applications web (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.

Non.

Non.

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é.

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. Les journaux de diagnostic peuvent également être envoyés à Event Hubs ou à des journaux Azure Monitor. Pour plus d’informations, consultez Diagnostics 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.

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.

Étapes suivantes

• Découvrez comment Créer un profil Azure Front Door.
• Découvrez l’architecture d’Azure Front Door.