Skip to content
Learni
Voir tous les tutoriels
AWS

Comment maîtriser Amazon Route 53 en 2026

Read in English

Introduction

Amazon Route 53 est le service DNS scalable et hautement disponible d'AWS, gérant des millions de requêtes par seconde avec une latence minimale. En 2026, il intègre nativement l'IA pour le routage prédictif et les résolutions hybrides on-prem/cloud. Ce tutoriel expert vous guide de la création de zones hébergées aux politiques de routage avancées comme le geoproximity et le multivalue answer, en passant par les health checks actifs/passifs et l'automatisation via CLI/SDK. Pourquoi c'est crucial ? Une mauvaise configuration DNS peut causer des outages mondiaux (ex. : 99,99% SLA Route 53 vs downtimes clients). Vous apprendrez à implémenter un setup résilient pour applications globales, avec failover automatique et monitoring intégré CloudWatch. Idéal pour architectes DevOps gérant des flottes EC2/S3 multi-régions. À la fin, vous maîtriserez l'optimisation pour réduire les coûts de 30% via traffic policies.

Prérequis

  • Compte AWS avec permissions IAM : Route53FullAccess, CloudWatchFullAccess
  • AWS CLI v2 installé et configuré (aws configure)
  • Node.js 20+ avec AWS SDK v3 (npm i @aws-sdk/client-route-53)
  • Connaissances avancées en networking (TTL, EDNS, anycast)
  • Outils : dig ou nslookup pour tests DNS

Installer et configurer AWS CLI

setup-aws-cli.sh
#!/bin/bash

# Vérifier installation AWS CLI v2
aws --version

# Configurer credentials (remplacez par vos valeurs)
aws configure set aws_access_key_id AKIAIOSFODNN7EXAMPLE
aws configure set aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws configure set default.region us-east-1

# Tester connexion
aws sts get-caller-identity

# Activer JSON output pour scripts
aws configure set default.output json

Ce script initialise AWS CLI v2, configure les credentials IAM et définit la région par défaut. Il teste l'authentification via STS et active le format JSON pour une parsing facile en automatisation. Évitez les clés hardcodées en prod : utilisez IAM roles ou SSM Parameter Store.

Comprendre les zones hébergées

Une zone hébergée est un conteneur pour les records DNS d'un domaine (ex. : example.com). Route 53 supporte public/private zones, avec propagation anycast globale (<50ms). Analogie : comme un annuaire téléphonique scalable. Avant de créer, listez les zones existantes via CLI pour éviter doublons.

Créer une zone hébergée publique

create-hosted-zone.sh
#!/bin/bash

ZONE_NAME="example.com"
HOSTED_ZONE_ID=$(aws route53 create-hosted-zone \
  --name $ZONE_NAME \
  --caller-reference "$(date +%s)" \
  --hosted-zone-config Comment="Zone experte 2026" \
  | jq -r '.HostedZone.Id' | sed 's|/hostedzone/||')

echo "Zone ID: $HOSTED_ZONE_ID"

# Récupérer NS records pour delegation chez registrar
aws route53 get-hosted-zone --id $HOSTED_ZONE_ID | jq '.DelegationSet.NameServers'

Ce script crée une zone publique avec un caller-reference unique (timestamp) pour idempotence. Il extrait l'ID et les NS pour déléguer chez votre registrar (GoDaddy, etc.). Piège : sans caller-reference unique, la création échoue ; utilisez UUID en prod.

Ajouter des records DNS basiques

Les records A/AAAA/CNAME pointent vers ressources (ELB, S3). TTL bas (60s) pour dev, 300s+ en prod. Utilisez weighted pour A/B testing.

Créer records A et CNAME

records-change-batch.json
{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [
          { "Value": "192.0.2.1" }
        ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "CNAME",
        "TTL": 60,
        "ResourceRecords": [
          { "Value": "example.com" }
        ]
      }
    }
  ]
}

Ce batch JSON crée un record A statique et CNAME alias. Appliquez-le via aws route53 change-resource-record-sets --hosted-zone-id Z123 --change-batch file://records-change-batch.json. Avantage batch : atomique. Piège : TTL trop bas augmente coûts queries.

Appliquer le batch de records

apply-records.sh
#!/bin/bash

HOSTED_ZONE_ID="Z123456789EXAMPLE"

aws route53 change-resource-record-sets \
  --hosted-zone-id $HOSTED_ZONE_ID \
  --change-batch file://records-change-batch.json

# Vérifier propagation
sleep 60
dig +short api.example.com

Ce script applique le batch et vérifie propagation avec dig. Remplacez ZONE_ID par le vôtre. En prod, ajoutez boucle retry pour status INSYN C. Propagation globale : 60s max.

Implémenter health checks

Health checks monitorent endpoints (HTTP/HTTPS/TCP), trigger failover si >3 échecs. Intégrez CloudWatch alarms pour alertes.

Créer un health check HTTP

create-health-check.sh
#!/bin/bash

HEALTH_CHECK_ID=$(aws route53 create-health-check \
  --caller-reference "hc-$(date +%s)" \
  --health-check-config \
    Port=80,Type=HTTP,ResourcePath=/health,RequestInterval=30,FailureThreshold=3 \
    FullyQualifiedDomainName=api.example.com \
  | jq -r '.HealthCheck.Id')

echo "Health Check ID: $HEALTH_CHECK_ID"

# Lister health checks
aws route53 list-health-checks

Crée un check HTTP sur /health toutes 30s, failover après 3 échecs (90s). Associez à records pour routing intelligent. Piège : sans FQDN correct, checks échouent ; testez avec curl.

Politiques de routage avancées

Latency-based : route vers région la plus rapide. Failover : primary/secondary avec health. Geolocation : par continent/pays.

Record avec routage latency-based

latency-routing.json
{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "us-east-1",
        "Region": "us-east-1",
        "TTL": 60,
        "ResourceRecords": [
          { "Value": "3.5.1.2" }
        ],
        "TrafficPolicyInstanceId": null,
        "RoutingPolicy": "latency"
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "app.example.com",
          "Type": "A",
          "SetIdentifier": "eu-west-1",
          "Region": "eu-west-1",
          "TTL": 60,
          "ResourceRecords": [
            { "Value": "3.6.1.3" }
          ],
          "RoutingPolicy": "latency"
        }
      }
    }
  ]
}

Ce batch implémente latency routing : Route 53 mesure RTT et route vers la région la plus rapide. Appliquez comme avant. Avantage : +20% perf globales. Piège : régions sans endpoints = fallback aléatoire.

Automatiser avec AWS SDK TypeScript

route53-manager.ts
import { Route53Client, createHostedZoneCommand, changeResourceRecordSetsCommand } from '@aws-sdk/client-route-53';

import { readFileSync } from 'fs';

const client = new Route53Client({ region: 'us-east-1' });

async function createZone(zoneName: string) {
  const command = new createHostedZoneCommand({
    Name: zoneName,
    CallerReference: `ref-${Date.now()}`,
    HostedZoneConfig: { Comment: 'Zone TS 2026' }
  });
  const response = await client.send(command);
  console.log('Zone ID:', response.HostedZone?.Id);
  return response.HostedZone?.Id;
}

async function upsertRecords(zoneId: string, batchFile: string) {
  const batch = JSON.parse(readFileSync(batchFile, 'utf8'));
  const command = new changeResourceRecordSetsCommand({
    HostedZoneId: zoneId!,
    ChangeBatch: batch
  });
  await client.send(command);
  console.log('Records updated');
}

// Usage
await createZone('ts-example.com');
// await upsertRecords('Z123', './latency-routing.json');

Ce script TS complet utilise SDK v3 pour créer zone et upsert records. Exécutez avec ts-node route53-manager.ts. Modularité pour CI/CD. Piège : gérer paginations pour >100 records ; utilisez ListHostedZonesCommand.

Bonnes pratiques

  • TTL adaptatif : 60s dev, 3600s prod ; utilisez CloudFront pour edge caching.
  • Health checks + alarms : Associez à SNS pour notifications instantanées.
  • Traffic policies : Préférez-les aux record sets pour complexité (JSON vs UI).
  • Resolver VPC : Pour hybrid DNS, inbound/outbound rules avec on-prem.
  • Coûts : Monitorez queries via Cost Explorer ; query logging vers S3/CloudWatch Logs.

Erreurs courantes à éviter

  • Caller-reference dupliqué : Toujours unique (UUID/timestamp) ou upsert échoue.
  • Propagation ignorée : Attendez 60s+ avant tests ; utilisez dig @NS1.ROUTE53.
  • Régions incompatibles : Latency routing ignore us-east-1 comme référence.
  • Pas de health check : Failover manuel ; intégrez toujours pour 99.99% uptime.

Pour aller plus loin