Introduction
Amazon Route 53 est le service DNS hautement disponible et scalable proposé par AWS, lancé en 2010 et continuellement évolué pour répondre aux besoins des architectures cloud modernes. Contrairement aux DNS traditionnels limités par des zones géographiques ou des capacités statiques, Route 53 offre une résolution DNS globale avec une latence minimale de 20 ms en moyenne, grâce à son réseau Anycast couvrant plus de 100 edge locations.
Pourquoi est-ce crucial en 2026 ? Avec l'essor des applications multi-régions, des microservices et des déploiements serverless, un DNS fiable est le pivot de votre infrastructure. Il gère non seulement la résolution de noms (A, CNAME, etc.), mais aussi des routages intelligents basés sur la latence, le poids ou la santé des endpoints. Imaginez une API globale : Route 53 dirige automatiquement le trafic vers la région la plus proche ou la plus performante, évitant les pannes et optimisant les coûts.
Ce tutoriel intermédiaire, sans code, se concentre sur la théorie et les bonnes pratiques. Vous apprendrez à structurer vos zones, choisir les bonnes politiques de routage et intégrer avec d'autres services AWS, pour des domaines résilients face aux pics de trafic ou aux défaillances.
Prérequis
- Compte AWS actif avec permissions IAM pour Route 53 (route53:*).
- Connaissances de base en DNS : records types (A, MX, TXT), propagation TTL.
- Familiarité avec les concepts AWS comme VPC, EC2, ALB et CloudFront.
- Accès à la console AWS Management Console.
Les fondations : Comprendre les Hosted Zones
Une hosted zone est le conteneur principal dans Route 53 pour vos enregistrements DNS. Il en existe deux types :
- Public hosted zone : Pour des domaines accessibles publiquement (ex. : example.com résolu mondialement).
- Private hosted zone : Limitée à un VPC, idéale pour des services internes (ex. : api.internal).
| Type | Utilisation | Avantages | Limites |
|---|---|---|---|
| ------ | ------------- | ----------- | --------- |
| Public | Sites web, APIs publiques | Résolution globale Anycast | Coût par requête |
| Private | VPC internes | Isolation réseau | Non résolu hors VPC |
Exemple concret : Pour acme.com, créez une public hosted zone. Ajoutez un record A pointant vers une ALB à acme.com, et un NS pour déléguer api.acme.com à une zone enfant.
Gérer les enregistrements DNS avancés
Route 53 supporte tous les types RFC standards, mais excelle avec les alias records, une alternative gratuite aux CNAME pour les ressources AWS.
Records clés :
- A/AAAA : IPv4/IPv6 vers instances EC2 ou Elastic IP.
- Alias : Pointe vers ALB, CloudFront, S3 sans TTL propagation (idéal pour load balancers dynamiques).
- CNAME : Alias pour domaines non-AWS.
- MX/TXT/SPF/DKIM : Emails et authentification.
- SRV : Services comme XMPP ou SIP.
| Record | Cas d'usage | TTL recommandé | Exemple |
|---|---|---|---|
| ------- | ------------- | ---------------- | --------- |
| Alias (ALB) | Web apps scalables | 60s | app.example.com → my-alb-123.us-east-1.elb.amazonaws.com |
| TXT (SPF) | Anti-spam emails | 300s | _spf.example.com → "v=spf1 include:amazonses.com ~all" |
| CAA | Contrôle certificats | 86400s | @ → 0 issue "letsencrypt.org" |
Bon conseil : Utilisez toujours des alias pour les ressources AWS natives – ils résolvent dynamiquement sans downtime lors de changements d'IP.
Politiques de routage : Du simple au complexe
Politique Simple : Routage basique vers un ou plusieurs endpoints (round-robin). Parfait pour une pool d'EC2 identiques.
Politique Weighted : Attribuez des poids (ex. : 70% vers us-east-1, 30% vers eu-west-1) pour A/B testing ou migrations progressives.
Politique Latency : Dirige vers la région avec la latence la plus faible, mesurée depuis 100+ locations. Idéal pour apps globales.
Politique Failover : Primaire actif + secondaire en backup, activé par health checks.
Politique Geolocation/Geoproximity : Routage par continent/pays ou distance ajustable.
| Politique | Utilisation | Groupe de ressources requis | Exemple concret |
|---|---|---|---|
| ----------- | ------------- | ----------------------------- | ----------------- |
| Latency | E-commerce mondial | Multi-régions EC2 | 45% trafic US → us-west-2 |
| Weighted | Blue-green deploy | Versions A/B | 90 poids nouvelle version |
| Failover | Haute disponibilité | Primary ALB + Secondary S3 static | Switch auto si primary down |
Health Checks et monitoring
Les health checks sont des sondes HTTP/HTTPS/TCP vers vos endpoints, exécutées toutes les 10-30s depuis 14+ régions.
Configuration clé :
- Type : HTTP (statut 200), HTTPS, TCP (port ouvert), CloudWatch Alarm, Calculated (agrégé).
- Seuils : 3 échecs consécutifs pour unhealthy.
- Régions : Choisissez Default ou spécifiques pour précision.
Intégrez avec Route 53 Resolver pour hybrid cloud (on-prem + AWS).
Exemple : Health check sur /health de votre API (intervalle 30s, timeout 5s). Si unhealthy > 3min, failover vers S3 bucket statique.
| Métrique | Seuil optimal | Action |
|---|---|---|
| ---------- | --------------- | -------- |
| Healthy | 100% | Routage normal |
| Unhealthy | <90% | Reroutage auto |
Intégrations avancées avec l'écosystème AWS
Route 53 s'intègre nativement :
- CloudFront : Alias pour CDN global.
- ELB/ALB/NLB : Routage dynamique.
- S3 : Websites statiques.
- VPC : Private zones avec endpoints.
- ACM : Certificats pour HTTPS health checks.
- CloudWatch : Logs et métriques (DNSQueries, HealthCheckStatus).
Cas d'étude : Application e-commerce : Latency routing vers ALB multi-AZ, failover sur S3, geoproximity pour EU/US, health checks sur
/healthz. Résultat : 99.99% uptime, latence <50ms.
Resolver pour hybrid : Associez on-prem DNS via inbound/outbound endpoints.
Bonnes pratiques essentielles
- Séparez zones par environnement :
prod.example.com,dev.example.compour isolation. - TTL bas pour dev, haut pour prod : 60s dev, 3600s prod pour équilibrer fraîcheur et charge.
- Utilisez alias partout possible : Évite propagation et coûts CNAME.
- Health checks obligatoires pour routages avancés : Couvrez 100% des endpoints critiques.
- Monitoring CloudWatch + alarms : Alertez sur >1% queries throttled ou latency spikes.
- DNSSEC pour sécurité : Activez pour prévenir spoofing (clé KSK/ZSK gérée par Route 53).
Erreurs courantes à éviter
- Oublier la délégation NS : Domaine registrar ne pointe pas vers Route 53 NS records → propagation 48h.
- TTL trop bas en prod : Augmente coûts (0.40$/million queries) et charge inutile.
- Health check sur root/ : Utilisez
/healthspécifique pour éviter faux positifs. - Simple routing pour global : Ignore latence → adoptez Latency/Geolocation dès le départ.
Pour aller plus loin
Plongez plus profond avec la documentation officielle AWS Route 53.
Étudiez les cas avancés : Traffic Flow pour visual policy builder.
Découvrez nos formations Learni sur AWS : certification Route 53 et architectures networking.
Ressources : AWS Well-Architected Framework (Reliability pillar), re:Post forums.