7 85 Stratégie de routage par basculement

La stratégie de routage par basculement (failover) repose sur deux cibles : une primaire et une secondaire (souvent placée dans une région différente pour le disaster recovery). Tant que le health check sur la cible primaire reste sain, Route 53 renvoie l'IP de la primaire. Si la primaire tombe (trois échecs consécutifs), Route 53 bascule automatiquement vers la cible secondaire.

Configuration

Dans Route 53, créez un enregistrement avec la politique Basculement, type A, TTL 60 secondes. Première étape : définir la cible primaire — par exemple l'instance Irlande. Sélectionnez « Primaire », saisissez l'IP, associez le health check correspondant (hc-irlande), donnez un identifiant unique. Sans health check, le basculement ne peut pas fonctionner.

Deuxième étape : créer un second enregistrement portant le même nom, cette fois marqué « Secondaire ». L'IP est celle de l'instance Asie (par exemple Tokyo), associée à son health check. Si la primaire tombe ET que la secondaire est saine, c'est cette dernière qui sera renvoyée. Si les deux tombent, Route 53 renvoie quand même la primaire (mieux que rien) et déclenche les alarmes CloudWatch éventuellement configurées.

Test du basculement

Pour valider le basculement, accédez à l'URL : la primaire (Irlande) répond. Ouvrez en parallèle la console des health checks pour suivre les changements d'état. Arrêtez l'instance EC2 Irlande depuis la console. Au bout de quelques cycles de vérification (trois échecs de 30 s), le health check passe en unhealthy. Route 53 commence à renvoyer l'IP de la secondaire, et le rafraîchissement du navigateur (après expiration du TTL) affiche désormais la page servie par l'instance Tokyo.

• Une seule paire primaire/secondaire par nom d'enregistrement
• Health check obligatoire sur les deux cibles
• TTL faible recommandé (60 s) pour minimiser le délai de bascule client
• Combinable avec CloudWatch pour alerter sur la bascule
• Idéal pour les architectures actif/passif disaster recovery