Route 53 Alias vs. CNAME Records: Wann welchen Typ verwenden?

Du richtest eine neue Domain ein, zeigst auf einen Application Load Balancer – und stehst vor der Frage: CNAME oder Alias? Auf den ersten Blick scheinen beide dasselbe zu tun. In der Praxis ist der Unterschied jedoch entscheidend, besonders wenn du den Zone Apex (example.com ohne Subdomain) konfigurieren willst.

TL;DR – Route 53 Alias vs. CNAME auf einen Blick

KriteriumCNAMERoute 53 Alias
Zone Apex (example.com)❌ Nicht erlaubt (RFC 1912)✅ Unterstützt
ZielBeliebiger HostnameAWS-Ressourcen (ALB, CloudFront, S3, etc.)
DNS-AbfragekostenKostenpflichtig pro QueryKostenlos für unterstützte AWS-Ziele
TTL steuerbar✅ Ja❌ Nein (von AWS verwaltet)
Health Check IntegrationEingeschränktDirekt integrierbar
Gibt A/AAAA zurückNein (gibt CNAME-Chain zurück)Ja (löst direkt auf)

Wie Route 53 Alias Records funktionieren

Ein CNAME-Record ist ein DNS-Standard: Er verweist einen Hostnamen auf einen anderen Hostnamen. Der Client muss dann diesen zweiten Hostnamen erneut auflösen. Das ist eine DNS-Indirektion – zwei Roundtrips, zwei Queries, zwei TTLs.

Ein Alias-Record ist kein DNS-Standard. Er ist eine Route-53-eigene Erweiterung, die intern wie ein A- oder AAAA-Record verhält. Route 53 löst den Alias-Zielwert (z.B. den DNS-Namen eines ALB) selbst auf und gibt dem Client direkt die IP-Adressen zurück. Aus Sicht des Clients sieht die Antwort wie ein normaler A-Record aus – keine CNAME-Chain, kein zweiter Lookup.

Das ist der Grund, warum Alias-Records am Zone Apex funktionieren: RFC 1912 verbietet CNAME-Records an der Apex-Position, weil dort zwingend SOA- und NS-Records existieren müssen – und ein CNAME schließt andere Record-Typen am selben Namen aus. Da ein Alias intern wie ein A-Record behandelt wird, existiert dieser Konflikt nicht.

graph LR subgraph CNAME_Pfad ["CNAME-Aufloesung"] C1["Client"] -->|"1. Query: www.example.com"| R1["Route 53"] R1 -->|"2. Antwort: CNAME → alb.amazonaws.com"| C1 C1 -->|"3. Query: alb.amazonaws.com"| R2["Externer DNS"] R2 -->|"4. Antwort: IP-Adressen"| C1 end subgraph Alias_Pfad ["Alias-Aufloesung"] C2["Client"] -->|"1. Query: example.com"| R3["Route 53"] R3 -->|"intern: ALB-IPs aufloesen"| ALB["ALB DNS"] R3 -->|"2. Antwort: IP-Adressen direkt"| C2 end style CNAME_Pfad fill:#fff3cd,stroke:#ffc107 style Alias_Pfad fill:#d4edda,stroke:#28a745
  1. CNAME-Auflösung (links): Der Client fragt nach www.example.com, erhält einen CNAME-Verweis auf den ALB-DNS-Namen, und muss diesen dann separat auflösen. Zwei DNS-Queries, zwei Roundtrips.
  2. Alias-Auflösung (rechts): Route 53 löst den ALB-DNS-Namen intern auf und gibt dem Client direkt die IP-Adressen zurück. Eine einzige DNS-Query aus Sicht des Clients.
  3. Zone Apex: Nur der Alias-Pfad ist für example.com (ohne Subdomain) möglich. Der CNAME-Pfad schlägt an dieser Position fehl.

Warum CNAME am Zone Apex scheitert – das konkrete Problem

Stell dir vor, du willst example.com direkt auf deinen ALB zeigen lassen. Du erstellst einen CNAME-Record für example.com und zeigst auf my-alb-123456789.us-east-1.elb.amazonaws.com. Route 53 lässt das gar nicht erst zu – die Konsole gibt einen Fehler zurück.

Der Grund ist im DNS-Standard verankert: An der Apex-Position einer Zone müssen SOA- und NS-Records existieren. Ein CNAME an derselben Position würde bedeuten, dass alle Queries für diesen Namen über den CNAME umgeleitet werden – einschließlich der Queries nach SOA und NS. Das bricht die DNS-Delegation und ist daher verboten.

Alias-Records umgehen das, weil sie keine echten DNS-Records sind. Route 53 behandelt sie intern und gibt nach außen einen synthetischen A-Record zurück. SOA und NS bleiben unberührt.

Ein Alias-Record verhält sich wie ein Makro in Route 53: Er wird zur Abfragezeit expandiert und gibt dem Client das Ergebnis – nicht den Verweis.

Route 53 Alias auf einen ALB konfigurieren

Für die meisten Produktionsszenarien – insbesondere wenn du example.com direkt auf einen ALB zeigen willst – ist der Alias-Record die richtige Wahl. Hier ist die vollständige Konfiguration über die AWS CLI.

Voraussetzungen prüfen

Du brauchst die Hosted Zone ID deiner Domain und den DNS-Namen sowie die Hosted Zone ID des ALB. Die ALB-Hosted-Zone-ID ist nicht deine Account-Hosted-Zone-ID – es ist eine AWS-seitige Zone-ID, die je nach Region variiert und im Describe-Output des Load Balancers enthalten ist.

# Hosted Zone ID deiner Domain ermitteln
aws route53 list-hosted-zones-by-name \
  --dns-name example.com \
  --query 'HostedZones[0].Id' \
  --output text

# DNS-Name und Hosted Zone ID des ALB ermitteln
aws elbv2 describe-load-balancers \
  --names mein-application-load-balancer \
  --query 'LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}' \
  --output table

Alias-Record erstellen

Das folgende Change-Batch erstellt einen Alias-A-Record für den Zone Apex. Ersetze die Platzhalter durch deine tatsächlichen Werte aus dem vorherigen Schritt.

🔽 Change-Batch JSON und CLI-Befehl anzeigen 
# change-batch.json
{
  "Comment": "Alias-Record fuer Zone Apex auf ALB",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "DEINE_ALB_HOSTED_ZONE_ID",
          "DNSName": "mein-alb-123456789.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

# Change-Batch anwenden
aws route53 change-resource-record-sets \
  --hosted-zone-id /hostedzone/DEINE_HOSTED_ZONE_ID \
  --change-batch file://change-batch.json

Der Parameter EvaluateTargetHealth: true ist hier wichtig: Route 53 wertet den Health-Status des ALB aus und leitet Traffic nur weiter, wenn der Ziel-Endpunkt als gesund gilt. Bei einem CNAME ist diese direkte Integration nicht verfügbar.

Propagation prüfen

# Aenderungsstatus prüfen (ChangeId aus dem vorherigen Output verwenden)
aws route53 get-change \
  --id /change/DEINE_CHANGE_ID \
  --query 'ChangeInfo.Status' \
  --output text

# DNS-Aufloesung verifizieren (gibt direkt IP-Adressen zurueck, keinen CNAME)
dig +short example.com A

Wann CNAME trotzdem sinnvoll ist

CNAME-Records haben ihren Platz – sie sind nicht grundsätzlich schlechter. Wenn du auf Nicht-AWS-Ziele verweisen musst (z.B. einen externen SaaS-Anbieter, der dir einen Hostnamen gibt), ist CNAME die einzige Option. Alias-Records funktionieren ausschließlich mit unterstützten AWS-Ressourcen: ALB, NLB, CloudFront-Distributionen, API Gateway, Elastic Beanstalk-Umgebungen, S3-Website-Endpoints und andere Route-53-Records in derselben Hosted Zone.

Für Subdomains wie www.example.com oder api.example.com, die auf externe Dienste zeigen, ist CNAME völlig legitim. Die Zone-Apex-Einschränkung gilt dort nicht.

graph TD A["DNS-Record erstellen"] --> B{"Ziel ist eine
AWS-Ressource?"} B -->|"Nein"| C["CNAME verwenden"] B -->|"Ja"| D{"Zone Apex
example.com?"} D -->|"Ja"| E["Alias-Record
PFLICHT"] D -->|"Nein – Subdomain"| F{"Health Check
Integration gewuenscht?"} F -->|"Ja"| G["Alias-Record
EMPFOHLEN"] F -->|"Nein"| H["CNAME oder Alias
beide moeglich"] style E fill:#d4edda,stroke:#28a745 style G fill:#d4edda,stroke:#28a745 style C fill:#fff3cd,stroke:#ffc107
  1. Entscheidungspunkt 1: Ist das Ziel eine unterstützte AWS-Ressource? Wenn nein, bleibt nur CNAME.
  2. Entscheidungspunkt 2: Handelt es sich um den Zone Apex? Wenn ja, ist Alias zwingend erforderlich.
  3. Empfehlung: Für Subdomains mit AWS-Zielen ist Alias ebenfalls bevorzugt – wegen der kostenlosen Queries und der Health-Check-Integration.

Ein typischer Fehler in der Praxis – und warum er schwer zu erkennen ist

Ein häufiges Muster: Die Applikation läuft auf www.example.com (CNAME auf ALB), und example.com soll per HTTP-Redirect auf www weiterleiten. Dafür wird ein S3-Bucket mit Website-Hosting und Redirect-Konfiguration verwendet.

Der Fehler passiert, wenn für example.com ein CNAME auf den S3-Website-Endpoint erstellt wird. Route 53 lehnt das ab. Die Fehlermeldung in der Konsole lautet sinngemäß, dass CNAME-Records am Zone Apex nicht erlaubt sind – aber wer das zum ersten Mal sieht, sucht oft zuerst nach einem Berechtigungsproblem oder einem Tippfehler im Hostnamen.

Die Lösung: Alias-Record für example.com, Ziel der S3-Website-Endpoint. S3-Website-Endpoints sind explizit als Alias-Ziele unterstützt. Der Redirect funktioniert dann wie erwartet, ohne dass ein EC2-Instanz oder Lambda-Funktion als Redirect-Handler nötig ist.

IAM-Berechtigungen für Route-53-Änderungen

Wenn du die CLI-Befehle oben über eine IAM-Rolle oder einen IAM-User ausführst, brauchst du mindestens die folgenden Berechtigungen. route53:GetChange ist für die Statusprüfung erforderlich, route53:ListHostedZonesByName für die Zone-ID-Ermittlung.

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

Hinweis: route53:GetChange und route53:ListHostedZones unterstützen keine ressourcenbasierte Einschränkung auf Hosted-Zone-Ebene – "Resource": "*" ist für diese Aktionen erforderlich. Für route53:ChangeResourceRecordSets und route53:ListResourceRecordSets kann die Ressource auf eine spezifische Hosted Zone eingeschränkt werden: arn:aws:route53:::hostedzone/DEINE_HOSTED_ZONE_ID.

Wrap-up: Route 53 Alias vs. CNAME – die operative Entscheidungsregel

Für AWS-Ziele ist der Alias-Record in fast allen Fällen die bessere Wahl: kein zweiter DNS-Lookup, keine Query-Kosten, direkte Health-Check-Integration, und als einzige Option am Zone Apex. CNAME bleibt relevant für externe Ziele außerhalb von AWS.

Wenn du eine neue Domain auf einen ALB, eine CloudFront-Distribution oder einen S3-Website-Endpoint zeigen lässt, fang immer mit dem Alias-Record an. CNAME ist die Fallback-Option, wenn das Ziel kein unterstützter AWS-Dienst ist.

Weiterführende Dokumentation: AWS Route 53 – Alias vs. Non-Alias Records

Glossar

BegriffErklärung
Zone ApexDer Root-Name einer DNS-Zone, z.B. example.com ohne Subdomain-Präfix. Auch 'naked domain' oder 'root domain' genannt.
CNAME (Canonical Name)DNS-Record-Typ, der einen Hostnamen auf einen anderen Hostnamen verweist. Standardisiert in RFC 1035.
Alias-RecordRoute-53-eigene Erweiterung, die intern wie ein A/AAAA-Record funktioniert und auf unterstützte AWS-Ressourcen zeigt.
CanonicalHostedZoneIdDie AWS-seitige Hosted Zone ID eines Load Balancers – nicht identisch mit der Hosted Zone ID deiner eigenen Domain.
EvaluateTargetHealthAlias-Parameter, der Route 53 anweist, den Health-Status der Zielressource zu prüfen, bevor Traffic weitergeleitet wird.

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

EC2 ohne Internetzugang im eigenen VPC – Internet Gateway und Route Table korrekt einrichten

Du hast ein eigenes VPC erstellt, eine EC2-Instanz in einem öffentlichen Subnetz gestartet – und ping google.com läuft ins Leere. Kein Timeout-Fehler, keine Fehlermeldung, einfach nichts. Dieses Problem tritt fast immer auf, wenn ein Custom VPC ohne Internet Gateway oder mit einer unvollständigen Route-Table-Konfiguration aufgesetzt wird, weil AWS bei eigenen VPCs bewusst keine Standard-Internetverbindung mitliefert. TL;DR – EC2 Internetzugang im Custom VPC Schritt Aktion Warum notwendig 1 Internet Gateway erstellen und an VPC anhängen Ohne IGW gibt es keinen Pfad ins öffentliche Internet 2 Route Table aktualisieren (0.0.0.0/0 → IGW) Der Traffic muss explizit über das IGW geroutet werden 3 Subnetz mit Route Table verknüpfen Eine Route Table ohne Subnetz-Assoziation hat keine Wirkung 4 Öffentliche IP oder Elastic IP prüfen Ohne öffentliche IP kann das IGW keinen eingehenden Rückpfad aufbauen 5 Securi...
Mehr anzeigen

EC2 SSH Verbindungs-Timeout: Security Group Inbound-Regeln richtig konfigurieren

Du startest eine neue EC2-Instanz, versuchst dich per SSH zu verbinden — und bekommst sofort ein 'Connection timed out'. Kein 'Connection refused', kein Passwort-Prompt, einfach Stille. Das ist fast immer ein Netzwerkproblem auf Infrastrukturebene, und die häufigste Ursache ist eine fehlende oder falsch konfigurierte Inbound-Regel in der Security Group der EC2 SSH-Verbindung. TL;DR — EC2 SSH Verbindungs-Timeout auf einen Blick Schicht Was prüfen Häufigste Ursache Security Group Inbound-Regel für TCP Port 22 Regel fehlt oder falsche Quell-IP Network ACL Inbound + Outbound für Port 22 und Ephemeral Ports Outbound-Regel für Ephemeral Ports fehlt Route Table Route zum Internet Gateway (0.0.0.0/0) Kein Internet Gateway zugewiesen Instanz Public IP vorhanden, Instanz-Status 'running' Keine öffentliche IP zugewiesen Wie EC2-Netzwerkzugriff funktioniert — Pflichtlektüre vor Schritt 1...
Mehr anzeigen