Route 53 Alias vs CNAME : lequel choisir pour pointer vers un ALB ?

Vous venez de déployer un Application Load Balancer et vous devez maintenant faire pointer votre domaine vers lui. Vous ouvrez la console Route 53, vous créez un enregistrement — et là, deux options s'offrent à vous : CNAME ou Alias. La plupart des ingénieurs choisissent le CNAME par réflexe, parce que c'est ce qu'ils connaissent depuis leurs débuts avec le DNS. C'est souvent une erreur, surtout pour l'apex de zone.

TL;DR — Alias vs CNAME pour Route 53

Critère CNAME Alias Route 53
Apex de zone (example.com) ❌ Interdit par la RFC 1034 ✅ Supporté nativement
Résolution DNS Deux requêtes minimum (CNAME + A) Une seule réponse A/AAAA
Coût des requêtes Route 53 Facturé à chaque requête Gratuit vers les ressources AWS éligibles
Health check intégré Non Oui (évalue la cible)
Cibles supportées N'importe quel hostname Ressources AWS spécifiques (ALB, CloudFront, S3, etc.)
TTL configurable Oui Non — géré par Route 53

Comment fonctionne la résolution DNS avec un CNAME vs un Alias Route 53

Avant de choisir, il faut comprendre ce qui se passe réellement au niveau du protocole DNS — parce que la différence entre les deux n'est pas cosmétique.

Un enregistrement CNAME est défini dans la RFC 1034 : il indique qu'un nom de domaine est un alias d'un autre nom canonique. Le résolveur DNS doit donc effectuer au moins deux requêtes : une pour résoudre le CNAME, puis une autre pour résoudre le nom canonique vers une adresse IP. Ce comportement est standard et universel, mais il a une contrainte fondamentale : un CNAME ne peut pas coexister avec d'autres enregistrements sur le même nom. Or, l'apex de zone (example.com) doit obligatoirement avoir un enregistrement SOA et NS — ce qui rend le CNAME structurellement impossible à cet endroit.

L'enregistrement Alias de Route 53 n'est pas un type DNS standard. C'est une extension propriétaire AWS qui existe uniquement dans Route 53. Lorsqu'un résolveur interroge Route 53 pour un enregistrement Alias, Route 53 résout lui-même la cible en temps réel et retourne directement les adresses IP dans la réponse. Du point de vue du résolveur externe, il reçoit un enregistrement A ou AAAA — sans jamais voir l'indirection.

sequenceDiagram participant Client as Client DNS participant R53 as Route 53 participant AWSDNS as DNS AWS (ALB) Note over Client,AWSDNS: Résolution CNAME (www.example.com) Client->>R53: Requête A pour www.example.com R53-->>Client: CNAME → alb-123.us-east-1.elb.amazonaws.com Client->>AWSDNS: Requête A pour alb-123.us-east-1.elb.amazonaws.com AWSDNS-->>Client: 54.12.34.56, 54.12.34.57 Note over Client,AWSDNS: Résolution Alias (example.com) Client->>R53: Requête A pour example.com R53->>R53: Résolution interne de la cible ALB R53-->>Client: 54.12.34.56, 54.12.34.57
  1. CNAME (haut) : le client interroge Route 53, reçoit un CNAME, puis doit interroger à nouveau le DNS d'AWS pour résoudre le nom de l'ALB en adresse IP. Deux allers-retours minimum.
  2. Alias (bas) : Route 53 résout lui-même la cible ALB en interne et retourne directement les adresses IP. Le client ne voit qu'une seule réponse de type A.

Pourquoi l'Alias Route 53 est indispensable pour l'apex de zone

L'apex de zone — example.com sans sous-domaine — est le cas d'usage qui force la décision. Si votre application doit être accessible directement sur le domaine racine (ce qui est le cas pour la grande majorité des sites en production), vous n'avez pas le choix : un CNAME est techniquement invalide à cet endroit.

Pensez à l'apex de zone comme au couloir principal d'un immeuble. Les appartements (sous-domaines) peuvent avoir des plaques indiquant 'voir l'appartement 12' (CNAME). Mais la plaque principale de l'immeuble doit indiquer une adresse réelle — elle ne peut pas pointer vers une autre plaque.

Certains ingénieurs contournent cette contrainte en redirigeant example.com vers www.example.com via une règle applicative ou un bucket S3 statique. C'est une solution valide, mais elle ajoute de la latence et de la complexité opérationnelle. L'enregistrement Alias élimine ce besoin.

Un autre avantage moins documenté : quand un ALB est mis à jour par AWS (changement d'adresses IP lors d'un scaling ou d'une maintenance), les enregistrements Alias reflètent automatiquement ces changements. Avec un CNAME, vous dépendez du TTL de l'enregistrement DNS de l'ALB lui-même — ce qui est hors de votre contrôle direct.

Configurer un enregistrement Alias Route 53 vers un ALB via la CLI

Voici comment créer un enregistrement Alias de type A pour pointer example.com vers un ALB. Vous aurez besoin du DNS name de votre ALB et de son Hosted Zone ID (différent de votre Hosted Zone ID Route 53 — c'est le zone ID propre à l'ALB, disponible via la CLI ou la console EC2).

Récupérez d'abord les informations de votre ALB :

aws elbv2 describe-load-balancers \
  --names mon-application-alb \
  --query 'LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}' \
  --output json

Notez le DNSName et le CanonicalHostedZoneId retournés. Récupérez ensuite l'ID de votre Hosted Zone Route 53 :

aws route53 list-hosted-zones-by-name \
  --dns-name example.com \
  --query 'HostedZones[0].Id' \
  --output text
🔽 Voir le fichier change-batch JSON complet 
{
  "Comment": "Alias vers ALB pour apex de zone",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "mon-application-alb-123456789.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

Appliquez le changement :

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

Vérifiez la propagation :

aws route53 get-change \
  --id /change/C1234567890EXAMPLE \
  --query 'ChangeInfo.Status' \
  --output text

Quelques points importants sur le fichier de configuration :

  • HostedZoneId dans AliasTarget : c'est le CanonicalHostedZoneId de l'ALB récupéré précédemment, pas votre Hosted Zone Route 53.
  • EvaluateTargetHealth: true : Route 53 évalue l'état de santé de l'ALB. Si l'ALB est unhealthy, Route 53 peut retourner une réponse NXDOMAIN ou basculer vers un enregistrement de failover si vous en avez configuré un.
  • Pas de TTL : le champ TTL est absent — il est géré par Route 53 et ne doit pas être spécifié pour un enregistrement Alias.

Le piège classique : CNAME sur un sous-domaine qui fonctionne, Alias sur l'apex qui échoue silencieusement

Voici un scénario réel. Un ingénieurs configure www.example.com avec un CNAME vers l'ALB — ça fonctionne parfaitement. Il essaie de répliquer la même configuration pour example.com et crée un CNAME. La console Route 53 le laisse faire dans certains cas (si la zone est mal configurée ou si l'enregistrement SOA/NS est absent), mais le comportement DNS devient imprévisible : certains résolveurs ignorent le CNAME sur l'apex, d'autres retournent des erreurs, d'autres encore résolvent correctement par chance.

Le diagnostic est frustrant parce que dig example.com depuis votre machine peut retourner une réponse correcte (votre résolveur local a peut-être mis en cache une réponse valide), alors que les utilisateurs en production voient des erreurs de résolution intermittentes.

La vraie cause : la RFC 1034 interdit explicitement un CNAME sur un nom qui a d'autres enregistrements. L'apex a toujours SOA et NS. Le comportement observé dépend de l'implémentation du résolveur — ce qui explique l'intermittence.

La correction est simple : supprimer le CNAME et créer un enregistrement Alias de type A à la place. Mais le temps de diagnostic peut être long si on ne connaît pas cette contrainte.

graph TD A["Enregistrement DNS créé"] --> B{"Apex de zone ?
example.com"} B -->|Oui| C["SOA + NS présents
obligatoirement"] B -->|Non| D["Sous-domaine
www.example.com"] C --> E["CNAME interdit
RFC 1034"] C --> F["Alias Route 53 ✅
Résolution directe A/AAAA"] D --> G["CNAME valide ✅
Deux requêtes DNS"] D --> H["Alias Route 53 ✅
Préférable pour cibles AWS"] E --> I["Comportement résolveur
imprévisible ⚠️"] F --> J["Réponse A directe
Health check intégré"] G --> K["Coût par requête
TTL configurable"] H --> J
  1. Zone apex : la présence obligatoire des enregistrements SOA et NS rend le CNAME invalide. Route 53 peut accepter la création mais le comportement DNS est non défini.
  2. Sous-domaine : pas d'enregistrements obligatoires, le CNAME est valide — mais l'Alias reste préférable pour les cibles AWS (coût, health check).
  3. Résolution imprévisible : certains résolveurs ignorent le CNAME en conflit, d'autres tentent de le résoudre, ce qui produit des comportements différents selon le résolveur utilisé par le client.

Quand utiliser un CNAME malgré tout

L'enregistrement Alias n'est pas universel. Il ne fonctionne qu'avec des ressources AWS spécifiques : ALB, NLB, CloudFront, S3 (site statique), Elastic Beanstalk, API Gateway, et quelques autres services documentés par AWS. Si votre cible est un service tiers — un endpoint SaaS, un CDN externe, un service hébergé hors AWS — vous devez utiliser un CNAME.

De même, si vous avez besoin d'un TTL personnalisé précis (par exemple pour une migration DNS avec un TTL très court), le CNAME vous donne ce contrôle. L'Alias délègue la gestion du TTL à Route 53.

IAM — permissions minimales pour gérer les enregistrements Route 53

Si vous gérez ces enregistrements via un pipeline CI/CD ou un rôle IAM dédié, voici la politique minimale requise :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets",
        "route53:GetChange"
      ],
      "Resource": [
        "arn:aws:route53:::hostedzone/Z1234567890EXAMPLE"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZonesByName",
        "route53:ListHostedZones"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "elasticloadbalancing:DescribeLoadBalancers"
      ],
      "Resource": "*"
    }
  ]
}

Note : route53:ListHostedZones et elasticloadbalancing:DescribeLoadBalancers ne supportent pas la restriction par ARN de ressource — "Resource": "*" est requis pour ces actions.

Conclusion — Alias Route 53 : le choix par défaut pour les ressources AWS

Pour tout domaine pointant vers une ressource AWS — ALB, CloudFront, S3, API Gateway — l'enregistrement Alias Route 53 est le choix correct. Il résout la contrainte de l'apex de zone, élimine le coût des requêtes DNS, et intègre nativement l'évaluation de santé de la cible. Le CNAME reste pertinent uniquement pour les cibles hors AWS ou quand un TTL personnalisé est nécessaire.

Pour approfondir, consultez la documentation officielle Route 53 sur le choix entre Alias et non-Alias et la liste des valeurs supportées pour les enregistrements Alias.

Glossaire

Terme Définition
Apex de zone Le domaine racine d'une zone DNS (example.com), sans sous-domaine. Doit obligatoirement avoir des enregistrements SOA et NS.
CNAME Canonical Name Record — type DNS standard qui fait pointer un nom vers un autre nom canonique. Interdit sur l'apex de zone.
Alias Record Extension propriétaire Route 53 qui résout une cible AWS en adresses IP directement, sans indirection DNS visible par le client.
CanonicalHostedZoneId Identifiant de zone hébergée propre à un ALB (ou autre ressource AWS), distinct du Hosted Zone ID de votre zone Route 53.
EvaluateTargetHealth Option Alias qui permet à Route 53 d'évaluer l'état de santé de la ressource cible et d'influencer le routage DNS en conséquence.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite