2 años después de migrar de AWS a bare metal: respuestas a preguntas sobre salir de AWS

 (oneuptime.com)
16 puntos por GN⁺ 2025-10-30 | 3 comentarios | Compartir por WhatsApp
  • Informe que recopila respuestas de seguimiento a varias preguntas de la comunidad, luego de compartir hace 2 años la experiencia de migrar de AWS a bare metal y ahorrar 230 mil dólares al año. También revela datos reales de operación durante 2 años y afirma haber logrado más de $1.2 millones en ahorro anual
  • A través de la operación real, el ahorro aumentó a más de 1.2 millones de dólares al año, y se reinvirtió en servidores para resúmenes de incidentes basados en IA y corrección automática de código, lo que llevó a una mejora en la calidad del servicio
  • Mantienen 99.993% de disponibilidad sobre una pila MicroK8s + Ceph, y eliminaron puntos únicos de falla con una configuración de doble centro de datos
  • Explican temas clave como costos reales de operación, respuesta a incidentes, vida útil del hardware, certificaciones de seguridad y servicios alternativos a la nube con cifras concretas
  • Como resultado, mejoraron tanto la estabilidad como la eficiencia en costos, y concluyen que para sistemas con carga constante de cierta escala, bare metal es una opción más razonable

Resumen de los resultados operativos de 2 años

  • Durante 24 meses operaron la pila MicroK8s + Ceph en producción y alcanzaron una disponibilidad de 99.993%
    • Para resolver el problema de un solo rack, añadieron un segundo rack en Frankfurt y lo conectaron al rack principal de París con una conexión DWDM redundante
    • Con NVMe local y la eliminación de interferencias de ruido, redujeron en 19% la latencia para los clientes
  • Reinvirtieron el dinero ahorrado en la compra de servidores de IA bare metal, ampliando las funciones de resumen de alertas basado en LLM y corrección automática de código de OneUptime

Ahorro y comparación de costos

  • El ahorro estimado inicial era de $230,000 al año, pero ahora aumentó a más de $1.2M
    • Esto equivale a aproximadamente 76% de ahorro frente a AWS
    • En términos de salarios globales, es una cantidad equivalente al sueldo anual de 2 a 5 ingenieros
  • Incluso aplicando Savings Plans / Reserved Instances, bare metal sigue siendo más conveniente
    • Los Savings Plans no aplican a S3, egress ni Direct Connect
    • Tampoco pueden reducirse costos como el control plane de EKS por $1,260/mes o el NAT Gateway por $600/mes
    • Al tratarse de una carga de trabajo estable 24/7, la eficiencia de las reserved instances era limitada

Migración y costos operativos

  • La migración inicial se completó con alrededor de 1 semana de trabajo de ingeniería
    • La mayor parte eran tareas que ya hacían falta, como poner al día IaC y reforzar las políticas de respaldo
  • Los costos operativos actuales son los siguientes:
    • Administración directa: unas 24 horas por trimestre (incluyendo parches y actualizaciones de firmware)
    • Remote Hands: solo hicieron falta 2 intervenciones en 24 meses (principalmente por problemas de disco), con un tiempo promedio de respuesta de 27 minutos
    • Automatización: arranque PXE (Tinkerbell), gestión de imágenes Talos, automatización de configuración con Flux/Terraform
  • En comparación con la época en AWS, el equipo de operaciones incluso vio aumentar la velocidad de lanzamiento, además de eliminar la carga de las “reuniones de optimización de costos”

Preparación ante fallas y aseguramiento de disponibilidad

  • Añadieron un segundo rack en Frankfurt y eliminaron puntos únicos de falla con conexiones DWDM por doble ruta
    • Configuraron mirroring de Ceph basado en replicación asíncrona y un doble control plane
    • También añadieron una ruta de administración basada en 4G/satélite para permitir acceso remoto durante fallas de red
  • Están en proceso de pasar de MicroK8s a Talos
  • Siguen manteniendo un clúster de respaldo para failover en AWS y realizan ensayos trimestrales de recuperación ante desastres
  • Con un Ingress basado en Anycast+BGP, también mejoraron el retraso del cambio por DNS a menos de 1 minuto
  • Mantuvieron 99.993% de disponibilidad durante 2 años y no se vieron afectados por incidentes recientes en regiones de AWS

Hardware y gestión de CapEx

  • Operan los servidores con una depreciación de 5 años como referencia (2×EPYC 9654, 1TB de RAM, configuración NVMe)
    • Cuando el rendimiento se satura, los mueven a un clúster de analítica y los reemplazan por servidores nuevos
    • Gracias al ahorro, ahora pueden hacer un refresh del 40% cada 2 años y aun así seguir ahorrando costos anuales frente a AWS
  • Tienen garantía extendida de Supermicro + 3 servidores de repuesto
    • La vida útil real es de 7 a 8 años, pero la estiman conservadoramente en 5 años

Lógica para sustituir servicios administrados

  • La filosofía de producto de OneUptime es permitir self-hosting, así que necesitan mantener la misma pila
    • Conservan la consistencia de open stack con Kubernetes, Postgres, Redis, ClickHouse, etc.
  • Evolucionaron de Terraform + EKS + RDS a MicroK8s + Argo Rollouts + Ceph
    • Usan open source puro sin forks propios
  • Aun así, siguen usando nube en paralelo: AWS Glacier (backups), CloudFront (caché en el edge) e instancias temporales para pruebas de carga
  • La nube encaja mejor para la elasticidad, mientras que bare metal se ajusta mejor a la carga base

Red y seguridad

  • Aseguraron 2 enlaces de 5Gbps (percentil 95), 8 veces más baratos que el egress en AWS
  • La defensa contra DDoS se resolvió con Cloudflare al frente de todo
  • Aseguraron una red de administración independiente basada en 4G/satélite para acceso remoto durante incidentes

Cumplimiento y respuesta a auditorías

  • Mantienen certificaciones SOC 2 Type II e ISO 27001
    • Aprovechan la documentación del centro de colocation sobre certificación Tier III, registros de acceso y CCTV
    • Usan los logs de configuración de Terraform/Talos como evidencia del historial de cambios
  • Según comentan, los auditores consideraron esto más confiable que capturas de pantalla de la consola de AWS

Comparación con alternativas en la nube

  • Comparan Hetzner, OVH, Leaseweb, Equinix Metal y AWS Outposts
    • Los hyperscalers siguen teniendo costos altos de egress
    • Los hosts europeos tienen dificultades para cumplir los requisitos de SLA y de clústeres Ceph a gran escala
    • Equinix Metal tiene un premium de 25~30% frente al CapEx
    • Operar hardware propio tiene ventaja en densidad energética y libertad de actualización
  • En resultado, gracias a una configuración de rack de 15kW y a la posibilidad de reutilizar componentes, la colocation resulta superior tanto en costo como en rendimiento

Medición de la carga operativa (TOIL)

  • Semanal: parches de kernel/firmware y revisión de Ceph (1 hora)
  • Mensual: actualización canary del control plane de Kubernetes (2 horas)
  • Trimestral: simulacros de DR, planeación de capacidad y revisión de contratos con carriers (12 horas)
  • En total, unas 14 horas al mes, similar a la época de AWS, pero con el enfoque moviéndose de “seguir costos” a “automatizar operaciones”

Casos donde la nube sigue siendo válida

  • Cuando la carga de trabajo tiene un patrón de picos o estacional
  • Cuando hay alta dependencia de servicios administrados como Aurora Serverless, Kinesis o Step Functions
  • Cuando no existe capacidad interna para operar directamente Kubernetes, Ceph, monitoreo y respuesta a incidentes
  • Es decir, para negocios en etapa inicial o con carga muy variable, la nube sigue teniendo ventaja

Planes a futuro

  • Planean publicar un módulo de Terraform y un runbook para prever presupuestos de colocation
  • También preparan un post técnico en profundidad sobre la experiencia operando con Talos
  • Seguirán respondiendo al feedback en HN y Reddit y compartiendo casos centrados en cifras reales

Lecturas relacionadas

3 comentarios

 
okxrr 2025-10-30

Trabajo en una empresa que usa AWS con mucho entusiasmo, aunque no utilizamos en absoluto ningún servicio exclusivo de AWS.

Una historia entre triste y absurda: vi que en esta decisión influyó mucho el deseo sumamente personal de algunos líderes de desarrollar su propia carrera.
 
GN⁺ 2025-10-30
Opinión de Hacker News

  • AWS es demasiado caro. Hay menos razones de las que parece para montar todo un sistema completamente sobre AWS. Antes todo el mundo sabía operar servidores bare metal por su cuenta, pero ahora parece que eso se olvidó. Nuestro equipo mantuvo 99.993% de disponibilidad durante más de 730 días, y además evitó la reciente caída de una región de AWS. Sí usamos Cloudflare para defensa contra DDoS, y entiendo que manejar DNS o el ingress puede volverse un trabajo de tiempo completo. Pero unas cuantas arquitecturas de microservicios y una base de datos se pueden operar directamente sin problema. AWS cobra de más para la mayoría de las empresas

    • El verdadero problema de AWS es la dependencia de AWS por parte de los empleados. Sacan certificaciones de AWS y se genera un ambiente donde sienten que todo debe alinearse con el AWS Well-Architected Framework, así que dejan de pensar por sí mismos. Los servicios con lock-in de AWS se fijan de forma que parezcan baratos a propósito, pero al final te atan más. Por ejemplo, mover PostgreSQL a DynamoDB puede parecer un ahorro a corto plazo, pero a largo plazo aumenta la dependencia de AWS
    • On-premise es más barato, pero es difícil conseguir personal especializado. Funciona bien para productos simples, pero en sistemas complejos el costo laboral y el riesgo operativo pueden ser mayores. AWS/Azure/GCP no son perfectos, pero hoy en día los expertos en on-premise son demasiado escasos
    • Cuando criticas AWS, hay mucha gente que reacciona de forma extraña. En Reddit pasa algo parecido. A veces da la impresión de que alguien les pagara por defender AWS
    • Las historias de éxito del self-hosting tienen sesgo de confirmación. Operar servidores por cuenta propia se ve bien al principio, pero después de como un año la documentación ya no coincide con la configuración real, y si la persona encargada se va de la empresa, el caos crece. Al final muchas startups vuelven a AWS. Estas historias de fracaso casi no se comparten
    • Para operar bien bare metal, se necesitan ingenieros con experiencia. Es difícil lograrlo con juniors o con “expertos en nube” que vienen de consultoras

  • La nube al principio empezó como un servicio simple y con buena relación costo-beneficio, pero ahora está enredada con más de 200 servicios complejos. Si no lo administras bien, la factura se dispara

    • En realidad, AWS nunca se trató de ser “barato”, sino de poder escalar rápido. A inicios de la década de 2010 era caro, pero su ventaja era la flexibilidad. Incluso hoy sigue siendo caro para el rendimiento que ofrece. Si tienes las bases de administración de servidores, un servidor dedicado sale mucho mejor
    • AWS ya se expandió en exceso a más de 200 servicios. Debería enfocarse en las funciones básicas
    • Cada vez que entro a la consola de AWS me invade una sensación de complejidad y agotamiento. Es demasiado grande
    • Entre los servicios de AWS hay mucha variación en la relación costo-beneficio. Sobre todo los servicios centrales más antiguos siguen teniendo valor

  • La verdadera función de AWS es: (1) permitir la expansión organizacional y ciertas estructuras de poder, (2) hacer posible tratarlo contablemente como OpEx en lugar de CapEx, y (3) ocultar estructuras de personal incompetentes. Antes se podía operar un datacenter con 5 a 10 personas, pero ahora aparecen organizaciones DevOps de 3000 personas

    • No entiendo por qué es tan importante la diferencia entre OpEx y CapEx. Al final, el dinero sigue siendo dinero, ¿no?
    • La nube sí es útil para startups en etapa temprana. Pueden crecer rápido sin preocuparse por la planeación de capacidad. Pero si una empresa con bajo crecimiento se queda en la nube de forma permanente, se vuelve ineficiente
    • On-premise suele estar tan personalizado que reemplazar personal es difícil. En cambio, personal con experiencia en AWS se consigue en cualquier lado
    • Los administradores de sistemas con experiencia realmente son difíciles de conseguir y caros. He visto casos donde por querer ahorrar, llevaban dos años sin backups

  • La clave de este éxito es una carga constante 24/7. En realidad, la mayoría de las empresas tienen un patrón parecido

    • En realidad, al principio tuvieron suerte de empezar con un solo rack y un solo datacenter. No pagaron por adelantado el costo de la confiabilidad
    • Artículo relacionado: One Big Server
    • AWS a menudo dice que “no hay capacidad” y te empuja a usar instancias reservadas. Al final termina pareciéndose al costo de operar infraestructura permanente
    • Proveedores como Hetzner ofrecen el mismo rendimiento por 10 veces menos que AWS. La “elasticidad” de la nube es un mito exagerado

  • La clave está en elasticidad vs. carga base. La nube solo conviene cuando hay picos explosivos de tráfico, como en recolección de datos. En la mayoría de los casos, bare metal es mejor

  • En la década de 2010 el hardware y la red eran lentos, pero ahora el rendimiento y la eficiencia de CPU mejoraron cientos de veces. Lo que antes requería 64 servidores hoy puede resolverse con 1. En el futuro podría llegarse a una proporción de 100:1. En este contexto, las ventajas de la nube se reducen cada vez más

  • Desde la perspectiva de un empleado de Amazon, administrar Kubernetes por cuenta propia es demasiado riesgoso. Componentes como etcd son inestables, y hasta había que aplicar parches manualmente. El self-hosting del que habla el artículo subestima los riesgos

    • Otros hyperscalers también han sufrido grandes incidentes por fallas al administrar Kubernetes. Una alternativa simple para un solo rack, como Microk8s, puede ser mejor. Artículo relacionado: Microk8s 6 Months Later
    • Los entornos complejos son difíciles en cualquier lugar, y al final se necesitan especialistas. AWS tampoco es tan fácil. Incluso cuando hay una caída en la nube, el mundo sigue girando
    • Versiones ligeras como k3 son mucho más simples
    • Kubernetes solo debería usarse cuando realmente hace falta. Usarlo por defecto es desperdiciar tiempo y dinero

  • Muchas startups ni siquiera habrían podido existir con lo caro que es AWS. Por ejemplo, algo como descargas gratuitas de GeoIP (enlace) habría sido imposible. La nube es lenta, y tiene alta latencia de disco y sobrecarga de CPU. Debajo de 10 mil dólares al mes puede estar bien, pero por encima de eso bare metal es mucho más eficiente

    • Uno se acostumbra al bajo rendimiento de la nube y aparece una adaptación extraña. Siempre hay que comparar tomando bare metal como referencia

  • En una empresa donde trabajé también había poco tráfico, pero querían migrar a AWS. La razón era simple: querían poner AWS en el CV. No solo los desarrolladores, también la gerencia. “Lideré una migración a AWS” se veía bien para la carrera profesional. Al final la empresa fue vendida y la oficina quedó vacía. Quizá ahora “salí de AWS” se vuelva un nuevo punto de valor profesional

    • Si los desarrolladores quieren AWS, la siguiente generación terminará conociendo solo AWS. La discusión se sesga
    • Al final, la decisión depende de la voluntad del liderazgo

  • Al final, lo importante es qué se quiere hacer

    • Si es un sitio web interno y centrado en datos, un solo rack de servidores puede ser suficiente
    • Si hay tráfico masivo, irregular y no cacheable, la nube conviene más
    • Si DNS o el ingress son complejos, un enfoque híbrido puede ser lo mejor
    • Mientras más crece el volumen de datos, más favorable puede volverse la estructura de depreciación a largo plazo de la nube