Architecture de base des Machines Virtuelles Azure

Cet article fournit une architecture de référence fondamentale pour une charge de travail déployée sur des machines virtuelles Azure.

L’exemple de charge de travail envisagée par cette architecture est une application Web à plusieurs niveaux accessible depuis Internet, déployée sur des ensembles distincts de machines virtuelles (VM). Les VM sont provisionnées dans le cadre des déploiements des ensembles d’échelle de machine virtuelle Azure. Cette architecture peut être utilisée pour les scénarios suivants :

• Applications privées Ces applications comprennent des applications internes d’entreprise ou des solutions commerciales prêtes à l’emploi.
• Applications publiques Ces applications sont des applications accessibles depuis Internet. Cette architecture n’est pas adaptée aux calculs haute performance, aux charges de travail critiques, aux applications fortement impactées par la latence ou à d’autres cas d’utilisation spécialisés.

L’objectif principal de cette architecture n’est pas l’application elle-même. Au contraire, cet article propose des conseils pour configurer et déployer les composants d’infrastructure avec lesquels l’application interagit. Ces composants incluent le calcul, le stockage, le réseau et les composants de surveillance.

Cette architecture sert de point de départ pour une charge de travail hébergée en tant qu’infrastructure IaaS. La couche de données est délibérément exclue de ces conseils pour maintenir la focalisation sur l’infrastructure de calcul.

Disposition de l’article

Architecture	Décision de conception	Approche Well-Architected Framework
▪ Diagramme d’architecture ▪ Ressources de charge de travail ▪ Ressources de support ▪ Flux d’utilisateurs	▪ Choix de conception de VM ▪ Disques ▪ Mise en réseau ▪ Monitoring ▪ Gestion des mises à jour	▪ Fiabilité ▪ Sécurité ▪ Optimisation des coûts

Architecture

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

Pour plus d’informations sur ces ressources, veuillez consulter la documentation produit Azure répertoriée dans les ressources connexes.

Composants

Cette architecture comprend plusieurs services Azure pour les ressources de charge de travail et les ressources de support de la charge de travail. Les services pour chacun et leurs rôles sont décrits dans les sections suivantes.

Ressources de charge de travail

• Les Machines Virtuelles Azure servent de ressource de calcul pour l’application et sont réparties sur les zones de disponibilité. Une combinaison de VM Windows et Linux est utilisée pour une illustration plus complète.

  Les Azure Virtual Machine Scale Sets en mode d’orchestration flexible sont utilisés pour provisionner et gérer les VM.

  L’application en exemple peut être représentée sur deux niveaux, chacun nécessitant sa propre puissance de calcul.

  • Le front-end exécute le serveur Web et reçoit les demandes des utilisateurs.
  • Le back-end exécute un autre serveur Web agissant comme une API Web qui expose un seul point de terminaison où la logique métier est exécutée.

  Les VM du front-end ont des disques de données (Premium_LRS) attachés, qui pourraient être utilisés pour déployer une application sans état. Les VM du back-end stockent des données sur des disques locaux Premium_ZRS dans le cadre de leur fonctionnement. Cette disposition peut être étendue pour inclure une couche de base de données pour stocker les données du front-end et du back-end. Cette couche est en dehors du champ d’application de cette architecture.

• Azure Virtual Network fournit un réseau privé pour toutes les ressources de charge de travail. Le réseau est segmenté en sous-réseaux, qui servent de limites d’isolation.

• Azure Application Gateway est le point d’entrée unique qui route les demandes vers les serveurs front-end. Le SKU sélectionné inclut un pare-feu d’application Web Azure intégré (WAF) pour une sécurité accrue.

• Le Azure Load Balancer interne route le trafic depuis le niveau front-end vers les serveurs back-end.

• Le SKU Standard Azure Load Balancer fournit un accès Internet sortant aux VM à l’aide de trois adresses IP publiques.

• Azure Key Vault stocke les certificats utilisés pour la sécurité de la communication de bout en bout (TLS). Il peut également être utilisé pour les secrets de l’application.

Ressources de support de charge de travail

• Azure Bastion fournit un accès opérationnel aux VM via des protocoles sécurisés.

• Application Insights collecte les journaux et les métriques de l’application. La collecte des journaux n’est pas démontrée dans l’implémentation car l’application n’est pas au centre de cette architecture.

• Log Analytics est le récepteur de données de surveillance qui collecte les journaux et les métriques des ressources Azure et d’Application Insights. Un compte de stockage est provisionné dans le cadre de l’espace de travail.

Flux d’utilisateurs

Il existe deux types d’utilisateurs qui interagissent avec les ressources de charge de travail : l’utilisateur de la charge de travail et l’opérateur. Les flux pour ces utilisateurs sont indiqués dans le diagramme d’architecture précédent.

Utilisateur de charge de travail

1. L’utilisateur accède au site Web en utilisant l’adresse IP publique exposée d’Application Gateway.

2. Application Gateway reçoit le trafic HTTPS, déchiffre les données à l’aide d’un certificat externe pour une inspection WAF, puis les ré-encrypte à l’aide du certificat générique interne pour le transport vers le front-end.

3. Application Gateway équilibre le trafic entre les VM du front-end et transmet la demande à une VM du front-end.

4. La VM du front-end sélectionnée communique avec une VM du back-end en utilisant l’adresse IP privée du répartiteur de charge, et non l’adresse IP d’une VM individuelle. Cette communication est également chiffrée à l’aide du certificat générique interne.

5. La VM du back-end déchiffre la demande à l’aide du certificat interne. Après le traitement de la demande du back-end, il renvoie le résultat au front-end, qui renvoie enfin le résultat à la passerelle d’application, qui le renvoie finalement à l’utilisateur.

Opérateur

Les VM dans cette architecture peuvent nécessiter un accès direct par les opérateurs, mais nous recommandons de minimiser l’accès à distance grâce à l’automatisation et de surveiller l’accès. L’accès peut être nécessaire pour des situations de réparation, de dépannage ou dans le cadre d’un processus de déploiement automatisé. Cette architecture n’a pas d’adresses IP publiques pour l’accès au plan de contrôle. Azure Bastion agit comme une passerelle sans serveur, permettant aux opérations d’accéder aux VM via SSH ou RDP. Cette configuration garantit une gestion d’accès sécurisée et efficace.

1. L’opérateur se connecte au portail Azure ou à l’interface de ligne de commande Azure.
2. L’opérateur accède au service Azure Bastion et se connecte à distance à la VM souhaitée.

Choix de conception de VM

Lors de la sélection des SKUs, il est important d’avoir des attentes concernant les performances de base. Plusieurs caractéristiques influencent le processus de prise de décision, notamment :

• CPU, mémoire et opérations d’entrée/sortie de disque par seconde (IOPS).
• Architecture des processeurs.
• Taille de l’image du système d’exploitation (SE).

Par exemple, si vous migrez une charge de travail depuis un environnement sur site nécessitant des machines Intel, choisissez les SKUs de VM qui prennent en charge les processeurs Intel.

Pour plus d’informations sur les SKUs de VM pris en charge, veuillez consulter les tailles des machines virtuelles dans Azure.

Amorçage

Les VM ont souvent besoin d’être initialisées, c’est-à-dire préparées et configurées pour exécuter l’application. Les tâches courantes d’initialisation comprennent l’installation de certificats, la configuration de l’accès à distance, l’installation de packages, la configuration et le durcissement de la configuration du SE, et le formatage et le montage des disques de données. Il est important d’automatiser autant que possible le processus d’initialisation, afin que l’application puisse démarrer sur la VM sans délai ni intervention manuelle. Voici les recommandations pour l’automatisation :

• Extensions de machine virtuelle. Ces extensions sont des objets du Gestionnaire de ressources Azure gérés via votre déploiement d’infrastructure en tant que code (IaC). De cette façon, tout échec est signalé comme un déploiement en échec sur lequel vous pouvez agir. S’il n’existe pas d’extension pour vos besoins d’initialisation, créez des scripts personnalisés. Il est recommandé d’exécuter les scripts via l’extension Azure Custom Script.

  Voici quelques autres extensions qui peuvent être utilisées pour installer automatiquement ou configurer des fonctionnalités sur les VM.

  • Azure Monitor Agent (AMA) collecte des données de surveillance à partir du système d’exploitation invité et les transmet à Azure Monitor.
  • L’extension Azure Custom Script (Windows, Linux) Version 2 télécharge et exécute des scripts sur des machines virtuelles Azure (VM). Cette extension est utile pour automatiser la configuration post-déploiement, l’installation de logiciels ou toute autre tâche de configuration ou de gestion.
  • L’extension de machine virtuelle Azure Key Vault (Windows, Linux) permet la mise à jour automatique des certificats stockés dans un Key Vault en détectant les modifications et en installant les certificats correspondants.
  • L’extension Application Health avec Virtual Machine Scale Sets est importante lorsque les ensembles d’échelle de machine virtuelle Azure effectuent des mises à jour automatiques progressives. Azure repose sur le monitoring de l’intégrité des instances individuelles pour effectuer les mises à jour. Vous pouvez également utiliser l’extension pour surveiller la santé de l’application de chaque instance dans votre ensemble d’échelle et effectuer des réparations d’instance à l’aide des réparations automatiques d’instance.
  • Microsoft Entra ID et OpenSSH (Windows, Linux) s’intègrent à l’authentification Microsoft Entra. Vous pouvez désormais utiliser Microsoft Entra ID comme plateforme d’authentification principale et autorité de certification pour établir une connexion SSH à une machine virtuelle Linux en tirant parti de Microsoft Entra ID et de l’authentification basée sur un certificat OpenSSH. Cette fonctionnalité vous permet de gérer l’accès aux VM avec le contrôle d’accès basé sur les rôles Azure (RBAC) et les politiques d’accès conditionnel.

• Configuration basée sur un agent. Les VM Linux peuvent utiliser un State Configuration natif léger souhaité disponible via cloud-init sur diverses images de VM fournies par Azure. La configuration est spécifiée et versionnée avec vos artefacts IaC. Apporter votre propre solution de gestion de la configuration est une autre option. La plupart des solutions suivent une approche déclarative en premier lieu pour l’initialisation, mais prennent en charge les scripts personnalisés pour plus de flexibilité. Parmi les choix populaires, on retrouve Desired State Configuration pour Windows, Desired State Configuration pour Linux, Ansible, Chef, Puppet, etc. Toutes ces solutions de configuration peuvent être associées à des extensions de VM pour une expérience optimale.

Dans l’implémentation de référence, toute l’initialisation est effectuée via des extensions de VM et des scripts personnalisés, y compris un script personnalisé pour automatiser le formatage et le montage des disques de données.

Veuillez consulter Well-Architected Framework : RE:02 - Recommandations pour la conception de l’automatisation.

Connectivité des VM

Pour permettre la communication privée entre une VM et d’autres dispositifs dans un réseau virtuel particulier, la carte d’interface réseau (NIC) de la VM est connectée à l’un des sous-réseaux du réseau virtuel. Si vous avez besoin de plusieurs NIC pour votre VM, sachez qu’un nombre maximum de NIC est défini pour chaque taille de VM.

Si la charge de travail nécessite une communication à faible latence entre les VM dans le réseau virtuel, envisagez l’utilisation de la mise en réseau accélérée, prise en charge par les NIC VM Azure. Pour plus d’informations, veuillez consulter les avantages de la mise en réseau accélérée.

Ensembles d’échelle de machine virtuelle avec orchestration flexible

Les VM sont approvisionnées dans le cadre des ensembles d’échelle de machine virtuelle avec une orchestration flexible. Les ensembles d’échelle de machine virtuelle sont des regroupements logiques de VM utilisés pour répondre aux besoins de l’entreprise. Les types de VM dans un regroupement peuvent être identiques ou différents. Ils vous permettent de gérer le cycle de vie des machines, des interfaces réseau et des disques à l’aide des API et des commandes standard des VM Azure.

Le mode d’orchestration flexible facilite les opérations à grande échelle et aide à prendre des décisions de mise à l’échelle granulaire.

La configuration des domaines de défaillance est nécessaire pour limiter l’effet des pannes matérielles, des pannes de réseau ou des interruptions de courant. Avec les ensembles d’échelle, Azure répartit uniformément les instances entre les domaines de défaillance pour résister à un seul problème matériel ou d’infrastructure.

Nous recommandons de décharger l’allocation des domaines de défaillance vers Azure pour une répartition maximale des instances, améliorant la résilience et la disponibilité.

Disques

Pour exécuter le système d’exploitation et les composants de l’application, des disques de stockage sont attachés à la VM. Envisagez d’utiliser des disques éphémères pour le système d’exploitation et des disques gérés pour le stockage de données.

Azure propose une gamme d’options en termes de performances, de polyvalence et de coûts. Commencez par le Premium SSD pour la plupart des charges de travail de production. Votre choix dépend de la SKU de la VM. Les SKUs prenant en charge Premium SSD contiennent un s dans le nom de la ressource, par exemple Dsv4 mais pas Dv4.

Pour plus d’informations au sujet des options de disque avec des métriques telles que la capacité, les IOPS et le débit, veuillez consulter la comparaison des types de disques.

Tenez compte des caractéristiques du disque et des attentes en matière de performances lors de la sélection d’un disque.

• Limitations de la SKU de VM. Les disques fonctionnent au sein de la VM à laquelle ils sont attachés, avec des limites d’IOPS et de débit. Assurez-vous que le disque ne limite pas les limites de la VM et vice versa. Sélectionnez la taille du disque, les performances et les capacités de la VM (cœurs, CPU, mémoire) qui permettent d’exécuter de manière optimale le composant de l’application. Évitez de sur-approvisionner car cela impacte les coûts.

• Modifications de configuration. Vous pouvez modifier certaines configurations de performance et de capacité des disques pendant que la VM est en cours d’exécution. Cependant, de nombreux changements peuvent nécessiter de réapprovisionner et une reconstruction du contenu du disque, ce qui affecte la disponibilité de la charge de travail. Par conséquent, planifiez soigneusement la sélection des disques et de la SKU de la VM pour minimiser l’impact sur la disponibilité et les travaux de révision.

• Disques OS éphémères. Approvisionnez les disques OS en tant que disques éphémères. Utilisez des disques managés uniquement si les fichiers OS doivent être persistants. Évitez d’utiliser des disques éphémères pour stocker des composants d’application et des données.

  La capacité des disques OS éphémères dépend de la SKU de la VM choisie. Assurez-vous que la taille du disque OS est inférieure à la taille du cache ou du disque temporaire disponible de la SKU. Vous pouvez utiliser l’espace restant pour le stockage temporaire.

• Performances des disques. Il est courant de pré-approvisionner l’espace disque en fonction de la charge maximale, mais cela peut entraîner une sous-utilisation des ressources car la plupart des charges de travail ne soutiennent pas une charge maximale.

  Surveillez les modèles d’utilisation de votre charge de travail, en notant les pics ou les opérations de lecture élevées soutenues, et prenez en compte ces modèles dans la sélection de la VM et de la SKU de disque managé.

  Vous pouvez ajuster les performances à la demande en modifiant les niveaux de performance ou en utilisant les fonctionnalités de « bursting » proposées dans certains SKUs de disques managés.

  Bien que le sur-approvisionnement réduise le besoin de « bursting », cela peut également avoir pour conséquence des capacités inutilisées qui vous sont facturées. Idéalement, combinez les deux fonctionnalités pour des résultats optimaux.

• Ajuster la mise en cache pour la charge de travail. Configurez les paramètres de mise en cache pour tous les disques en fonction de l’utilisation des composants de l’application.

  Les composants qui effectuent principalement des opérations de lecture n’ont pas besoin d’une grande cohérence transactionnelle des disques. Ces composants peuvent bénéficier de la mise en cache en lecture seule. Les composants lourds en écriture nécessitant une grande cohérence transactionnelle des disques ont souvent la mise en cache désactivée.

  L’utilisation de la mise en cache en lecture et en écriture pourrait entraîner une perte de données en cas de crash de la VM et n’est pas recommandée pour la plupart des scénarios de disque de données.

Dans cette architecture :

• Les disques OS de toutes les VM sont éphémères et sont situés sur le disque de cache.

  L’application de charge de travail en front-end (Linux) et back-end (Windows Server) tolère les échecs individuels des VM et utilise des images de petite taille (environ 30 Go). Ces attributs les rendent éligibles à l’utilisation de disques OS éphémères créés dans le cadre du stockage local des VM (partition de cache) au lieu de disques OS persistants qui sont enregistrés dans des ressources de stockage Azure à distance. Cette situation n’entraîne pas de coût de stockage pour les disques OS et améliore également les performances en offrant des latences plus faibles et en réduisant le temps de déploiement de la VM.

• Chaque machine virtuelle possède son propre disque managé SSD Premium P1, fournissant un débit de base approvisionné en fonction de la charge de travail.

Configuration réseau

Cette architecture déploie la charge de travail dans un seul réseau virtuel. Les contrôles réseau sont une partie significative de cette architecture et sont décrits dans la section Sécurité.

Cette configuration peut être intégrée à une topologie d’entreprise. Un exemple est présenté dans l’architecture de base de la machine virtuelle dans une zone d’atterrissage Azure.

Réseau virtuel

L’une de vos premières décisions de configuration réseau concerne la plage d’adresses réseau. Tenez compte de la croissance anticipée du réseau lors de la phase de planification de la capacité. Le réseau doit être suffisamment important pour supporter la croissance, ce qui peut nécessiter des constructions réseau supplémentaires. Par exemple, le réseau virtuel doit avoir la capacité d’accueillir les autres VM qui résultent d’une opération de mise à l’échelle.

Inversement, adaptez la taille de votre espace d’adressage. Un réseau virtuel excessivement grand peut entraîner une sous-utilisation. Il est important de noter que, une fois que le réseau virtuel est créé, la plage d’adresses ne peut pas être modifiée.

Dans cette architecture, l’espace d’adressage est défini sur /21, une décision basée sur la croissance projetée.

Considérations de sous-réseaux

Au sein du réseau virtuel, les sous-réseaux sont divisés en fonction de la fonctionnalité et des exigences de sécurité, comme décrit ci-dessous :

• Un sous-réseau pour héberger la passerelle d’application, qui sert de proxy inverse. La passerelle d’application nécessite un sous-réseau dédié.
• Un sous-réseau pour héberger le répartiteur de charge interne pour la distribution du trafic vers les VM du back-end.
• Des sous-réseaux pour héberger les machines virtuelles de charge de travail, une pour le serveur frontal et une pour le serveur principal. Ces sous-réseaux sont créés en fonction des niveaux de l’application.
• Un sous-réseau pour l’hôte Azure Bastion afin de faciliter l’accès opérationnel aux VM de charge de travail. Par conception, l’hôte Azure Bastion nécessite un sous-réseau dédié.
• Un sous-réseau pour héberger des points de terminaison privés créés pour accéder à d’autres ressources Azure via Azure Private Link. Bien que des sous-réseaux dédiés ne soient pas obligatoires pour ces points de terminaison, nous les recommandons.

Tout comme les réseaux virtuels, les sous-réseaux doivent être dimensionnés correctement. Par exemple, vous voudrez peut-être appliquer la limite maximale de VM prise en charge par l’orchestration flexible pour répondre aux besoins de mise à l’échelle de l’application. Les sous-réseaux de charge de travail doivent être capables d’accommoder cette limite.

Un autre cas d’utilisation à considérer est la mise à niveau du système d’exploitation des VM, qui peut nécessiter des adresses IP temporaires. Un bon dimensionnement vous donne le niveau de segmentation souhaité en regroupant des ressources similaires de manière à ce que des règles de sécurité significatives via des groupes de sécurité réseau (NSG) puissent être appliquées aux limites du sous-réseau. Pour plus d’informations, veuillez consulter la section Sécurité : Segmentation.

Trafic d’entrée

Deux adresses IP publiques sont utilisées pour les flux entrants. Une adresse est destinée à Application Gateway qui sert de proxy inverse. Les utilisateurs se connectent en utilisant cette adresse IP publique. Le proxy inverse équilibre la charge du trafic entrant vers les adresses IP privées des VM. L’autre adresse est destinée à l’accès opérationnel via Azure Bastion.

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

Trafic de sortie

Cette architecture utilise un équilibreur de charge de type SKU standard avec des règles de sortie définies à partir des instances de VM. Load Balancer a été choisi car il est redondant au niveau des zones.

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

Cette configuration vous permet d’utiliser les adresses IP publiques de votre équilibreur de charge pour fournir une connectivité Internet sortante pour les VM. Les règles de sortie vous permettent de définir explicitement la traduction d’adresse réseau source (SNAT). Les règles vous permettent d’ajuster et d’optimiser cette capacité grâce à une allocation manuelle de ports. L’allocation manuelle du port SNAT en fonction de la taille du pool en amont et du nombre de frontendIPConfigurations peut aider à éviter l’épuisement du SNAT.

Nous vous recommandons d’allouer des ports en fonction du nombre maximal d’instances en amont. Si plus d’instances sont ajoutées que ce que permettent les ports SNAT restants, les opérations de mise à l’échelle des ensembles d’échelle de machine virtuelle peuvent être bloquées, ou les nouvelles VM ne reçoivent pas suffisamment de ports SNAT.

Calculez les ports par instance comme suit : Number of front-end IPs * 64K / Maximum number of back-end instances.

Il existe d’autres options que vous pouvez utiliser, telles que le déploiement d’une ressource Azure NAT Gateway attachée au sous-réseau. Une autre option consiste à utiliser le pare-feu Azure ou un autre périphérique réseau virtuel avec une route utilisateur définie (UDR) personnalisée comme prochain saut via le pare-feu. Cette option est illustrée dans l’architecture de base de la machine virtuelle dans une zone d’atterrissage Azure.

Résolution DNS

Azure DNS est utilisé comme service de base pour tous les cas de résolution comme la résolution des noms de domaine complets (FQDN) associés aux VM de charge de travail. Dans cette architecture, les VM utilisent les valeurs DNS définies dans la configuration du réseau virtuel, qui est Azure DNS.

Les zones DNS privées Azure sont utilisées pour résoudre les demandes vers les points de terminaison privés utilisés pour accéder aux ressources de Private Link nommées.

Surveillance

Cette architecture dispose d’une pile de surveillance qui est découplée de l’utilité de la charge de travail. L’accent est principalement mis sur les sources de données et les aspects de collecte.

Des métriques et des journaux sont générés à partir de diverses sources de données, fournissant des informations d’observabilité à différents niveaux :

• L’infrastructure sous-jacente et les composants sont pris en compte, tels que les VM, les réseaux virtuels et les services de stockage. Les journaux de la plate-forme Azure fournissent des informations sur les opérations et les activités au sein de la plate-forme Azure.

• Niveau de l’application fournit des informations sur les performances et le comportement des applications en cours d’exécution sur votre système.

L’espace de travail Log Analytics est le récepteur de données de monitoring recommandé utilisé pour collecter les journaux et les métriques des ressources Azure et Application Insights.

Cette image montre le monitoring stack pour la configuration de base avec des composants pour la collecte de données à partir de l’infrastructure et de l’application, des récepteurs de données et divers outils de consommation pour l’analyse et la visualisation. La mise en œuvre déploie certains composants, tels que Application Insights, les diagnostics de démarrage de la VM et Log Analytics. D’autres composants sont décrits pour présenter les options d’extensibilité, telles que les tableaux de bord et les alertes.

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

Monitoring au niveau de l’infrastructure

Ce tableau relie les journaux d’activité et métriques collectés par Azure Monitor. Les alertes disponibles vous aident à anticiper les problèmes avant qu’ils n’affectent les utilisateurs.

Ressource Azure	Métriques et journaux	Alertes
Application Gateway	Description des métriques et des journaux d’Application Gateway	Alertes Application Gateway
Application Insights	Métriques et API de journalisation d’Application Insights	alertes Application Insights
Azure Bastion	Métriques d’Azure Bastion
Key Vault	Descriptions des métriques et des journaux Key Vault	Alertes Key Vault
Standard Load Balancer	Journaux et métriques de Load Balancer	Alertes de Load Balancer
Adresse IP publique	Description des métriques et des journaux d’adresse IP publique	Alertes des métriques d’adresse IP publique
Réseau virtuel	Informations de référence sur les métriques et les journaux du réseau virtuel	Alertes du réseau virtuel
Machines virtuelles et groupes de machines virtuelles identiques	Informations de référence sur les métriques et les journaux des machines virtuelles (VM)	Alertes et tutoriels des métriques des machines virtuelles (VM)
Pare-feu d’applications web	Description des métriques et des journaux du pare-feu d’applications Web	Alertes du pare-feu d’applications Web

Pour plus d’informations sur le coût de la collecte de métriques et de journaux, veuillez consulter les calculs de coût et les options de Log Analytics et la tarification de l’espace de travail Log Analytics. La nature de la charge de travail, la fréquence et le nombre de métriques et de journaux collectés ont un impact significatif sur les coûts de collecte de métriques et de journaux.

Machines virtuelles

Les diagnostics de démarrage Azure sont activés pour observer l’état des machines virtuelles (VM) pendant le démarrage en collectant des informations de journal série et des captures d’écran. Dans cette architecture, ces données peuvent être consultées via le portail Azure et la commande Azure CLI vm boot-diagnostics get-boot-log. Les données sont gérées par Azure, et vous n’avez aucun contrôle ni accès aux ressources de stockage sous-jacentes. Cependant, si les besoins de votre entreprise exigent plus de contrôle, vous pouvez approvisionner votre propre compte de stockage pour stocker les diagnostics de démarrage.

VM Insights offre un moyen efficace de surveiller les machines virtuelles (VM) et les ensembles d’échelle. Il recueille des données à partir des espaces de travail Log Analytics et fournit des tableaux de bord prédéfinis pour les tendances des données de performance. Ces données peuvent être consultées par VM individuelle ou agrégées sur plusieurs VM.

Application Gateway et le Load Balancer interne utilisent des sondes de santé pour détecter l’état de l’extrémité des VM avant d’envoyer du trafic.

Mise en réseau

Dans cette architecture, les données de journalisation sont collectées à partir de plusieurs composants réseau qui participent au flux. Ces composants comprennent Application Gateway, les répartiteurs de charge et Azure Bastion. Ils incluent également des composants de sécurité réseau tels que les réseaux virtuels, les groupes de sécurité réseau (NSG), les adresses IP publiques et Private Link.

Disques managés

Les métriques des disques dépendent de votre charge de travail, nécessitant un mélange de métriques clés. Le monitoring doit combiner ces perspectives pour isoler les problèmes de débit du système d’exploitation ou de l’application.

• La perspective de la plate-forme Azure représente les métriques qui indiquent le service Azure, quel que soit le travail connecté. Les métriques de performance des disques (IOPS et débit) peuvent être consultées individuellement ou collectivement pour tous les disques attachés à la VM. Basez-vous sur les métriques d’utilisation des E/S de stockage pour le dépannage ou l’alerte sur le débordement potentiel du disque. Si vous utilisez le bursting pour l’optimisation des coûts, surveillez le pourcentage de crédits des métriques pour identifier les opportunités d’optimisation supplémentaires.

• La perspective du système d’exploitation invité représente les métriques que l’opérateur de la charge de travail verrait, quelles que soient les technologies de disque sous-jacentes. VM insights est recommandé pour les métriques clés sur les disques attachés, telles que l’espace disque logique utilisé, et la perspective du noyau du système d’exploitation sur les IOPS et le débit des disques.

Monitoring au niveau de l’application

Même si l’implémentation de référence n’en fait pas usage, Application Insights est approvisionné en tant que Gestion de la performance des applications (APM) à des fins d’extensibilité. Application Insights collecte des données à partir d’une application et envoie ces données vers l’espace de travail Log Analytics. Il peut également visualiser ces données à partir des applications de charge de travail.

L’extension d’intégrité de l’application est déployée sur les VM pour surveiller l’état d’intégrité binaire de chaque instance de VM dans l’ensemble d’échelle, et effectuer des réparations d’instance si nécessaire en utilisant la réparation automatique des instances de l’ensemble d’échelle. Elle teste le même fichier que Application Gateway et la sonde d’intégrité du Azure Load Balancer interne pour vérifier si l’application répond.

Gestion des mises à jour

Les VM doivent être mises à jour et patchées régulièrement afin de ne pas affaiblir la posture de sécurité de la charge de travail. Nous recommandons d’effectuer des évaluations automatiques et régulières des VM afin de pouvoir identifier les problèmes le plus tôt possible et appliquer les correctifs.

Les mises à jour de l’infrastructure.

Azure met à jour sa plate-forme régulièrement pour améliorer la fiabilité, les performances et la sécurité de l’infrastructure hôte des machines virtuelles. Ces mises à jour incluent entre autres la mise à jour des composants logiciels dans l’environnement d’hébergement, la mise à niveau des composants de mise en réseau ou la mise hors service du matériel. Pour plus d’informations concernant le processus de mise à jour, veuillez consulter la section Maintenance des machines virtuelles dans Azure.

Si une mise à jour ne nécessite pas de redémarrage, la VM est mise en pause pendant la mise à jour de l’hôte, ou la VM est migrée en direct vers un hôte déjà mis à jour. Si la maintenance nécessite un redémarrage, vous êtes informé de la maintenance planifiée. Azure vous fournit également un créneau pendant lequel vous pouvez commencer la maintenance, à votre convenance. Pour plus d’informations concernant la fenêtre de maintenance automatique et la configuration des options disponibles, veuillez consulter la section Gestion des notifications de maintenance planifiée.

Certaines charges de travail pourraient ne pas tolérer quelques secondes d’arrêt ou de déconnexion de la VM pour la maintenance. Pour un plus grand contrôle sur toutes les activités de maintenance, dont les mises à jour sans conséquences néfastes et sans redémarrage, veuillez consulter les configurations de maintenance. La création d’une configuration de maintenance vous donne la possibilité de sauter toutes les mises à jour de la plate-forme et d’appliquer les mises à jour à votre convenance. Lorsque cette configuration personnalisée est définie, Azure ignore toutes les mises à jour non à impact nul, y compris les mises à jour sans redémarrage. Pour plus d’informations, veuillez consulter la section Gestion des mises à jour de la plate-forme avec les configurations de maintenance.

Mises à niveau de l’image du système d’exploitation (OS)

Lorsque vous effectuez des mises à niveau du système d’exploitation, dotez-vous d’une image de référence qui a été testée. Envisagez d’utiliser Azure Shared Image Gallery et Azure Compute Gallery pour publier vos images personnalisées. Il est recommandé d’avoir un processus en place qui met à niveau des lots d’instances de manière progressive chaque fois qu’une nouvelle image est publiée par l’éditeur.

Retirez les images de VM avant qu’elles n’atteignent leur fin de vie pour réduire la surface d’exposition.

Votre processus d’automatisation doit prendre en compte le sur-approvisionnement avec une capacité supplémentaire.

Vous pouvez utiliser Azure Update Management pour gérer les mises à jour du système d’exploitation de vos machines virtuelles Windows et Linux dans Azure.

Patchs du système d’exploitation invité

Les machines virtuelles Azure offrent la possibilité de mettre à jour automatiquement les machines virtuelles invitées. Lorsque ce service est activé, les machines virtuelles sont évaluées régulièrement et les correctifs disponibles sont catégorisés. Il est recommandé d’activer le mode d’évaluation pour permettre une évaluation quotidienne des correctifs en attente. Une évaluation à la demande peut être effectuée, mais cela ne déclenche pas l’application des correctifs. Si le mode d’évaluation n’est pas activé, disposez de moyens manuels pour détecter les mises à jour en attente.

Seuls les correctifs classés comme critiques ou de sécurité sont automatiquement appliqués dans toutes les régions Azure. Définissez des processus de gestion des mises à jour personnalisées qui appliquent d’autres patchs.

Pour la gouvernance, envisagez la stratégie Azure de mise à jour corrective automatique des images de système d’exploitation sur les Virtual Machine Scale Sets.

La mise à jour automatique peut surcharger le système et peut être source de perturbations car les machines virtuelles utilisent des ressources et peuvent redémarrer pendant les mises à jour. Il est recommandée de sur-approvisionner pour la gestion de la charge. Déployez des machines virtuelles dans différentes zones de disponibilité pour éviter les mises à jour concurrentes et maintenez au moins deux instances par zone pour une haute disponibilité. Les machines virtuelles de la même région peuvent recevoir des correctifs différents, qui doivent être réconciliés au fil du temps.

Soyez conscient du compromis concernant le coût lié à au sur-approvisionnement.

Les vérifications de l’état de santé sont incluses dans le cadre de la mise à jour automatique des machines virtuelles invitées. Ces vérifications vérifient si l’application des patchs est réussie et détectent les problèmes.

S’il existe des processus personnalisés pour l’application des patchs, utilisez des référentiels privés pour les sources de patchs. Cela vous permet un meilleur contrôle pour tester les patchs afin de vous assurer que la mise à jour n’a pas d’impact négatif sur les performances ou sur la sécurité.

Pour plus d’informations, veuillez consulter la mise à jour automatique des machines virtuelles Azure.

Fiabilité

Cette architecture utilise les zones de disponibilité comme élément fondateur pour traiter les problèmes de fiabilité.

Dans cette configuration, les machines virtuelles individuelles sont liées à une seule zone. En cas de panne, ces machines virtuelles peuvent être facilement remplacées par d’autres instances de machines virtuelles à l’aide des ensembles d’échelle de machines virtuelles.

Tous les autres composants de cette architecture sont soit :

• Redondants d’une zone à l’autre, ce qui signifie qu’ils sont répliqués dans plusieurs zones pour une haute disponibilité, comme Application Gateway ou les adresses IP publiques.
• Soit résilients d’une zone à l’autre, ce qui implique qu’ils peuvent résister aux pannes de zone, comme Key Vault.
• Les ressources régionales ou globales sont disponibles dans plusieurs régions ou dans le monde entier, comme Microsoft Entra ID.

La conception de la charge de travail devrait intégrer des garanties de fiabilité dans le code de l’application, l’infrastructure et les opérations. Les sections suivantes illustrent quelques stratégies pour s’assurer que la charge de travail est résiliente aux pannes et capable de récupérer en cas de pannes au niveau de l’infrastructure.

Les stratégies utilisées dans l’architecture sont basées sur la liste de contrôle de conception de fiabilité donnée dans le cadre Azure Well-Architected. Les sections sont annotées avec des recommandations de cette liste de contrôle.

Parce qu’aucune application n’est déployée, la résilience dans le code de l’application dépasse le cadre de cette architecture. Nous vous recommandons de passer en revue toutes les recommandations de la liste de contrôle et de les adopter dans votre charge de travail, le cas échéant.

Donnez la priorité aux garanties de fiabilité par flux d’utilisateur

Dans la plupart des conceptions, il existe plusieurs flux d’utilisateurs, chacun ayant ses propres exigences métier. Tous ces flux ne nécessitent pas le plus haut niveau de garanties, il est donc recommandé de les segmenter en tant que stratégie de fiabilité. Chaque segment peut être géré de manière indépendante, en veillant à ce qu’un segment n’impacte pas les autres et en fournissant le bon niveau de résilience dans chaque niveau. Cette approche rend également le système flexible.

Dans cette architecture, les niveaux d’application implémentent la segmentation. Des ensembles d’échelle distincts sont provisionnés pour les niveaux front-end et back-end. Cette séparation permet une mise à l’échelle indépendante de chaque niveau, permettant entre autres la mise en œuvre de schémas de conception en fonction de leurs besoins spécifiques.

Veuillez consulter Well-Architected Framework: RE:02 - Recommandations pour identifier et évaluer les flux.

Identifiez les points de défaillance potentiels

Chaque architecture est susceptible de connaître des pannes. L’exercice d’analyse des modes de défaillance vous permet d’anticiper les pannes et de vous préparer avec des mesures d’atténuation. Voici quelques points de défaillance potentiels dans cette architecture :

Composant	Risque	Vraisemblance	Effet / Atténuation / Remarque	Outage
Microsoft Entra ID	Configuration incorrecte	Moyenne	Les utilisateurs des opérations ne peuvent pas se connecter. Aucun effet aval. Le service d’assistance signale un problème de configuration à l’équipe d’identité.	Aucun
Application Gateway	Configuration incorrecte	Moyenne	Les mauvaises configurations doivent être détectées lors du déploiement. Si ces erreurs se produisent lors d’une mise à jour de configuration, l’équipe DevOps doit revenir en arrière. Pour la plupart des déploiements qui utilisent la référence SKU v2, le provisionnement prend environ 6 minutes. Toutefois, cette opération peut prendre plus de temps en fonction du type de déploiement. Par exemple, les déploiements sur plusieurs zones de disponibilité avec de nombreuses instances peuvent prendre plus de 6 minutes.	Complète
Application Gateway	Attaque DDoS	Moyenne	Risque de perturbation. Microsoft gère la protection contre les attaques DDoS de niveau 3 et 4. Risque potentiel d’effets des attaques de niveau 7.	Complète
Jeux de mise à l’échelle de machine virtuelle	Interruption de service	Faible	Possibilité d’indisponibilité de la charge de travail si des instances de VM non saines déclenchent l’auto-réparation. Dépendance vis-à-vis de Microsoft pour y remédier.	Panne potentielle
Jeux de mise à l’échelle de machine virtuelle	Panne de zone de disponibilité	Faible	Aucun effet. Les scale sets (groupes identiques) sont déployés comme redondants interzone.	Aucun

Veuillez vous reporter à Well-Architected Framework : RE :03 - Recommandations pour effectuer une analyse du mode d’échec.

Objectifs de fiabilité

Pour prendre des décisions relatives à la conception, il est important de calculer les objectifs de fiabilité, tels que les objectifs de niveau de service composites (SLO) de la charge de travail. Cela implique de comprendre les accords de niveau de service (SLA) fournis par les services Azure utilisés dans l’architecture. Les SLO de la charge de travail ne doivent pas être supérieurs aux SLA garantis par Azure. Examinez attentivement chaque composant, des VM et de leurs dépendances, en passant par la mise en réseau et les options de stockage.

Voici un exemple de calcul où l’objectif principal est de fournir un SLO composite approximatif. Bien qu’il s’agisse ici de lignes directrices générales, vous devriez arriver à quelque chose de similaire. Vous ne devriez pas obtenir un SLO composite maximum plus élevé pour les mêmes flux à moins de modifier l’architecture.

Flux d’opération

Composant	SLO
Microsoft Entra ID	99,99 %
Azure Bastion	99,95 %

SLO composite : 99,94 % | Temps d’arrêt par an : 0 j 5 h 15 min 20 s

Flux utilisateur de l’application

Composant	SLO
Application Gateway	99,95 %
Azure Load Balancer (interne)	99,99 %
Machines virtuelles front-end utilisant le stockage Premium (SLO composite)	99.70%
Machines virtuelles back-end utilisant le stockage Premium (SLO composite)	99.70%

SLO composite : 99,34 % | Temps d’arrêt par an : 2 j 9 h 42 min 18 s

Dans l’exemple précédent, la fiabilité des VM et des dépendances est incluse, comme les disques associés aux VM. Les SLA associés au stockage de disques ont un impact sur la fiabilité globale.

Il y a des défis lors du calcul du SLO composite. Il est important de noter que différentes catégories de service peuvent avoir des SLA différents, et ceux-ci incluent souvent des garanties financièrement étayées qui fixent des objectifs de fiabilité. Enfin, il peut y avoir des composants de l’architecture qui n’ont pas de SLA définis. Par exemple, en ce qui concerne la mise en réseau, les cartes réseau virtuelles (NIC) et les réseaux virtuels n’ont pas leurs propres SLA.

Les exigences commerciales et leurs objectifs doivent être clairement définis et pris en compte dans le calcul. Tenez compte des limites de service et d’autres contraintes imposées par l’organisation. Le partage de votre abonnement avec d’autres charges de travail pourrait avoir un impact sur les ressources disponibles pour vos VM. Il se peut que la charge de travail soit autorisée à utiliser un nombre limité de cœurs disponibles pour les VM. Bien comprendre l’utilisation des ressources de votre abonnement peut vous aider à concevoir vos VM de manière plus efficace.

Veuillez vous reporter à Well-Architected Framework : RE :04 - Recommandations pour définir des objectifs de fiabilité.

Redondance

Cette architecture utilise la redondance interzone pour plusieurs composants. Chaque zone est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. Le fait de faire fonctionner les instances dans des zones séparées protège l’application contre les défaillances des centres de données.

• Virtual Machine Scale Sets alloue un nombre spécifié d’instances et les répartit uniformément entre les zones de disponibilité et les domaines de défaillance. Cette répartition est obtenue grâce à la capacité de dispersion maximale, que nous recommandons. La répartition des instances de VM dans les domaines de défaillance permet de s’assurer que toutes les VM ne sont pas mises à jour en même temps.

  Imaginez un scénario où il y a trois zones de disponibilité. Si vous avez trois instances, chaque instance est allouée à une zone de disponibilité différente et placée dans un domaine de défaillance différent. Azure garantit que seul un domaine d’erreur est mis à jour à la fois dans chaque zone de disponibilité. Cependant, il peut arriver que les trois domaines de défaillance hébergeant vos VM dans les trois zones de disponibilité soient mis à jour simultanément. Toutes les zones et tous les domaines sont impactés. Le fait d’avoir au moins deux instances dans chaque zone crée une marge de manœuvre lors des mises à niveau.

• Les disques managés ne peuvent être attachés qu’à une VM de la même région. Leur disponibilité impacte généralement la disponibilité de la VM. Pour les déploiements dans une seule région, les disques peuvent être configurés pour la redondance afin de résister aux défaillances par zone. Dans cette architecture, les disques de données sont configurés en stockage redondant interzone (ZRS) sur les VM de back-end. Cela nécessite une stratégie de récupération pour tirer parti des zones de disponibilité. La stratégie de récupération consiste à redéployer la solution. Idéalement, pré-approvisionnez des ressources de calcul dans des zones de disponibilité alternatives pour être prêt à récupérer d’une défaillance par zone.

• Une passerelle Application Gateway redondante interzone ou un Load Balancer standard peut router le trafic vers les VM à travers les zones en utilisant une seule adresse IP, garantissant ainsi la continuité même en cas de défaillance de zone. Ces services utilisent des sondes d’intégrité pour vérifier la disponibilité des VM. Tant qu’une zone dans la région reste opérationnelle, le routage continue malgré les éventuelles défaillances dans d’autres zones. Cependant, le routage entre les zones peut avoir une latence plus élevée par rapport au routage à l’intérieur de la zone.

  Toutes les adresses IP publiques utilisées dans cette architecture sont redondantes interzone.

• Azure propose des services comme Key Vault qui sont résilients par rapport aux zones pour une meilleure fiabilité.

• Les ressources globales Azure sont toujours disponibles et peuvent basculer vers une autre région si nécessaire, comme le fournisseur d’identité fondamental, Microsoft Entra ID.

Veuillez vous reporter à Well-Architected Framework : RE:05 - Recommandations pour la conception de la redondance.

Stratégie de mise à l’échelle

Pour éviter la dégradation du niveau de service et des défaillances, assurez-vous d’effectuer des opérations de mise à l’échelle fiables. Mettez à l’échelle la charge de travail horizontalement (scale out), verticalement (scale up) ou utilisez une combinaison de ces deux approches. Utilisez Azure Monitor Autoscale pour approvisionner suffisamment de ressources pour prendre en charge la demande de votre application sans allouer plus de capacité que nécessaire et encourir des coûts inutiles.

La mise à l’échelle automatique (autoscale) vous permet de définir différents profils en fonction de différents types d’événements, tels que le temps, la planification ou les métriques. Les profils basés sur les métriques peuvent utiliser des métriques intégrées (basées sur l’hôte) ou des métriques plus détaillées (métriques VM intégrées) qui nécessitent l’installation de l’Agent Azure Monitor pour les collecter. Chaque profil contient des règles de scale out (augmentation) et de scale in (diminution). Envisagez d’explorer tous les scénarios de mise à l’échelle différents en fonction des profils conçus et évaluez-les pour les éventuelles conditions de boucle qui peuvent provoquer une série d’événements de mise à l’échelle opposés. Azure Monitor tentera d’atténuer cette situation en attendant le temps de recharge avant de réessayer de mettre à l’échelle.

Bien que les Virtual Machine Scale Sets Azure en mode Flexible prennent en charge les environnements hétérogènes, l’automatisation de la mise à l’échelle de plusieurs profils n’est pas prise en charge. Si vous prévoyez d’utiliser l’automatisation de la mise à l’échelle avec plus d’un type de VM, envisagez de créer différents jeux d’instances de mise à l’échelle pour les gérer séparément.

Tenez compte d’autres aspects tels que le démarrage, les arrêts en douceur, l’installation de la charge de travail et de toutes ses dépendances, ainsi que la gestion des disques lors de la création ou de la suppression d’instances de VM.

Les charges de travail avec état (stateful) peuvent nécessiter une gestion supplémentaire des disques gérés qui doivent survivre à une instance de charge de travail. Concevez votre charge de travail pour la gestion des données lors d’événements de mise à l’échelle en ce qui concerne la cohérence, la synchronisation, la réplication et l’intégrité des données de la charge de travail. Pour ces scénarios, envisagez d’ajouter des disques pré-remplis aux jeux d’instances de mise à l’échelle. Pour les cas d’utilisation où la mise à l’échelle est utilisée pour éviter les goulots d’étranglement lors de l’accès aux données, prévoyez la partition et la fragmentation. Pour plus d’informations, veuillez consulter les Bonnes pratiques pour l’automatisation de la mise à l’échelle.

Veuillez vous reporter à Well-Architected Framework : RE :06 - Recommandations pour concevoir une stratégie de mise à l’échelle fiable.

Self-healing et récupération

Les réparations automatiques des instances sont activées dans les jeux d’instances de machines virtuelles pour automatiser la récupération des défaillances des VM. L’extension d’intégrité de l’application est déployée sur les VM pour détecter les VM et les applications qui ne répondent pas. Pour ces instances, des actions de réparation sont automatiquement déclenchées.

Veuillez vous reporter à Well-Architected Framework : Recommandations pour le self-healing et l’auto-conservation.

Sécurité

Cette architecture illustre certaines des assurances de sécurité données dans la liste de contrôle de la conception de la sécurité donnée dans Azure Well-Architected Framework. Les sections sont annotées avec des recommandations de cette liste de contrôle.

La sécurité ne concerne pas uniquement les contrôles techniques. Nous vous recommandons de suivre l’ensemble de la liste de contrôle pour comprendre les aspects opérationnels de la colonne de sécurité.

Segmentation

• Segmentation réseau Les ressources de la charge de travail sont placées dans un réseau virtuel, ce qui les isole de l’internet. Au sein du réseau virtuel, les sous-réseaux peuvent être utilisés comme frontières de confiance. Placez des ressources liées nécessaires au traitement d’une transaction dans un sous-réseau. Dans cette architecture, le réseau virtuel est divisé en sous-réseaux en fonction du regroupement logique de l’application et de l’objectif des différents services Azure utilisés dans le cadre de la charge de travail.

  L’avantage de la segmentation en sous-réseaux est que vous pouvez placer des contrôles de sécurité à la périphérie qui contrôlent le flux de trafic entrant et sortant du sous-réseau, limitant ainsi l’accès aux ressources de la charge de travail.

• Segmentation d’identité. Attribuez des rôles distincts à différentes identités avec des autorisations suffisantes pour effectuer leur tâche. Cette architecture utilise des identités gérées par Microsoft Entra ID pour segmenter l’accès aux ressources.

• Segmentation des ressources. L’application est segmentée par niveaux en ensembles de mise à l’échelle distincts, ce qui garantit que les composants de l’application ne sont pas situés au même endroit.

Veuillez consulter Well-Architected Framework : SE :04 - Recommandations pour élaborer une stratégie de segmentation.

Gestion des identités et des accès

Nous recommandons l’utilisation de Microsoft Entra ID pour l’authentification et l’autorisation des utilisateurs et des services.

L’accès aux VM nécessite un compte utilisateur, contrôlé par l’authentification Microsoft Entra ID et soutenu par des groupes de sécurité. Cette architecture offre un support en déployant l’extension d’authentification Microsoft Entra ID sur toutes les VM. Nous recommandons que les utilisateurs humains utilisent leurs identités d’entreprise dans le locataire Microsoft Entra ID de leur organisation. De plus, assurez-vous que l’accès basé sur les principaux de service n’est pas partagé entre les fonctions.

Les ressources de la charge de travail, telles que les VM, s’authentifient en utilisant leurs identités gérées assignées à d’autres ressources. Ces identités, basées sur les principaux de service Microsoft Entra ID, sont gérées automatiquement.

Par exemple, des extensions Key Vault sont installées sur les VM, qui démarreront les VM avec des certificats en place. Dans cette architecture, des identités managées attribuées par l’utilisateur sont utilisées par Application Gateway, les VM front-end et les VM de back-end pour accéder à Key Vault. Ces identités managées sont configurées lors du déploiement et utilisées pour l’authentification auprès de Key Vault. Les stratégies d’accès sur Key Vault sont configurées pour n’accepter que les demandes des identités managées précédentes.

L’architecture de base utilise un mélange d’identités managées attribuées par le système et par l’utilisateur. Ces identités sont requises pour utiliser Microsoft Entra ID à des fins d’autorisation lors de l’accès à d’autres ressources Azure.

Veuillez vous reporter à Well-Architected Framework : SE :05 - Recommandations pour la gestion de l’identité et de l’accès.

Contrôles de réseau

• Trafic d’entrée. Les VM de la charge de travail ne sont pas directement exposées à l’internet public. Chaque machine virtuelle a une adresse IP privée. Les utilisateurs de la charge de travail se connectent en utilisant l’adresse IP publique de l’Application Gateway.

  Une sécurité supplémentaire est fournie par Web Application Firewall qui est intégré à Application Gateway. Il comporte des règles qui inspectent le trafic entrant et peuvent prendre des mesures appropriées. Le WAF surveille les vulnérabilités du projet de sécurité des applications Web ouvertes (OWASP) pour prévenir les attaques connues.

• Trafic de sortie. Il n’y a pas de contrôles sur le trafic sortant, sauf les règles de groupe de sécurité réseau sortant sur les sous-réseaux des VM. Nous recommandons que tout le trafic internet sortant passe par un seul pare-feu. Ce pare-feu est généralement un service central fourni par une organisation. Ce cas d’utilisation est illustré dans L’architecture de base des machines virtuelles dans une zone d’atterrissage Azure.

• Trafic est-ouest. Le flux de trafic entre les sous-réseaux est restreint en appliquant des règles de sécurité granulaires.

  Des groupes de sécurité réseau (NSG) sont placés pour restreindre le trafic entre les sous-réseaux en fonction de paramètres tels que la plage d’adresses IP, les ports et les protocoles. Des groupes de sécurité des applications (ASG) sont placés sur les VM front-end et back-end. Ils sont utilisés avec les NSG pour filtrer le trafic vers et depuis les VM.

• Trafic opérationnel. Nous recommandons que l’accès opérationnel sécurisé à une charge de travail soit assuré par Azure Bastion, ce qui élimine la nécessité d’une adresse IP publique. Dans cette architecture, cette communication se fait via SSH et est prise en charge à la fois par les VM Windows et Linux. Microsoft Entra ID est intégré à SSH pour les deux types de VM en utilisant l’extension VM correspondante. Cette intégration permet d’authentifier et d’autoriser l’identité de l’opérateur via Microsoft Entra ID.

  Sinon, utilisez une VM séparée comme jumpbox, déployée dans son propre sous-réseau, où vous pouvez installer votre choix d’outils d’administration et de dépannage. L’opérateur accède à la jumpbox via l’hôte Azure Bastion. Ensuite, il se connecte aux VM derrière le load balancer depuis la jumpbox.

  Dans cette architecture, le trafic opérationnel est protégé en utilisant les règles NSG pour restreindre le trafic, et l’accès just-in-time (JIT) aux VM est activé sur les VM. Cette fonctionnalité de Microsoft Defender for Cloud permet un accès entrant temporaire à des ports sélectionnés.

  Pour une sécurité renforcée, utilisez Microsoft Entra Privileged Identity Management (PIM). PIM est un service dans Microsoft Entra ID qui vous permet de gérer, de contrôler et de surveiller l’accès aux ressources importantes de votre organisation. PIM fournit une activation de rôle basée sur l’heure et à l’approbation pour atténuer les risques d’autorisations d’accès excessives, inutiles ou inutilisées sur les ressources qui vous intéressent.

• Connectivité privée aux services de la plate-forme en tant que service (PaaS). La communication entre les VM et Key Vault se fait via Private Link. Ce service nécessite des points de terminaison privés, qui sont placés dans un sous-réseau séparé.

• Protection DDOS. Considérez l’activation de la Protection Azure DDoS sur les adresses IP publiques exposées par l’Application Gateway et l’hôte Azure Bastion pour détecter les menaces. La Protection DDoS offre également des alertes, des données télémétriques et des analyses via Monitor. Pour plus d’informations, consultez Azure DDoS Protection : Bonnes pratiques et architectures de référence.

Veuillez vous reporter à Well-Architected Framework : SE:06 - Recommandations pour la mise en réseau et la connectivité.

Chiffrement

• Données en transit. Le trafic utilisateur entre les utilisateurs et l’adresse IP publique de l’Application Gateway est chiffré à l’aide du certificat externe. Le trafic entre la passerelle de l’application et les VM front-end, ainsi qu’entre les VM front-end et les VM back-end, est chiffré à l’aide d’un certificat interne. Les deux certificats sont stockés dans Key Vault :

  • app.contoso.com: Un certificat externe utilisé par les clients et l’Application Gateway pour un trafic internet public sécurisé.
  • *.workload.contoso.com : Un certificat générique utilisé par les composants d’infrastructure pour un trafic interne sécurisé.

• Données au repos. Les données de journalisation sont stockées sur un disque géré attaché aux VM. Ces données sont automatiquement chiffrées à l’aide du chiffrement fourni par la plate-forme sur Azure.

Veuillez vous reporter à Well-Architected Framework : SE:07 - Recommandations pour le chiffrement des données.

Gestion des secrets

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

Key Vault offre une gestion sécurisée des secrets, y compris des certificats TLS. Dans cette architecture, les certificats TLS sont stockés dans le Key Vault et récupérés lors du processus de provisionnement par les identités gérées de l’Application Gateway et des VM. Après la configuration initiale, ces ressources accèdent uniquement au coffre de clés lorsque les certificats sont actualisés.

Les machines virtuelles utilisent l’extension de machine virtuelle Key Vault pour actualiser automatiquement les certificats surveillés. Si des modifications sont détectées dans le magasin de certificats local, l’extension récupère et installe les certificats correspondants à partir de Key Vault. L’extension prend en charge les types de contenu de certificat PKCS #12 et PEM.

Reportez-vous à Well-Architected Framework : SE :09 - Recommandations pour protéger les secrets d’application.

Optimisation des coûts

Les exigences en matière de charge de travail doivent être satisfaites en tenant compte des contraintes de coût. Les stratégies utilisées dans l’architecture sont basées sur la liste de contrôle de conception de l’optimisation des coûts donnée dans Azure Well-Architected Framework. Cette section décrit certaines options pour optimiser les coûts et est assortie de recommandations tirées de cette liste de contrôle.

Coût du composant

Sélectionnez des images de machines virtuelles optimisées pour la charge de travail au lieu d’utiliser des images à usage général. Dans cette architecture, les images de machines virtuelles relativement petites sont choisies pour Windows et Linux, soit 30 Go chacune. Avec des images plus petites, les références SKU de machine virtuelle avec disques sont également plus petites, ce qui réduit les coûts et la consommation des ressources, et accélère le déploiement et les temps de démarrage. La réduction de la surface de contact permet d’améliorer la sécurité.

L’implémentation de la rotation des journaux avec des limites de taille est une autre stratégie de réduction des coûts. Elle permet d’utiliser de petits disques de données, ce qui peut entraîner des coûts inférieurs. L’implémentation de cette architecture utilise des disques de 4 Go.

L’utilisation de disques de système d’exploitation éphémères peut également permettre de réaliser des économies et d’améliorer les performances. Ces disques sont conçus pour utiliser les ressources de machines virtuelles que vous payez déjà, car ils sont installés sur le cache de disque fourni avec la machine virtuelle. On élimine ainsi les coûts de stockage associés aux disques persistants traditionnels. Comme ces disques sont temporaires, il n’y a pas de coûts associés au stockage de données à long terme.

Reportez-vous à Well-Architected Framework : CO :07 - Recommandations pour optimiser les coûts des composants.

Coût de flux

Choisissez des ressources de calcul en fonction du caractère critique du flux. Pour les flux conçus pour tolérer une longueur indéterminée, envisagez d’utiliser des machines virtuelles spot avec le mode d’orchestration flexible Virtual Machine Scale Sets. Cette approche peut être utile pour héberger des flux de faible priorité sur des machines virtuelles de faible priorité. Cette stratégie permet l’optimisation des coûts tout en répondant aux exigences des différents flux.

Reportez-vous à Well-Architected Framework : CO :09 - Recommandations pour optimiser les coûts des flux.

Coût de la mise à l’échelle

Si le principal facteur de coût est le nombre d’instances, la mise à l’échelle peut s’avérer plus rentable en augmentant la taille ou les performances des machines virtuelles. Cette approche peut entraîner des économies de coûts dans plusieurs domaines :

• Licences des logiciels. Les machines virtuelles de plus grande envergure peuvent gérer davantage de charges de travail, ce qui peut réduire le nombre de licences logicielles requises.
• Temps de maintenance : des machines virtuelles moins nombreuses et plus grandes peuvent réduire les coûts d’exploitation.
• Équilibrage de charge : la réduction du nombre de machines virtuelles peut entraîner des coûts moindres pour l’équilibrage de la charge. Par exemple, dans cette architecture, il existe plusieurs couches d’équilibrage de charge, notamment une passerelle d’application à l’avant et un équilibreur de charge interne au milieu. Les coûts d’équilibrage de la charge augmenteraient si un plus grand nombre d’instances devaient être gérées.
• Stockage sur disque. S’il s’agit d’applications avec état, plus d’instances nécessitent plus de disques managés attachés, ce qui augmente le coût du stockage.

Reportez-vous à Well-Architected Framework : CO :12 - Recommandations pour optimiser les coûts de mise à l’échelle.

Coûts d’exploitation

La mise à jour corrective automatique d’un invité de machine virtuelle réduit la surcharge liée à la mise à jour corrective manuelle et aux coûts de maintenance associés. Cette action permet non seulement de rendre le système plus sûr, mais aussi d’optimiser l’allocation des ressources, contribuant ainsi à la rentabilité globale.

Reportez-vous à Well-Architected Framework : CO :13 - Recommandations pour optimiser le temps du personnel.

Déployer ce scénario

Un déploiement pour cette architecture de référence est disponible sur GitHub.

Ressources associées

Consultez la documentation produit pour plus d’informations sur des services Azure spécifiques :

• Machines virtuelles Azure
• Groupes de machines virtuelles identiques Azure
• Réseau virtuel Azure
• Qu’est-ce qu’Azure Application Standard v2 ?
• Équilibrage de charge Azure
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Étape suivante

Examinez les architectures de référence IaaS qui présentent des options pour le niveau de données :

• Application Windows multi-niveau sur Azure avec SQL Server