Migration d'AWS Route 53 vers Bunny DNS pour réduire les coûts et gagner en contrôle

Vincent Bernat a récemment documenté la migration de l'infrastructure de son blog personnel d'Amazon Web Services (AWS) vers Bunny.net. Publié le 6 novembre 2026, cette étude de cas met en lumière comment le passage de Route 53 et CloudFront aux services DNS et CDN de Bunny a réduit les coûts mensuels de cinq dollars à un dollar. Ce changement a été motivé par les frais élevés des requêtes de géolocalisation et des vérifications de santé sur AWS, ainsi que par le désir d'utiliser un fournisseur basé en Europe.

Ce qui s'est passé

Bernat utilisait auparavant Amazon CloudFront pour la distribution de contenu et Route 53 pour le routage DNS sensible à la géolocalisation. Cette configuration dirigeait les lecteurs vers l'hôte le plus proche servant leur contenu, optimisant ainsi les métriques de performance. Cependant, le modèle tarifaire s'est avéré coûteux pour un site personnel à faible trafic. Route 53 facturait par zone, par million de requêtes de géolocalisation et par vérification de santé, avec des coûts supplémentaires pour les clés du Key Management Service (KMS) nécessaires à la signature DNSSEC. Après avoir découvert que Bunny DNS offre des réponses scriptables et est presque gratuit pour jusqu'à 500 domaines, il a décidé de migrer.

La transition impliquait de déplacer la distribution de contenu vers Bunny CDN et de mettre en œuvre une logique DNS complexe en utilisant la fonctionnalité DNS scriptable de Bunny. Cette fonctionnalité permet aux utilisateurs d'exécuter du JavaScript sur chaque requête DNS pour calculer dynamiquement les réponses. Bernat utilise cette capacité pour retourner les adresses IP des deux serveurs les plus proches parmi sa flotte mondiale de sept machines virtuelles NixOS. Cette configuration fournit une redondance, permettant aux navigateurs de basculer vers le second serveur si le principal est indisponible. Il gère cette infrastructure à l'aide de CDK Terraform et OpenTofu, déployant les états cibles définis en TypeScript.

Un défi majeur est apparu avec les défis ACME DNS pour l'obtention de certificats TLS. Contrairement à Route 53, Bunny DNS ne peut pas restreindre l'accès à une seule zone avec des politiques d'accès granulaires, ni publier les enregistrements DS requis pour la sécurité DNSSEC sur les zones déléguées. Pour résoudre ce problème, Bernat a remplacé Route 53 pour la zone spécifique acme.luffy.cx par Hickory DNS, un serveur DNS écrit en Rust garantissant la sécurité mémoire. Il héberge la zone parente luffy.cx sur deSEC, un hébergeur DNS à but non lucratif, pour gérer les enregistrements DS nécessaires. Cette approche hybride maintient la sécurité tout en tirant parti du routage économique de Bunny pour le trafic général.

Détails clés

• Les coûts d'infrastructure mensuels ont chuté de 5 $ US à 1 $ US après la migration d'AWS vers Bunny.net.
• Bunny DNS prend en charge les réponses JavaScript scriptables, permettant une logique de géoroutage personnalisée sans frais premium.
• L'auteur exécute sept machines virtuelles NixOS dans le monde entier, y compris à Paris, Singapour et Sydney.
• Hickory DNS a été déployé pour gérer les défis ACME DNS-01 car Bunny ne dispose pas de contrôles d'accès granulaires aux zones.
• deSEC est utilisé pour héberger la zone parente et publier les enregistrements DS, car Bunny DNS ne les prend pas en charge.
• La performance reste comparable à celle d'AWS, bien que le support HTTP/3 soit actuellement absent du CDN Bunny.

Contexte

Le GeoDNS est une technique qui résout les noms de domaine vers différentes adresses IP en fonction de l'emplacement géographique de l'utilisateur. Cela réduit la latence en dirigeant le trafic vers le serveur le plus proche. Les fournisseurs traditionnels comme AWS facturent lourdement les ressources informatiques nécessaires pour déterminer ces emplacements et surveiller la santé des serveurs. Le DNS scriptable va plus loin en permettant aux développeurs d'injecter une logique personnalisée dans le processus de résolution. Au lieu de dépendre de règles prédéfinies, le serveur DNS exécute du code pour décider quelle IP retourner, offrant une plus grande flexibilité pour les configurations complexes multi-régions.

Les défis ACME DNS-01 sont une méthode utilisée par les autorités de certification comme Let’s Encrypt pour vérifier la propriété du domaine. Le serveur doit prouver qu'il contrôle le domaine en créant un enregistrement DNS spécifique. Ce processus nécessite souvent des mises à jour automatisées des zones DNS. Les normes de sécurité comme DNSSEC reposent sur les enregistrements DS (Delegation Signer) pour établir une chaîne de confiance entre les zones parent et enfant. Tous les fournisseurs DNS ne prennent pas en charge la publication de ces enregistrements ou les mises à jour dynamiques via des protocoles sécurisés, ce qui rend nécessaire des solutions hybrides lors de la migration hors des grands fournisseurs cloud.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés, l'enfermement propriétaire (vendor lock-in) et les prix imprévisibles sont des préoccupations constantes. Les grands fournisseurs cloud regroupent souvent des fonctionnalités essentielles comme les vérifications de santé et le routage géolocalisé dans leurs offres premium. Cette étude de cas démontre que des alternatives viables existent pour les opérations petites et moyennes. En tirant parti du DNS scriptable, les ingénieurs peuvent construire une logique de routage sophistiquée sans payer pour des services gérés de niveau entreprise. Cela réduit la charge opérationnelle et les coûts tout en maintenant une haute disponibilité grâce à des mécanismes de basculement personnalisés.

Cependant, la migration souligne également les compromis. S'éloigner d'écosystèmes intégrés comme AWS signifie perdre l'interopérabilité transparente entre les services. Les ingénieurs doivent combler manuellement les lacunes, comme utiliser des outils tiers pour la gestion des certificats ou des fournisseurs séparés pour DNSSEC. Cela augmente la complexité et nécessite une connaissance approfondie des protocoles DNS et des normes de sécurité. Les équipes doivent peser les économies réalisées contre l'effort d'ingénierie requis pour maintenir ces architectures hybrides. Pour beaucoup, le bénéfice financier justifie la responsabilité technique accrue, surtout lorsqu'on utilise des outils d'infrastructure-as-code pour automatiser les déploiements.

Ce que vous pouvez faire

• Évaluez vos coûts DNS actuels, en vous concentrant sur les frais pour les vérifications de santé et les requêtes de géolocalisation.
• Testez les fournisseurs de DNS scriptables pour voir si une logique personnalisée peut remplacer les fonctionnalités de routage gérées coûteuses.
• Utilisez des outils d'infrastructure-as-code comme Terraform ou OpenTofu pour gérer les configurations DNS de manière cohérente.
• Implémentez une sélection de serveurs redondante dans les réponses DNS pour améliorer la disponibilité sans vérifications de santé externes.
• Revoyez votre stratégie de défi ACME pour vous assurer que votre nouveau fournisseur DNS prend en charge les mises à jour dynamiques nécessaires.
• Surveillez attentivement les métriques de performance après la migration pour vérifier que les améliorations de latence correspondent aux attentes.