Partager via

Meilleures pratiques d’architecture pour Azure Application Gateway v2

Azure Application Gateway v2 est un équilibreur de charge de trafic web qui fonctionne au niveau de la couche Application. Application Gateway gère le trafic vers vos applications web en fonction des attributs d’une requête HTTP. Utilisez Application Gateway pour les scénarios qui ont des fonctionnalités de routage avancées et nécessitent une sécurité et une scalabilité améliorées.

Cet article suppose qu’en tant qu’architecte, vous avez examiné les options de mise en réseau et choisi Application Gateway comme équilibreur de charge de trafic web pour votre charge de travail. Les conseils fournis dans cet article proposent des recommandations architecturales alignées sur les principes des piliers du Framework Well-Architected.

Important

Comment utiliser ce guide

Chaque section dispose d’une liste de contrôle de conception qui présente des domaines d’intérêt architecturaux, ainsi que des stratégies de conception localisées dans l’étendue technologique.

Sont également incluses les recommandations relatives aux fonctionnalités technologiques qui peuvent aider à matérialiser ces stratégies. Les recommandations ne représentent pas une liste exhaustive de toutes les configurations disponibles pour Application Gateway et ses dépendances. Au lieu de cela, ils énumèrent les principales recommandations mappées aux perspectives de conception. Utilisez les recommandations pour créer votre preuve de concept ou pour optimiser vos environnements existants.

Architecture fondamentale qui illustre les recommandations clés : architecture d'une application web à haute disponibilité et redondante entre zones.

Étendue de la technologie

Cette révision se concentre sur les décisions liées aux ressources Azure suivantes :

  • Application Gateway v2
  • Pare-feu d’applications web (WAF) sur Application Gateway

Fiabilité

L'objectif du pilier Fiabilité est de fournir une fonctionnalité continue en construisant suffisamment de résilience et la capacité de récupérer rapidement en cas de défaillance.

Les principes de conception pour la fiabilité offrent une stratégie de haut niveau appliquée aux composants individuels, aux flux de système et au système dans son ensemble.

Liste de contrôle pour la conception

Commencez votre stratégie de conception basée sur la checklist de revue de conception pour la fiabilité. Déterminez sa pertinence pour vos besoins métier tout en gardant à l’esprit les fonctionnalités d’Application Gateway et de ses dépendances. Étendez la stratégie pour inclure davantage d’approches en fonction des besoins.

  • Utilisez Application Gateway v2 dans les nouveaux déploiements, sauf si votre charge de travail nécessite spécifiquement Application Gateway v1.

  • Générer la redondance dans votre conception. Répartissez les instances Application Gateway entre les zones de disponibilité pour améliorer la tolérance de panne et la redondance de build. Le trafic passe à d’autres zones en cas d’échec d’une zone. Pour plus d’informations, consultez Recommandations relatives à l’utilisation des zones de disponibilité et des régions.

  • Planifiez un délai supplémentaire pour les mises à jour des règles et d’autres modifications de configuration avant d’accéder à Application Gateway ou d’apporter d’autres modifications. Par exemple, vous pourriez avoir besoin de temps supplémentaire pour supprimer des serveurs d’un pool de serveurs arrière parce que les connexions existantes doivent être vidées.

  • Implémentez le modèle de surveillance des points de terminaison de santé. Votre application doit exposer des points de terminaison de santé, qui agrègent l'état des services et dépendances critiques nécessaires pour traiter les requêtes. Les sondes d’intégrité Application Gateway utilisent le point de terminaison pour détecter l’intégrité des serveurs dans le pool principal. Pour plus d’informations, consultez Modèle Supervision de point de terminaison d’intégrité.

  • Évaluez l’impact des paramètres d’intervalle et de seuil sur une sonde de santé. La sonde d’intégrité envoie des requêtes au point de terminaison configuré à un intervalle défini. Et le back-end tolère un nombre limité de requêtes ayant échoué avant qu’elles ne sont marquées comme non saines. Ces paramètres peuvent entrer en conflit, ce qui présente un compromis.

    • Un intervalle plus élevé place une charge plus élevée sur votre service. Chaque instance Application Gateway envoie sa propre sonde d’intégrité, de sorte que 100 instances toutes les 30 secondes sont égales à 100 requêtes toutes les 30 secondes.

    • Un intervalle inférieur allonge le temps avant que la sonde d'intégrité détecte une panne.

    • Un seuil faible et malsain augmente la probabilité d’échecs brefs et transitoires qui mettent hors service un back-end.

    • Un seuil élevé augmente le temps nécessaire pour qu'un serveur de fond sorte de la rotation.

  • Vérifiez les dépendances en aval via les points de terminaison de santé. Pour isoler les défaillances, chacun de vos systèmes dorsaux peut avoir ses propres dépendances. Par exemple, une application que vous hébergez derrière Application Gateway peut avoir plusieurs back-ends, et chaque back-end se connecte à une autre base de données ou réplica. Lorsqu’une telle dépendance échoue, l’application peut fonctionner, mais ne retourne pas de résultats valides. Pour cette raison, le point de terminaison de santé doit idéalement valider toutes les dépendances.

    Si chaque appel au point de terminaison d’intégrité a un appel de dépendance direct, cette base de données reçoit 100 requêtes toutes les 30 secondes au lieu d’une requête. Pour éviter des requêtes excessives, l'endpoint de santé doit mettre en cache l'état des dépendances pendant une courte période.

  • Tenez compte des limitations d’Application Gateway et des problèmes connus susceptibles d’affecter la fiabilité. Passez en revue les questions fréquentes (FAQ) d’Application Gateway pour obtenir des informations importantes sur le comportement de conception, les correctifs en cours de construction, les limitations de plateforme et les solutions de contournement ou les stratégies d’atténuation possibles. N’utilisez pas d’UDR dans le sous-réseau dédié Application Gateway.

  • Considérez les limitations de port SNAT (Source Network Address Translation) dans votre conception qui peuvent affecter les connexions back-end sur Application Gateway. Certains facteurs affectent la façon dont Application Gateway atteint la limite de port SNAT. Par exemple, si le serveur principal est une adresse IP publique, il nécessite son propre port SNAT. Pour éviter les limitations de port SNAT, vous pouvez effectuer l’une des options suivantes :

    • Augmentez le nombre d’instances pour chaque application Gateway.

    • Effectuez un scale-out des back-ends pour avoir plus d’adresses IP.

    • Déplacez vos back-ends dans le même réseau virtuel et utilisez des adresses IP privées pour les back-ends.

      Si Application Gateway atteint la limite de port SNAT, elle affecte les requêtes par seconde (RPS). Par exemple, Application Gateway ne peut pas ouvrir une nouvelle connexion au serveur principal et la requête échoue.

Recommandations

Recommandation Avantage
Déployez des instances Application Gateway dans une configuration prenant en charge les zones.

Vérifiez la prise en charge régionale de la redondance de zone, car toutes les régions n’offrent pas cette fonctionnalité.		 Lorsque vous répartissez plusieurs instances entre des zones, votre charge de travail peut résister aux défaillances dans une seule zone. Si vous avez une zone indisponible, le trafic est automatiquement redirigé vers des instances saines dans d’autres zones, ce qui maintient la fiabilité de l’application.
Utilisez des sondes d’intégrité Application Gateway pour détecter l’indisponibilité du back-end. Les sondes de santé garantissent que le trafic est uniquement acheminé vers les systèmes de traitement en arrière-plan qui peuvent gérer le trafic. Application Gateway surveille l’intégrité de tous les serveurs de son pool principal et arrête automatiquement l’envoi du trafic à n’importe quel serveur qu’il considère non sain.
Configurez des règles de limitation de débit pour Azure WAF afin que les clients ne puissent pas envoyer trop de trafic à votre application. Utilisez la limitation du débit pour éviter des problèmes tels que des avalanches de tentatives répétées.
N’utilisez pas d’UDR sur Application Gateway afin que le rapport de santé du back-end fonctionne correctement et génère des journaux et métriques précis.

Si vous devez utiliser un UDR dans le sous-réseau Application Gateway, consultez les UDR pris en charge.		 Les UDR sur le sous-réseau Application Gateway peuvent entraîner des problèmes. N’utilisez pas d’UDR sur le sous-réseau Application Gateway afin de pouvoir afficher la santé du back-end, les journaux et les données de performance.
Configurez les paramètres IdleTimeout pour qu’ils correspondent aux caractéristiques de trafic et d’écouteur de l’application back-end. La valeur par défaut est de quatre minutes. Vous pouvez le configurer pour un maximum de 30 minutes.

Pour plus d’informations, consultez la réinitialisation et le délai d'inactivité du protocole TCP du répartiteur de charge.		 Définissez IdleTimeout pour qu'il corresponde au système back-end. Ce paramètre garantit que la connexion entre Application Gateway et le client reste ouverte si le serveur principal prend plus de quatre minutes pour répondre à la demande. Si vous ne configurez pas ce paramètre, la connexion se ferme et le client ne voit pas la réponse back-end.

Sécurité

L'objectif du pilier Sécurité est de fournir des garanties de confidentialité, d'intégrité et de disponibilité à la charge de travail.

Les principes de conception de sécurité fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs en appliquant des approches à la conception technique d’Application Gateway.

Liste de contrôle pour la conception

Démarrez votre stratégie de conception à partir de la checklist de révision de conception pour la sécurité, et identifiez les vulnérabilités ainsi que les mesures de contrôle pour améliorer la posture de sécurité. Étendez la stratégie pour inclure davantage d’approches en fonction des besoins.

  • Passez en revue la base de référence de sécurité pour Application Gateway.

  • Bloquer les menaces courantes à la périphérie. WAF s’intègre à Application Gateway. Activez les règles WAF sur les frontaux pour protéger les applications contre les attaques et les vulnérabilités courantes sur la périphérie du réseau, qui est proche de la source d’attaque. Pour plus d’informations, consultez WAF sur Application Gateway.

    Découvrez comment le pare-feu d'applications web affecte les modifications de capacité de l'Application Gateway. Lorsque vous activez WAF, Application Gateway :

    • Met en mémoire tampon chaque requête jusqu’à ce qu’elle arrive entièrement.

    • Vérifie si la requête correspond à une violation de règle dans son ensemble de règles de base.

    • Transfère le paquet aux instances principales.

    Les chargements de fichiers volumineux qui sont de 30 Mo ou plus peuvent introduire une latence significative. Les exigences en matière de capacité d’Application Gateway changent lorsque vous activez waf. Nous vous recommandons donc de tester et de valider cette méthode en premier.

    Lorsque vous utilisez Azure Front Door et Application Gateway pour protéger les applications HTTP ou HTTPS, utilisez des stratégies WAF dans Azure Front Door et verrouillez Application Gateway pour recevoir le trafic uniquement à partir d’Azure Front Door. Certains scénarios peuvent vous forcer à implémenter des règles spécifiquement sur Application Gateway. Par exemple, si vous avez besoin de règles ModSec CRS 2.2.9, CRS 3.0 ou CRS 3.1, vous pouvez uniquement implémenter ces règles sur Application Gateway. À l’inverse, Azure Front Door prend en charge la limitation de débit et le filtrage géographique, et Application Gateway ne prend pas en charge ces fonctionnalités.

  • Autorisez uniquement l’accès autorisé au plan de contrôle. Utilisez le contrôle d’accès en fonction du rôle Application Gateway (RBAC) pour restreindre l’accès aux identités qui en ont besoin uniquement.

  • Protégez les données en transit. Activez le chiffrement TLS (Transport Layer Security) de bout en bout, l’arrêt TLS et le chiffrement TLS de bout en bout. Lorsque vous chiffrez à nouveau le trafic principal, vérifiez que le certificat de serveur principal contient les autorités de certification racine et intermédiaires.

    Utilisez une autorité de certification connue pour émettre un certificat TLS du serveur principal. Si vous n’utilisez pas d’autorité de certification approuvée pour émettre le certificat, Application Gateway vérifie jusqu’à ce qu’il trouve un certificat d’autorité de certification approuvé. Il établit une connexion sécurisée uniquement lorsqu’elle trouve une autorité de certification approuvée. Sinon, Application Gateway marque le back-end comme non sain.

  • Protégez les secrets d’application. Utilisez Azure Key Vault pour stocker des certificats TLS pour renforcer la sécurité et faciliter le renouvellement et le processus de rotation des certificats.

  • Réduisez la surface d’attaque et renforcez la configuration. Supprimez les configurations par défaut dont vous n’avez pas besoin et renforcez votre configuration Application Gateway pour renforcer les contrôles de sécurité. Respectez toutes les restrictions de groupe de sécurité réseau (NSG) pour Application Gateway.

    Utilisez un serveur DNS (Domain Name System) approprié pour les ressources du pool principal. Lorsque le pool principal contient un nom de domaine complet (FQDN) résolvable, la résolution DNS est basée sur une zone DNS privée ou un serveur DNS personnalisé (s’il est configuré sur le réseau virtuel) ou utilise le DNS fourni par défaut par Azure.

  • Surveillez l’activité anormale. Passez régulièrement en revue les journaux pour rechercher les attaques et les faux positifs. Envoyez les journaux WAF d’Application Gateway aux informations de sécurité centralisées et à la gestion des événements (SIEM) de votre organisation, comme Microsoft Sentinel, pour détecter les modèles de menaces et incorporer des mesures préventives dans la conception de la charge de travail.

Recommandations

Recommandation Avantage
Configurez une stratégie TLS pour renforcer la sécurité. Veillez à utiliser la dernière version de la stratégie TLS. Utilisez la dernière stratégie TLS pour appliquer l’utilisation de TLS 1.2 et des chiffrements plus forts. La stratégie TLS inclut le contrôle de la version du protocole TLS et les suites de chiffrement, ainsi que l’ordre dans lequel une négociation TLS utilise des chiffrements.
Utilisez Application Gateway pour l’arrêt TLS. Les performances s’améliorent, car les requêtes qui passent à différents back-ends n’ont pas besoin de se réauthentifier à chaque back-end.

La passerelle peut accéder au contenu de la demande et prendre des décisions de routage intelligentes.

Vous devez uniquement installer le certificat sur Application Gateway, ce qui simplifie la gestion des certificats.
Intégrez Application Gateway à Key Vault pour stocker des certificats TLS. Cette approche offre une sécurité plus forte, une séparation plus facile des rôles et des responsabilités, la prise en charge des certificats managés et un processus de renouvellement et de rotation des certificats plus faciles.
Respectez toutes les restrictions de groupe de sécurité réseau pour Application Gateway. Le sous-réseau Application Gateway prend en charge les groupes de sécurité réseau, mais il existe certaines restrictions. Par exemple, certaines communications avec certaines plages de ports sont interdites. Veillez à comprendre les implications de ces restrictions.

Optimisation des coûts

L’optimisation des coûts se concentre sur la détection des modèles de dépense, la hiérarchisation des investissements dans les domaines critiques et l’optimisation dans d’autres pour répondre au budget de l’organisation tout en répondant aux besoins de l’entreprise.

Les principes de conception de l’optimisation des coûts fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs et faire des compromis si nécessaire dans la conception technique liée à Application Gateway et à son environnement.

Liste de contrôle pour la conception

Démarrez votre stratégie de conception en utilisant la liste de contrôle de révision de conception pour optimiser les coûts dans vos investissements. Ajustez la conception afin que la charge de travail soit alignée sur le budget alloué pour la charge de travail. Votre conception doit utiliser les fonctionnalités Azure appropriées, surveiller les investissements et trouver des opportunités d’optimisation au fil du temps.

  • Familiarisez-vous avec les tarifs Application Gateway et WAF. Choisissez des options de taille appropriée pour répondre à la demande de capacité de votre charge de travail et fournir des performances attendues sans perdre de ressources. Pour estimer les coûts, utilisez la calculatrice de prix.

  • Supprimez les instances Application Gateway inutilisées et optimisez les instances sous-utilisées. Pour éviter les coûts inutiles, identifiez et supprimez les instances Application Gateway qui ont des pools back-end vides. Arrêtez les instances Application Gateway quand elles ne sont pas utilisées.

  • Optimisez le coût de mise à l’échelle de votre instance Application Gateway. Pour optimiser votre stratégie de mise à l’échelle et réduire les demandes de votre wokload, consultez Recommandations pour optimiser le coût de mise à l’échelle.

    Pour mettre à l’échelle le service en fonction des exigences de trafic d’application, utilisez la mise à l’échelle automatique dans Application Gateway v2.

  • Surveillez les métriques de consommation d’Application Gateway et comprenez leur impact sur les coûts. Frais Azure pour les instances limitées d’Application Gateway en fonction des métriques suivies. Évaluez les différentes métriques et unités de capacité, puis déterminez les facteurs de coût. Pour plus d’informations, consultez Microsoft Cost Management.

Recommandations

Recommandation Avantage
Arrêtez les instances Application Gateway quand elles ne sont pas utilisées. Pour plus d’informations, consultez Stop-AzApplicationGateway et Start-AzApplicationGateway. Une instance Application Gateway arrêtée n’entraîne pas de coûts. Les instances Application Gateway qui s’exécutent en continu peuvent entraîner des coûts inutiles. Évaluez les modèles d’utilisation et arrêtez les instances lorsque vous n’en avez pas besoin. Par exemple, attendez-vous à une faible utilisation après les heures d’activité dans les environnements de développement/test.
Surveillez les métriques Application Gateway, comme les principaux facteurs de coût :

- Unités de capacité facturées estimées.
- Unités de capacité facturables fixes.
- Unités de capacité actuelles.

Veillez à prendre en compte les coûts de bande passante.		 Utilisez ces métriques pour vérifier si le nombre d’instances provisionnés correspond à la quantité de trafic entrant et vérifiez que vous utilisez entièrement les ressources allouées.

Excellence opérationnelle

L'excellence opérationnelle se concentre principalement sur les procédures relatives aux pratiques de développement, à l'observabilité et à la gestion des versions.

Les principes de la conception d'excellence opérationnelle fournissent une stratégie de conception de haut niveau pour les exigences opérationnelles de la charge de travail afin d'atteindre ces objectifs.

Liste de contrôle pour la conception

Démarrez votre stratégie de conception en fonction de la liste de contrôle de révision de conception pour l’excellence opérationnelle pour définir des processus d’observabilité, de test et de déploiement liés à Application Gateway.

  • Activer les diagnostics sur Application Gateway et WAF. Collectez les journaux et les métriques pour surveiller l’intégrité de la charge de travail, identifier les tendances dans les performances et la fiabilité de la charge de travail et résoudre les problèmes. Pour concevoir votre approche globale de supervision, consultez Recommandations pour la conception et la création d’un système de supervision.

    Utilisez les métriques de capacité pour surveiller l’utilisation de la capacité Application Gateway provisionnée. Définissez des alertes sur les métriques pour vous avertir des problèmes de capacité ou d’autres problèmes au niveau d’Application Gateway ou du serveur principal. Utilisez les journaux de diagnostic pour gérer et résoudre les problèmes liés aux instances d’Application Gateway.

  • Utilisez Azure Monitor Network Insights pour obtenir une vue complète de l’intégrité et des métriques des ressources réseau, notamment Application Gateway. Utilisez la supervision centralisée pour identifier et résoudre rapidement les problèmes, optimiser les performances et garantir la fiabilité de vos applications.

  • Surveillez les recommandations d’Application Gateway dans Azure Advisor. Configurez des alertes pour avertir votre équipe lorsque vous avez de nouvelles recommandations critiques pour votre instance Application Gateway. Advisor génère des recommandations basées sur les propriétés, telles que la catégorie, le niveau d’impact et le type de recommandation.

Recommandations

Recommandation Avantage
Configurez des alertes pour avertir votre équipe lorsque les métriques de capacité, telles que l’utilisation du processeur et l’utilisation de l’unité de calcul, dépassent les seuils recommandés.

Pour configurer un ensemble complet d’alertes basées sur les métriques de capacité, consultez la prise en charge du trafic élevé d’Application Gateway.		 Définissez des alertes lorsque les métriques dépassent les seuils afin que vous sachiez quand votre utilisation augmente. Cette approche garantit que vous avez suffisamment de temps pour implémenter les modifications nécessaires à votre charge de travail et empêcher la dégradation ou les pannes.
Configurez des alertes pour informer votre équipe des métriques qui indiquent des problèmes au niveau d’Application Gateway ou du serveur principal. Nous vous recommandons d’évaluer les alertes suivantes :

- Nombre d'hôtes en mauvais état
- État de la réponse, tel que les erreurs 4xx et 5xx
- État de réponse du serveur, tel que les erreurs 4xx et 5xx
- Temps de réponse du dernier octet du back-end
- Durée totale d’Application Gateway

Pour plus d’informations, consultez Métriques pour Application Gateway.		 Utilisez des alertes pour vous assurer que votre équipe peut répondre aux problèmes en temps voulu et faciliter la résolution des problèmes.
Activez les journaux de diagnostic sur Application Gateway et WAF pour collecter les journaux de pare-feu, les journaux de performances et les journaux d’accès. Utilisez les journaux pour détecter, examiner et résoudre les problèmes liés aux instances d’Application Gateway et à votre charge de travail.
Utilisez Advisor pour surveiller les problèmes de configuration de Key Vault. Définissez une alerte pour avertir votre équipe lorsque vous recevez la recommandation qui indique Résolvez le problème Azure Key Vault pour votre Application Gateway. Utilisez les alertes Advisor pour rester à jour et résoudre immédiatement les problèmes. Empêcher tout problème lié au plan de contrôle ou au plan de données.

Application Gateway vérifie la version de certificat renouvelée dans l’instance de Key Vault liée toutes les 4 heures. Si la version du certificat est inaccessible en raison d’une configuration Key Vault incorrecte, elle enregistre cette erreur et envoie une recommandation Advisor correspondante.

Efficacité des performances

L'efficacité des performances consiste à maintenir l'expérience de l'utilisateur même en cas d'augmentation de la charge en gérant la capacité. La stratégie inclut la mise à l’échelle des ressources, l’identification et l’optimisation des goulots d’étranglement potentiels et l’optimisation des performances maximales.

Les principes de conception de l'efficacité des performances fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs de capacité en fonction de l'utilisation attendue.

Liste de contrôle pour la conception

  • Estimer les besoins en capacité d'Application Gateway pour prendre en charge vos exigences de charge de travail. Tirez parti de la fonctionnalité de mise à l’échelle automatique dans Application Gateway v2. Définissez les valeurs appropriées pour le nombre minimal et maximal d’instances. Dimensionner correctement le sous-réseau dédié requis par Application Gateway. Pour plus d’informations, consultez Recommandations pour la planification de la capacité.

    Application Gateway v2 effectue un scale-out basé sur de nombreux aspects, tels que le processeur, le débit réseau et les connexions actuelles. Pour déterminer le nombre approximatif d’instances, tenez compte de ces métriques :

    • Unités de calcul actuelles : Cette métrique indique l’utilisation du processeur. Une instance Application Gateway est égale à environ 10 unités de calcul.

    • Débit: Une instance Application Gateway peut servir environ 500 Mbits/s de débit. Ces données dépendent du type de charge utile.

    Tenez compte de cette équation lorsque vous calculez le nombre d’instances. Équation montrant le nombre approximatif d’instances.

    Après avoir estimé le nombre d’instances, comparez cette valeur au nombre maximal d’instances. Utilisez cette comparaison pour déterminer la proximité de la capacité maximale disponible.

  • Tirez parti des fonctionnalités pour la mise à l’échelle automatique et les avantages en matière de performances. La référence SKU v2 offre une mise à l'échelle automatique, ce qui augmente la capacité de l'Application Gateway à mesure que le trafic augmente. Par rapport à la référence SKU v1, la référence SKU v2 offre des fonctionnalités qui améliorent les performances de la charge de travail. Par exemple, la référence SKU v2 offre de meilleures performances de déchargement TLS, des temps de déploiement et de mise à jour plus rapides, ainsi que la prise en charge de la redondance de zone. Pour plus d’informations, consultez l’article Mettre à l’échelle Application Gateway v2 et WAF v2.

    Si vous utilisez Application Gateway v1, envisagez de migrer vers Application Gateway v2. Pour plus d’informations, consultez Migrer Application Gateway et WAF de v1 vers v2.

Recommandations

Recommandation Avantage
Définissez le nombre minimal d’instances à un niveau optimal en fonction du nombre d’instances estimé, des tendances réelles de mise à l’échelle automatique d’Application Gateway et de vos modèles d’application.

Vérifiez les unités de calcul actuelles pour le mois dernier. Cette métrique représente l’utilisation du processeur de la passerelle. Pour définir le nombre minimal d’instances, divisez l’utilisation maximale par 10. Par exemple, si vos unités de calcul actuelles moyennes au cours du mois précédent sont de 50, définissez le nombre minimal d’instances sur cinq.		 Pour Application Gateway v2, la mise à l’échelle automatique prend environ trois à cinq minutes avant que l’ensemble supplémentaire d’instances soit prêt à servir le trafic. Pendant ce temps, si Application Gateway a de courts pics de trafic, attendez-vous à une latence temporaire ou à une perte de trafic.
Définissez le nombre maximal d’instances de mise à l’échelle automatique sur la valeur maximale possible, qui est de 125 instances. Assurez-vous que le sous-réseau dédié Application Gateway dispose d’adresses IP disponibles suffisantes pour prendre en charge l’ensemble accru d’instances.

Si vos besoins en trafic nécessitent plus de 125 instances, vous pouvez utiliser Azure Traffic Manager ou Azure Front Door devant votre Application Gateway. Pour plus d’informations, consultez Connecter Azure Front Door Premium à une passerelle Azure Application Gateway avec Private Link et utiliser Azure App Gateway avec Azure Traffic Manager.		 Application Gateway peut effectuer un scale-out en fonction des besoins pour gérer un trafic accru vers vos applications. Ce paramètre n’augmente pas le coût, car vous payez uniquement pour la capacité consommée.
Dimensionner correctement le sous-réseau dédié Application Gateway. Nous recommandons vivement un sous-réseau /24 pour un déploiement Application Gateway v2.

Si vous souhaitez déployer d’autres ressources Application Gateway dans le même sous-réseau, tenez compte des adresses IP supplémentaires dont vous avez besoin pour le nombre maximal d’instances.

Pour plus d’informations sur le dimensionnement du sous-réseau, consultez la configuration de l’infrastructure Application Gateway.		 Utilisez un sous-réseau /24 pour prendre en charge toutes les adresses IP dont votre déploiement Application Gateway v2 a besoin.

Application Gateway utilise une adresse IP privée pour chaque instance et une autre adresse IP privée si vous configurez une adresse IP frontale privée. La référence SKU Standard_v2 ou WAF_v2 peut prendre en charge jusqu’à 125 instances.

Azure réserve cinq adresses IP dans chaque sous-réseau pour une utilisation interne.

Stratégies Azure

Azure fournit un ensemble complet de stratégies intégrées liées à App Service et à ses dépendances. Un ensemble de stratégies Azure peut auditer certaines des recommandations précédentes. Par exemple, vous pouvez vérifier si :

  • Vous devez activer WAF pour Application Gateway. Déployez WAF devant les applications web publiques pour ajouter une autre couche d’inspection pour le trafic entrant. WAF fournit une protection centralisée pour vos applications web. Il permet d’éviter les attaques et vulnérabilités courantes, telles que les injections SQL, les scripts intersites et les exécutions de fichiers locaux et distants. Vous pouvez également utiliser des règles personnalisées pour restreindre l’accès à vos applications web en fonction de pays ou de régions, de plages d’adresses IP et d’autres paramètres HTTP ou HTTPS.

  • Le pare-feu d’applications web doit utiliser le mode spécifié pour Application Gateway. Vérifiez que toutes les stratégies WAF pour Application Gateway utilisent le mode détection ou prévention .

  • Vous devez activer Azure DDoS Protection. Activez la protection DDoS pour tous les réseaux virtuels qui ont un sous-réseau qui contient Application Gateway avec une adresse IP publique.

Pour une gouvernance complète, passez en revue les définitions intégrées d’Azure Policy et d’autres stratégies susceptibles d’affecter la mise en réseau.

Recommandations d’Azure Advisor

Azure Advisor est un consultant cloud personnalisé qui vous aide à suivre les meilleures pratiques pour optimiser vos déploiements Azure. Voici quelques recommandations qui peuvent vous aider à améliorer la fiabilité, la sécurité, l’efficacité des coûts, les performances et l’excellence opérationnelle d’Application Gateway.

Étapes suivantes