Migrating from AWS Route 53 to Bunny DNS for cost and control

Vincent Bernat recently documented his migration of personal blog infrastructure from Amazon Web Services (AWS) to Bunny.net. Published on November 6, 2026, the case study highlights how switching from Route 53 and CloudFront to Bunny’s DNS and CDN services reduced monthly costs from five dollars to one dollar. The move was driven by high fees for geolocation queries and health checks on AWS, alongside a desire to use a European-based provider.

What happened

Bernat previously relied on Amazon CloudFront for content delivery and Route 53 for geo-aware DNS routing. This setup directed readers to the nearest host serving his content, optimizing performance metrics. However, the pricing model proved expensive for a low-traffic personal site. Route 53 charged per zone, per million geolocation queries, and per health check, with additional costs for Key Management Service (KMS) keys required for DNSSEC signing. Upon discovering that Bunny DNS offers scriptable answers and is nearly free for up to 500 domains, he decided to migrate.

The transition involved moving content delivery to Bunny CDN and implementing complex DNS logic using Bunny’s scriptable DNS feature. This feature allows users to run JavaScript on each DNS query to compute responses dynamically. Bernat uses this capability to return the IP addresses of the two nearest servers from his global fleet of seven NixOS virtual machines. This setup provides redundancy, allowing browsers to fall back to the second server if the primary one is unavailable. He manages this infrastructure using CDK Terraform and OpenTofu, deploying target states defined in TypeScript.

A significant challenge arose with ACME DNS challenges for obtaining TLS certificates. Unlike Route 53, Bunny DNS cannot restrict access to a single zone with fine-grained access policies, nor can it publish DS records required for DNSSEC security on delegated zones. To solve this, Bernat replaced Route 53 for the specific acme.luffy.cx zone with Hickory DNS, a memory-safe DNS server written in Rust. He hosts the parent luffy.cx zone on deSEC, a non-profit DNS host, to manage the necessary DS records. This hybrid approach maintains security while leveraging Bunny’s cost-effective routing for general traffic.

Key details

• Monthly infrastructure costs dropped from US$5 to US$1 after migrating from AWS to Bunny.net.
• Bunny DNS supports scriptable JavaScript responses, enabling custom geo-routing logic without premium fees.
• The author runs seven NixOS virtual machines globally, including locations in Paris, Singapore, and Sydney.
• Hickory DNS was deployed to handle ACME DNS-01 challenges because Bunny lacks fine-grained zone access controls.
• deSEC is used to host the parent zone and publish DS records, as Bunny DNS does not support them.
• Performance remains comparable to AWS, though HTTP/3 support is currently missing from Bunny CDN.

Background

GeoDNS is a technique that resolves domain names to different IP addresses based on the geographic location of the user. This reduces latency by directing traffic to the nearest server. Traditional providers like AWS charge heavily for the computational resources required to determine these locations and monitor server health. Scriptable DNS takes this further by allowing developers to inject custom logic into the resolution process. Instead of relying on predefined rules, the DNS server executes code to decide which IP to return, offering greater flexibility for complex multi-region setups.

ACME DNS-01 challenges are a method used by certificate authorities like Let’s Encrypt to verify domain ownership. The server must prove it controls the domain by creating a specific DNS record. This process often requires automated updates to DNS zones. Security standards like DNSSEC rely on DS (Delegation Signer) records to establish a chain of trust between parent and child zones. Not all DNS providers support publishing these records or allowing dynamic updates via secure protocols, necessitating hybrid solutions when migrating away from major cloud providers.

Why it matters

For teams running self-hosted software, vendor lock-in and unpredictable pricing are constant concerns. Major cloud providers often bundle essential features like health checks and geolocation routing into premium tiers. This case study demonstrates that viable alternatives exist for small to mid-sized operations. By leveraging scriptable DNS, engineers can build sophisticated routing logic without paying for enterprise-grade managed services. This reduces operational overhead and costs while maintaining high availability through custom failover mechanisms.

However, the migration also highlights trade-offs. Moving away from integrated ecosystems like AWS means losing seamless interoperability between services. Engineers must manually bridge gaps, such as using third-party tools for certificate management or separate providers for DNSSEC. This increases complexity and requires deeper knowledge of DNS protocols and security standards. Teams must weigh the cost savings against the engineering effort required to maintain these hybrid architectures. For many, the financial benefit justifies the added technical responsibility, especially when using infrastructure-as-code tools to automate deployments.

What you can do

• Evaluate your current DNS costs, focusing on charges for health checks and geolocation queries.
• Test scriptable DNS providers to see if custom logic can replace expensive managed routing features.
• Use infrastructure-as-code tools like Terraform or OpenTofu to manage DNS configurations consistently.
• Implement redundant server selection in DNS responses to improve uptime without external health checks.
• Review your ACME challenge strategy to ensure your new DNS provider supports necessary dynamic updates.
• Monitor performance metrics closely after migration to verify that latency improvements match expectations.