Multi-AZ ou Multi-Région pour RDS / Aurora — ce que le basculement vous achète réellement

La revue d’architecture pose la même question chaque fois qu’un SaaS prend la disponibilité au sérieux : « on a Multi-AZ sur le RDS, est-ce qu’on a aussi besoin d’Aurora Global Database dans une seconde région ? » La réponse n’est presque jamais celle que la question suggère. Multi-AZ couvre les modes de défaillance qui surviennent réellement — panne matérielle d’instance, blip réseau dans une AZ, correctif qui tourne mal. Multi-Région couvre les rares — panne régionale, régulateur qui veut les données physiquement ailleurs, client sur un autre continent qui exige des lectures sous 100ms. Confondre les deux, c’est payer pour la mauvaise protection tout en restant exposé.

Ce qui se passe

Multi-AZ et Multi-Région sont deux topologies de réplication différentes bâties sur deux modèles de cohérence différents.

Multi-AZ (une région, standby synchrone). Activé sur RDS via MultiAZ: true et sur Aurora via un cluster multi-AZ avec des instances reader dans des AZ distinctes. Sur RDS, les écritures sont validées au primaire et au standby avant que l’accusé de réception revienne au client — le standby est une copie chaude au niveau du stockage. Sur Aurora, le volume de cluster est répliqué sur six nœuds de stockage répartis sur trois AZ, donc la couche stockage est intrinsèquement multi-AZ même avec un seul writer. Le basculement est automatique, déclenché par des health checks, et le point d’entrée DNS bascule. Temps de basculement réels : 30–90 secondes sur RDS, 10–30 secondes sur Aurora.

Multi-Région (Aurora Global Database, secondaire asynchrone). Un second cluster Aurora dans une autre région se réplique depuis le primaire en utilisant la réplication au niveau du volume de stockage, avec un retard typique sous la seconde en charge normale. Le secondaire est en lecture seule jusqu’à promotion explicite. La promotion est un appel API manuel (ou une Step Function que vous câblez), elle rompt le lien de réplication, et prend une à deux minutes. RTO avec un runbook manuel : 5–15 minutes ; avec une promotion entièrement automatisée : 2–5 minutes. RPO : retard de réplication au moment de la défaillance — sous la seconde en régime permanent, potentiellement plus long si la région primaire a disparu en plein batch.

Les compromis se présentent ainsi :

La conversation se brouille parce que les deux fonctionnalités sont vendues comme « haute disponibilité ». Ce ne sont pas le même type de HA. Multi-AZ est la HA opérationnelle — elle maintient la base de données en vie à travers les défaillances qui surviennent plusieurs fois par an. Multi-Région est la reprise après sinistre — elle maintient l’entreprise opérationnelle à travers les défaillances qui surviennent une fois par décennie.

Comment vérifier

Commencez par demander ce que vous essayez réellement de protéger. La réponse honnête pour la plupart des SaaS est : « on veut que notre base survive à un redémarrage EC2 dans une AZ à 03:00 un dimanche ». C’est Multi-AZ. La réponse malhonnête est « on veut un basculement régional complet » sans runbook, sans stratégie DNS et sans plan pour la couche applicative — c’est payer pour Multi-Région tout en opérant comme Multi-AZ.

Vérifiez ce que vous avez aujourd’hui. Pour RDS :

aws rds describe-db-instances \
  --db-instance-identifier prod-db-1 \
  --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,AvailabilityZone,SecondaryAvailabilityZone]' \
  --output table

Pour Aurora, le writer est dans une AZ mais le volume du cluster s’étend sur trois :

aws rds describe-db-clusters \
  --db-cluster-identifier prod-aurora-1 \
  --query 'DBClusters[].[DBClusterIdentifier,AvailabilityZones,MultiAZ,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output json

Pour Aurora Global, le secondaire apparaît comme un cluster distinct dans une autre région, lié au primaire :

aws rds describe-global-clusters \
  --global-cluster-identifier prod-global-1 \
  --query 'GlobalClusters[].[GlobalClusterIdentifier,Status,GlobalClusterMembers[*].[DBClusterArn,IsWriter]]' \
  --output json

Puis vérifiez que la couche applicative est prête pour la topologie choisie. Le basculement Multi-AZ change l’IP sous-jacente du writer endpoint, pas le nom DNS — l’application doit gérer une brève chute de connexion et se reconnecter en moins de 60 secondes. Les pools de connexions avec détection de connexion morte (pgbouncer, RDS Proxy, ou HikariCP avec validationQuery) gèrent cela ; les pools sans cette détection se bloquent pendant 5–10 minutes jusqu’à expiration du keepalive TCP.

Pour Multi-Région, la liste de vérification est plus longue. L’application doit pouvoir se rediriger vers la nouvelle région. Enregistrements Route 53 avec health check, target groups ALB dans les deux régions, secrets et config de l’application répliqués dans la région secondaire, buckets S3 répliqués entre régions, runbook automatisé de promotion-et-bascule — tout doit être répété. Une base Multi-Région sans plan de basculement applicatif est un Multi-AZ à double coût.

La correction

Choisissez la topologie qui correspond aux modes de défaillance que vous prenez vraiment au sérieux.

Par défaut pour un SaaS de production : Multi-AZ. Chaque base de production, chaque environnement qui prend une écriture client réelle, tourne en Multi-AZ. Non négociable. Le coût est environ une prime de 100% sur la ligne compute de la base, parfois moins sur Aurora parce que le reader est aussi un endpoint de lecture utilisable. La prime achète le basculement automatique face aux défaillances d’AZ, qui surviennent assez souvent pour justifier la ligne.

Ajoutez Multi-Région seulement quand l’exigence est réelle. Les exigences réelles sont : réglementaires (les données doivent être disponibles depuis une seconde région pour conformité), commerciales (un SLA promet la continuité de service à travers une panne régionale), ou géographiques (une base clientèle substantielle a besoin de lectures dans sa région). « On pourrait en vouloir un jour » n’est pas une exigence réelle.

Si vous partez en Multi-Région, construisez d’abord le basculement applicatif. La promotion de la base est la partie facile. La partie difficile, ce sont les secrets dans Secrets Manager, les files SQS, les buckets S3, la config en cache dans ElastiCache, les domaines personnalisés API Gateway, la fédération SAML qui pointe sur le fournisseur d’identité de la région primaire. Une promotion de base sans bascule applicative donne une base en bonne santé recevant un trafic qui ne peut pas l’atteindre.

Répétez le basculement trimestriellement. Le basculement Multi-AZ est testable avec aws rds reboot-db-instance --force-failover — planifiez-le dans une fenêtre calme, observez la reconnexion de l’application, journalisez le temps. La promotion Multi-Région est testable dans un global cluster hors-prod — promouvez le secondaire, exécutez un smoke test, puis ré-établissez le global cluster dans l’autre sens. Une topologie de basculement qui n’a pas été exercée en production au cours du dernier trimestre n’est pas vérifiée, peu importe ce que dit la documentation.

N’exécutez pas Multi-Région avec une application monorégionale. C’est le gaspillage de budget le plus fréquent que nous voyons — Aurora Global Database payé plein tarif, sans runbook pour s’en servir, sans stratégie DNS, et une couche applicative qui pointe sur un endpoint primaire codé en dur. Si le runbook est « on appelle quelqu’un et on improvise », la seconde région est de la paperasse, pas de la protection.

La décision est essentiellement binaire. Soit l’entreprise prend une panne régionale assez au sérieux pour payer l’appareil Multi-Région complet et le répéter, soit non. S’asseoir au milieu — payer Aurora Global Database sans jamais s’en servir — est le pire des deux mondes.

Stack Harbor conçoit et opère les topologies RDS / Aurora en production dans le cadre de Gestion AWS et de la couche Environnements infogérés. Si votre posture base de données se résume à « case Multi-AZ cochée + espoir », commencez par une consultation d’infrastructure.