Équilibrage de charge sur plusieurs régions avec Traffic Manager, Pare-feu Azure et Application Gateway

Cette architecture est destinée aux applications globales et accessibles sur Internet qui utilisent les protocoles HTTP(S) et non-HTTP(S). Elle comprend l’équilibrage de charge global basé sur DNS, deux types d’équilibrage de charge régional et l’appairage de réseaux virtuels global pour créer une architecture haute disponibilité en mesure de résister à une panne régionale. L’inspection du trafic est fournie par Azure Web Application Firewall (WAF) et Pare-feu Azure.

Notes sur l’architecture

L’architecture de ce document est facilement extensible à une conception de réseau virtuel hub-and-spoke, où le pare-feu Azure se trouverait dans le réseau hub, et les Application Gateway dans le réseau hub également ou dans un réseau spoke. Si la passerelle applicative est déployée dans le hub, vous souhaiterez toujours plusieurs passerelles applicatives, chacune pour un ensemble donné d’applications, afin d’éviter les conflits RBAC et pour ne pas atteindre les limites d’Application Gateway (voir Limites d’Application Gateway).

Dans un environnement Virtual WAN, les passerelles applicatives ne peuvent pas être déployées dans le hub. Elles sont donc installées dans des réseaux virtuels spoke.

L’architecture proposée opte pour une double inspection du contenu web par le biais d’un pare-feu d'applications web (basé sur Application Gateway) devant le pare-feu Azure. D’autres options existent, comme indiqué dans Pare-feu et Application Gateway pour les réseaux virtuels, mais cette option est la plus flexible et la plus complète : elle expose l’adresse IP du client dans l’en-tête HTTP X-Forwarded-For de l’application finale, fournit un chiffrement de bout en bout et empêche les clients de contourner le WAF pour accéder à l’application.

Si seules les applications web sont exposées (aucune application non HTTP(S)) et que la double inspection par WAF et Pare-feu Azure de ce trafic web n’est pas requise, Azure Front Door serait une meilleure solution d’équilibrage de charge globale que Traffic Manager. Front Door est un équilibreur de charge de couche 7 pour le contenu HTTP(S) qui fournit aussi la mise en cache, l’accélération du trafic, la terminaison SSL/TLS, la gestion des certificats, les sondes d’intégrité et autres fonctionnalités. Toutefois, Application Gateway propose une meilleure intégration à Pare-feu Azure pour une approche de protection en couches.

Flux de trafic HTTP(S) entrant

Téléchargez un fichier Visio de cette architecture.

1. Azure Traffic Manager utilise le routage DNS pour équilibrer la charge du trafic entrant dans les deux régions. Traffic Manager résout les requêtes DNS pour l’application vers les adresses IP publiques des points de terminaison Application Gateway Azure. Les points de terminaison publics des passerelles applicatives servent de points de terminaison principaux de Traffic Manager pour le trafic HTTP(S). Traffic Manager résout les requêtes DNS grâce à différentes méthodes de routage. Le navigateur se connecte directement au point de terminaison, Traffic Manager ne voit pas le trafic HTTP(S).

2. Les passerelles applicatives déployées dans les zones de disponibilité reçoivent le trafic HTTP(S) à partir du navigateur, et les pare-feu d’applications web Premium inspectent le trafic pour détecter les attaques web. Les passerelles applicatives envoient le trafic vers leur back-end, l’équilibreur de charge interne pour les machines virtuelles frontales. Pour ce flux en particulier, l’équilibreur de charge interne devant les serveurs web n’est pas strictement nécessaire, car la passerelle applicative peut effectuer cet équilibrage de charge elle-même. Toutefois, il est inclus pour la cohérence avec le flux pour les applications non HTTP(S).

3. Le trafic entre la passerelle applicative et l’équilibreur de charge interne frontend est intercepté par le pare-feu Azure Premium via des itinéraires définis par l’utilisateur appliqués sur le sous-réseau de passerelle applicative. Le pare-feu Azure Premium applique l’inspection TLS au trafic pour plus de sécurité. Le pare-feu Azure est également redondant interzone. Si le pare-feu Azure détecte une menace dans le trafic, il supprime les paquets. Sinon, une fois l’inspection réussie, le pare-feu Azure transfère le trafic à l’équilibreur de charge interne de la couche Web de destination.

4. La couche Web est la première couche de l’application à trois niveaux, elle contient l’interface utilisateur et analyse également les interactions utilisateur. L’équilibreur de charge de la couche web est réparti sur les trois zones de disponibilité et répartit le trafic vers chacune des trois machines virtuelles de la couche Web.

5. Les machines virtuelles de la couche Web sont réparties sur les trois zones de disponibilité et communiquent avec la couche Métier via un équilibreur de charge interne dédié.

6. La couche Métier traite les interactions utilisateur et détermine les étapes suivantes, et se trouve entre les couches Web et Données. L’équilibreur de charge interne de la couche Métier distribue le trafic vers les machines virtuelles de la couche Métier entre les trois zones de disponibilité. L’équilibreur de charge de la couche Métier est redondant interzone, comme l’équilibreur de charge de la couche Web.

7. Les machines virtuelles de couche Métier sont réparties entre les zones de disponibilité et acheminent le trafic vers l’écouteur de groupe de disponibilité des bases de données.

8. La couche Données stocke les données d’application, généralement dans une base de données, un stockage d’objets ou des partages de fichiers. SQL Server se trouve sur des machines virtuelles distribuées dans trois zones de disponibilité de cette architecture. Elles se trouvent dans un groupe de disponibilité et utilisent un nom de réseau distribué (DNN) pour acheminer le trafic vers l’écouteur de groupe de disponibilité pour l’équilibrage de charge.

Flux de trafic non HTTP(S) entrant

Téléchargez un fichier Visio de cette architecture.

1. Azure Traffic Manager utilise le routage DNS pour équilibrer la charge du trafic entrant dans les deux régions. Traffic Manager résout les requêtes DNS pour l’application vers les adresses IP publiques des points de terminaison Azure. Les points de terminaison publics des passerelles applicatives servent de points de terminaison principaux de Traffic Manager pour le trafic non HTTP(S). Traffic Manager résout les requêtes DNS grâce à différentes méthodes de routage. Le navigateur se connecte directement au point de terminaison, Traffic Manager ne voit pas le trafic HTTP(S).

2. La pare-feu Azure Premium est redondant interzone et inspecte le trafic entrant à des fins de sécurité. Si le pare-feu Azure détecte une menace dans le trafic, il supprime les paquets. Sinon, une fois l’inspection réussie, le pare-feu Azure transfère le trafic vers l’équilibreur de charge interne de la couche Web qui effectue la traduction d’adresses réseau de destination (DNAT) sur les paquets entrants.

3. La couche Web est la première couche de l’application à trois niveaux, elle contient l’interface utilisateur et analyse également les interactions utilisateur. L’équilibreur de charge de la couche web est réparti sur les trois zones de disponibilité et répartit le trafic vers chacune des trois machines virtuelles de la couche Web.

4. Les machines virtuelles de la couche Web sont réparties sur les trois zones de disponibilité et communiquent avec la couche Métier via un équilibreur de charge interne dédié.

5. La couche Métier traite les interactions utilisateur et détermine les étapes suivantes, et se trouve entre les couches Web et Données. L’équilibreur de charge interne de la couche Métier distribue le trafic vers les machines virtuelles de la couche Métier entre les trois zones de disponibilité. L’équilibreur de charge de la couche Métier est redondant interzone, comme l’équilibreur de charge de la couche Web.

6. Les machines virtuelles de couche Métier sont réparties entre les zones de disponibilité et acheminent le trafic vers l’écouteur de groupe de disponibilité des bases de données.

7. La couche Données stocke les données d’application, généralement dans une base de données, un stockage d’objets ou des partages de fichiers. SQL Server se trouve sur des machines virtuelles distribuées dans trois zones de disponibilité de cette architecture. Elles se trouvent dans un groupe de disponibilité et utilisent un nom de réseau distribué (DNN) pour acheminer le trafic vers l’écouteur de groupe de disponibilité pour l’équilibrage de charge.

Flux de trafic sortant (tous les protocoles)

Les flux de trafic sortant pour les mises à jour correctives des machines virtuelles ou d’autres connectivités à Internet passent des machines virtuelles de charge de travail au pare-feu Azure via des itinéraires définis par l’utilisateur. Le pare-feu Azure applique des règles de connectivité à l’aide de catégories web, ainsi que des règles de réseau et d’application pour empêcher les charges de travail d’accéder à des scénarios d’exfiltration de contenu ou de données inappropriés.

Composants

• Pare-feu Azure est un pare-feu nouvelle génération géré par Microsoft basé sur le cloud qui fournit une inspection approfondie des paquets pour les flux de trafic Nord/Sud et Est/Ouest. Il peut être réparti entre Zones de disponibilité et offre une mise à l’échelle automatique pour faire face aux changements de demandes des applications.
• Azure Application Gateway est un équilibreur de charge de couche 7 avec des fonctionnalités Web Application Firewall (WAF) facultatives. La référence SKU v2 de Application Gateway prend en charge la redondance de zone de disponibilité et elle est recommandée pour la plupart des scénarios. La passerelle applicative Application Gateway inclut une mise à l’échelle horizontale configurable afin qu’elle puisse réagir automatiquement aux changements de demandes de l’application.
• Azure Traffic Manager est un équilibreur de charge du trafic DNS global qui distribue le trafic aux services dans toutes les régions Azure du monde, tout en offrant réactivité et haute disponibilité. Pour plus d’informations, consultez la section Configuration de Traffic Manager.
• Azure Load Balancer est un équilibreur de charge de couche 4. Un équilibreur de charge redondant interzone distribue toujours le trafic avec un échec de zone de disponibilité dans les zones restantes.
• Azure DDoS Protection offre des fonctionnalités améliorées de protection contre les attaques par déni de service distribué (DDoS).
• Azure DNS est un service d’hébergement pour les domaines DNS. Il offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. En hébergeant vos domaines dans Azure, vous pouvez gérer vos enregistrements DNS avec les mêmes informations d’identification, les mêmes API, les mêmes outils et la même facturation que vos autres services Azure.
• Les zones DNS privées Azure sont une fonctionnalité d’Azure DNS. Azure DNS Private Zones fournit la résolution de noms au sein d’un réseau virtuel et entre des réseaux virtuels. Les enregistrements contenus dans une zone DNS privée ne peuvent pas être résolus à partir d’Internet. La résolution des enregistrements DNS sur une zone DNS privée fonctionne uniquement à partir de réseaux virtuels liés à cette zone.
• Les machines virtuelles Azure sont des ressources de calcul évolutives à la demande qui vous donnent la flexibilité de la virtualisation, mais éliminent les exigences de maintenance du matériel physique. Le système d’exploitation peut être Windows ou Linux. Certains composants des applications peuvent être remplacés par des ressources Azure de plateforme en tant que service (par exemple, la base de données et le niveau frontal), mais l’architecture ne changerait pas considérablement si vous utilisiez Private Link et l’intégration au réseau virtuel App Service pour intégrer ces services PaaS au réseau virtuel.
• Microsoft Azure Virtual Machine Scale Sets est une mise à l’échelle de machine virtuelle automatisée avec équilibrage de charge qui simplifie la gestion de vos applications et augmente la disponibilité.
• SQL Server sur les machines virtuelles permet d’utiliser des versions complètes de SQL Server dans le cloud sans gérer de matériel local.
• Le réseau virtuel Azure est un réseau privé sécurisé dans le cloud. Il connecte des machines virtuelles les unes aux autres, à Internet et à des réseaux intersites.
• Les itinéraires définis par l’utilisateur sont un mécanisme permettant de remplacer le routage par défaut dans les réseaux virtuels. Dans ce scénario, ils sont utilisés pour forcer le trafic entrant et sortant à traverser le pare-feu Azure.

Détails de la solution

Traffic Manager - Nous avons configuré Traffic Manager pour utiliser le routage basé sur les performances. Ce service achemine le trafic vers le point de terminaison qui présente la latence la plus faible pour l’utilisateur. Traffic Manager ajuste automatiquement son algorithme d’équilibrage de charge au fur et à mesure que la latence du point de terminaison change. Traffic Manager fournit un basculement automatique en cas de panne régionale. Il utilise le routage prioritaire et des contrôles d’intégrité réguliers pour déterminer comment acheminer le trafic.

Zones de disponibilité - L’architecture utilise trois zones de disponibilité. Les zones créent une architecture à haute disponibilité pour les passerelles applicatives, les équilibreurs de charge internes et les machines virtuelles de chaque région. En cas de panne de zone, les zones de disponibilité restantes dans cette région prendraient en charge la charge, ce qui ne déclencherait pas de basculement régional.

Application Gateway – Si Traffic Manager fournit l’équilibrage de charge régional basé sur DNS, Application Gateway, quant à lui, offre de nombreuses fonctionnalités similaires à Azure Front Door, mais au niveau régional, comme :

• Pare-feu d’applications web (WAF)
• Terminaison TLS (Transport Layer Security)
• Routage basé sur le chemin
• Affinité de session basée sur les cookies

Pare-feu Azure – Pare-feu Azure Premium offre une sécurité réseau pour les applications génériques (trafic web et non web), inspectant trois types de flux dans cette architecture :

• Les flux HTTP(S) entrants de la passerelle applicative sont protégés par l’inspection TLS de Pare-feu Azure Premium.
• Les flux entrants non HTTP(S) provenant de l’Internet public sont inspectés avec le reste des fonctionnalités Premium de Pare-feu Azure.
• Les flux sortants d’Azure Machines Virtuelles sont inspectés par Pare-feu Azure pour empêcher l’exfiltration des données et l’accès aux sites et applications interdits.

Appairage de réseaux virtuels – Nous appelons l’appairage de réseaux virtuels entre les régions « appairage de réseaux virtuels global ». L’appairage de réseaux virtuels global fournit une réplication de données à faible latence et à bande passante élevée entre les régions. Vous pouvez transférer des données dans des abonnements Azure, des locataires Microsoft Entra et des modèles de déploiement avec ce Peering mondial. Dans l’environnement hub-spoke, des appairages de réseaux virtuels existent entre les réseaux hub-and-spoke.

Recommandations

Les recommandations suivantes sont conformes aux piliers du Framework WAF (Well-Architected Framework). Les piliers WAF sont des principes directeurs qui garantissent la qualité des charges de travail cloud. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

Régions - Utilisez au moins deux régions Azure pour la haute disponibilité. Vous pouvez déployer votre application sur plusieurs régions Azure dans des configurations actives/passives ou actives/actives. Utiliser plusieurs régions permet également éviter les temps d’arrêt de l’application si un sous-système de l’application échoue.

• Traffic Manager bascule automatiquement vers la région secondaire si la région primaire échoue.
• Pour choisir les meilleures régions selon vos besoins, vous devez prendre en compte des considérations techniques et réglementaires, ainsi que la prise en charge des zones de disponibilité.

Paires de régions - Utilisez des paires de régions pour une meilleure résilience. Vérifiez que les deux paires de régions prennent en charge tous les services Azure nécessaires à votre application (consultez Services par région). Voici deux avantages des paires de régions :

• Les mises à jour Azure planifiées sont déployées vers les régions jumelées une par une pour réduire les temps d’arrêt et les risques d’interruption de l’application.
• Les données continuent de résider dans la même zone géographique que la région avec laquelle elle est jumelée (sauf Brésil Sud) pour répondre aux exigences en termes de fiscalité et de législation.

Zones de disponibilité – Utilisez plusieurs zones de disponibilité pour prendre en charge votre passerelle applicative, Pare-feu Azure, l’équilibreur de charge Azure et vos couches Application quand elles sont disponibles.

Mise à l’échelle automatique et instances de la passerelle applicative – Configurez la passerelle applicative avec un minimum de deux instances pour éviter les temps d’arrêt, ainsi que la mise à l’échelle automatique pour fournir une adaptation dynamique aux changements de demandes de capacité des applications.

Pour plus d'informations, consultez les pages suivantes :

• Régions et zones de disponibilité dans Azure
• Continuité et reprise d’activité  (BCDR): régions associées Azure

Routage global

Méthode de routage global – Utilisez la méthode de routage du trafic qui convient le mieux aux besoins de vos clients. Traffic Manager prend en charge plusieurs méthodes de routage du trafic pour acheminer de manière déterministe le trafic vers les différents points de terminaison de service.

Configuration imbriquée - utilisez Traffic Manager dans une configuration imbriquée si vous avez besoin d’un contrôle plus granulaire pour choisir un basculement préféré au sein d’une région.

Pour plus d'informations, consultez les pages suivantes :

• Configurer la méthode de routage en fonction des performances
• Méthodes de routage de Traffic Manager

Vue du trafic global

Utilisez la fonctionnalité Vue du trafic dans Traffic Manager pour afficher les modèles de trafic et les métriques de latence. La Vue du trafic permet de planifier l’expansion de votre empreinte vers de nouvelles régions Azure.

Consultez Traffic Manager Vue du trafic pour plus d’informations.

Application Gateway

Utilisez la référence SKU Application Gateway v2 pour la résilience automatisée prête à l’emploi.

• La référence SKU v2 d’Application Gateway garantit automatiquement que les nouvelles instances sont générées sur les domaines d’erreur et les domaines de mise à jour. Si vous optez pour la redondance de zone, les instances les plus récentes sont également générées sur les zones de disponibilité pour offrir une tolérance de panne.

• La référence SKU v1 d’Application Gateway prend en charge les scénarios de haute disponibilité lorsque vous avez déployé deux instances ou plus. Azure distribue ces instances dans différents domaines de mise à jour et d’erreur pour garantir qu’elles n’échouent pas simultanément. La référence SKU v1 prend en charge la scalabilité en ajoutant plusieurs instances de la même passerelle pour partager la charge.

La passerelle applicative doit approuver le certificat d’autorité de certification de Pare-feu Azure.

Pare-feu Azure

Le niveau Premium de Pare-feu Azure est requis dans cette conception pour fournir une inspection TLS. Pare-feu Azure intercepte les sessions TLS entre Application Gateway et les machines virtuelles de la couche Web générant leurs propres certificats, et inspecte les flux de trafic sortant des réseaux virtuels vers l’Internet public. Pour plus d’informations sur cette conception, consultez Réseau Confiance Zéro pour les applications web avec Pare-feu Azure et Application Gateway.

Recommandations relatives aux sondes d’intégrité

Voici quelques recommandations pour les sondes d’intégrité dans Traffic Manager, Application Gateway et Load Balancer.

Traffic Manager

État d’intégrité des points de terminaison - créez un point de terminaison qui rend compte de l’intégrité globale de l’application. Traffic Manager utilise une sonde HTTP(S) pour superviser la disponibilité de chaque région. La sonde vérifie la présence d’une réponse HTTP 200 pour un chemin d’URL spécifié. Utilisez le point de terminaison que vous avez créé pour la sonde d’intégrité. Dans le cas contraire, la sonde risque de signaler un point de terminaison intègre alors que des parties critiques de l’application sont défaillantes.

Pour plus d’informations, consultez Modèle Supervision de point de terminaison d’intégrité.

Délai de basculement - Traffic Manager présente un délai de basculement. Les facteurs suivants déterminent la durée du retard :

• Intervalles de détection : fréquence à laquelle la sonde vérifie l’intégrité du point de terminaison.
• Nombre d’échecs tolérés : nombre d’échecs tolérés par la sonde avant de marquer le point de terminaison comme étant non sain.
• Délai d’expiration de la sonde : délai avant que Traffic Manager considère le point de terminaison comme étant non sain.
• Durée de vie (TTL) : les serveurs DNS (Domain Name Service) doivent mettre à jour les enregistrements DNS mis en cache pour l’adresse IP. Le temps nécessaire dépend de la durée de vie DNS. La valeur TTL par défaut est de 300 secondes (5 minutes), mais vous pouvez configurer cette valeur quand vous créez le profil Traffic Manager.

Pour plus d’informations, consultez Supervision Traffic Manager.

Application Gateway et Load Balancer

Familiarisez-vous avec les stratégies de sonde d’intégrité d’Application Gateway et de l’équilibreur de charge pour vous assurer que vous comprenez l’intégrité de vos machines virtuelles. Voici une brève vue d’ensemble :

• Application Gateway utilise toujours une sonde HTTP.

• Load Balancer peut évaluer le protocole HTTP ou TCP. Utilisez une sonde HTTP si une machine virtuelle exécute un serveur HTTP. Utilisez TCP dans tous les autres cas.

• Les sondes HTTP envoient une requête HTTP GET à un chemin spécifié et écoutent une réponse HTTP 200. Ce chemin peut être un chemin racine (« / ») ou d’un point de terminaison de surveillance de l’intégrité qui implémente une logique personnalisée afin de vérifier l’intégrité de l’application.

• Le point de terminaison doit autoriser les requêtes HTTP anonymes. Si une sonde ne peut pas atteindre une instance avant le délai d’expiration, Application Gateway ou Load Balancer cesse d’envoyer le trafic vers cette machine virtuelle. La sonde poursuit les vérifications et renvoie la machine virtuelle au pool back-end si elle redevient disponible.

Pour plus d'informations, consultez les pages suivantes :

• Sondes d'intégrité Load Balancer
• Vue d'ensemble de l'analyse d'intégrité Application Gateway
• Modèle Supervision de point de terminaison d’intégrité

Excellence opérationnelle

Groupes de ressources -  Utilisez des groupes de ressources pour gérer les ressources Azure par durée de vie, propriétaire et autres caractéristiques.

Peering de réseaux virtuels - Utilisez le peering de réseaux virtuels pour connecter de manière fluide deux réseaux virtuels ou plus dans Azure. Les réseaux virtuels apparaissent comme un seul réseau à des fins de connectivité. Le trafic entre les machines virtuelles des réseaux virtuels appairés utilise l'infrastructure principale de Microsoft. Assurez-vous que l’espace d’adressage des réseaux virtuels ne se chevauche pas.

Réseau virtuel et sous-réseaux - créez un sous-réseau distinct pour chaque niveau de votre sous-réseau. Vous devez déployer des machines virtuelles et des ressources, comme Application Gateway et Load Balancer, dans un réseau virtuel avec des sous-réseaux.

Sécurité

Web Application Firewall – Les fonctionnalités WAF d’Azure Application Gateway détectent et empêchent les attaques au niveau HTTP, telles que l’injection SQL (SQLi) ou le script entre sites (CSS).

Pare-feu nouvelle génération – Pare-feu Azure Premium fournit une couche de défense supplémentaire en inspectant le contenu pour les attaques non web, telles que les fichiers malveillants chargés via HTTP(S) ou tout autre protocole.

Chiffrement de bout en bout – Le trafic est chiffré à tout moment lors de la traversée du réseau Azure. Application Gateway et Pare-feu Azure chiffrent le trafic avant de l’envoyer au système principal correspondant.

Déni de service distribué (DDoS) : utilisez Azure DDoS Network Protection pour bénéficier d’une protection DDoS supérieure à la protection de base fournie par Azure.

Groupes de sécurité réseau (NSG) – Utilisez des NSG pour limiter le trafic au sein du réseau virtuel. Dans l’architecture à trois niveaux illustrée ici par exemple, la couche Données accepte uniquement le trafic en provenance de la couche Métier, et non depuis le front-end web. Uniquement le niveau Business peut communiquer directement avec le niveau base de données. Pour appliquer cette règle, le niveau base de données doit bloquer tout le trafic entrant, à l’exception du sous-réseau de niveau Business.

1. Autorisez le trafic entrant à partir du sous-réseau du niveau Business.
2. Autorisez le trafic entrant à partir du sous-réseau du niveau base de données. Cette règle autorise la communication entre les machines virtuelles de base de données. Le basculement et la réplication de la base de données ont besoin de cette règle.
3. Refusez tout le trafic entrant du réseau virtuel, à l’aide de la balise VirtualNetwork dans la règle, pour remplacer l’instruction d’autorisation incluse dans les règles de groupe de sécurité réseau par défaut.

Créez la règle 3 avec une priorité inférieure (nombre plus élevé) que les premières règles.

Vous pouvez utiliser des étiquettes de service pour définir des contrôles d’accès réseau sur des groupes de sécurité réseau ou sur le Pare-feu Azure.

Pour plus d’informations, consultez Configuration de l’infrastructure Application Gateway.

Optimisation des coûts

Pour plus d'informations, consultez les pages suivantes :

• Tarification de l’équilibrage de charge
• Tarification du réseau virtuel
• Tarification d’Application Gateway
• Choisir la référence SKU de Pare-feu Azure appropriée répondant à vos besoins
• Tarification de Traffic Manager
• Calculatrice de prix

Efficacité des performances

Groupes de machines virtuelles identiques – Utilisez des groupes de machines virtuelles identiques pour automatiser la scalabilité de vos machines virtuelles. Les groupes de machines virtuelles identiques sont disponibles sur toutes les tailles de machines virtuelles Windows et Linux. Seule la consommation des machines virtuelles qui sont déployées et des ressources d’infrastructure sous-jacentes est facturée. Aucun coût supplémentaire n’est facturé. Les avantages du service Virtual Machine Scale Sets sont les suivants :

• Créer et gérer facilement plusieurs machines virtuelles
• Haute disponibilité et résilience des applications
• Mise à l’échelle automatisée à mesure que la demande de ressources change

Pour plus d’informations, consultez Groupes de machines virtuelles identiques.

Étapes suivantes

Pour obtenir des architectures de référence supplémentaires utilisant les mêmes technologies, consultez :

• Application multiniveau multirégion
• Base de référence AKS pour les clusters multirégions