RDS Multi-AZ : haute disponibilité, basculement automatique et impact réel sur les performances

Quand une instance RDS tombe en production à 3h du matin, la question n'est pas 'pourquoi Multi-AZ n'était pas activé' — c'est 'combien de temps avant que le basculement soit terminé'. Comprendre ce que le Multi-AZ RDS apporte réellement, et ce qu'il ne fait pas, évite des surprises architecturales coûteuses.

TL;DR — RDS Multi-AZ en un coup d'œil

Dimension	Comportement Multi-AZ
Objectif principal	Haute disponibilité et reprise automatique après incident
Réplication	Synchrone vers l'instance secondaire (standby)
Basculement automatique	Oui — RDS détecte la défaillance et redirige l'endpoint DNS
Gain de performance en lecture	Non — le standby ne sert pas de trafic en lecture
Durée typique de basculement	Varie selon le moteur et la charge — consultez la documentation AWS
Coût	Environ le double d'une instance Single-AZ (instance secondaire facturée)
Alternative pour la lecture	Read Replicas (réplication asynchrone, endpoint séparé)

Comment fonctionne RDS Multi-AZ

RDS Multi-AZ provisionne une instance secondaire (standby) dans une zone de disponibilité différente de la primaire, au sein de la même région. La réplication entre les deux est synchrone : chaque transaction validée sur la primaire est écrite sur le standby avant que l'acquittement ne soit renvoyé à l'application. Ce mécanisme garantit qu'aucune donnée validée n'est perdue en cas de basculement.

Le point critique que beaucoup d'équipes ratent au départ : le standby est passif. Il ne répond à aucune requête de lecture ou d'écriture tant que la primaire est opérationnelle. Il n'apparaît pas comme un endpoint séparé. Son seul rôle est d'être prêt à prendre le relais.

graph TD App["Application"] -->|"Écriture via endpoint DNS"| Primary["Instance Primaire
AZ us-east-1a"] Primary -->|"Réplication synchrone"| Standby["Instance Standby
AZ us-east-1b"] Monitor["RDS Health Monitor"] -->|"Surveille"| Primary Monitor -->|"Défaillance détectée"| Failover["Basculement initié"] Failover -->|"Promotion du standby"| NewPrimary["Nouvelle Primaire
AZ us-east-1b"] Failover -->|"Mise à jour DNS"| DNS["Endpoint DNS RDS"] DNS -->|"Reconnexion transparente"| App

1. Écriture applicative : l'application écrit via l'endpoint DNS RDS, qui pointe vers la primaire.
2. Réplication synchrone : RDS réplique chaque transaction vers le standby dans une AZ distincte avant de confirmer la validation.
3. Surveillance continue : RDS surveille la santé de la primaire (infrastructure, OS, moteur de base de données).
4. Détection de défaillance : en cas d'incident détecté, RDS initie le basculement automatiquement.
5. Bascule DNS : l'endpoint DNS est redirigé vers le standby promu en nouvelle primaire. L'application se reconnecte sans modification de configuration.

Ce que Multi-AZ protège — et ce qu'il ne couvre pas

RDS initie un basculement automatique dans plusieurs scénarios documentés : défaillance de la zone de disponibilité primaire, panne de l'instance sous-jacente, défaillance du système d'exploitation ou du moteur de base de données, et lors de certaines opérations de maintenance planifiée (comme les mises à jour de version mineures).

En revanche, Multi-AZ ne protège pas contre la corruption logique des données — si une requête DELETE sans WHERE s'exécute sur la primaire, elle est répliquée de façon synchrone sur le standby. Pour ce scénario, les snapshots automatiques et le Point-in-Time Recovery (PITR) sont les bons outils.

Multi-AZ ressemble à un groupe électrogène de secours : il est là pour les pannes d'infrastructure, pas pour les erreurs humaines. Si vous coupez le câble vous-même, le générateur ne change rien.

Impact réel sur les performances — la confusion fréquente

La question revient régulièrement en revue d'architecture : 'Est-ce que Multi-AZ améliore les performances de lecture ?' La réponse courte est non. Le standby ne sert aucun trafic.

Il existe cependant un effet secondaire observable sur les écritures : la réplication synchrone introduit une latence additionnelle par rapport à une instance Single-AZ, car chaque transaction doit être confirmée par le standby avant validation. Cet impact est généralement faible dans des conditions réseau normales au sein d'une région AWS, mais il est mesurable sous forte charge d'écriture.

Si l'objectif est de distribuer la charge de lecture, la bonne solution est les Read Replicas RDS — des instances séparées avec leurs propres endpoints, utilisant une réplication asynchrone. Les Read Replicas et Multi-AZ sont complémentaires et peuvent être combinés sur la même instance primaire.

graph LR Primary["Instance Primaire"] -->|"Synchrone
Aucun trafic applicatif"| Standby["Multi-AZ Standby
Basculement uniquement"] Primary -->|"Asynchrone
Trafic de lecture"| RR1["Read Replica 1
Endpoint dédié"] Primary -->|"Asynchrone
Trafic de lecture"| RR2["Read Replica 2
Endpoint dédié"] AppWrite["Écritures"] --> Primary AppRead["Lectures"] --> RR1 AppRead --> RR2

1. Multi-AZ Standby : réplication synchrone, aucun trafic applicatif, basculement automatique uniquement.
2. Read Replica : réplication asynchrone, endpoint dédié, sert le trafic de lecture, pas de basculement automatique natif vers la primaire.
3. Les deux peuvent coexister sur la même instance primaire avec des objectifs distincts.

Activer et vérifier Multi-AZ sur une instance existante

L'activation de Multi-AZ sur une instance existante déclenche une opération de modification qui peut provoquer un bref redémarrage selon le moteur et la version. Planifiez cette opération pendant une fenêtre de maintenance ou activez l'option 'Apply Immediately' en connaissance de cause.

Activer Multi-AZ via AWS CLI

aws rds modify-db-instance \
  --db-instance-identifier mon-instance-rds \
  --multi-az \
  --apply-immediately \
  --region us-east-1

Vérifier le statut Multi-AZ

aws rds describe-db-instances \
  --db-instance-identifier mon-instance-rds \
  --region us-east-1 \
  --query 'DBInstances[0].{MultiAZ:MultiAZ,Status:DBInstanceStatus,SecondaryAZ:SecondaryAvailabilityZone}'

La sortie doit afficher MultiAZ: true et l'AZ secondaire utilisée. Si SecondaryAvailabilityZone est absent de la réponse, l'instance n'a pas encore terminé le provisionnement du standby.

Consulter les événements de basculement

aws rds describe-events \
  --source-identifier mon-instance-rds \
  --source-type db-instance \
  --duration 1440 \
  --region us-east-1

Les événements de basculement apparaissent avec le message Multi-AZ instance failover started suivi de Multi-AZ instance failover completed. C'est la source de vérité pour mesurer la durée réelle d'un basculement en production.

Tester le basculement manuellement

RDS expose une API de reboot avec basculement forcé — utile pour valider que l'application gère correctement la reconnexion et mesurer l'impact réel sur votre charge de travail spécifique.

aws rds reboot-db-instance \
  --db-instance-identifier mon-instance-rds \
  --force-failover \
  --region us-east-1

Exécutez ce test en environnement de staging avec une charge représentative. Observez combien de temps votre application met à se reconnecter et si les connexions persistantes sont correctement gérées par votre pool de connexions.

Politique IAM minimale pour gérer Multi-AZ

Pour permettre à un opérateur ou à un pipeline CI/CD d'activer Multi-AZ, de redémarrer une instance et de consulter les événements, voici la politique IAM au moindre privilège :

🔽 Afficher la politique IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RDSModifyAndRebootSpecificDB",
      "Effect": "Allow",
      "Action": [
        "rds:ModifyDBInstance",
        "rds:RebootDBInstance"
      ],
      "Resource": "arn:aws:rds:us-east-1:123456789012:db:mon-instance-rds"
    },
    {
      "Sid": "RDSDescribeGlobal",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:DescribeEvents"
      ],
      "Resource": "*"
    }
  ]
}

Les actions rds:DescribeDBInstances et rds:DescribeEvents ne supportent pas les permissions au niveau de la ressource individuelle dans le modèle IAM RDS — elles nécessitent Resource: *. Les actions de modification et de redémarrage, en revanche, acceptent l'ARN de l'instance spécifique.

Symptôme terrain : basculement silencieux et connexions bloquées

Un scénario que l'on voit régulièrement en production : Multi-AZ est activé, le basculement se déclenche correctement, le DNS est mis à jour — mais l'application reste bloquée pendant plusieurs minutes après la fin du basculement.

Le diagnostic initial pointe vers RDS : les métriques CloudWatch montrent que la nouvelle primaire est opérationnelle, les événements confirment que le basculement est terminé. L'équipe commence à investiguer le moteur de base de données.

La vraie cause : le pool de connexions applicatif conserve les connexions TCP vers l'ancienne adresse IP résolue avant le basculement. Le TTL DNS de l'endpoint RDS est court (généralement 5 secondes), mais si l'application ou le driver JDBC met en cache l'IP résolue indéfiniment, le basculement DNS ne suffit pas.

Le correctif n'est pas côté RDS — c'est la configuration du pool de connexions. Vérifiez que votre driver respecte le TTL DNS et que le pool est configuré pour invalider les connexions mortes (testOnBorrow, validationQuery, ou équivalent selon le framework). C'est un comportement d'interaction entre la résolution DNS côté client et le mécanisme de basculement RDS qui n'est pas immédiatement évident à la lecture de la documentation de chaque composant séparément.

Multi-AZ et RDS Multi-AZ DB Cluster — ne pas confondre

AWS propose deux offres distinctes sous le terme 'Multi-AZ' :

• Multi-AZ DB Instance : le mode classique décrit dans cet article — une primaire, un standby passif, basculement automatique.
• Multi-AZ DB Cluster : disponible pour certains moteurs (MySQL, PostgreSQL), avec une primaire et deux instances de lecture dans des AZ distinctes. Les instances de lecture servent du trafic en lecture et participent au quorum de basculement. C'est une architecture différente avec des caractéristiques de performance et de disponibilité distinctes.

Si vous voyez des références à des endpoints de lecture dans un contexte Multi-AZ, vérifiez si la documentation parle du mode 'DB Cluster' et non du mode 'DB Instance' standard.

Conclusion — RDS Multi-AZ et prochaines étapes

RDS Multi-AZ est un mécanisme de haute disponibilité, pas un levier de performance. Il protège contre les défaillances d'infrastructure via une réplication synchrone et un basculement automatique sans modification de la chaîne de connexion applicative. Pour la distribution de charge en lecture, les Read Replicas sont la bonne réponse.

Étapes recommandées :

• Activer Multi-AZ sur toutes les instances RDS de production via la console ou le CLI.
• Tester le basculement avec --force-failover en staging et mesurer le temps de reconnexion applicatif réel.
• Vérifier la configuration du pool de connexions pour s'assurer qu'il respecte le TTL DNS.
• Consulter la documentation officielle RDS Multi-AZ pour les spécificités par moteur de base de données.

Glossaire

Terme	Définition
Standby	Instance RDS secondaire passive maintenue en synchronisation avec la primaire dans une AZ distincte.
Basculement (Failover)	Processus automatique par lequel RDS promeut le standby en primaire et redirige l'endpoint DNS.
Réplication synchrone	Mode de réplication où chaque transaction est confirmée sur le standby avant validation sur la primaire.
Read Replica	Instance RDS séparée avec réplication asynchrone, exposant un endpoint dédié pour les lectures.
PITR (Point-in-Time Recovery)	Capacité de restaurer une instance RDS à un instant précis dans le passé à partir des logs de transaction.

Related Posts

• 📄 Restauration RDS depuis un Snapshot : Nouvelle Instance ou Écrasement ?