Share via

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. Les conseils sont basés sur les cinq piliers de l’excellence architecturale :

Nous partons du principe que vous avez une connaissance opérationnelle d’Azure Application Gateway et que vous connaissez bien les fonctionnalités de référence SKU v2. Pour plus d’informations, consultez les fonctionnalités d’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 le pare-feu d’applications web (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 votre configuration 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é place 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 la détection d’une panne.
- La définition d’un seuil non sain faible peut signifier que des défaillances temporaires courtes peuvent prendre un back-end.
- La définition d’un seuil élevé peut prendre plus de temps pour retirer la rotation d’un back-end.
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 autre base de données (réplica). Lorsqu’une telle dépendance échoue, 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 forcer à implémenter des règles spécifiquement sur Application Gateway. Par exemple, si les règles ModSec CRS 2.2.9, CRS 3.0 ou CRS 3.1 sont requises, ces règles peuvent uniquement être implémentées 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 permet de garantir et d’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 de toute 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 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 principal, vérifiez que le certificat de 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
  • Respecter 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 modifications de capacité d’Application Gateway lors de l’activation du WAF

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration 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 qui vont à différents back-ends doivent s’authentifier à nouveau auprès de chaque back-end.
- Meilleure utilisation des serveurs back-end, car ils n’ont pas besoin d’effectuer le traitement TLS
- Routage intelligent en accédant au contenu de la requête.
- 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 peut être intégré à 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 principal, vérifiez que le certificat de 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 case activée si le certificat a été émis par une autorité de certification approuvée, et ainsi de suite, jusqu’à ce qu’un certificat d’autorité de certification approuvé soit trouvé. 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.
Respecter 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 le sous-réseau Application Gateway, mais certaines restrictions sont présentes. 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 modifications de capacité d’Application Gateway lors de l’activation du WAF Lorsque waf est activé, chaque requête doit être mise en mémoire tampon par Application Gateway jusqu’à ce qu’elle arrive complètement, case activée si la requête correspond à une violation de règle dans son ensemble de règles de base, puis transfère le paquet aux instances principales. Lorsqu’il existe des chargements de fichiers volumineux (30 Mo+ en taille), il peut entraîner une latence significative. É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 permet de garantir et d’améliorer la continuité de vos applications critiques pour l’entreprise. Passez en revue les recommandations d’Azure Advisor.

Définitions de stratégies

  • Le pare-feu d’applications web (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.
  • Le pare-feu d’applications web (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 les 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 consulter les principes de conception de l’optimisation des coûts.

Check-list pour la conception

  • Familiarisez-vous avec la tarification d’Application Gateway
  • Examiner les ressources sous-utilisées
  • Arrêter les instances Application Gateway qui ne sont pas en cours d’utilisation
  • 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 la tarification d’Application Gateway Pour accéder aux informations sur la tarification d’Application Gateway, consultez Compréhension de la tarification d’Azure Application Gateway et du pare-feu d’applications web. 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 des instances Application Gateway avec des pools principaux vides pour éviter les 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 qu’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 clés 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 plus de suggestions, consultez Principes du pilier d’optimisation des coûts.

Azure Advisor vous permet de garantir et d’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 les diagnostics sont essentiels pour garantir l’excellence opérationnelle de votre passerelle 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 et corriger 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 les diagnostics sur Application Gateway et le pare-feu d’applications web (WAF)
  • Utiliser Azure Monitor Network Insights
  • Adapter les paramètres de délai d’attente à l’application principale
  • Surveiller les problèmes de configuration de Key Vault à l’aide d’Azure Advisor
  • Configurer et surveiller les limitations du port SNAT
  • Tenez compte des 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 sain
- État de la réponse (dimension 4xx et 5xx)
- État de la réponse du serveur principal (dimension 4xx et 5xx)
- Heure 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.
Activer les diagnostics sur Application Gateway et le pare-feu d’applications web (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é de l’application pour la fiabilité.
Surveiller les problèmes de configuration de Key Vault à l’aide d’Azure Advisor Application Gateway case activée pour la version renouvelée du certificat dans le coffre de clés lié à chaque intervalle de 4 heures. S’il est inaccessible en raison d’une configuration Key Vault incorrecte, il enregistre 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 pour éviter tout problème lié au plan de contrôle ou 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 pour résoudre le problème Azure Key Vault pour votre instance Application Gateway.
Tenez 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 serveur principal est une adresse IP publique, il nécessite 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 une passerelle Application Gateway atteint la limite de port SNAT, elle ne pourra pas ouvrir une nouvelle connexion au serveur principal et la requête échouera.

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

Azure Advisor vous permet de garantir et d’améliorer la continuité de vos applications critiques pour l’entreprise. 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 d’Application Gateway V2 pour la mise à l’échelle automatique et les avantages en matière de performances

Recommandations

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

Recommandation Avantage
Estimer le nombre d’instances Application Gateway Application Gateway v2 est mis à l’échelle en fonction de nombreux aspects, tels que l’UC, 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 : l’instance Application Gateway 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 vos unités de calcul actuelles moyennes au cours du mois précédent sont 50, définissez le nombre minimal d’instances 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 Application Gateway supplémentaires dans le même sous-réseau, tenez compte des adresses IP supplémentaires requises pour leur nombre maximal d’instances pour les deux, Standard et Standard v2.
Tirer parti des fonctionnalités pour la mise à l’échelle automatique et les 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 d’Application Gateway v2 et WAF v2.

Si vous exécutez la référence SKU v1 Application Gateway, envisagez de migrer vers la référence SKU Application Gateway v2. Pour plus d’informations, consultez Migrer Azure Application Gateway et le pare-feu d’applications web de v1 vers v2.

Azure Advisor vous permet de garantir et d’améliorer la continuité de vos applications critiques pour l’entreprise. 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é, l’efficacité, les performances et l’excellence opérationnelle de votre application Gateway.

Fiabilité

Ressources supplémentaires

Conseils du Centre d’architecture Azure

Étapes suivantes