Aller au contenu

AWS Mis à jour le 2026-07-04

Haute disponibilité sur AWS : des architectures multi-AZ qui survivent aux vraies pannes

Une configuration de haute disponibilité AWS qui tient quand une zone se dégrade pour vrai : répartition de charge multi-AZ, autoscaling avec de la capacité à perdre, bases Multi-AZ, NAT par zone, et les tests de panne qui le prouvent.

Une configuration de haute disponibilité AWS qui fonctionne, c’est un seul patron appliqué avec constance : chaque couche roule dans au moins deux zones de disponibilité avec de la capacité pour en perdre une, ou bascule automatiquement vers une autre zone sans humain dans la boucle. Répartiteur de charge sur plusieurs zones, groupe d’autoscaling sur les mêmes zones avec de la marge, base de données Multi-AZ, une passerelle NAT par zone, et aucun état prisonnier d’une instance unique. La plupart des environnements « hautement disponibles » échouent ce test sur exactement une couche — et cette couche fixe la disponibilité de tout ce qui est au-dessus.

Ce qui se passe

Les zones de disponibilité sont des groupes de centres de données physiquement séparés dans une région, reliés par des liens à faible latence; le contrat pratique est qu’elles tombent en panne indépendamment. La conception multi-AZ transforme « une zone a passé une mauvaise journée » d’une panne en une réduction de capacité. Mais le contrat ne paie que si chaque couche l’honore, et les vrais événements de zone sont rarement des coupures franches — ils sont partiels : taux d’erreurs élevés, réseau d’une zone qui se dégrade, ralentissements EBS dans une seule zone. Les architectures survivent à ces « pannes grises » quand chaque couche peut détecter et contourner une zone malade toute seule — les vérifications de santé du répartiteur qui éjectent les cibles malades, l’autoscaling qui remplace les instances dans les zones survivantes, la base de données qui promeut son instance de secours.

Les angles morts récurrents, ce sont les singletons. RDS sans Multi-AZ activé. Une seule passerelle NAT, qui fait dépendre la sortie de chaque sous-réseau privé d’une seule zone. Une machine de tâches planifiées ou un consommateur de file qui existe exactement une fois. L’état de session sur le disque de l’instance, si bien que perdre une zone déconnecte la moitié des utilisateurs même si « rien n’est tombé ». Chaque singleton plafonne en silence la disponibilité du système entier, peu importe la redondance du reste. Le multi-AZ a aussi un coût modeste et réel : les instances de secours facturent comme des primaires, les passerelles NAT supplémentaires facturent à l’heure plus le traitement de données, et le transfert inter-AZ est mesuré — c’est pourquoi chaque singleton a habituellement un défenseur qui pointe la facture.

Quoi vérifier en premier

  • La répartition réelle de la capacité par zone. Pas le diagramme — les instances réelles. Deux zones sur papier et 90 % de la capacité dans une seule, c’est un système mono-AZ avec des étapes en plus.
  • Le drapeau Multi-AZ de la base de données. Un champ, vérifié en quelques secondes, et le trou le plus fréquent.
  • Le nombre et l’emplacement des passerelles NAT. Un seul NAT au total, ou des NAT dans chaque zone mais des tables de routage qui pointent toutes vers le même — les deux sont le même singleton.
  • L’état sur les instances. Sessions, téléversements, caches qui comptent. Si le disque d’une instance est précieux, la couche n’est pas redondante.
  • Le calcul de capacité. Deux instances à 80 % de charge chacune ne survivent pas à la perte d’une. N+1 veut dire que les zones survivantes portent la pointe.

Comment vérifier

# Où vit vraiment la capacité, par zone
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].Placement.AvailabilityZone' | sort | uniq -c

# La base de données est-elle vraiment Multi-AZ?
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,AvailabilityZone,SecondaryAvailabilityZone]' \
  --output table

# ASG : zones et capacité saine
aws autoscaling describe-auto-scaling-groups \
  --query 'AutoScalingGroups[].[AutoScalingGroupName,AvailabilityZones,DesiredCapacity,MinSize]'

# Les cibles sont-elles saines dans chaque zone servie par le répartiteur?
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:ca-central-1:123456789012:targetgroup/prod/abc123 \
  --query 'TargetHealthDescriptions[].[Target.Id,Target.AvailabilityZone,TargetHealth.State]' \
  --output table

# Un NAT ou plusieurs, et où
aws ec2 describe-nat-gateways \
  --query 'NatGateways[].[NatGatewayId,SubnetId,State]' --output table

Dans la console, EC2 > Load Balancers > (sélection) > Network mapping montre quelles zones le répartiteur sert, et RDS > Databases > (sélection) > Configuration montre l’état Multi-AZ et la zone de l’instance de secours. Le comportement d’Elastic Load Balancing — y compris la différence de répartition inter-zones entre ALB (activée par défaut) et NLB (désactivée par défaut au niveau du répartiteur) — est documenté à https://docs.aws.amazon.com/elasticloadbalancing/; cette différence de défaut compte quand une zone n’a plus qu’une seule cible saine.

La démarche

  1. Régler la fondation des sous-réseaux d’abord. Sous-réseaux publics et privés dans au moins deux zones, routage symétrique par zone — la disposition de la conception de sous-réseaux multi-AZ. Tout le reste se construit là-dessus.
  2. Rendre la base de données Multi-AZ. Pour RDS, activer Multi-AZ est une modification avec une brève interruption de bascule au moment de l’application — planifiez-la. La bascule est automatique et se termine typiquement en quelques dizaines de secondes à deux minutes. Quand quelqu’un demande si ça devrait plutôt être multi-région, le cadre de réponse est dans Multi-AZ ou multi-région.
  3. Étaler et tamponner la couche applicative. ASG sur les zones avec un MinSize qui donne N+1, vérifications de santé ELB sur le chemin applicatif (pas juste TCP), et réglages ajustés pour que l’éjection soit plus rapide que votre patience — voyez l’ajustement des vérifications de santé.
  4. Éliminer les singletons d’état. Les sessions vers Redis ou DynamoDB, les téléversements vers S3, les caches reconstructibles. Le test : terminer n’importe quelle instance en plein jour devrait être un non-événement.
  5. Une passerelle NAT par zone, avec routage par zone. La table de routage de chaque sous-réseau privé pointe vers le NAT de sa propre zone, pour qu’une panne de zone n’emporte que sa propre sortie.
  6. Trouver les singletons cachés. L’instance de tâches planifiées, le consommateur de file solitaire, le bastion dont tout le monde dépend, le Redis autogéré sur une seule machine. Chacun reçoit de la redondance, une bascule, ou une acceptation de risque écrite.
  7. Le prouver avec un test de panne. En fenêtre de maintenance : terminez une instance, forcez une bascule RDS (aws rds reboot-db-instance --db-instance-identifier prod-db --force-failover), et observez ce que les utilisateurs verraient. Une conception HA non testée est une hypothèse.

Quand c’est la mauvaise approche

Le multi-AZ complet est de la surconception pour les charges qui tolèrent des heures d’arrêt — un outil de rapports interne restauré d’un instantané en deux heures ne justifie peut-être pas une base de secours qui facture jour et nuit. Le multi-AZ ne fait rien non plus contre les pannes régionales, les mauvais déploiements, la corruption de données ou les tables supprimées; ça prend des sauvegardes et un plan de reprise, pas plus de zones. Et si l’application elle-même est un monolithe qui garde son état en mémoire par conception, achetez la redondance à la couche de données et soyez honnête : la couche applicative bascule avec un redémarrage, pas de façon transparente.

Erreurs fréquentes

  • Sous-réseaux multi-AZ, capacité mono-AZ. Le VPC couvre trois zones; le compte désiré de l’ASG est 1.
  • Des vérifications de santé qui mentent. Un / qui retourne 200 depuis un processus dont la connexion à la base est morte garde une cible malade en service.
  • Deux de chaque, à 80 % de charge chacun. La redondance sans marge échoue exactement quand on en a besoin.
  • Ne jamais tester la bascule, ou seulement au lancement. La dérive casse la bascule en silence; le premier vrai événement de zone devient le test.

Garder le contrôle

  • Mettez des alarmes sur le déséquilibre entre zones et sur le compte d’hôtes malsains par groupe de cibles, pas seulement sur la capacité totale.
  • Refaites le test de panne chaque trimestre : une instance terminée, une bascule de base forcée, chronométrées et observées.
  • Posez la question du singleton en revue pour chaque nouveau service : « qu’arrive-t-il quand la zone où ça roule se dégrade? »
  • Surveillez le transfert inter-AZ dans la facture; c’est la taxe qui tente les gens de tout reconcentrer discrètement dans une zone.
  • Gardez le calcul de capacité par écrit : charge de pointe, capacité par instance, et la cible N+1 par couche.

Le multi-AZ est le palier de disponibilité le moins cher qu’AWS offre précisément parce que les zones existent déjà — le travail consiste à refuser qu’une couche se soustraie à leur usage. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.