Amazon Route 53 Cheat Sheet — DNS, routing policies et failover

1. Route 53 en une phrase

Amazon Route 53 est le service DNS managé d’AWS. Il permet d’enregistrer des noms de domaine, de gérer des zones DNS, de créer des enregistrements DNS, de router le trafic vers des ressources AWS ou externes, et de mettre en place du failover DNS.

À retenir :

• Route 53 sert à associer un nom de domaine à une destination.
• Il peut router vers des ressources AWS comme CloudFront, Load Balancer, API Gateway, S3 website endpoint ou EC2.
• Il peut aussi router vers des ressources externes.
• Il supporte plusieurs politiques de routage : simple, weighted, latency, failover, geolocation, geoproximity, multivalue answer, IP-based.
• Il peut surveiller la santé de ressources avec des health checks.
• AWS présente Route 53 autour de trois fonctions principales : enregistrement de domaines, routage DNS et health checking.

Ressources officielles :

• Amazon Route 53 Developer Guide.
• Choosing a routing policy.

2. Les concepts essentiels Route 53

• Domain name
  • Nom lisible par les humains.
  • Exemple : lecloudfacile.com.
• DNS
  • Système qui traduit un nom de domaine en adresse IP ou en autre nom DNS.
  • Exemple : www.example.com vers une adresse IP ou vers un Load Balancer.
• Hosted Zone
  • Conteneur DNS qui stocke les enregistrements d’un domaine.
  • Exemple : une hosted zone pour example.com.
• Public Hosted Zone
  • Zone DNS accessible publiquement sur Internet.
  • À utiliser pour les domaines publics.
• Private Hosted Zone
  • Zone DNS privée associée à un ou plusieurs VPC.
  • À utiliser pour la résolution DNS interne dans AWS.
• Record
  • Entrée DNS dans une hosted zone.
  • Exemple : www.example.com A 192.0.2.10.
• Routing Policy
  • Logique utilisée par Route 53 pour répondre aux requêtes DNS.
  • Exemple : simple, weighted, latency, failover.
• Health Check
  • Vérification de santé d’une ressource.
  • Route 53 peut surveiller un endpoint, un groupe de health checks ou une alarme CloudWatch.
• Alias Record
  • Enregistrement spécial Route 53 qui pointe vers certaines ressources AWS.
  • Exemple : CloudFront, Elastic Load Balancer, API Gateway, S3 website endpoint.
  • Souvent préféré à un CNAME pour les ressources AWS compatibles.

3. DNS : ce qu’il faut comprendre

Le DNS fonctionne comme un annuaire.

Quand un utilisateur saisit :

www.example.com

Le système DNS cherche la réponse associée :

• une adresse IPv4 ;
• une adresse IPv6 ;
• un autre nom DNS ;
• un serveur de messagerie ;
• une information de vérification ;
• ou une autre donnée DNS selon le type d’enregistrement.

À retenir :

• DNS ne transporte pas l’application.
• DNS indique seulement où aller.
• Le navigateur ou client utilise ensuite la réponse DNS pour contacter la destination.
• Une erreur DNS peut rendre une application inaccessible même si l’application fonctionne.
• Les changements DNS peuvent prendre du temps à se propager selon le TTL et les caches DNS.

4. Types d’enregistrements DNS courants

A Record

À utiliser pour :

• Associer un nom à une adresse IPv4.

Exemple :

example.com -> 203.0.113.10

À retenir :

• Très courant pour pointer vers une adresse IPv4.
• Pour les ressources AWS comme un Load Balancer, on utilise souvent un alias plutôt qu’une IP.

AAAA Record

À utiliser pour :

• Associer un nom à une adresse IPv6.

Exemple :

example.com -> 2001:db8::1

À retenir :

• Équivalent IPv6 du record A.

CNAME Record

À utiliser pour :

• Faire pointer un nom vers un autre nom DNS.

Exemple :

www.example.com -> app.example.net

À retenir :

• Ne doit pas être utilisé au niveau apex du domaine dans le DNS classique.
• Exemple d’apex : example.com.
• Route 53 propose les alias records pour résoudre ce besoin avec des ressources AWS compatibles.

---

MX Record

À utiliser pour :

• Définir les serveurs de messagerie d’un domaine.

Exemple :

example.com -> mail provider

À retenir :

• Indispensable pour recevoir des emails sur un domaine.

TXT Record

À utiliser pour :

• Vérifications de domaine.
• SPF, DKIM, DMARC.
• Validation de services tiers.

À retenir :

• Très utilisé pour prouver la propriété d’un domaine.
• Très utilisé pour la sécurité email.

NS Record

À utiliser pour :

• Définir les serveurs de noms autoritaires d’une zone DNS.

À retenir :

• Les NS indiquent quels serveurs DNS gèrent le domaine.
• Quand vous créez une public hosted zone Route 53, AWS fournit des name servers à configurer chez le registrar si Route 53 n’est pas déjà le registrar.

SOA Record

À utiliser pour :

• Informations d’autorité de la zone DNS.

À retenir :

• Créé automatiquement dans une hosted zone.
• Rarement modifié par les débutants.

5. Hosted Zones : public vs private

Public Hosted Zone

À utiliser pour :

• Un site web public.
• Une API publique.
• Un domaine Internet.
• Une application accessible par des utilisateurs externes.

Exemples :

• www.lecloudfacile.com
• api.lecloudfacile.com
• app.example.com

À retenir :

• Les enregistrements sont résolus publiquement sur Internet.
• Il faut configurer les bons name servers au niveau du registrar.
• Très souvent utilisé avec CloudFront, Load Balancer, API Gateway ou S3 website hosting.

Private Hosted Zone

À utiliser pour :

• Résolution DNS interne à un ou plusieurs VPC.
• Noms privés pour des services internes.
• Applications backend.
• Environnements multi-VPC.
• Architectures hybrides avec DNS privé.

Exemples :

• db.internal.local
• api.private.company
• service.backend.lcf

À retenir :

• Les noms ne sont pas résolus publiquement sur Internet.
• La zone doit être associée à un ou plusieurs VPC.
• Très utile pour éviter d’utiliser des adresses IP en dur dans les applications.

6. TTL : Time To Live

Le TTL indique combien de temps une réponse DNS peut être mise en cache par les résolveurs DNS.

À retenir :

• TTL court :
  • changements plus rapides ;
  • plus de requêtes DNS ;
  • utile pendant les migrations ou bascules.
• TTL long :
  • moins de requêtes DNS ;
  • meilleure efficacité de cache ;
  • changements plus lents à propager.

Bonnes pratiques :

• Utiliser un TTL court avant une migration DNS.
• Revenir à un TTL plus long après stabilisation.
• Ne pas supposer qu’un changement DNS est instantané.
• Pour du failover DNS, utiliser des TTL adaptés au temps de bascule attendu.
• Si DNSSEC signing est activé dans une hosted zone Route 53, AWS limite le TTL effectif à une semaine pour les records de cette zone.

7. Alias Records

Un alias record est un type d’enregistrement Route 53 qui permet de pointer vers certaines ressources AWS.

À utiliser pour pointer vers :

• Elastic Load Balancer.
• Amazon CloudFront distribution.
• API Gateway.
• S3 static website endpoint.
• Elastic Beanstalk environment.
• Certains endpoints AWS compatibles.

À retenir :

• Très utile pour pointer le domaine racine, par exemple example.com, vers une ressource AWS.
• Peut remplacer un CNAME dans certains cas.
• Supporte l’intégration avec plusieurs services AWS.
• Peut être utilisé avec certaines routing policies.
• Peut évaluer la santé de la cible selon le service et la configuration.

Exemple d’usage :

• example.com vers un Application Load Balancer.
• www.example.com vers une distribution CloudFront.
• api.example.com vers API Gateway.

8. Routing policies Route 53

Une routing policy définit comment Route 53 choisit la réponse DNS à retourner.

AWS liste plusieurs politiques de routage, dont failover, geolocation, latency, IP-based, multivalue answer et weighted.

9. Simple routing policy

À utiliser pour :

• Un domaine qui pointe vers une seule ressource.
• Une configuration DNS simple.
• Un site ou service avec une seule destination principale.

Exemple :

• www.example.com vers un Load Balancer unique.

À retenir :

• C’est la politique la plus simple.
• Pas de répartition avancée.
• Pas idéale pour des besoins de haute disponibilité multi-destination.
• Bon choix pour démarrer.

10. Weighted routing policy

À utiliser pour :

• Répartir le trafic selon des pourcentages.
• Faire du blue/green deployment.
• Faire du canary release.
• Tester une nouvelle version avec une petite partie du trafic.
• Migrer progressivement d’une infrastructure vers une autre.

Exemple :

• 90 % vers l’ancienne version.
• 10 % vers la nouvelle version.

À retenir :

• Les poids ne sont pas des pourcentages exacts, mais des proportions.
• Très utile pour les migrations progressives.
• Peut être combiné avec des health checks.
• Si une cible devient unhealthy et qu’un health check est configuré, Route 53 peut l’exclure des réponses selon la configuration.

11. Latency-based routing policy

À utiliser pour :

• Router les utilisateurs vers la région AWS qui offre la meilleure latence.
• Déployer une application dans plusieurs régions.
• Améliorer l’expérience utilisateur selon la localisation réseau.

Exemple :

• Utilisateurs européens vers eu-west-1.
• Utilisateurs américains vers us-east-1.
• Utilisateurs asiatiques vers ap-southeast-1.

À retenir :

• Route 53 sélectionne la région avec la latence la plus faible observée pour l’utilisateur.
• Ce n’est pas exactement un routage géographique.
• Le routage dépend de mesures de latence réseau.
• Peut être combiné avec des health checks.

12. Failover routing policy

À utiliser pour :

• Mettre en place une architecture active-passive.
• Router vers une ressource secondaire si la principale est unhealthy.
• Créer un plan de continuité de service au niveau DNS.

AWS précise que le failover routing permet de router vers une ressource quand elle est saine, ou vers une autre ressource quand la première est unhealthy.

Exemple :

• Primary : application principale.
• Secondary : site de secours, autre région, page statique S3 ou environnement standby.

À retenir :

• Très utile pour du disaster recovery.
• Nécessite des health checks bien configurés.
• Le TTL influence la rapidité perçue de la bascule.
• Route 53 supporte les configurations active-active et active-passive avec health checks ; l’active-passive utilise la failover routing policy.

13. Geolocation routing policy

À utiliser pour :

• Router selon la localisation géographique des utilisateurs.
• Afficher un contenu différent selon le pays ou le continent.
• Respecter certaines exigences locales.
• Envoyer les utilisateurs d’un pays vers une ressource spécifique.

Exemple :

• Utilisateurs du Sénégal vers une endpoint spécifique.
• Utilisateurs de France vers une autre endpoint.
• Utilisateurs non couverts vers une ressource par défaut.

À retenir :

• Basé sur la localisation géographique de l’utilisateur.
• Il faut prévoir un record par défaut.
• Utile pour contenu localisé, conformité ou expérience régionale.

14. Geoproximity routing policy

À utiliser pour :

• Router selon la proximité géographique entre utilisateurs et ressources.
• Ajuster le trafic avec un biais, appelé bias.
• Contrôler l’étendue d’une zone géographique desservie par une ressource.

À retenir :

• Plus flexible que geolocation.
• Souvent utilisé avec Route 53 Traffic Flow.
• Utile pour des architectures globales avancées.
• Demande une conception plus précise.

15. Multivalue answer routing policy

À utiliser pour :

• Retourner plusieurs réponses DNS.
• Fournir une forme simple de disponibilité.
• Répondre avec plusieurs endpoints sains.

À retenir :

• Peut être associé à des health checks.
• Ce n’est pas un Load Balancer complet.
• Le client ou resolver peut choisir parmi les réponses.
• Utile pour des services simples avec plusieurs endpoints.

16. IP-based routing policy

À utiliser pour :

• Router selon l’adresse IP source de la requête DNS.
• Définir des CIDR d’utilisateurs ou de réseaux.
• Contrôler le routage pour certains réseaux clients, partenaires ou opérateurs.

À retenir :

• Plus précis quand vous connaissez les plages IP d’origine.
• Utile pour des besoins spécifiques entreprise, partenaires ou réseaux.
• AWS le décrit comme une option pour router selon l’emplacement des utilisateurs quand vous connaissez les adresses IP d’origine du trafic.

17. Tableau de décision des routing policies

• Une seule destination
  • Simple routing.
• Répartir le trafic par proportion
  • Weighted routing.
• Tester une nouvelle version
  • Weighted routing.
• Router vers la région la plus rapide
  • Latency-based routing.
• Router selon le pays ou continent
  • Geolocation routing.
• Router selon proximité avec contrôle par bias
  • Geoproximity routing.
• Mettre en place active-passive
  • Failover routing.
• Retourner plusieurs endpoints sains
  • Multivalue answer routing.
• Router selon plages IP connues
  • IP-based routing.

18. Health Checks Route 53

Un health check permet à Route 53 de vérifier si une ressource est saine.

Route 53 health checks peut surveiller :

• un endpoint spécifique ;
• le statut d’autres health checks ;
• une alarme CloudWatch.

À utiliser pour :

• Failover DNS.
• Surveillance de disponibilité.
• Routage selon la santé des endpoints.
• Notifications en cas de changement d’état.
• Architectures multi-régions.

À retenir :

• Un health check peut vérifier HTTP, HTTPS ou TCP selon le cas.
• Il peut être associé à certains records Route 53.
• Il peut influencer les réponses DNS.
• Route 53 peut router le trafic d’une ressource unhealthy vers une ressource healthy.
• Un nouveau health check est considéré healthy jusqu’à ce que Route 53 ait assez de données pour déterminer son état réel, sauf configuration inversée.

Bonnes pratiques :

• Vérifier une vraie endpoint applicative, pas seulement un serveur allumé.
• Utiliser une page de santé légère, par exemple /health.
• Tester les scénarios d’échec.
• Configurer des alarmes.
• Éviter de supprimer un health check encore associé à des records.
• Documenter la logique de failover.

Point important :

• AWS avertit que Route 53 ne vous empêche pas de supprimer un health check associé à des records ; si vous le faites sans mettre à jour les records, le futur statut du health check devient imprévisible et peut affecter le routage DNS.

19. Failover DNS : active-active vs active-passive

Active-active failover

Principe :

• Plusieurs ressources servent le trafic en même temps.
• Route 53 choisit parmi les ressources disponibles selon la routing policy.
• Les ressources unhealthy sont retirées des réponses si des health checks sont configurés.

À utiliser pour :

• Haute disponibilité multi-région.
• Répartition de charge DNS.
• Optimisation de latence.
• Applications capables de fonctionner sur plusieurs endpoints actifs.

À retenir :

• Peut utiliser weighted, latency, geolocation ou d’autres politiques.
• Plus performant en disponibilité.
• Plus complexe côté données et synchronisation applicative.

AWS indique que l’active-active peut être configuré avec n’importe quelle routing policy ou combinaison de policies, à l’exception de failover.

Active-passive failover

Principe :

• Une ressource principale reçoit le trafic.
• Une ressource secondaire prend le relais si la principale devient unhealthy.

À utiliser pour :

• Disaster recovery.
• Site de secours.
• Page de maintenance.
• Environnement standby dans une autre région.

À retenir :

• Utilise la failover routing policy.
• Plus simple à comprendre.
• Le temps de bascule dépend des health checks, du TTL et des caches DNS.
• Le secondaire doit être prêt à recevoir le trafic.

AWS précise que l’active-passive se configure avec la failover routing policy.

20. Exemple de stratégie failover simple

Cas d’usage :

• Une application principale est derrière un Application Load Balancer.
• Une page statique de secours est hébergée sur S3 ou CloudFront.
• Si l’application principale devient indisponible, les utilisateurs doivent être redirigés vers la page de secours.

Configuration possible :

• Record primaire :
  • app.example.com
  • Alias vers Application Load Balancer.
  • Health check associé.
  • Type : Primary.
• Record secondaire :
  • app.example.com
  • Alias vers CloudFront ou S3 website endpoint.
  • Type : Secondary.

À retenir :

• La cible secondaire doit être testée avant incident.
• Le contenu de secours doit être clair pour les utilisateurs.
• Le TTL doit être adapté.
• Les health checks doivent refléter l’état réel de l’application.
• Le failover DNS n’est pas toujours instantané à cause des caches DNS.

21. Route 53 et CloudFront

Route 53 est souvent utilisé avec CloudFront.

À utiliser pour :

• Distribuer un site web globalement.
• Accélérer un site statique S3.
• Protéger une application avec AWS WAF.
• Router un domaine personnalisé vers une distribution CloudFront.

À retenir :

• Le record Route 53 pointe souvent vers CloudFront via un alias.
• Le certificat TLS pour CloudFront doit être dans la région us-east-1.
• CloudFront gère la distribution globale du contenu.
• Route 53 gère la résolution DNS du domaine.

22. Route 53 et Load Balancers

Route 53 est souvent utilisé avec Elastic Load Balancing.

À utiliser pour :

• Pointer app.example.com vers un Application Load Balancer.
• Pointer un domaine racine vers un Load Balancer.
• Utiliser un alias record au lieu d’une adresse IP.
• Combiner Load Balancer et routing policies.

À retenir :

• Ne pointez pas vers les IP d’un Load Balancer.
• Les IP d’un Load Balancer peuvent changer.
• Utilisez le nom DNS du Load Balancer via un alias record Route 53.
• Pour la haute disponibilité, le Load Balancer doit lui-même être déployé sur plusieurs Availability Zones.

23. Route 53 Resolver

Route 53 Resolver permet la résolution DNS dans les VPC.

À utiliser pour :

• Résolution DNS interne dans AWS.
• Intégration avec des DNS on-premises.
• Architectures hybrides.
• Forwarding de requêtes DNS entre AWS et un réseau d’entreprise.

Concepts utiles :

• Inbound Resolver Endpoint
  • Permet à un réseau externe de résoudre des noms DNS hébergés dans AWS.
• Outbound Resolver Endpoint
  • Permet aux ressources AWS d’envoyer certaines requêtes DNS vers des serveurs DNS externes.
• Resolver Rules
  • Règles de forwarding DNS selon le domaine.

À retenir :

• Très utile dans les environnements hybrides.
• Important pour les private hosted zones.
• Doit être conçu avec attention dans les architectures multi-comptes et multi-VPC.

24. DNSSEC avec Route 53

DNSSEC ajoute une protection cryptographique au DNS pour réduire les risques de spoofing DNS et de cache poisoning.

À retenir :

• Route 53 prend en charge DNSSEC signing pour les hosted zones.
• Il faut établir une chaîne de confiance avec un Delegation Signer record, ou DS record, dans la zone parente.
• Route 53 Resolver peut aussi effectuer de la validation DNSSEC dans les VPC, avec certaines limites indiquées par AWS.
• DNSSEC doit être activé avec prudence.
• Une mauvaise configuration DNSSEC peut rendre un domaine difficile ou impossible à résoudre.

Bonnes pratiques :

• Comprendre la chaîne de confiance avant activation.
• Suivre les étapes officielles AWS.
• Tester sur un domaine non critique si nécessaire.
• Ne pas désactiver DNSSEC sans retirer proprement les DS records.
• AWS recommande de retirer les DS records dans la chaîne de confiance avant de désactiver le signing pour éviter les problèmes de résolution.

Ressources officielles :

• Configuring DNSSEC signing in Amazon Route 53.
• Enabling DNSSEC signing and establishing a chain of trust.

25. Bonnes pratiques Route 53

DNS

• Utiliser des noms clairs et cohérents.
• Éviter les records inutiles.
• Utiliser des TTL adaptés.
• Réduire le TTL avant une migration.
• Vérifier les NS records lors d’un changement de registrar ou de zone.
• Ne pas pointer vers des IP dynamiques de services managés.
• Utiliser des alias records pour les ressources AWS compatibles.
• Documenter les records critiques.

Sécurité

• Limiter les permissions IAM liées à Route 53.
• Protéger les changements DNS avec des processus de validation.
• Activer CloudTrail pour auditer les changements.
• Utiliser DNSSEC si le besoin de protection DNS le justifie.
• Contrôler les accès aux hosted zones de production.
• Séparer les zones de production et de test.
• Surveiller les modifications non autorisées.

Haute disponibilité

• Utiliser des health checks pertinents.
• Tester régulièrement le failover.
• Prévoir une cible secondaire réellement fonctionnelle.
• Utiliser des routing policies adaptées au besoin.
• Ne pas confondre DNS failover et reprise applicative complète.
• Prévoir la cohérence des données dans les architectures multi-régions.
• Garder en tête que les caches DNS peuvent ralentir la bascule.

Coût

• Supprimer les hosted zones inutilisées.
• Supprimer les health checks inutilisés.
• Éviter de multiplier les records complexes sans besoin.
• Surveiller les coûts des requêtes DNS, health checks et domaines.
• Documenter les ressources Route 53 par application ou environnement.

26. Erreurs fréquentes à éviter

• Modifier les DNS en production sans plan de rollback.
• Oublier de baisser le TTL avant une migration.
• Croire qu’un changement DNS est instantané.
• Confondre registrar et DNS hosting.
• Créer une hosted zone Route 53 sans mettre à jour les name servers chez le registrar.
• Utiliser un CNAME au niveau apex du domaine.
• Pointer vers les IP d’un Load Balancer au lieu d’un alias.
• Configurer un failover sans tester le scénario réel.
• Utiliser un health check qui ne reflète pas la santé applicative.
• Supprimer un health check encore associé à des records.
• Oublier que DNS failover ne réplique pas les données.
• Mettre un TTL trop long pour une application nécessitant une bascule rapide.
• Ne pas documenter les records critiques.
• Activer DNSSEC sans comprendre la chaîne de confiance.
• Oublier le record par défaut avec geolocation routing.

27. Mini méthode LCF pour configurer Route 53

Avant de créer ou modifier une configuration Route 53, posez-vous ces questions :

• Quel domaine ou sous-domaine dois-je gérer ?
  • Exemple : example.com, www.example.com, api.example.com.
• La zone doit-elle être publique ou privée ?
  • Publique pour Internet.
  • Privée pour les VPC.
• Quelle est la destination ?
  • CloudFront, Load Balancer, API Gateway, S3, EC2, ressource externe ?
• Quel type de record utiliser ?
  • A, AAAA, CNAME, MX, TXT, alias ?
• Quelle routing policy correspond au besoin ?
  • Simple, weighted, latency, failover, geolocation, geoproximity, multivalue, IP-based ?
• Ai-je besoin d’un health check ?
  • Oui pour failover, active-active, ou routage selon santé.
• Quel TTL choisir ?
  • Court pour migration ou failover.
  • Plus long pour stabilité et cache.
• Quels sont les impacts sécurité ?
  • IAM, CloudTrail, DNSSEC, protection des hosted zones.
• Comment tester ?
  • Résolution DNS.
  • Accès applicatif.
  • Failover.
  • Rollback.

28. Résumé à mémoriser

• Route 53 est le service DNS managé d’AWS.
• Une hosted zone contient les enregistrements DNS d’un domaine.
• Une public hosted zone sert aux noms publics sur Internet.
• Une private hosted zone sert aux noms internes dans les VPC.
• Les records courants sont A, AAAA, CNAME, MX, TXT, NS et SOA.
• Les alias records sont très utiles pour pointer vers des ressources AWS.
• Le TTL influence la rapidité de propagation perçue des changements.
• Simple routing convient à une destination unique.
• Weighted routing convient aux migrations progressives et canary releases.
• Latency routing oriente vers la région avec la meilleure latence.
• Geolocation routing oriente selon la localisation des utilisateurs.
• Failover routing permet une architecture active-passive.
• Les health checks permettent de router selon l’état de santé des ressources.
• Le failover DNS doit être testé avant un incident.
• DNSSEC peut renforcer la sécurité DNS, mais doit être configuré avec prudence.
• Route 53 est simple en apparence, mais critique pour la disponibilité d’une application.