Révision d’Azure Well-Architected Framework - Azure Application Gateway v2

  • Article

Cet article décrit les meilleures pratiques architecturales pour la famille de références SKU Azure Application Gateway v2. L’orientation repose sur les cinq piliers de l’excellence architecturale :

Nous partons du principe que vous avez une connaissance pratique de Azure Application Gateway et que vous connaissez bien les fonctionnalités de référence SKU v2. Pour plus d’informations, consultez fonctionnalités Azure Application Gateway.

Prérequis

Fiabilité

Dans le cloud, nous reconnaissons que des échecs se produisent. Au lieu d’essayer d’empêcher toutes les défaillances, l’objectif est de réduire les répercussions d’une défaillance potentielle au niveau de chaque composant. Utilisez les informations suivantes pour réduire les instances ayant échoué.

Check-list pour la conception

Lorsque vous effectuez des choix de conception pour Application Gateway, passez en revue les principes de conception de fiabilité.

  • Déployez les instances dans une configuration prenant en charge les zones, le cas échéant.
  • Utilisez Application Gateway avec Web Application Firewall (WAF) au sein d’un réseau virtuel pour protéger le trafic entrant HTTP/S à partir d’Internet.
  • Dans les nouveaux déploiements, utilisez Azure Application Gateway v2, sauf s’il existe une raison convaincante d’utiliser Azure Application Gateway v1.
  • Planifier les mises à jour de règle
  • Utiliser des sondes d’intégrité pour détecter l’indisponibilité du serveur principal
  • Examiner l’impact des paramètres d’intervalle et de seuil sur les sondes d’intégrité
  • Vérifier les dépendances en aval via des points de terminaison d’intégrité

Recommandations

Explorez le tableau de recommandations suivant pour optimiser la configuration de votre Application Gateway pour la fiabilité.

Recommandation Avantage
Planifier les mises à jour de règle Planifiez suffisamment de temps pour les mises à jour avant d’accéder à Application Gateway ou d’apporter d’autres modifications. Par exemple, la suppression de serveurs du pool principal peut prendre un certain temps, car elle nécessite un drainage des connexions existantes.
Utiliser des sondes d’intégrité pour détecter l’indisponibilité du serveur principal Si Application Gateway est utilisé pour équilibrer la charge du trafic entrant sur plusieurs instances de serveur principal, nous vous recommandons d’utiliser des sondes d’intégrité. Celles-ci permettent de s’assurer que le trafic n’est pas acheminé vers des serveurs principaux incapables de le gérer.
Examiner l’impact des paramètres d’intervalle et de seuil sur les sondes d’intégrité La sonde d’intégrité envoie des requêtes au point de terminaison configuré à intervalles définis. Il existe également un seuil d’échecs de demandes tolérés avant que le serveur principal soit marqué comme non sain. Ces chiffres résultent d’un compromis.

- La définition d’un intervalle plus élevé entraîne une charge plus élevée sur votre service. Chaque instance Application Gateway envoyant ses propres sondes d’intégrité, 100 instances toutes les 30 secondes équivalent à 100 requêtes par tranche de 30 secondes.
- La définition d’un intervalle inférieur laisse plus de temps avant qu’une panne ne soit détectée.
- La définition d’un seuil de non-intégrité faible peut signifier que des défaillances temporaires et courtes peuvent entraîner l’arrêt d’un serveur principal.
- La définition d’un seuil élevé peut prendre plus de temps pour sortir un back-end de la rotation.
Vérifier les dépendances en aval via des points de terminaison d’intégrité Supposez que chaque serveur principal a ses propres dépendances pour garantir que les défaillances sont isolées. Par exemple, une application hébergée derrière Application Gateway peut avoir plusieurs back-ends, chacun connecté à une base de données différente (réplica). En cas d’échec d’une telle dépendance, l’application peut fonctionner, mais ne retourne pas de résultats valides. C’est pourquoi le point de terminaison d’intégrité doit idéalement valider toutes les dépendances. Gardez à l’esprit que, si chaque appel au point de terminaison d’intégrité a pour corollaire un appel de dépendance directe, cette base de données recevra 100 requêtes toutes les 30 secondes au lieu d’une. Pour éviter cela, le point de terminaison d’intégrité doit brièvement mettre en cache l’état des dépendances.
Lors de l’utilisation d’Azure Front Door et d’Application Gateway pour protéger les applications HTTP/S, utilisez des stratégies WAF dans Front Door, et verrouillez Application Gateway pour recevoir le trafic uniquement en provenance de Front Door. Certains scénarios peuvent vous obliger à implémenter des règles spécifiquement sur Application Gateway. Par exemple, si des règles ModSec CRS 2.2.9, CRS 3.0 ou CRS 3.1 sont requises, ces règles peuvent être implémentées uniquement sur Application Gateway. À l’inverse, la limitation du débit et le géofiltrage sont disponibles uniquement sur Azure Front Door, et non sur AppGateway.

Azure Advisor vous aide à garantir et à améliorer la continuité de vos applications critiques pour l’entreprise. Passez en revue les recommandations d’Azure Advisor.

Sécurité

La sécurité est l’un des aspects les plus importants d’une architecture. Application Gateway fournit des fonctionnalités pour utiliser les principes du privilège minimum et de la défense dans la défense. Nous vous recommandons de passer en revue les principes de conception de la sécurité.

Check-list pour la conception

  • Configurer une stratégie de protocole TLS pour plus de sécurité
  • Utiliser Application Gateway pour la terminaison TLS
  • Utiliser Azure Key Vault pour stocker des certificats TLS
  • Lors du rechiffrage du trafic back-end, vérifiez que le certificat du serveur principal contient à la fois les autorités de certification racine et intermédiaires.
  • Utiliser un serveur DNS approprié pour les ressources du pool principal
  • Se conformer à toutes les restrictions de groupe de sécurité réseau pour Application Gateway
  • Évitez d’utiliser des UDR sur le sous-réseau Application Gateway
  • Tenez compte des changements de capacité Application Gateway lors de l’activation du WAF

Recommandations

Explorez le tableau de recommandations suivant pour optimiser la configuration de votre Application Gateway pour la sécurité.

Recommandation Avantage
Configurer une stratégie de protocole TLS pour plus de sécurité Configurez une stratégie de protocole TLS pour plus de sécurité. Vérifiez que vous utilisez la dernière version de la stratégie TLS (AppGwSslPolicy20170401S). Cela garantit le chiffrement TLS 1.2 et les chiffrements renforcés.
Utiliser Application Gateway pour la terminaison TLS L’utilisation d’Application Gateway pour la terminaison TLS présente des avantages :

- Les performances s’améliorent, car les demandes envoyées à différents back-ends doivent s’authentifier à nouveau auprès de chaque back-end.
- Meilleure utilisation des serveurs principaux, car ils n’ont pas à effectuer de traitement TLS
- Routage intelligent en accédant au contenu de la demande.
- Gestion des certificats plus facile, car le certificat doit uniquement être installé sur Application Gateway.
Utiliser Azure Key Vault pour stocker des certificats TLS Application Gateway est intégré avec Azure Key Vault. Cela offre une sécurité renforcée, une séparation plus simple des rôles et des responsabilités, la prise en charge des certificats gérés et un processus plus facile de renouvellement et de rotation des certificats.
Lors du rechiffrage du trafic back-end, vérifiez que le certificat du serveur principal contient à la fois les autorités de certification racine et intermédiaires. Un certificat TLS du serveur principal doit être émis par une autorité de certification connue. Si le certificat n’a pas été émis par une autorité de certification approuvée, Application Gateway vérifie si l’autorité de certification émettrice a été certifiée par une autorité de certification approuvée, et ainsi de suite jusqu’à trouver une autorité de certification approuvée. Ce n’est qu’alors qu’une connexion sécurisée est établie. Dans le cas contraire, Application Gateway marque le serveur principal comme non sain.
Utiliser un serveur DNS approprié pour les ressources du pool principal Quand le pool principal contient un nom de domaine complet (FQDN) pouvant être résolu, 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 par défaut fourni par Azure.
Se conformer à toutes les restrictions de groupe de sécurité réseau pour Application Gateway Les groupes de sécurité réseau sont pris en charge sur Application Gateway sous-réseau, mais il existe certaines restrictions. Par exemple, certaines communications avec certaines plages de ports sont interdites. Assurez-vous de bien comprendre les implications de ces restrictions. Pour plus d’informations, consultez Groupes de sécurité réseau.
Évitez d’utiliser des UDR sur le sous-réseau application gateway L’utilisation d’itinéraires définis par l’utilisateur (UDR) sur le sous-réseau Application Gateway peut entraîner des problèmes. Il se peut l’état d’intégrité du serveur principal soit inconnu. Il se peut que des journaux et métriques d’Application Gateway ne puissent ne pas être générés. Nous vous recommandons de ne pas utiliser de routes définies par l’utilisateur sur le sous-réseau Application Gateway afin de pouvoir voir l’état d’intégrité, les journaux et les métriques du back-end. Si votre organisation requiert l’utilisation d’itinéraires définis par l’utilisateur dans le sous-réseau Application Gateway, veillez à passer examiner les scénarios pris en charge. Pour plus d’informations, consultez Routes définies par l’utilisateur prises en charge.
Tenez compte des changements de capacité Application Gateway lors de l’activation du WAF Quand le pare-feu d’applications web (WAF) est activé, Application Gateway doit mettre chaque requête en mémoire tampon jusqu’à ce qu’elle arrive entièrement, vérifier dans son ensemble de règles de base si la requête correspond à une violation de règle, puis transférer le paquet aux instances de serveur principal. Pour les chargements de fichiers volumineux (plus de 30 Mo), cela peut entraîner une latence importante. Étant donné que les exigences en matière de capacité d’Application Gateway diffèrent de celles du WAF, nous vous déconseillons d’activer celui-ci sur Application Gateway sans avoir dûment testé et validé cette configuration.

Pour plus de suggestions, consultez Principes du pilier de sécurité.

Azure Advisor vous aide à garantir et à améliorer la continuité de vos applications critiques pour l’entreprise. Passez en revue les recommandations d’Azure Advisor.

Définitions de stratégies

  • Web Application Firewall (WAF) doit être activé pour Application Gateway. Déployez Azure Web Application Firewall (WAF) devant les applications web publiques pour bénéficier d’un contrôle supplémentaire du trafic entrant. Web Application Firewall (WAF) offre une protection centralisée de vos applications web contre les codes malveillants exploitant une faille de sécurité et les vulnérabilités telles que les injections de code SQL, le scripting inter-site, les exécutions de fichiers locales et à distance. Vous pouvez également restreindre l’accès à vos applications Web par pays/régions, plages d’adresses IP et autres paramètres http(s) par le biais de règles personnalisées.
  • Web Application Firewall (WAF) doit utiliser le mode spécifié pour Application Gateway. Impose l’utilisation du mode de « détection » ou de « blocage » pour être actif sur toutes les stratégies de pare-feu d’applications web pour Application Gateway.
  • Azure DDoS Protection doit être activé. La protection DDoS doit être activée pour tous les réseaux virtuels avec un sous-réseau qui fait partie d’une passerelle applicative avec une adresse IP publique.

Toutes les définitions de stratégie intégrées liées à la mise en réseau Azure sont répertoriées dans Stratégies intégrées - Réseau.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Nous vous recommandons de passer en revue les principes de conception de l’optimisation des coûts.

Check-list pour la conception

  • Familiarisez-vous avec Application Gateway tarification
  • Examiner les ressources sous-utilisées
  • Arrêter Application Gateway instances qui ne sont pas utilisées
  • Adopter une stratégie de mise à l’échelle
  • Examiner les métriques de consommation en fonction de différents paramètres

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration Application Gateway pour l’optimisation des coûts.

Recommandation Avantage
Familiarisez-vous avec Application Gateway tarification Pour plus d’informations sur la tarification Application Gateway, consultez Présentation de la tarification des Azure Application Gateway et des Web Application Firewall. Vous pouvez également tirer parti de la calculatrice de prix.

Veillez à ce que les options soient correctement dimensionnées pour répondre à la demande de capacité et fournir les performances attendues, sans gaspillage de ressources.
Examiner les ressources sous-utilisées Identifiez et supprimez Application Gateway instances avec des pools back-ends vides pour éviter des coûts inutiles.
Arrêter les instances non utilisées d’Application Gateway Vous n’êtes pas facturé quand Application Gateway est à l’arrêt. L’exécution continue d’instances Application Gateway peut occasionner des coûts superflus. Évaluez les modèles d’utilisation et arrêtez les instances dont vous n’avez pas besoin. Par exemple, la probabilité de leur utilisation en dehors des heures de bureau dans des environnements de Dev/Test est faible.

Pour plus d’informations sur l’arrêt et le démarrage des instances, consultez les articles suivants.
- Stop-AzApplicationGateway
- Start-AzApplicationGateway
Adopter une stratégie de mise à l’échelle Une stratégie de montée en puissance (scale-out), ou d’augmentation d’échelle, garantit la disponibilité d’un nombre suffisant d’instances pour gérer le trafic entrant et les pics de trafic. Vous devez également disposer d’une stratégie de descente en puissance (scale-in), ou de réduction d’échelle, garantissant une diminution du nombre d’instances en cas de chute de la demande. Étudiez soigneusement la taille d’instance. La taille peut avoir une incidence significative sur le coût. Certaines considérations sont décrites dans Estimer le nombre d’instances Application Gateway.

Pour plus d’informations, consultez Qu’est-ce que Azure Application Gateway v2 ?
Examiner les métriques de consommation en fonction de différents paramètres Vous êtes facturé pour l’utilisation d’instances Application Gateway, calculée sur la base des métriques suivies par Azure. Évaluez les différentes métriques et unités de capacité, et déterminez les facteurs de coût. Pour plus d’informations, consultez Microsoft Cost Management and Billing.

Les métriques suivantes sont essentielles pour Application Gateway. Ces informations vous permettent de vérifier que le nombre d’instances approvisionnées correspond au volume de trafic entrant.

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

Pour plus d’informations, consultez Métriques d’Application Gateway.

Veillez à prendre en compte les coûts de bande passante.

Pour obtenir d’autres suggestions, consultez Principes du pilier d’optimisation des coûts.

Azure Advisor vous aide à garantir et à améliorer la continuité de vos applications critiques pour l’entreprise. Passez en revue les recommandations d’Azure Advisor.

Excellence opérationnelle

La surveillance et la diagnostics sont essentielles pour garantir l’excellence opérationnelle de votre Application Gateway et des applications web ou back-ends derrière la passerelle. Vous pouvez non seulement mesurer les statistiques de performances, mais également utiliser des métriques pour résoudre rapidement les problèmes. Nous vous recommandons de passer en revue les principes de conception de l’excellence opérationnelle.

Check-list pour la conception

  • Surveiller les métriques de capacité
  • Activer diagnostics sur Application Gateway et Web Application Firewall (WAF)
  • Utiliser Azure Monitor Network Insights
  • Adapter les paramètres de délai d’attente à l’application principale
  • Surveiller les problèmes de configuration Key Vault à l’aide d’Azure Advisor
  • Configurer et surveiller les limitations de port SNAT
  • Prendre en compte les limitations de port SNAT dans votre conception

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration Application Gateway pour l’excellence opérationnelle.

Recommandation Avantage
Surveiller les métriques de capacité Utilisez ces métriques comme des indicateurs d’utilisation de la capacité approvisionnée d’Application Gateway. Nous vous recommandons vivement de configurer des alertes de capacité. Pour plus de détails, consultez Prendre en charge le trafic élevé avec Application Gateway.
Troubleshoot using metrics (Résoudre les problèmes à l’aide de mesures) D’autres métriques peuvent indiquer des problèmes au niveau d’Application Gateway ou du serveur principal. Nous vous recommandons d’évaluer les alertes suivantes :

- Nombre d’hôtes non sains
- État de la réponse (dimension 4xx et 5xx)
- État de la réponse back-end (dimension 4xx et 5xx)
- Heure de réponse du dernier octet du back-end
- Application Gateway Durée totale

Pour plus d’informations, consultez Métriques pour Application Gateway.
Activer diagnostics sur Application Gateway et Web Application Firewall (WAF) Les journaux de diagnostic vous permettent de consulter les journaux de pare-feu, les journaux de performances et les journaux d’accès. Utilisez ces journaux pour gérer et résoudre les problèmes liés aux instances Application Gateway. Pour plus d’informations, consultez Intégrité du back-end et journaux de diagnostic pour Application Gateway.
Utiliser Azure Monitor Network Insights Azure Monitor Network Insights offre une vue complète de l’intégrité et des métriques des ressources réseau, y compris d’Application Gateway. Pour plus de détails et pour connaître les fonctionnalités prises en charge pour Application Gateway, consultez Azure Monitor Network Insights.
Adapter les paramètres de délai d’attente à l’application principale Vérifiez que vous avez configuré les paramètres IdleTimeout pour qu’ils correspondent aux spécifications d’écouteur et de trafic de l’application principale. La valeur par défaut est définie sur quatre minutes et peut être configurée sur un maximum de 30. Pour plus d’informations, consultez Réinitialisation TCP de l’équilibreur de charge et délai d’inactivité.

Pour connaître les considérations relatives à la charge de travail, consultez Surveillance de l’intégrité des applications pour la fiabilité.
Surveiller les problèmes de configuration Key Vault à l’aide d’Azure Advisor Application Gateway vérifie la version renouvelée du certificat dans le Key Vault lié à tous les 4 heures. S’il est inaccessible en raison d’une configuration de Key Vault incorrecte, il consigne cette erreur et envoie une recommandation Advisor correspondante. Vous devez configurer les alertes Advisor pour rester à jour et résoudre ces problèmes immédiatement afin d’éviter tout problème lié au contrôle ou au plan de données. Pour plus d’informations, consultez Examen et résolution des erreurs de coffre de clés. Pour définir une alerte pour ce cas spécifique, utilisez le type de recommandation comme Résoudre le problème azure Key Vault pour votre Application Gateway.
Tenir compte des limitations de port SNAT dans votre conception Les limitations de port SNAT sont importantes pour les connexions principales sur Application Gateway. Différents facteurs affectent la façon dont Application Gateway atteint la limite de port SNAT. Par exemple, si le back-end est une adresse IP publique, il aura besoin de son propre port SNAT. Pour éviter les limitations de port SNAT, vous pouvez augmenter le nombre d’instances par Application Gateway, effectuer un scale-out des back-ends pour avoir plus d’adresses IP ou déplacer vos back-ends dans le même réseau virtuel et utiliser des adresses IP privées pour les back-ends.

Les requêtes par seconde (RPS) sur Application Gateway sont affectées si la limite de port SNAT est atteinte. Par exemple, si un Application Gateway atteint la limite de port SNAT, il ne sera pas en mesure d’ouvrir une nouvelle connexion au back-end et la demande échouera.

Pour plus de suggestions, consultez Principes du pilier d’excellence opérationnelle.

Azure Advisor vous aide à garantir et à améliorer la continuité de vos applications stratégiques. Passez en revue les recommandations d’Azure Advisor.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Nous vous recommandons de passer en revue les principes d’efficacité des performances.

Check-list pour la conception

  • Estimer le nombre d’instances Application Gateway
  • Définir le nombre maximal d’instances
  • Définir le nombre minimal d’instances
  • Définir la taille du sous-réseau d’Application Gateway
  • Tirer parti des fonctionnalités de Application Gateway V2 pour bénéficier d’avantages en matière de mise à l’échelle automatique et de performances

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration Application Gateway pour l’efficacité des performances.

Recommandation Avantage
Estimer le nombre d’instances Application Gateway Application Gateway v2 évolue en fonction de nombreux aspects, tels que le processeur, le débit réseau, les connexions actuelles, etc. Pour déterminer le nombre approximatif d’instances, prenez en compte les métriques suivantes :

Unités de calcul actuelles : indique l’utilisation du processeur. Une instance Application Gateway instance correspond approximativement à 10 unités de calcul.
Débit : Application Gateway instance peut servir environ 500 Mbits/s de débit. Ces données dépendent du type de charge utile.

Pour le calcul du nombre d’instances, prenez en compte l’équation ci-dessous.
Nombre approximatif d’instances

Après avoir estimé le nombre d’instances, comparez cette valeur au nombre maximal d’instances. Cela vous indique à quel point vous êtes proche de la capacité maximale disponible.
Définir le nombre minimal d’instances Pour la référence (SKU) Application Gateway v2, la mise à l’échelle automatique prend un certain temps (environ six à sept minutes) avant que l’ensemble supplémentaire d’instances soit prêt à traiter le trafic. Pendant ce temps, si de brefs pics de trafic se produisent, attendez-vous à une latence temporaire ou à une perte de trafic.

Nous vous recommandons de définir votre nombre minimal d’instances sur un niveau optimal. Après avoir estimé le nombre moyen d’instances et déterminé les tendances de mise à l’échelle automatique de votre Application Gateway, définissez le nombre minimal d’instances sur la base de vos modèles d’application. Pour plus d’informations, consultez Prendre en charge le trafic élevé avec Application Gateway.

Vérifiez les unités de calcul actuelles du mois passé. Cette mesure indique l’utilisation du processeur de la passerelle. Pour définir le nombre minimal d’instances, divisez le pic d’utilisation par 10. Par exemple, si votre moyenne d’unités de calcul actuelles au cours du mois précédent est de 50, définissez le nombre minimal de instance sur cinq.
Définir le nombre maximal d’instances Nous recommandons de fixer à 125 le nombre maximal d’instances de mise à l’échelle automatique. Assurez-vous que le sous-réseau hébergeant Application Gateway offre un nombre suffisant d’adresses IP pour prendre en charge l’augmentation d’échelle du jeu d’instances.

Le fait de définir le nombre maximal d’instances sur 125 n’a aucune incidence sur le coût, car vous êtes facturé uniquement pour la capacité utilisée.
Définir la taille du sous-réseau d’Application Gateway Application Gateway a besoin d’un sous-réseau dédié au sein d’un réseau virtuel. Le sous-réseau peut avoir plusieurs instances de la ressource Application Gateway déployée. Vous pouvez également déployer d’autres ressources Application Gateway dans ce sous-réseau, de référence (SKU) v1 ou v2.

Voici quelques éléments à prendre en compte pour définir la taille du sous-réseau :

- Application Gateway utilise une adresse IP privée par instance et une autre adresse IP privée si une adresse IP frontale privée est configurée.
- Azure réserve cinq adresses IP dans chaque sous-réseau pour une utilisation interne.
- Application Gateway (référence SKU Standard ou WAF) peut prendre en charge jusqu’à 32 instances. En considérant 32 adresses IP d’instance + 1 adresse IP frontale privée + 5 réservées pour Azure, une taille de sous-réseau minimale de /26 est recommandée. Étant donné que les références (SKU) Standard_v2 ou WAF_v2 peuvent prendre en charge jusqu’à 125 instances, en vertu du même calcul, une taille de sous-réseau de /24 est recommandée.
- Si vous souhaitez déployer des ressources de Application Gateway supplémentaires dans le même sous-réseau, tenez compte des adresses IP supplémentaires qui seront nécessaires pour leur nombre maximal de instance à la fois pour standard et standard v2.
Tirer parti des fonctionnalités de mise à l’échelle automatique et d’avantages en matière de performances La v2 applique la mise à l’échelle automatique pour s’assurer que votre Application Gateway peut monter en puissance à mesure que le trafic augmente. Par rapport à la référence (SKU) v1, la SKU v2 offre des capacités qui améliorent les performances de la charge de travail, par exemple, en matière de déchargement TLS, de temps de déploiement et de mise à jour, de redondance de zone et bien plus encore. Pour plus d’informations sur les fonctionnalités de mise à l’échelle automatique, consultez Mise à l’échelle Application Gateway v2 et WAF v2.

Si vous exécutez la passerelle Application Gateway de référence SKU v1, envisagez de migrer vers la référence SKU Application Gateway v2. Pour plus d’informations, consultez Migrer Azure Application Gateway et Web Application Firewall de la version 1 vers la version 2.

Azure Advisor vous aide à garantir et à améliorer la continuité de vos applications stratégiques. Passez en revue les recommandations d’Azure Advisor.

Recommandations Azure Advisor

Azure Advisor est un conseiller cloud personnalisé qui vous aide à suivre les bonnes pratiques pour optimiser vos déploiements Azure. Voici quelques recommandations qui peuvent vous aider à améliorer la fiabilité, la sécurité, la rentabilité, les performances et l’excellence opérationnelle de votre Application Gateway.

Fiabilité

Ressources supplémentaires

Conseils d’Azure Architecture Center

Étapes suivantes