Hetzner Online y AS24940: por qué la nube barata exige una disciplina operativa costosa

Resumen

El RDAP de RIPE NCC registra AS24940 como HETZNER-AS activo e identifica a Hetzner Online GmbH. El 5 de agosto de 2026, RIPEstat lo observó anunciado y devolvió 94 entradas de prefijos. Esto establece una identidad de red visible, no una garantía de disponibilidad o desempeño.
Hetzner describe centros de datos interconectados, filtrado DDoS, backups, snapshots y compromisos concretos de disponibilidad. Sus condiciones también dejan al cliente la administración y seguridad de servidores root y cloud, la estrategia de copias y la prueba de que la aplicación y el negocio volvieron a funcionar.

Hetzner Online GmbH ofrece servidores cloud, servidores dedicados, almacenamiento y servicios de infraestructura. Muchos compradores comienzan por una comparación de precios. El costo mensual de cómputo puede ser bajo, pero un servicio en producción también necesita actualizaciones, control de acceso, certificados, monitoreo, copias, guardias y un plan de recuperación.

AS24940 permite observar una parte pública de ese sistema. Un número de sistema autónomo, o ASN, es un identificador único con el que una red intercambia información de rutas con otras redes. Es parecido a un nombre en el mapa vial de internet. No demuestra que una compra, un inicio de sesión o una base de datos funcionen.

La pregunta útil no es si Hetzner es “bueno” o “malo” en términos generales. Hay que separar qué prueba el registro, qué observan los recolectores BGP, qué publica el operador sobre interconexión, qué mide el SLA, qué controla el cliente y qué evidencia confirma el retorno del servicio real.

La imagen destacada es una escena fotorrealista generada para BTW Media. Muestra a un técnico genérico trabajando en un rack sin marca. No representa a personal, instalaciones, equipos, clientes, rendimiento, incidentes ni respaldo de Hetzner.

El registro identifica una organización, no el estado de una aplicación

El objeto de este artículo es la entidad COMPANY publicada de Hetzner Online GmbH en el directorio BTW. En la verificación previa no tenía enlaces ArticleEntity. Existen otras filas con nombres parecidos y contextos distintos; no se usan como sustitutos de esta compañía.

La respuesta RDAP de RIPE NCC llama HETZNER-AS a AS24940, lo marca activo e incluye a Hetzner Online GmbH como organización registrante y contacto. RDAP es un formato estructurado de acceso a datos de registro. La captura informa un evento de registro el 3 de junio de 2002 y una última modificación el 30 de junio de 2026.

El valor del registro está en la unicidad y la coordinación. Si otro operador necesita tratar una ruta o un reporte de abuso, dispone de un objeto estable y de roles de contacto. Eso reduce la ambigüedad que existiría si solo hubiera una marca comercial.

El registro no muestra todos los routers, fibras, ubicaciones, clientes o contratos. Tampoco prueba capacidad, latencia, autorización RPKI, disponibilidad o velocidad de respuesta del contacto. Es un libro de identidad y cambios, no la red que está corriendo.

Cada pregunta necesita su evidencia. RDAP responde quién figura en el registro. La observación de rutas responde qué anuncio fue visible. Los registros de la aplicación responden si el usuario completó su tarea. Una evaluación responsable no convierte una de esas capas en las otras.

La mejor práctica es reconciliarlas. Registro, inventario interno, autorizaciones, BGP observado y contactos deberían describir realidades compatibles. Una diferencia activa una investigación: puede ser una migración autorizada, una relación con un cliente, retraso de datos o un error.

La ventana de 94 prefijos

RIPEstat asoció el recurso 24940 con HETZNER-AS Hetzner Online GmbH y lo marcó anunciado el 5 de agosto de 2026. En lenguaje sencillo, sus sistemas de observación veían al ASN participar en el enrutamiento global.

La respuesta de prefijos cubrió del 22 de julio al 5 de agosto y contenía 94 entradas: 89 IPv4 y cinco IPv6. Un prefijo representa un bloque de direcciones. La captura confirma una superficie observada en ambas familias.

El número no equivale a clientes, servidores, centros de datos ni conexiones exitosas. Los recolectores miran desde puntos concretos y las rutas cambian. La lista tampoco decide propiedad jurídica, capacidad, validez RPKI o experiencia del usuario.

Sí puede alimentar alertas. Si un prefijo protegido aparece con un origen inesperado o desaparece de varias vistas, alguien debe compararlo con el estado aprobado. La alerta no es una acusación; es el inicio de una comprobación.

La dirección no necesita operar BGP, pero debe saber qué dominios dependen de qué direcciones, cuál es el ASN previsto, quién revisa una anomalía y cuándo se escala a Hetzner.

PeeringDB aporta contexto, no una auditoría

El perfil gestionado por el operador en PeeringDB nombra Hetzner Online, AS24940, hetzner.com y AS-HETZNER. Clasifica la red como Content y su política general como abierta. Sus estimaciones de prefijos tienen otro alcance que la ventana observada por RIPEstat.

Los endpoints capturados devolvieron 63 registros de LAN de intercambio repartidos entre 49 identificadores de intercambio y 23 identificadores de instalaciones. Es una huella pública amplia.

No prueba diversidad física, capacidad disponible o rutas de clientes. Dos puertos pueden estar en el mismo intercambio. Dos edificios pueden compartir fibra metropolitana, energía o proveedor ascendente. Una fila operational no es una prueba de tráfico actual ni un SLA.

PeeringDB funciona bien como mapa de planificación y contacto. Para evaluar resiliencia hay que añadir contratos, telemetría, pruebas de ruta y confirmación del proveedor.

La nube depende de una cadena física

La documentación de Hetzner enumera ocho centros de datos en Núremberg, 22 en Falkenstein y diez en Helsinki. Describe UPS, generadores, rutas eléctricas separadas y fibra oscura redundante entre parques. También indica al menos 120 Gbit/s en determinados enlaces alemanes.

Son declaraciones del emisor, no una auditoría independiente. Aun así, recuerdan que una máquina virtual depende de un host, switches, energía, refrigeración, fibra, operadores externos y acceso humano.

La palabra redundante necesita un objeto. Dos fuentes no cubren todos los eventos eléctricos. Dos fibras solo protegen de un corte si se separan en el tramo decisivo. Dos instancias no permiten continuar si comparten una única base, un único DNS o un único plano de control.

El cliente debe saber qué dominio de fallo cubre el producto, dónde reside cada copia, cuánta capacidad queda después de una pérdida y cuándo se probó el cambio. No necesita un plano privado completo; necesita una frontera verificable.

El 99,9 % mide objetos concretos

Las condiciones generales hablan de esfuerzos económicamente razonables para lograr 99,9 % de disponibilidad media anual de red en los centros de datos. El acuerdo de Cloud Server habla de 99,9 % mensual para cada servidor cloud.

Ese acuerdo define disponible al servidor cuyo host funciona, cuyo hipervisor arrancó la instancia y que muestra actividad en métricas como CPU o red. También excluye mantenimiento, software o configuración del cliente, ciertos ataques, migraciones necesarias y redes fuera del control razonable de Hetzner.

Una aplicación puede estar caída mientras la máquina cumple esa definición. La base puede estar dañada, DNS puede señalar otro lugar, el firewall puede bloquear usuarios o el pago puede fallar. Actividad de CPU no es una transacción de negocio.

El período y el remedio importan. Un promedio anual, una medición mensual por servidor y el objetivo de una tienda son cosas distintas. Los Cloud Credits reducen una factura futura, pero no sustituyen ventas, horas de personal o atención al cliente.

La organización debe definir un objetivo extremo a extremo y calcular su propio costo de interrupción. El SLA del proveedor es un dato de entrada, no el resultado completo.

El acceso root crea una responsabilidad operativa

Las condiciones entregan al cliente derechos completos de administrador sobre productos root y cloud y le asignan su gestión y seguridad. Esa libertad permite elegir software y automatización, pero exige parches, claves, firewall, logs, certificados, capacidad y respuesta a vulnerabilidades.

En una empresa pequeña, un desarrollador puede crear un servidor temporal que termina siendo crítico y queda sin dueño cuando se marcha. En una empresa grande, proyectos y tokens pueden crecer más rápido que el inventario. Mientras el servidor responda, la deuda permanece oculta.

Cada servicio de producción necesita propietario, cuenta de pago, clasificación de datos, dependencias, receptor de alertas y prueba de recuperación. La protección contra borrado y la infraestructura como código ayudan, pero no sustituyen propiedad, revisión y gestión de secretos.

El filtrado DDoS es una capa, no inmunidad

Las medidas técnicas describen reconocimiento continuo de DDoS y filtrado automático de tráfico malicioso. Una defensa en la red del proveedor puede reducir ataques volumétricos antes de que lleguen al servidor.

Otras fallas quedan fuera: demanda legítima que satura la base, una regla del cliente, un bucle de software, DNS, certificados o una API externa. Tener filtrado no elimina toda indisponibilidad.

Por eso el cliente debe observar por separado host, aplicación, acceso externo y operación de negocio. También debe definir quién contacta al proveedor, quién puede cambiar reglas, quién autoriza la emergencia y cómo se revierte.

Un backup se convierte en control cuando restaura

La documentación presenta los backups cloud, si se habilitan, como copias diarias con siete espacios. Los snapshots los crea el cliente y permanecen hasta su eliminación. La FAQ dice que los backups no admiten protección y se borran con el servidor, mientras que los snapshots sí pueden protegerse.

Una copia diaria permite perder cambios entre ejecuciones. Una base activa puede necesitar consistencia específica. Un disco sin claves, secretos o configuración externa no devuelve el negocio.

La ubicación también tiene límites. En Europa, los backups suelen estar en otro centro dentro de la misma ubicación y los snapshots siguen reglas de zona. Algunos lugares de Estados Unidos o Singapur usan un solo centro. Otro host no siempre significa otro desastre.

Las condiciones generales piden al cliente copias regulares fuera del servidor, y la documentación recomienda copias independientes para varios productos. La función del proveedor puede ser una capa; una copia bajo otra autoridad y ubicación es otra.

Una política debe responder qué se copia, con qué frecuencia, dónde, quién puede borrar, cuánto se conserva y cuándo pasó la última restauración completa. Un job verde confirma escritura; una prueba confirma recuperación.

Un mapa simple para incidentes comunes

Si un servidor no responde, Hetzner puede controlar host, hipervisor y red central; el cliente controla sistema, software y firewall. El primer paso es identificar la capa con evidencia y la persona con la próxima autoridad, no discutir culpa.

Un evento del host obliga al cliente a elegir espera, failover o degradación. Un disco lleno puede dejar la máquina activa y la aplicación caída. Un DNS viejo puede enviar usuarios al sistema equivocado. Una copia sin clave se detiene en el límite de acceso.

Una cuenta comprometida puede permitir acciones destructivas mediante interfaces legítimas. Autenticación multifactor, tokens limitados, auditoría, protección contra borrado y copias independientes cubren riesgos diferentes.

Para cada servicio crítico conviene registrar capas del proveedor, capas del cliente, interfaces compartidas, fuentes de evidencia, decisor y prueba de negocio. Esa hoja reduce transferencias durante la crisis.

El costo total de la nube económica

El precio del servidor es visible. La integración con identidad, correo, pagos, almacenamiento y APIs agrega credenciales, límites y soporte. La supervisión agrega parches, revisión de acceso, certificados, capacidad, backups y guardias. La falla agrega transacciones perdidas, personal inactivo, trabajo urgente y comunicación.

La migración también cuesta. Mover una aplicación requiere datos, secretos, DNS, reglas y una ventana de cambio. Decir que un contenedor corre en cualquier lugar no demuestra que el sistema completo sea portátil.

El modelo financiero debe sumar factura, personas, herramientas, fallas probables, copias independientes, ejercicios y capacidad alternativa. Hetzner puede seguir siendo una opción atractiva. El objetivo es no confundir un precio bajo con un sistema operativo completo.

Preguntas antes y después del lanzamiento

Antes de producción hay que identificar dueño de cuenta y servicio, objeto medido por el SLA, dominios de falla compartidos, estrategia de datos, derechos de borrado, monitoreo, dependencias y salida. ¿Quién recupera la cuenta si falta el administrador? ¿Servidor y copias pueden desaparecer juntos? ¿Qué transacción prueba la recuperación?

Después, hay que vigilar recursos sin dueño, tokens antiguos, edad de backups, restauraciones vencidas, errores de usuario, cambios de ruta, DNS y certificados. Los informes deben distinguir servidor activo, aplicación que responde y negocio verificado.

La calidad del cambio también importa. Registrar si una falla provino del proveedor, de la configuración o de una interacción permite corregir el sistema, no solo buscar culpables.

Conclusión

La evidencia pública establece una identidad clara entre Hetzner Online GmbH y AS24940. RIPE NCC mantiene el registro; RIPEstat observó el ASN anunciado y 94 entradas de prefijos el 5 de agosto de 2026; PeeringDB ofrece un mapa amplio mantenido por el operador.

Hetzner documenta interconexión de centros, filtrado DDoS, backups, snapshots y compromisos definidos. También marca la frontera: el cliente administra y protege sus sistemas, organiza copias y demuestra la recuperación del negocio.

Para un lector no especializado, la regla es sencilla. El registro es identidad; las rutas son observaciones con fecha; PeeringDB es un mapa declarado; el SLA es un contrato para un objeto; un backup no está probado hasta restaurar. Una máquina encendida es solo una parte de un servicio útil.

Sources

Atribución de la imagen

Imagen editorial fotorrealista generada para BTW Media: un técnico genérico revisa un rack sin marca en un pasillo ordinario de centro de datos. La imagen se creó con la herramienta integrada y se convirtió a JPEG de 1600 × 900 sin cambiar la escena. No representa instalaciones, personal, clientes, pantallas, marcas ni sistemas reales, y no muestra ni sugiere equipos, rendimiento, incidentes o respaldo de Hetzner Online GmbH.