Meilleures pratiques pour Azure Load Balancer

Cet article présente l’ensemble des meilleures pratiques Azure pour améliorer le déploiement de vos équilibreurs de charge. Ces meilleures pratiques sont issues de notre expérience dans le domaine de la mise en réseau Azure, mais également de celle des clients, comme vous.

Cet article détaille les points suivants pour chaque bonne pratique :

• Nature de la bonne pratique
• Raison pour laquelle activer cette bonne pratique
• Ce qui peut se produire si vous ne respectez pas ces meilleures pratiques
• Comment apprendre à utiliser ces bonnes pratiques

Ces meilleures pratiques reposent sur un consensus, ainsi que sur les capacités et les fonctionnalités de la plateforme Azure alors disponibles au moment de la rédaction de cet article.

Meilleures pratiques architecturales

En matière d’architecture, les conseils suivants permettent de garantir la fiabilité de votre déploiement Azure Load Balancer. Cela inclut les meilleures pratiques pour le déploiement avec redondance de zone, la redondance sur votre pool principal et le déploiement d’un équilibreur de charge global. Ainsi que la fiabilité de Gateway Load Balancer, qui est recommandée lors de l’utilisation de NVA plutôt que d’une configuration à double équilibreur de charge.

Meilleures pratiques en matière de fiabilité

Les meilleures pratiques suivantes permettent de garantir la fiabilité de votre déploiement Azure Load Balancer.

Déploiement avec redondance de zone

La redondance de zone offre la meilleure résilience, car elle protège le chemin des données contre les défaillances de zone. La sélection de la zone de disponibilité de l’équilibreur de charge est synonyme de la sélection de son adresse IP frontale. Pour les équilibreurs de charge publics, si l’adresse IP publique du serveur front-end de l’équilibreur de charge est redondante interzone, l’équilibreur de charge l’est également.

• Déployez l’équilibreur de charge dans une région qui prend en charge les zones de disponibilité et activez la redondance de zone lorsque vous créez une nouvelle adresse IP publique utilisée pour la configuration de l’adresse IP front-end.
• Les adresses IP publiques ne peuvent pas être changées en adresses IP redondantes interzones. Cependant, nous mettons à jour toutes les adresses IP publiques Standard non zonales pour qu’elles soient redondantes interzones par défaut. Pour plus d’informations, consultez le blog Microsoft Azure Les adresses IP publiques Azure sont désormais redondantes interzones par défaut | Blog Microsoft Azure. Pour afficher la dernière liste des régions compatibles avec les adresses IP publiques Standard redondantes interzones par défaut, consultez Adresses IP publiques dans Azure
• Si vous ne pouvez pas effectuer un déploiement avec redondance de zone, l’option suivante consiste à utiliser un déploiement d’équilibreur de charge zonal.
• Nous recommandons d’utiliser un serveur front-end zonal lorsque le serveur back-end est concentré dans une zone particulière. Cependant, nous recommandons de déployer les membres du pool back-end sur plusieurs zones pour profiter de la redondance de zone.
• Pour migrer des déploiements existants vers des déploiements par zone ou redondants entre zones, consultez le document suivant : Migrer Load Balancer vers la prise en charge des zones de disponibilité.

Redondance dans votre pool de serveurs back-end

Vérifiez que le pool back-end contient au moins deux instances. Si le pool back-end n’a qu’une seule instance et qu’il n’est pas sain, tout le trafic envoyé au pool back-end échoue par manque de redondance. Le contrat SLA du Standard Load Balancer n'est pris en charge que lorsqu'il existe au moins deux instances saines par pool de serveurs principaux. Pour plus d’informations, consultez la documentation SLA.

Déployer un équilibreur de charge global

Standard Load Balancer prend en charge l’équilibrage de charge interrégional, ce qui permet une redondance régionale en reliant un équilibreur de charge global à vos équilibreurs de charge régionaux existants. Avec un équilibreur de charge global, le trafic est acheminé vers l'équilibreur de charge régional sain le plus proche en cas de défaillance d'une région. Pour plus d’informations, consultez la documentation Global Load Balancer.

Pour plus d’informations, consultez la documentation Fiabilité d’Azure Load Balancer.

Fiabilité avec un équilibreur de charge de passerelle

Les meilleures pratiques suivantes permettent de garantir la fiabilité de votre déploiement avec un équilibreur de charge de passerelle.

Chaîner un Équilibreur de charge de passerelle à un Load Balancer public standard

Nous recommandons de chaîner votre équilibreur de charge de passerelle à un équilibreur de charge public Standard. Cette configuration assure la haute disponibilité et la redondance de la NVA et de la couche d'application. Pour plus d’informations, consultez le Tutoriel : Créer un équilibreur de charge de passerelle.

Utilisez un équilibreur de charge Gateway lorsque vous utilisez des appliances virtuelles réseau (NVA) au lieu d’une configuration à deux équilibreurs de charge.

Nous recommandons d’utiliser un équilibreur de charge de passerelle pour les scénarios de trafic Nord-Sud avec des appliances virtuelles réseau (NVA) partenaires. Ce déploiement est plus simple. En effet, les équilibreurs de charge de passerelle ne nécessitent aucune configuration supplémentaire (comme les itinéraires définis par l’utilisateur, UDR), car ils conservent l’adhérence et la symétrie des flux. Il est également plus facile à gérer, car les NVA peuvent être facilement ajoutées et supprimées. Pour plus d’informations, consultez la documentation sur l’équilibreur de charge de passerelle.

Conseils sur la configuration

Les conseils de configuration suivants sont les meilleures pratiques pour configurer vos déploiements Azure Load Balancer.

Créer des groupes de sécurité réseau (NSG)

Utilisez une règle d’équilibrage de charge pour mapper le trafic frontend vers un pool backend, et utilisez un groupe de sécurité réseau (NSG) sur le sous-réseau backend ou l’interface réseau pour permettre le trafic applicatif. Pour le trafic équilibré en charge, le NSG évalue l’adresse IP source et le port source du client, et non l’équilibreur de charge, permettant ainsi la plage source-port client plutôt que seulement le port de destination de l’application. Pour plus d’informations, consultez Créer, modifier ou supprimer un groupe de sécurité réseau.

Débloquer l’adresse IP 168.63.129.16

Vérifiez l’accès à la sonde de santé indépendamment de l’accès au trafic applicatif. Autoriser les sondes de santé depuis le AzureLoadBalancer tag de service dans les NSG et depuis 168.63.129.16 dans les politiques de pare-feu locales. Si vous bloquez le trafic applicatif mais que les sondes aboutissent, vérifiez la règle NSG relative au trafic applicatif. Si les sondes échouent, examinez l’autorisation de la sonde et l’écoute de l’application sur le port de la sonde. Pour plus d’informations, consultez Azure Load Balancer health probe et Qu’est-ce que l’adresse IP 168.63.129.16 ?

Utiliser des règles de trafic sortant avec une allocation manuelle des ports

Utilisez des règles de trafic sortant avec une allocation manuelle des ports au lieu de l’allocation par défaut des ports afin d’éviter l’épuisement du SNAT ou les échecs de connexion. L’allocation de ports par défaut affecte automatiquement un nombre défini de ports, ce qui peut présenter un risque supérieur d’insuffisance des ports SNAT. L’allocation de ports manuelle permet d’optimiser le nombre de ports SNAT disponibles pour chaque instance du pool back-end. Cela permet de protéger vos connexions en cas de nouvelle allocation des ports. Concernant l’allocation de ports manuelle, deux options s’offrent à vous : « Ports par instance » ou « Nombre maximal d’instances back-end ». Pour mieux comprendre chaque option, consultez Source Network Address Translation (SNAT) pour les connexions sortantes.

Vérifier le mode de distribution

Par défaut, Azure Load Balancer utilise un mode de distribution basé sur 5 tuples. La solution offre également une persistance de session grâce à un hachage en 2 ou 3 tuples. Déterminez si votre déploiement peut tirer parti de la persistance de session (également appelée affinité de session) qui permet d’envoyer les connexions à partir d’une même adresse IP cliente ou d’un même protocole client sur la même instance back-end du pool back-end. Déterminez si l’activation de l’affinité de session peut entraîner une distribution de charge inégale. En effet, la plupart des connexions provenant d’une même adresse IP cliente (ou d’une même adresse IP client et d’un même protocole client) sont envoyées à la même machine virtuelle back-end. Pour plus d’informations sur les modes de distribution Azure Load Balancer, consultez Modes de distribution Azure Load Balancer.

Activer les réinitialisations TCP

Activer les réinitialisations TCP sur votre équilibreur de charge entraîne l’envoi bidirectionnel de paquets de réinitialisation TCP aux deux points de terminaison, côté client et côté serveur, à l’expiration du délai d’inactivité, afin d’informer les points de terminaison de l’application que la connexion a expiré et n’est plus utilisable. Lorsque la réinitialisation TCP est désactivée, l’équilibreur de charge supprime silencieusement les flux lorsque le délai d’inactivité d’un flux est atteint. Il peut également être utile d’augmenter le délai d’inactivité et/ou d’utiliser un mécanisme de conservation de connexion TCP active si vous constatez que des connexions expirent. Pour plus d’informations sur les réinitialisations TCP, les délais d’inactivité et conservation de connexion TCP active, consultez Réinitialisation TCP du Load Balancer et délai d’inactivité dans Azure.

Configurer l’interface loopback lors de la configuration d’une adresse IP flottante

Si vous activez les adresses IP flottantes, assurez-vous de disposer d’une interface de bouclage dans le système d’exploitation invité. Celle-ci doit être configurée avec l’adresse IP front-end de l’équilibreur de charge. L’option Floating IP doit être activée si vous voulez réutiliser le port principal dans plusieurs règles. Le clustering à des fins de haute disponibilité et les appliances virtuelles réseau constituent des cas d’utilisation de la réutilisation de ports. Pour plus d’informations, consultez Configuration de l’IP flottante pour Azure Load Balancer.

Implémenter les meilleures pratiques concernant la configuration d’un équilibreur de charge de passerelle

Séparez le trafic approuvé et non approuvé sur deux interfaces de tunnel différentes. Utilisez le type d’interface de tunnel externe pour le trafic non approuvé (ou pas encore inspecté/géré) et utilisez le type d’interface de tunnel interne pour le trafic approuvé/inspecté. Cette meilleure pratique de sécurité garantit l’isolation du trafic approuvé et non approuvé. Elle permet un contrôle et une résolution des problèmes de trafic plus précis.

Assurez-vous de porter le MTU de vos NVA à au moins 1 550, voire à la limite recommandée de 4 000 dans les scénarios utilisant des trames jumbo. Si vous n’augmentez pas la limite MTU, vous risquez de subir des pertes de paquets en raison de l’augmentation de la taille des autres paquets générés par les en-têtes VXLAN.

Annonces de mise hors service

Outre les améliorations et mises à jour apportées à Azure Load Balancer, certaines fonctionnalités font également l’objet d’une dépréciation. Vous devez vous informer et vous assurer d’apporter les modifications nécessaires pour éviter toute interruption de service potentielle. Pour obtenir la liste complète des annonces de mise hors service, consultez la page Mises à jour Azure et appliquez le filtre « Load Balancer » sous « Produits » et « Mises hors service » sous « Type de mise à jour ».

Utiliser ou basculer vers Standard Load Balancer

Basic Load Balancer a été retiré du service le 30 septembre 2025. Si vous utilisez toujours Basic Load Balancer, effectuez une mise à niveau vers Standard Load Balancer dès que possible. Standard Load Balancer apporte des améliorations significatives, notamment des performances élevées, une latence ultra-faible, une sécurité par défaut et un SLA de 99,99% disponibilité.

Ne pas utiliser l’accès sortant par défaut

À l’avenir, vous ne devez plus utiliser l’accès sortant par défaut. Assurez-vous d’avoir défini une méthode de trafic sortant explicite pour toutes les machines virtuelles. Cette approche offre une meilleure sécurité et un meilleur contrôle sur la façon dont vos machines virtuelles se connectent à Internet. L’accès sortant par défaut a été supprimé le 31 mars 2026 et les machines virtuelles créées après cette date doivent utiliser l’une des solutions sortantes suivantes pour communiquer avec Internet :

• Associer une passerelle NAT au sous-réseau
• Utiliser une ou plusieurs adresses IP frontales d’un Load Balancer pour le trafic sortant via des règles de trafic sortant
• Assigner une adresse IP publique de niveau d’instance à la machine virtuelle

Étapes suivantes