6.66 - AWS RDS Répliques en lecture seule vs Replique Multi AZ.mp4

RDS propose deux mécanismes de réplication aux objectifs très différents : les read replicas pour la scalabilité en lecture, et le déploiement multi-AZ pour la haute disponibilité. Avec les read replicas, on peut créer jusqu'à 5 répliques par instance master, dans la même AZ, dans d'autres AZ de la même région, voire dans d'autres régions. La réplication est asynchrone : les données écrites sur le master se propagent aux répliques avec une légère latence — éventuellement consistantes mais cohérentes à terme.

Côté usage applicatif, les requêtes en écriture vont toujours vers le master, et les requêtes SELECT peuvent être routées vers une réplique pour soulager le master. Une réplique peut aussi être promue en master autonome en cas de défaillance (mais cela exige de mettre à jour les chaînes de connexion de l'application). Les opérations INSERT / UPDATE / DELETE sont impossibles directement sur une réplique : il faut toujours passer par le master.

Cas d'usage des read replicas

• Application de production normale + base de monitoring/reporting qui tape uniquement sur la réplique.
• Travaux d'analytics ou ETL hors heures de pointe sans impacter la production.
• Limites : SELECT uniquement, pas de modifs sur la réplique.
• Coût de transit réseau si la réplique est dans une autre AZ ou région.
• Pour économiser : placer la réplique dans la même AZ que le master (zéro trafic inter-AZ facturé).

Le déploiement multi-AZ répond à un besoin radicalement différent : la haute disponibilité et le Disaster Recovery. Le master situé dans us-east-1a est répliqué de façon synchrone dans une autre AZ comme us-east-1b. La réplique est strictement identique en temps réel, mais elle n'est jamais sollicitée en lecture : son seul rôle est d'être prête en cas de panne du master.

Quand le master tombe (problème réseau, panne stockage ou défaillance d'instance), un nom DNS associé à la ressource RDS permet à AWS de basculer automatiquement les requêtes vers la réplique multi-AZ — sans intervention manuelle ni modification côté application. Important : le multi-AZ n'est pas un mécanisme de scaling, puisque la réplique n'est jamais active en lecture. Enfin, pour mettre en place un véritable plan de reprise d'activité (DRP), il faut que les répliques soient configurées en multi-AZ.