🌐 Amazon Route 53 – DNS mondial & routage avancé

Service DNS managé, rapide et hautement disponible, au cœur de toutes les architectures Internet sur AWS.

1.1

Qu’est-ce que Route 53 ?

Service DNS hautement disponible et scalable, utilisé comme point d’entrée pour la majorité des applications AWS.

DNS Global

1.2

Zones publiques & privées

Gestion des zones DNS Internet (publiques) et internes (privées) associées aux VPC.

Public Zone Private Zone

1.3

Types d’enregistrements DNS

A/AAAA, CNAME, MX, TXT, SRV, et enregistrements Alias spécifiques AWS.

A / AAAA CNAME

2.1

Routage Simple & Multi-Value

Renvoi d’une ou plusieurs réponses DNS, pour un routage simple ou pseudo-load balancing.

Simple Multi-Value

2.2

Weighted & Latency-Based Routing

Répartition du trafic selon des poids ou selon la latence vers les régions AWS.

Weighted Latency

2.3

Geolocation & Geoproximity

Routage en fonction de la localisation géographique des utilisateurs et de la proximité.

Geo Proximity

3.1

Alias vers ressources AWS

Pointage direct vers CloudFront, ALB, S3 Website, API Gateway, Global Accelerator…

Alias AWS Services

3.2

Health Checks & Failover

Surveillance des endpoints HTTP/HTTPS/TCP et bascule automatique vers un site de secours.

Health Failover

4.1

DNS privé pour VPC

Résolution des noms internes (microservices, bases, services internes) dans un ou plusieurs VPC.

Private DNS VPC

4.2

Sécurité, IAM & DNSSEC

Contrôle des opérations DNS via IAM, protection contre le spoofing avec DNSSEC.

Security DNSSEC

5.1

Patterns d’architecture Route 53

Site statique mondial, API multi-région, disaster recovery, hybrid cloud, etc.

Patterns Multi-Region

5.2

Tarifs & bonnes pratiques FinOps

Coûts par zone, par requête, par health check, et optimisations possibles.

Pricing FinOps

1. Route 53 : DNS Global & Traffic Management

Plus qu'un simple annuaire DNS

Route 53 est un DNS Authoritative (il détient la vérité sur votre domaine) utilisant un réseau Anycast mondial.

SLA 100% (Unique)

C'est le seul service AWS qui garantit 100% de disponibilité.
Si Route 53 tombe, c'est tout Internet qui vacille.
Technique : Réseau Anycast distribué sur des centaines de PoP.

Port 53 (UDP/TCP)

Gère les requêtes DNS standards (UDP < 512 bytes, TCP sinon).
Intègre aussi un Registrar (Achat de nom de domaine) et des Health Checks.

Pourquoi "53" ? C'est une référence au port TCP/UDP 53 utilisé par le protocole DNS. Et "Route 66" pour le jeu de mot.

Hosted Zones : Le Conteneur de Records

Une Hosted Zone est l'équivalent d'un fichier de zone DNS. Il en existe deux types critiques.

Public Hosted Zone	VS	Private Hosted Zone
Accessible depuis Internet.		Accessible uniquement depuis vos VPC.
Résout `www.google.com` ou `mon-site.com`.		Résout `db.internal` ou `api.backend`.
Visible par le monde entier.		Split-Horizon DNS : Vous pouvez avoir une zone publique `example.com` ET une zone privée `example.com`. Le VPC verra la privée, Internet verra la publique.

Architecture : CNAME vs Alias (Vital)

C'est la question n°1 à l'examen Solutions Architect et en design réel.

CNAME (Standard)

Pointe vers un autre nom de domaine.
INTERDIT à la racine du domaine (Zone Apex / Naked Domain).
Ex: Impossible de mettre un CNAME sur example.com, seulement sur www.example.com.
Coût : Payant (Requête DNS standard).

Alias (AWS Specific)

Pointe vers une ressource AWS (ALB, CloudFront, S3, API Gateway).
AUTORISÉ à la racine (Zone Apex).
Ex: example.com -> my-loadbalancer...
Coût : GRATUIT pour les requêtes vers des ressources AWS.
Dynamique : Si l'IP de l'ALB change, Route 53 le sait instantanément.

👉 Règle : Utilisez TOUJOURS un Alias quand vous ciblez une ressource AWS.

Les Records DNS supportés

Route 53 supporte tous les standards DNS majeurs.

A
IPv4 Address

AAAA
IPv6 Address

CNAME
Canonical Name

MX
Mail Exchange

TXT
Text / SPF / Verification

NS
Name Server

SOA
Start of Authority

SRV
Service Locator

PTR
Pointer (Reverse DNS)

TTL (Time To Live) : La durée de cache chez le client (FAI/Navigateur).
Pour un Alias, Route 53 respecte le TTL de la ressource cible (souvent 60s). Pour un record A statique, vous le définissez (ex: 300s, 86400s).

FinOps : Combien ça coûte ?

Le modèle de coût est hybride (Fixe + Variable).

Élément	Prix (Approximatif)	Optimisation
Hosted Zone	0.50$ / zone / mois	Supprimez les zones de test non utilisées. (Note : Les 25 premières zones sont au même prix, ensuite ça baisse un peu).
Requêtes Standards	0.40$ / million de requêtes	Augmenter le TTL pour réduire le nombre de requêtes.
Requêtes Latency/Geo	0.60$ - 0.70$ / million	Plus cher car nécessite du calcul de routage.
Requêtes Alias (AWS)	GRATUIT	Le meilleur moyen d'économiser. Pointez vers CloudFront/ALB via Alias.
Health Checks	0.50$ - 2.00$ / check / mois	Attention si vous checkez des centaines d'endpoints (ex: AWS non-AWS).

2. Zones & Records : La Mécanique DNS de Précision

Hosted Zones : Le Conteneur d'Autorité

Une "Hosted Zone" (Zone Hébergée) est l'équivalent cloud d'un fichier de zone BIND. C'est là que vous gérez vos enregistrements.

Public Hosted Zone

Portée : Internet Mondial.
Fonction : Résout monsite.com vers des IPs publiques (ALB, CloudFront).
Coût : 0.50$ / zone / mois.
Indispensable : Pour valider les certificats ACM (DNS Validation).

Private Hosted Zone

Portée : Un ou plusieurs VPC (Virtual Private Cloud).
Fonction : Résout db.prod.internal vers 10.0.1.50.
Sécurité : Invisible depuis Internet. Impossible à requêter sans être dans le VPC.
Association : Doit être "attachée" aux VPCs concernés.

La Zoologie des Records DNS

Type	Rôle Technique	Note Architecte
A	Nom -> IPv4 (192.168.1.1).	Fondamental. Utilisé pour les IPs statiques (EIP).
AAAA	Nom -> IPv6 (2001:db8::1).	Critique : Les réseaux mobiles (4G/5G) et l'IoT sont souvent IPv6-only. Activez-le sur CloudFront/ALB.
CNAME	Nom -> Autre Nom (Canonical Name).	INTERDIT à la racine (Apex). Coûteux (résolution en 2 temps).
Alias	Nom -> Ressource AWS (Pointeur Interne).	GRATUIT & RAPIDE. Autorisé à la racine (Apex). Met à jour l'IP automatiquement si l'ALB scale.
NS	Name Servers (Autorité).	Définit qui gère la zone. Ne touchez pas aux NS par défaut de la zone !
TXT	Texte libre.	Utilisé pour SPF (Email) et la validation de propriété (Google, Facebook, ACM).

Architecture Avancée : Split-Horizon DNS

C'est l'art d'avoir le même nom de domaine (ex: app.corp.com) qui pointe vers des endroits différents selon qui pose la question.

Le Scénario :

Utilisateur Internet : Tape app.corp.com -> Reçoit l'IP Publique de l'ALB (Public Zone).
Serveur EC2 (Interne) : Tape app.corp.com -> Reçoit l'IP Privée de l'instance (Private Zone).

Implémentation

Créer une Zone Publique corp.com.
Créer une Zone Privée corp.com et l'attacher au VPC.
Magie AWS : Le Resolver du VPC (x.x.x.2) regarde TOUJOURS la zone privée en priorité. S'il ne trouve pas, il sort vers le public.

Gérer les Sous-Domaines (Délégation)

Comment donner à l'équipe "Dev" le contrôle total sur dev.monsite.com sans leur donner accès à la zone racine ?

Zone Racine (monsite.com) ├── www (A) -> Prod IP ├── mail (MX) -> Google └── dev (NS) -> ns-1.awsdns.com, ns-2.awsdns.com <-- DÉLÉGATION

Le Processus

Créer une nouvelle Hosted Zone pour dev.monsite.com.
Noter les 4 serveurs NS attribués par AWS à cette nouvelle zone.
Dans la zone parente (monsite.com), créer un record de type NS nommé "dev".
Y coller les 4 serveurs NS de l'étape 2.

Glue Records (Le détail qui tue)

Si vos NS sont dans le sous-domaine délégué (ex: ns1.dev.monsite.com), vous devez fournir leur IP ("Glue Record") dans la zone parente pour éviter une boucle infinie de résolution.
(Rare avec Route 53 car AWS fournit des noms NS génériques).

Maîtriser le Temps (TTL - Time To Live)

Le TTL est la durée de cache chez le client (FAI, Box, Navigateur). C'est votre levier de contrôle lors d'une migration.

Durée	Usage	Avantage / Inconvénient
60 secondes	Records dynamiques (ALB, Failover).	Réactif (Changement rapide en cas de panne). Coûteux (Beaucoup de requêtes facturées).
300 secondes (5 min)	Standard Web.	Bon compromis coût/réactivité.
86400 secondes (24h)	Records stables (MX, TXT, DKIM).	Économique (Cache long). Dangereux pour une migration (il faut attendre 24h pour corriger une erreur).

Procédure de Migration (Flip) :
1. 48h avant la migration : Baissez le TTL de 24h à 60s.
2. Attendez que l'ancien TTL expire partout.
3. Faites le changement d'IP (Migration).
4. Une fois stable, remontez le TTL à 24h (FinOps).

3. Stratégies de Routage : Piloter le Trafic Mondial

Weighted Routing : Blue/Green & Migration

Permet d'envoyer un % précis du trafic vers une ressource. Les poids sont relatifs (Somme totale).

Use Case : Canary Deployment

Vous lancez une V2 de votre site mais vous avez peur des bugs.

Record A (V1) : Weight = 90.
Record A (V2) : Weight = 10.
Résultat : 10% des requêtes DNS vont vers la V2. Si tout va bien, on augmente progressivement (50/50 -> 0/100).

Le Piège du TTL

Si vous mettez un TTL de 24h, le client qui tombe sur la V2 restera sur la V2 toute la journée.
Conseil : Baissez le TTL à 60s pendant les phases de A/B Testing pour pouvoir rollback rapidement.

Performance (Latency) ou Légalité (Geo) ?

Deux stratégies souvent confondues, mais aux buts opposés.

Latency-Based Routing	VS	Geolocation Routing
Objectif : Vitesse pure.		Objectif : Localisation / Loi.
AWS mesure la latence réseau entre l'utilisateur et les régions AWS.		AWS regarde l'IP de l'utilisateur pour déterminer son Pays/Continent.
"Dirige-moi vers le serveur qui répond le plus vite" (Même si c'est dans un autre pays).		"Si IP = France, va à Paris. Si IP = USA, va en Virginie."
Usage : Architecture Active-Active globale.		Usage : RGPD (Données en UE), Droits de diffusion, Langue par défaut.

Default Record : En Geolocation, créez toujours un record "Default" pour capturer les IPs qui ne matchent aucun pays spécifique (ou les proxys anonymes).

Failover Routing : Active-Passive (DR)

Le mode "Roue de secours". Nécessite obligatoirement des Health Checks.

Primary (Active)

Pointe vers votre Load Balancer de Prod.
Associé à un Health Check.
Tant que le Health Check est Healthy, Route 53 répond avec cette IP.

Secondary (Passive)

Pointe vers une page de maintenance S3 ou une région de secours (DR).
Route 53 ne répond avec cette IP QUE si le Primary est Unhealthy.

Geoproximity : Le "Bias" (Trafic Flow)

C'est la version avancée de la géolocalisation. Elle permet d'influencer la zone d'attraction d'une région.
Utilisable uniquement via l'outil visuel "Traffic Flow".

Le Concept de BIAS (Biais)

Bias 0 : L'utilisateur va à la région physiquement la plus proche.
Bias + (Positif) : La région "aspire" plus de trafic (agrandit sa zone).
Bias - (Négatif) : La région repousse le trafic (rétrécit sa zone).

Exemple Concret

Vous avez une grosse région à Francfort et une petite à Paris.
Vous mettez un Bias +10 sur Francfort pour qu'elle gère le nord de la France, ne laissant à Paris que l'Île-de-France et le Sud.

Multi-Value : Le Load Balancing du Pauvre

Différent du "Simple Routing". Ici, Route 53 renvoie plusieurs IPs (jusqu'à 8) en réponse, mais seulement celles qui sont saines.

Simple Routing	Multi-Value Answer
Renvoie toutes les IPs configurées, même si le serveur est mort.	Vérifie les Health Checks avant de répondre. Ne renvoie que les IPs saines.
Pas de haute dispo intelligente.	Améliore la dispo (Client-Side Load Balancing).
Le navigateur reçoit tout et tente de se connecter.	Le navigateur reçoit une liste épurée. Si une IP plante, il tente la suivante.

4. Alias Records : L'Extension DNS made in AWS

Qu'est-ce qu'un Alias ?

Ce n'est pas un type de record DNS standard (RFC). C'est un pointeur interne à AWS qui se "déguise" en record standard (A ou AAAA) lors de la réponse.

Le Problème du "Zone Apex"

Le standard DNS interdit de mettre un CNAME à la racine d'un domaine (ex: monsite.com).
Les CNAMEs ne sont autorisés que sur les sous-domaines (ex: www.monsite.com).

Conséquence classique : Impossible de faire pointer monsite.com vers un Load Balancer... sauf avec un Alias.

La Magie de l'Alias

Route 53 sait que l'Alias pointe vers un ALB.
Quand un client demande l'IP de monsite.com (Type A), Route 53 interroge l'ALB en interne, récupère ses IPs actuelles (ex: 1.2.3.4), et répond directement au client : A 1.2.3.4.

CNAME vs Alias : Le Guide Définitif

Critère	CNAME (Standard)	Alias (AWS Only)
Cible	N'importe quel nom DNS (interne ou externe).	Uniquement des ressources AWS spécifiques (CloudFront, ALB, S3...).
Zone Apex	INTERDIT (Sur la racine du domaine).	AUTORISÉ (Permet `example.com` -> ALB).
Coût	Payant (Tarif requête standard).	GRATUIT (Si la cible est AWS).
Performance	Lente (2 résolutions DNS : Nom -> CNAME -> IP).	Rapide (1 résolution : Nom -> IP).
TTL	Défini par vous. Risque de cache obsolète.	Respecte le TTL de la ressource cible. Mise à jour instantanée si l'IP change.

Vers quoi peut-on pointer un Alias ?

Distribution de Contenu

CloudFront : Cible n°1 pour les sites statiques.
S3 Website Endpoint : Uniquement si le bucket est configuré en mode site web.

Networking

ALB / NLB : Load Balancers (Application / Network).
API Gateway : Pour les Custom Domains.
VPC Interface Endpoint : Pour les services privés.

Global

Global Accelerator : Pour les IPs statiques anycast.
Elastic Beanstalk : Environnements web.

Attention : Vous ne pouvez PAS créer un Alias vers une instance EC2 directement. Pour une EC2, utilisez une Elastic IP (EIP) et un record A standard.

Evaluate Target Health : Le Failover sans délai

C'est une case à cocher optionnelle sur les records Alias.
Si activé (True) : Route 53 vérifie la santé de la ressource AWS cible avant de répondre.

Scénario Failover

Vous avez 2 ALBs (Primaire et Secondaire) configurés en Failover.
L'ALB Primaire tombe en panne (toutes les instances derrière sont Unhealthy).
Si Evaluate Target Health = True, Route 53 le voit instantanément.
Il retire l'ALB Primaire des réponses DNS et sert le Secondaire.

Pourquoi c'est mieux qu'un Health Check classique ?

Un Health Check classique coûte de l'argent et pollue vos logs (requêtes HTTP).
Evaluate Target Health utilise les données internes d'AWS (l'état du Load Balancer). C'est gratuit et plus rapide.

IaC : Les "Magic Zone IDs"

En Terraform ou CloudFormation, pour créer un Alias, vous devez fournir l'ID de zone de la cible.
Pour CloudFront et Elastic Beanstalk, ces IDs sont fixes et globaux (magiques).

# Exemple Terraform : Alias vers CloudFront resource "aws_route53_record" "www" { zone_id = aws_route53_zone.primary.zone_id name = "example.com" type = "A" alias { name = aws_cloudfront_distribution.main.domain_name # ID Magique fixe pour toutes les distribs CloudFront zone_id = "Z2FDTNDATAQYW2" evaluate_target_health = false } }

Pour les ALBs, le zone_id dépend de la région de l'ALB. Terraform peut le récupérer via aws_lb.main.zone_id.

5. Health Checks : Haute Disponibilité & Failover

Comment Route 53 sait-il que vous êtes en panne ?

Ce n'est pas un simple "ping" depuis un serveur. C'est un réseau de surveillance mondial.

Le Réseau de Checkers

AWS possède des serveurs de health check répartis dans 8 régions autour du monde. Chaque région envoie des requêtes vers votre endpoint.

Intervalle : Standard (30s) ou Fast (10s).
Seuil (Threshold) : Combien de checkers doivent échouer ? (Par défaut : 18% des checkers).

Le Processus de Décision

Les checkers interrogent votre IP/Domaine (HTTP 200 OK ?).
Si > 18% des checkers reçoivent une erreur ou un timeout...
...Route 53 marque l'endpoint Unhealthy.
La propagation DNS retire cette IP des réponses (via le TTL).

Important : Les Checkers sont sur Internet Public. Pour qu'ils fonctionnent, votre Pare-feu/Security Group doit autoriser les plages d'IPs des Checkers AWS (disponibles dans ip-ranges.json).

Les 3 Types de Health Checks

Type	Fonctionnement	Cas d'usage
Endpoint Check (Le Standard)	Surveille une IP ou un Nom de Domaine (HTTP, HTTPS, TCP). Peut chercher un texte spécifique dans la réponse HTML ("String Matching").	Site Web public, Load Balancer externe.
CloudWatch Alarm (L'Indirect)	Surveille l'état d'une alarme CloudWatch (ex: CPU > 90%, DynamoDB Throttled).	Ressources Privées (VPN, RDS interne) ou métriques métiers complexes.
Calculated (Le Logique)	Combine d'autres Health Checks avec une logique ET/OU/NOT (ex: Check A + Check B doivent être OK).	Architectures complexes (ex: Front sain ET Back sain).

Architecture : Active-Active vs Active-Passive

Active-Passive (Failover)

Primary : IP Prod (Associé au Health Check).
Secondary : Page S3 "Maintenance" (Pas de check).

Route 53 répond toujours Primary. Si Primary meurt, il répond Secondary.
Idéal pour le Disaster Recovery (DR) simple.

Active-Active (Multi-Site)

Region A : Check A.
Region B : Check B.
(Routing : Latency ou Weighted).

Si Region A meurt, Route 53 arrête de l'envoyer et dirige 100% du trafic vers Region B.
Idéal pour la Haute Disponibilité.

Réglages Fins pour Pros

1. Fast Interval (10s vs 30s)

Standard (30s) : Moins cher. Délai de détection ~2-3 minutes.
Fast (10s) : Plus cher. Délai de détection ~60 secondes.
Conseil : Fast pour la Prod, Standard pour le reste.

2. String Matching

Ne vous contentez pas du code 200 OK. Vérifiez que la page contient </html> pour être sûr que la page est chargée complètement.

3. SNI (Server Name Indication)

Si vous checkez un ALB qui héberge 50 sites en HTTPS, vous DEVEZ spécifier le Host Name dans la config du Health Check.
Sinon, le check échouera (certificat invalide).

4. Latency Graphs

Bonus : Route 53 mesure le temps de réponse des checkers et génère des graphiques de latence mondiale dans CloudWatch Metrics.

Le Défi : Monitorer une ressource privée

Problème : Les checkers Route 53 sont sur Internet. Ils ne peuvent pas pinger votre base de données dans un sous-réseau privé (Private Subnet).

La Solution : CloudWatch Alarm Check

Créez une Alarme CloudWatch interne (ex: via une Lambda qui ping la DB, ou métrique EC2).
Créez un Health Check Route 53 de type "State of CloudWatch Alarm".
Liez ce Health Check à votre enregistrement DNS privé.

Résultat : Si la DB interne plante, l'alarme sonne, Route 53 le voit et bascule le DNS interne vers la DB Slave.

6. DNS Privé : VPC, Split-Horizon & Hybride

Private Hosted Zone : Le DNS de l'Intranet

Une Zone Privée permet de résoudre des noms de domaine (ex: db.prod.internal) vers des IPs privées, uniquement depuis vos VPCs.

Fonctionnement

Isolation : Invisible depuis Internet. Impossible de la requêter sans être dans le réseau AWS.
Association : Une Zone Privée doit être "attachée" à un ou plusieurs VPCs.
Multi-Account : Vous pouvez partager une Zone Privée avec d'autres comptes AWS (via VPC Association Authorization).

Cas d'usage : Microservices

Au lieu de coder des IPs en dur (10.0.5.12), vos applications appellent user-service.local.
Si le service change d'IP (redémarrage), Route 53 met à jour le record A. L'application ne casse pas.

Split-Horizon : Le Double Visage

Utiliser le même nom de domaine (ex: app.corp.com) pour servir des IPs différentes selon qui pose la question.

Source de la requête	Zone interrogée	Réponse DNS (Record A)	Route réseau
Client Internet (Public)	Public Hosted Zone (gérée par R53 Public)	35.180.x.x (IP Publique de l'ALB)	Passe par l'Internet Gateway (IGW).
Serveur EC2 (Dans le VPC)	Private Hosted Zone (gérée par R53 Resolver)	10.0.1.50 (IP Privée de l'instance)	Reste dans le réseau privé (Pas de coût NAT).

Avantage Sécurité : Vos employés au bureau (VPN) accèdent à l'app d'administration via son IP privée, sans jamais l'exposer sur Internet.

Configuration VPC : Les "Flags" obligatoires

Si votre Zone Privée ne marche pas ("NXDOMAIN"), c'est à 99% à cause de ces paramètres VPC.

1. enableDnsSupport

Active le serveur DNS Amazon (le Resolver) dans le VPC.
Doit être : true.

2. enableDnsHostnames

Permet aux instances d'avoir des noms DNS publics/privés. Nécessaire pour les Private Zones.
Doit être : true.

Le Serveur Magique ".2"

Dans chaque VPC, l'adresse IP VPC_CIDR_BASE + 2 est réservée au Route 53 Resolver.
Exemple : Si VPC = 10.0.0.0/16, le serveur DNS est à 10.0.0.2.
C'est lui qui intercepte toutes les requêtes DNS et décide (Zone Privée ? Zone Publique ? Internet ?).

Route 53 Resolver : Le pont vers l'On-Premise

Comment faire parler vos serveurs physiques (Datacenter) avec vos serveurs AWS via Direct Connect / VPN ?

Inbound Endpoint (Entrant)

Permet au Datacenter de résoudre aws.corp.local.
AWS crée des ENI (Interfaces Réseau) dans votre VPC. Votre DNS sur site (Bind/AD) forwarde les requêtes vers ces IPs.

Outbound Endpoint (Sortant)

Permet à vos EC2 de résoudre intranet.legacy.corp (hébergé sur site).
Vous créez des Forwarding Rules dans Route 53 : "Si domaine = *.legacy.corp, envoie la requête aux IPs des DNS du Datacenter".

VPC Interface Endpoints (PrivateLink)

Comment accéder à SQS ou S3 depuis un sous-réseau privé sans NAT Gateway (pour économiser de l'argent) ?

Vous créez un Interface Endpoint pour SQS.
AWS dépose une ENI (ex: 10.0.1.55) dans votre subnet.
Magie DNS : AWS crée automatiquement une Private Hosted Zone cachée pour sqs.us-east-1.amazonaws.com.
Cette zone force la résolution du domaine public vers l'IP privée 10.0.1.55.

# Depuis l'EC2 privée nslookup sqs.us-east-1.amazonaws.com > Server: 10.0.0.2 > Address: 10.0.1.55 <-- IP Privée (Gratuit, Rapide, Sécurisé)

7. Sécurité : DNSSEC, IAM & Resolver Firewall

IAM : Empêcher la catastrophe

La suppression accidentelle d'une Hosted Zone de production est irréversible (perte des NS, downtime mondial).

Stratégie de Moindre Privilège

DNS Admin : Droit de créer/modifier des records.
Zone Manager : Droit de créer/supprimer des zones (À restreindre drastiquement).

Policy : Interdire la suppression de la Prod

                            {
                            "Effect": "Deny",
                            "Action": "route53:DeleteHostedZone",
                            "Resource": "arn:aws:route53:::hostedzone/Z1234567890PROD",
                            "Condition": {
                            "StringNotLike": {
                            "aws:PrincipalArn": "arn:aws:iam::*:role/SuperAdmin"
                            }
                            }
                            }

Astuce : Utilisez aussi les Service Control Policies (SCP) au niveau AWS Organizations pour empêcher tout compte de désactiver les logs de requêtes DNS.

DNSSEC : La Chaîne de Confiance

Protège contre le DNS Spoofing et le Cache Poisoning en signant cryptographiquement les réponses.

Comment ça marche ?

Signature : Route 53 signe la zone avec une clé privée (ZSK).
Validation : Le résolveur du client (Google 8.8.8.8) vérifie la signature avec la clé publique.
Chain of Trust : La clé est validée par le domaine parent (.com) via un enregistrement DS.

Responsabilité Partagée

AWS gère : La rotation des clés (KSK/ZSK) et la signature des records.
Vous gérez : La publication de l'enregistrement DS (Delegation Signer) chez votre Registrar (GoDaddy, Gandi, ou AWS).
Danger : Si vous oubliez de mettre à jour le record DS, votre domaine devient inaccessible.

Route 53 Resolver DNS Firewall

C'est un pare-feu pour le trafic sortant. Il empêche vos serveurs EC2 de contacter des domaines malveillants (C&C Botnets).

Composant	Fonction
Domain Lists	Liste de domaines (ex: `.malware.com`). AWS fournit des Managed Lists* (Threat Intelligence) mises à jour automatiquement.
Rule Groups	Associe une liste à une action : `ALLOW`, `BLOCK`, ou `ALERT`.
Response	Si bloqué, le DNS répond : `NXDOMAIN` (Introuvable) ou `NODATA`, ou redirige vers une "Sinkhole IP" (pour analyse).

Voir l'invisible : Query Logs

Il y a deux types de logs très différents.

1. CloudTrail (Management)

Logue les appels API : "Qui a modifié le record A de www.monsite.com ?"
Usage : Audit de configuration, Conformité.

2. DNS Query Logs (Traffic)

Logue les requêtes DNS réelles : "Quelle IP a demandé api.monsite.com à 14h00 ?"
Destination : CloudWatch Logs.
Usage : Debugging, Forensics, Détection de trafic suspect.

AWS Shield & Route 53

Le DNS est souvent la première cible d'une attaque DDoS (UDP Flood, DNS Query Flood).

Architecture Résiliente

Route 53 utilise le Shuffle Sharding.
Chaque hosted zone est servie par un ensemble unique de 4 serveurs de noms (NS).
Si un client est attaqué, seuls ses shards sont touchés, les voisins ne sont pas impactés.

Shield Advanced

Si vous avez Shield Advanced (~3k$/mois) :
Les coûts liés aux pics de requêtes Route 53 (Query Flood) durant une attaque sont remboursés.

8. Intégrations : Patterns d'Architecture AWS

Le Pattern "Serverless Website"

L'architecture standard pour héberger un frontend (React, Vue) à moindre coût et haute performance.

Le Flux

Route 53 (Alias) : Résout www.monsite.com vers CloudFront.
ACM : Certificat SSL gratuit validé par DNS via Route 53.
CloudFront : Terminaison TLS et Cache CDN.
S3 Bucket : Stockage des fichiers (Origin).

Pourquoi pas S3 Website direct ?

S3 Website Hosting ne supporte PAS le HTTPS avec un domaine personnalisé.
L'intégration Route 53 + CloudFront est obligatoire pour avoir le cadenas vert 🔒.

API Gateway & Custom Domains

Ne donnez jamais l'URL moche AWS (xyz.execute-api...) à vos clients.

Régional

Config : API Gateway Regional.
R53 : Alias Record simple vers l'API.
Usage : API standard, Backend mobile.

Multi-Région (Active-Active)

Config : API Gateway dans 2 régions + DynamoDB Global Table.
R53 : Latency-Based Routing vers les 2 APIs.
Usage : API Critique mondiale.

ALB/NLB : La Gestion Dynamique

Les IPs des Load Balancers AWS changent tout le temps (Scaling). Ne pointez jamais vers une IP (Record A), pointez vers le nom DNS (Alias).

Load Balancer	Type Alias	Spécificité
ALB (Application)	Alias A / AAAA	Supporte Evaluate Target Health. Si toutes les instances derrière l'ALB crashent, Route 53 le sait instantanément.
NLB (Network)	Alias A / AAAA	Le NLB peut avoir des IPs statiques (EIP), mais l'Alias reste recommandé pour la simplicité et le coût (Gratuit).
Classic (CLB)	Alias A	Legacy. À migrer vers ALB/NLB.

Route 53 vs Global Accelerator

Deux services pour router le trafic mondial. Lequel choisir ?

Route 53 (DNS)

Route basé sur l'IP du client.
Dépend du TTL (cache) pour le failover (lent).
Le trafic passe par l'Internet public jusqu'à la région cible.
Coût : Très faible.

Global Accelerator (Anycast IP)

Vous donne 2 IPs statiques mondiales.
Pas de cache DNS. Failover en < 30 secondes.
Le trafic entre dans le réseau AWS au plus proche de l'utilisateur (Edge).
Coût : Élevé (Fixe + Data Transfer).

Intégration : Vous pouvez créer un Alias Route 53 qui pointe vers le DNS de Global Accelerator pour avoir un nom de domaine propre sur vos IPs statiques anycast.

ACM : Validation de Certificats

Pour obtenir un certificat SSL gratuit, vous devez prouver que vous possédez le domaine.

Le Workflow Automatisé

Demande de certificat dans ACM (Amazon Certificate Manager).
Choisir DNS Validation (pas Email).
Cliquer sur le bouton "Create records in Route 53".
AWS crée un record CNAME secret (ex: _x9df8...acm-validations.aws).
Résultat : Renouvellement automatique chaque année sans action humaine.

9. Architectures de Référence & Patterns Avancés

Pattern : Le Site Web "Serverless" Mondial

L'architecture standard pour héberger des SPA (React/Vue) ou sites statiques avec une latence minimale et zéro serveur à gérer.

User -> Route 53 (Alias A) -> CloudFront (Edge Cache) -> S3 Bucket (Origin) -> ACM (SSL Cert)

Pourquoi c'est robuste ?

Zone Apex : Route 53 permet l'Alias sur la racine (monsite.com), ce que les autres DNS ne font pas toujours avec un CDN.
Sécurité : Protection DDoS (Shield Standard) incluse au niveau R53 et CloudFront.
Coût : Les requêtes DNS Alias vers CloudFront sont gratuites.

Pattern : Haute Disponibilité Multi-Région

Objectif : 99.999% de disponibilité. Si une région entière (ex: us-east-1) tombe, le trafic bascule automatiquement.

Composant	Configuration	Rôle
Route 53	Latency Routing + Health Checks.	Dirige l'utilisateur vers la région la plus rapide (ou la survivante).
Compute	API Gateway + Lambda (x2 Régions).	Exécution du code sans état (Stateless).
Data	DynamoDB Global Tables.	Réplication des données en < 1 seconde entre les régions (Multi-Master).

Secret : Pour que ça marche, l'application doit être Idempotente (tolérer qu'une requête soit rejouée dans une autre région en cas de coupure réseau).

Pattern : L'Extension du Datacenter

Faire en sorte que les serveurs sur site (On-Prem) et les serveurs AWS se parlent par leur nom, via Direct Connect ou VPN.

Sens AWS -> On-Prem

Besoin : EC2 doit résoudre db.legacy.corp.
Solution : Route 53 Resolver Outbound Endpoint.
Config : Une "Forwarding Rule" dit : "Tout ce qui finit par .corp -> Envoie aux IPs des DNS Windows du Datacenter".

Sens On-Prem -> AWS

Besoin : Le bureau doit résoudre api.internal.aws.
Solution : Route 53 Resolver Inbound Endpoint.
Config : Sur les DNS du bureau, créer un "Conditional Forwarder" : "Tout ce qui finit par .aws -> Envoie aux IPs des ENI AWS".

Pattern : Migration sans Risque (Blue/Green)

Vous migrez un monolithe (Legacy) vers des microservices (Modern) sans downtime.

La Stratégie "Weighted Routing"

Étape 1 : TTL DNS baissé à 60 secondes.
Étape 2 : Créer le nouvel environnement (Green) sur AWS.
Étape 3 : Configurer Route 53 avec des poids :
- Record A (Legacy IP) : Poids 100.
- Record A (AWS ALB) : Poids 0.
Étape 4 (Canary) : Passer AWS à Poids 5 (5% du trafic). Monitorer les erreurs.
Étape 5 (Ramp-up) : Augmenter progressivement (20%, 50%, 100%).
Étape 6 : Décommissionner le Legacy.

Pattern : Service Discovery Interne

Dans un cluster ECS/EKS, les conteneurs sont éphémères. Leurs IPs changent chaque jour.

L'Intégration Cloud Map

Au lieu de gérer des Load Balancers (coûteux) pour chaque microservice interne, on utilise le DNS.

Namespace : service.local (Private Hosted Zone).
Service : auth, payment.
Instance : Quand le conteneur démarre, il s'enregistre automatiquement.

# Résolution depuis un autre conteneur curl http://auth.service.local:8080 # Route 53 répond (Multivalue A record) : 10.0.1.45 10.0.2.99

Note : Le client doit gérer le "Client-Side Load Balancing" (réessayer une autre IP si la première échoue).