Migración de AWS Route 53 a Bunny DNS por costes y control

Vincent Bernat documentó recientemente la migración de la infraestructura de su blog personal desde Amazon Web Services (AWS) a Bunny.net. Publicado el 6 de noviembre de 2026, este caso de estudio destaca cómo el cambio de Route 53 y CloudFront a los servicios de DNS y CDN de Bunny redujo los costes mensuales de cinco dólares a uno. La decisión se debió a las altas tarifas por consultas de geolocalización y comprobaciones de estado en AWS, junto con el deseo de utilizar un proveedor basado en Europa.

Qué ocurrió

Bernat dependía previamente de Amazon CloudFront para la entrega de contenido y de Route 53 para el enrutamiento DNS consciente de la ubicación geográfica. Esta configuración dirigía a los lectores al host más cercano que servía su contenido, optimizando las métricas de rendimiento. Sin embargo, el modelo de precios resultó costoso para un sitio personal con bajo tráfico. Route 53 cobraba por zona, por millón de consultas de geolocalización y por cada comprobación de estado, además de costes adicionales por las claves del Key Management Service (KMS) necesarias para la firma DNSSEC. Al descubrir que Bunny DNS ofrece respuestas programables y es casi gratuito para hasta 500 dominios, decidió migrar.

La transición implicó mover la entrega de contenido a Bunny CDN e implementar lógica DNS compleja utilizando la función de DNS programable de Bunny. Esta característica permite a los usuarios ejecutar JavaScript en cada consulta DNS para calcular respuestas dinámicamente. Bernat utiliza esta capacidad para devolver las direcciones IP de los dos servidores más cercanos de su flota global de siete máquinas virtuales NixOS. Esta configuración proporciona redundancia, permitiendo a los navegadores recurrir al segundo servidor si el principal no está disponible. Gestiona esta infraestructura utilizando CDK Terraform y OpenTofu, desplegando estados objetivo definidos en TypeScript.

Surgió un desafío significativo con los desafíos ACME DNS para obtener certificados TLS. A diferencia de Route 53, Bunny DNS no puede restringir el acceso a una sola zona con políticas de acceso granulares, ni publicar registros DS necesarios para la seguridad DNSSEC en zonas delegadas. Para resolver esto, Bernat reemplazó Route 53 para la zona específica acme.luffy.cx con Hickory DNS, un servidor DNS seguro en memoria escrito en Rust. Aloja la zona padre luffy.cx en deSEC, un anfitrión DNS sin fines de lucro, para gestionar los registros DS necesarios. Este enfoque híbrido mantiene la seguridad mientras aprovecha el enrutamiento rentable de Bunny para el tráfico general.

Detalles clave

• Los costes mensuales de infraestructura disminuyeron de US$5 a US$1 tras la migración de AWS a Bunny.net.
• Bunny DNS admite respuestas JavaScript programables, lo que permite una lógica de geo-enrutamiento personalizada sin comisiones premium.
• El autor ejecuta siete máquinas virtuales NixOS globalmente, incluyendo ubicaciones en París, Singapur y Sídney.
• Se desplegó Hickory DNS para manejar los desafíos ACME DNS-01 porque Bunny carece de controles de acceso granulares a zonas.
• Se utiliza deSEC para alojar la zona padre y publicar registros DS, ya que Bunny DNS no los admite.
• El rendimiento sigue siendo comparable al de AWS, aunque actualmente falta soporte HTTP/3 en Bunny CDN.

Antecedentes

GeoDNS es una técnica que resuelve nombres de dominio a diferentes direcciones IP basándose en la ubicación geográfica del usuario. Esto reduce la latencia dirigiendo el tráfico al servidor más cercano. Los proveedores tradicionales como AWS cobran fuertemente por los recursos computacionales necesarios para determinar estas ubicaciones y monitorear la salud del servidor. El DNS programable lleva esto más lejos al permitir a los desarrolladores inyectar lógica personalizada en el proceso de resolución. En lugar de depender de reglas predefinidas, el servidor DNS ejecuta código para decidir qué IP devolver, ofreciendo mayor flexibilidad para configuraciones complejas multi-región.

Los desafíos ACME DNS-01 son un método utilizado por autoridades de certificación como Let’s Encrypt para verificar la propiedad del dominio. El servidor debe demostrar que controla el dominio creando un registro DNS específico. Este proceso a menudo requiere actualizaciones automatizadas de las zonas DNS. Los estándares de seguridad como DNSSEC dependen de los registros DS (Delegation Signer) para establecer una cadena de confianza entre zonas padre e hijo. No todos los proveedores de DNS admiten la publicación de estos registros o permiten actualizaciones dinámicas mediante protocolos seguros, lo que hace necesarias soluciones híbridas al migrar fuera de los principales proveedores de nube.

Por qué importa

Para equipos que ejecutan software autoalojado, el bloqueo de proveedor y los precios impredecibles son preocupaciones constantes. Los principales proveedores de nube suelen agrupar funciones esenciales como comprobaciones de estado y enrutamiento de geolocalización en niveles premium. Este caso de estudio demuestra que existen alternativas viables para operaciones pequeñas y medianas. Al aprovechar el DNS programable, los ingenieros pueden construir lógica de enrutamiento sofisticada sin pagar por servicios gestionados de grado empresarial. Esto reduce la sobrecarga operativa y los costes mientras mantiene una alta disponibilidad mediante mecanismos personalizados de conmutación por error.

Sin embargo, la migración también pone de manifiesto las compensaciones. Alejarse de ecosistemas integrados como AWS significa perder la interoperabilidad perfecta entre servicios. Los ingenieros deben cerrar brechas manualmente, como usar herramientas de terceros para la gestión de certificados o proveedores separados para DNSSEC. Esto aumenta la complejidad y requiere un conocimiento más profundo de los protocolos DNS y los estándares de seguridad. Los equipos deben sopesar el ahorro de costes frente al esfuerzo de ingeniería necesario para mantener estas arquitecturas híbridas. Para muchos, el beneficio financiero justifica la responsabilidad técnica adicional, especialmente cuando se utilizan herramientas de infraestructura como código para automatizar despliegues.

Qué puedes hacer

• Evalúa tus costes actuales de DNS, centrándote en los cargos por comprobaciones de estado y consultas de geolocalización.
• Prueba proveedores de DNS programables para ver si la lógica personalizada puede reemplazar funciones caras de enrutamiento gestionado.
• Utiliza herramientas de infraestructura como código como Terraform u OpenTofu para gestionar configuraciones DNS de manera consistente.
• Implementa la selección redundante de servidores en las respuestas DNS para mejorar la disponibilidad sin comprobaciones de estado externas.
• Revisa tu estrategia de desafíos ACME para asegurarte de que tu nuevo proveedor de DNS admite las actualizaciones dinámicas necesarias.
• Monitorea de cerca las métricas de rendimiento después de la migración para verificar que las mejoras de latencia coinciden con las expectativas.