Migration von AWS Route 53 zu Bunny DNS für Kostenkontrolle und Flexibilität

Vincent Bernat hat kürzlich seine Migration der persönlichen Blog-Infrastruktur von Amazon Web Services (AWS) zu Bunny.net dokumentiert. Der am 6. November 2026 veröffentlichte Fallbericht zeigt, wie der Wechsel von Route 53 und CloudFront zu Bunnys DNS- und CDN-Diensten die monatlichen Kosten von fünf Dollar auf einen Dollar reduzierte. Auslöser waren die hohen Gebühren für Geolokalisierungsabfragen und Health Checks bei AWS sowie der Wunsch nach einem europäischen Anbieter.

Was passiert ist

Bernat verließ sich zuvor auf Amazon CloudFront für die Content-Auslieferung und Route 53 für geo-bewusstes DNS-Routing. Diese Konfiguration leitete Leser zum nächstgelegenen Host, der seinen Inhalt auslieferte, und optimierte so die Leistungsmetriken. Das Preismodell erwies sich jedoch als teuer für eine persönliche Seite mit geringem Traffic. Route 53 berechnete Gebühren pro Zone, pro Million Geolokalisierungsabfragen und pro Health Check, zusätzlich fielen Kosten für Key Management Service (KMS)-Schlüssel an, die für die DNSSEC-Signierung erforderlich waren. Als er feststellte, dass Bunny DNS scriptbare Antworten bietet und bis zu 500 Domains nahezu kostenlos sind, entschied er sich zur Migration.

Der Übergang umfasste die Verlagerung der Content-Auslieferung zu Bunny CDN und die Implementierung komplexer DNS-Logik unter Nutzung der scriptbaren DNS-Funktion von Bunny. Diese Funktion ermöglicht es Benutzern, JavaScript bei jeder DNS-Abfrage auszuführen, um Antworten dynamisch zu berechnen. Bernat nutzt diese Fähigkeit, um die IP-Adressen der beiden nächsten Server aus seinem globalen Bestand von sieben NixOS-Virtual-Machines zurückzugeben. Dieses Setup bietet Redundanz, sodass Browser auf den zweiten Server wechseln können, wenn der primäre nicht verfügbar ist. Er verwaltet diese Infrastruktur mit CDK Terraform und OpenTofu und stellt Zielzustände bereit, die in TypeScript definiert sind.

Eine erhebliche Herausforderung ergab sich bei den ACME-DNS-Challenges zur Erlangung von TLS-Zertifikaten. Im Gegensatz zu Route 53 kann Bunny DNS den Zugriff auf eine einzelne Zone nicht mit feingranularen Zugriffsrichtlinien einschränken und keine DS-Records veröffentlichen, die für die DNSSEC-Sicherheit in delegierten Zonen erforderlich sind. Zur Lösung dieses Problems ersetzte Bernat Route 53 für die spezifische Zone acme.luffy.cx durch Hickory DNS, einen speichersicheren DNS-Server, der in Rust geschrieben ist. Er hostet die übergeordnete Zone luffy.cx bei deSEC, einem gemeinnützigen DNS-Host, um die notwendigen DS-Records zu verwalten. Dieser hybride Ansatz wahrt die Sicherheit, nutzt aber gleichzeitig Bunnys kosteneffizientes Routing für den allgemeinen Datenverkehr.

Wichtige Details

• Die monatlichen Infrastrukturkosten sanken nach der Migration von AWS zu Bunny.net von 5 US$ auf 1 US$.
• Bunny DNS unterstützt scriptbare JavaScript-Antworten, was benutzerdefiniertes Geo-Routing ohne Premium-Gebühren ermöglicht.
• Der Autor betreibt weltweit sieben NixOS-Virtual-Machines, darunter Standorte in Paris, Singapur und Sydney.
• Hickory DNS wurde eingesetzt, um ACME-DNS-01-Challenges zu bearbeiten, da Bunny keine feingranularen Zonenzugriffskontrollen bietet.
• deSEC wird genutzt, um die übergeordnete Zone zu hosten und DS-Records zu veröffentlichen, da Bunny DNS diese nicht unterstützt.
• Die Leistung bleibt vergleichbar mit AWS, obwohl HTTP/3-Unterstützung derzeit bei Bunny CDN fehlt.

Hintergrund

GeoDNS ist eine Technik, die Domain-Namen basierend auf dem geografischen Standort des Nutzers unterschiedlichen IP-Adressen zuordnet. Dies reduziert die Latenz, indem der Datenverkehr zum nächsten Server geleitet wird. Traditionelle Anbieter wie AWS verlangen hohe Gebühren für die Rechenressourcen, die zur Bestimmung dieser Standorte und zur Überwachung der Servergesundheit erforderlich sind. Scriptbares DNS geht noch weiter, indem es Entwicklern erlaubt, eigene Logik in den Auflösungsprozess einzubringen. Anstatt auf vordefinierte Regeln angewiesen zu sein, führt der DNS-Server Code aus, um zu entscheiden, welche IP zurückgegeben wird, was mehr Flexibilität für komplexe Multi-Region-Setups bietet.

ACME-DNS-01-Challenges sind eine Methode, die von Zertifizierungsstellen wie Let’s Encrypt verwendet wird, um das Eigentum an einer Domain zu überprüfen. Der Server muss beweisen, dass er die Kontrolle über die Domain hat, indem er einen spezifischen DNS-Record erstellt. Dieser Prozess erfordert oft automatisierte Updates der DNS-Zonen. Sicherheitsstandards wie DNSSEC verlassen sich auf DS-Records (Delegation Signer), um eine Vertrauenskette zwischen Eltern- und Kindzonen herzustellen. Nicht alle DNS-Anbieter unterstützen die Veröffentlichung dieser Records oder dynamische Updates über sichere Protokolle, was Hybridlösungen bei der Migration von großen Cloud-Anbietern notwendig macht.

Warum das wichtig ist

Für Teams, die Self-Hosted-Software betreiben, sind Vendor-Lock-in und unberechenbare Preise ständige Sorgen. Große Cloud-Anbieter bündeln oft essentielle Funktionen wie Health Checks und Geolocation-Routing in Premium-Tiers. Dieser Fallbericht demonstriert, dass für kleine bis mittelgroße Betriebe tragfähige Alternativen existieren. Durch die Nutzung von scriptbarem DNS können Ingenieure ausgefeilte Routing-Logik erstellen, ohne für unternehmensweite Managed Services zu zahlen. Dies reduziert den operativen Overhead und die Kosten, während die hohe Verfügbarkeit durch benutzerdefinierte Failover-Mechanismen gewahrt bleibt.

Die Migration zeigt jedoch auch Kompromisse auf. Der Wechsel weg von integrierten Ökosystemen wie AWS bedeutet den Verlust nahtloser Interoperabilität zwischen Diensten. Ingenieure müssen Lücken manuell schließen, etwa durch die Nutzung von Drittanbieter-Tools für das Zertifikatsmanagement oder separater Anbieter für DNSSEC. Dies erhöht die Komplexität und erfordert tiefgreifende Kenntnisse der DNS-Protokolle und Sicherheitsstandards. Teams müssen die Kosteneinsparungen gegen den technischen Aufwand abwägen, der für die Wartung dieser hybriden Architekturen erforderlich ist. Für viele rechtfertigt der finanzielle Vorteil die zusätzliche technische Verantwortung, insbesondere wenn Infrastructure-as-Code-Tools zur Automatisierung der Deployments eingesetzt werden.

Was Sie tun können

• Bewerten Sie Ihre aktuellen DNS-Kosten, wobei Sie sich auf Gebühren für Health Checks und Geolokalisierungsabfragen konzentrieren.
• Testen Sie Anbieter von scriptbarem DNS, um zu prüfen, ob benutzerdefinierte Logik teure Managed-Routing-Funktionen ersetzen kann.
• Verwenden Sie Infrastructure-as-Code-Tools wie Terraform oder OpenTofu, um DNS-Konfigurationen konsistent zu verwalten.
• Implementieren Sie redundante Serverauswahl in DNS-Antworten, um die Uptime ohne externe Health Checks zu verbessern.
• Überprüfen Sie Ihre Strategie für ACME-Challenges, um sicherzustellen, dass Ihr neuer DNS-Anbieter die erforderlichen dynamischen Updates unterstützt.
• Überwachen Sie Leistungsmetriken nach der Migration genau, um zu verifizieren, dass die Latenzverbesserungen den Erwartungen entsprechen.