Aller au contenu

AWS Mis à jour le 2026-09-12

Alias Route 53 vs CNAME : ce que sont vraiment les enregistrements alias et quand chacun gagne

Alias Route 53 vs CNAME se décide selon l'endroit où vit la cible, et ce guide vous montre quel enregistrement créer dans chaque cas. Vous verrez pourquoi un alias fonctionne sur votre domaine nu, quand le CNAME reste le bon choix, et comment vérifier le résultat avec dig.

Cet article s’adresse à vous si vous modifiez des enregistrements DNS (Domain Name System, le système de noms de domaine) dans AWS Route 53 et que vous hésitez entre un enregistrement alias et un enregistrement CNAME. La question arrive souvent quand vous voulez que example.com, sans www devant, pointe vers un répartiteur de charge, et que Route 53 refuse le CNAME (Canonical Name) que vous tentez d’enregistrer. En bref, prenez un enregistrement alias quand la cible est une ressource AWS que Route 53 accepte, comme un répartiteur de charge applicatif (ALB) ou une distribution CloudFront (le réseau de diffusion de contenu d’AWS). Gardez le CNAME pour les cibles qui vivent hors d’AWS, et rappelez-vous que seul un alias peut se placer à l’apex de la zone, votre domaine nu sans rien devant. À la fin, vous saurez quel enregistrement créer pour chaque cible et comment confirmer en ligne de commande qu’un nom répond comme prévu.

Ce que vous décidez

Un CNAME est un vrai type d’enregistrement DNS défini par les standards : il dit « ce nom est un alias pour cet autre nom, allez résoudre celui-là ». Le résolveur fait cette deuxième recherche, ce qui coûte un aller-retour de plus. Le standard interdit aussi à un CNAME de coexister avec tout autre enregistrement au même nom. C’est exactement pourquoi vous ne pouvez pas en mettre un à l’apex de la zone, où vivent déjà les enregistrements SOA et NS.

Un enregistrement alias n’est pas un type d’enregistrement DNS du tout. C’est une fonctionnalité Route 53 : un pointeur interne que Route 53 suit côté serveur au moment de la requête, puis il répond directement avec les enregistrements A ou AAAA finaux. Le résolveur ne voit jamais l’indirection. Cette seule différence de conception produit toutes les conséquences pratiques :

  • Support de l’apex. Comme la réponse est un A/AAAA ordinaire, un alias peut vivre à example.com lui-même. C’est la réponse standard au problème du domaine apex sur AWS.
  • Coût. Les requêtes vers des alias pointant sur des ressources AWS ne sont pas facturées; les requêtes CNAME le sont comme n’importe quelle requête. Sur une zone à fort trafic, c’est une vraie ligne, même petite.
  • TTL. Vous ne pouvez pas fixer de TTL sur un alias — Route 53 utilise celui de la ressource sous-jacente (60 secondes pour une cible ALB, par exemple). Avec un CNAME, vous contrôlez le TTL vous-même.
  • Fraîcheur. Quand un ALB change d’échelle et que ses IP sous-jacentes changent, la réponse de l’alias suit automatiquement. Un CNAME vers le nom DNS de l’ALB arrive au même résultat, juste une recherche plus tard.
  • Conscience de l’état. Un alias peut activer Evaluate target health : Route 53 cesse de répondre avec une cible dont le répartiteur de charge ne rapporte aucune instance saine — aucune vérification de l’état séparée requise. Un CNAME ne sait rien de l’état de sa cible.

Quoi vérifier en premier

  • L’enregistrement est-il à l’apex? La décision est prise pour vous : alias (ou un enregistrement A vers des IP statiques). Un CNAME sera rejeté.
  • La cible est-elle une ressource AWS de la liste supportée? ALB/NLB, CloudFront, API Gateway, points de terminaison de site web S3, Elastic Beanstalk, Global Accelerator, points de terminaison d’interface VPC et enregistrements de la même zone qualifient tous.
  • La cible est-elle un service tiers (nom de vérification d’un fournisseur SaaS, CDN externe)? Alors le CNAME est la seule option.
  • Autre chose doit-il exister à ce nom? Des enregistrements MX ou TXT au même nom excluent le CNAME immédiatement.

Comment vérifier

Regardez ce qu’un nom retourne réellement — un alias répond avec des adresses, un CNAME répond avec un nom :

# Alias vers un ALB : retourne des A directement, aucun CNAME dans la chaîne
dig +short app.example.com A

# CNAME : retourne d'abord le nom cible, puis ses adresses
dig app.example.com A +noall +answer

Dans l’API, un alias apparaît comme un bloc AliasTarget au lieu de ResourceRecords :

aws route53 list-resource-record-sets --hosted-zone-id Z0123456789ABC \
  --query "ResourceRecordSets[?Name=='app.example.com.']"

Dans la console, Route 53 > Hosted zones > example.com montre une bascule Alias sur le formulaire d’édition; quand elle est activée, le champ valeur devient un sélecteur de ressources AWS du compte plus un champ libre.

L’approche

  1. Alias par défaut pour tout ce qui est AWS. ALB, CloudFront, domaines personnalisés API Gateway, sites statiques S3 — alias, type A (et un deuxième alias, type AAAA, si la cible parle IPv6, ce que font CloudFront et les ALB à double pile).
  2. CNAME pour les cibles externes. Enregistrements de vérification des fournisseurs de courriel, pages de statut tierces, CDN externes — le CNAME y est correct et inévitable.
  3. À l’apex, alias ou rien. Si votre DNS n’est pas chez Route 53 et que le fournisseur n’offre aucun ANAME ni aplatissement, cette contrainte à elle seule justifie de déménager la zone chez Route 53. Le registraire peut rester où il est.
  4. Activez Evaluate target health de façon délibérée. Pour un montage mono-région derrière un seul ALB, ça ajoute peu. Pour des enregistrements pondérés ou de bascule entre régions, c’est le mécanisme qui fait vraiment bouger le trafic — jumelez-le à l’ajustement des vérifications de l’état du répartiteur pour que le signal évalué soit significatif.
  5. Alias vers alias dans une zone, c’est correct. Pointer www vers l’enregistrement de l’apex (ou plusieurs noms d’environnement vers un enregistrement canonique) garde un seul endroit à mettre à jour quand la cible change.

Quand c’est la mauvaise approche

Les alias n’existent que dans Route 53 : si la zone vit chez un autre fournisseur DNS, la discussion est close — vous avez des CNAME et le contournement d’apex que le fournisseur offre. Et un alias n’est pas une redirection : pointer example.com vers une distribution CloudFront sert le même contenu à ce nom; ça ne réécrit pas l’URL dans le navigateur. Si vous voulez que example.com devienne www.example.com, c’est un 301 HTTP émis par quelque chose — pas un tour de DNS. Enfin, n’utilisez pas un CNAME vers un ALB sur un nom qui porte aussi des MX pour le courriel : le CNAME détourne le nom au complet et la livraison du courriel casse de façon déroutante.

Erreurs fréquentes

  • Créer un CNAME vers d111abcdef.cloudfront.net à l’apex chez un fournisseur non-Route 53 qui l’« accepte » silencieusement — certains le font — et briser la résolution SOA/NS du domaine.
  • Oublier l’alias AAAA : les clients IPv6 seulement (une part croissante des réseaux mobiles) échouent à se connecter pendant que tous les tests du bureau passent.
  • Mettre un long TTL sur un CNAME vers un point de terminaison AWS, puis se demander pourquoi la bascule en incident prend une heure.
  • S’attendre à ce qu’Evaluate target health fonctionne à travers une chaîne dont la cible finale ne rapporte pas d’état — il suit les chaînes d’alias, mais la cible finale doit émettre un signal d’état.

Garder le contrôle

  • Standardisez : alias pour les cibles AWS, CNAME pour l’externe, documenté dans le runbook de la zone.
  • Auditez la zone chaque trimestre avec list-resource-record-sets et signalez les CNAME pointant vers des ressources AWS — chacun est une mise à niveau gratuite vers un alias.
  • Créez les alias A et AAAA ensemble, chaque fois, par habitude.
  • Gardez la zone dans le même compte que la charge de travail quand c’est possible; les cibles d’alias inter-comptes fonctionnent, mais le sélecteur de la console ne les trouve pas, ce qui invite les coquilles.

La documentation Route 53 tient à jour la liste des cibles d’alias supportées, et elle s’allonge avec le temps — ça vaut une vérification avant de conclure qu’un CNAME est requis. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.