- La necesidad de migrar a una nube europea surgió por problemas de soberanía de datos y cumplimiento de GDPR asociados con los servicios de nube de EE. UU.
- Aunque se renunció por completo a la comodidad y los servicios integrados de AWS, con hosting europeo como Hetzner se lograron ahorros inmediatos y mayor claridad sobre los datos
- Para mejorar la eficiencia operativa de la infraestructura, se implementó automatización basada en Ansible y un sistema de monitoreo autogestionado
- Al construirlo directamente, se obtuvo un diseño de seguridad más riguroso y una estructura que facilita auditorías transparentes
- También se consiguieron ventajas estratégicas de negocio, como una reducción de costos del 90% y una menor exposición al riesgo de vigilancia de EE. UU.
Proceso de migración de AWS a una nube europea (Hetzner) y estrategia para mantener ISO 27001
El dilema de un CTO europeo: los problemas de cumplimiento al salir de AWS
- Una preocupación habitual entre muchos líderes tecnológicos surge de las limitaciones de los proveedores de nube de EE. UU.
- Aunque estaban satisfechos con los sólidos servicios certificados en ISO 27001 que ofrece AWS, no podían evitar que los datos de clientes dentro de Europa quedaran expuestos a la jurisdicción de EE. UU. por el CLOUD Act y la FISA
- Se generó así una situación en la que era difícil cumplir las promesas de GDPR, sin importar la ubicación física real de los servidores
- Se dieron cuenta de que el gasto anual en nube, de $24,000, era excesivo frente a la demanda real
- También confirmaron que depender del futuro de la empresa de un único proveedor con base en EE. UU. era una decisión estratégicamente riesgosa
Un caso real: Datapult
- Datapult es una empresa danesa de software de gestión de personal, donde funciones como programación de turnos, ajuste de pago por horas extra y manejo de datos de asistencia exigen confiabilidad de nivel financiero
- Habían adaptado los requisitos legales a un flujo de trabajo basado en AWS, pero migrar a alternativas on-premise o servicios independientes requería revisión legal adicional
Qué preocupa al dejar AWS y qué se pierde en la práctica
- Renunciar a la conveniencia integrada de AWS representa una barrera psicológica importante
- Se pierden la simplicidad y la automatización de herramientas como Lambda, RDS con un clic y varias utilidades integradas de cumplimiento regulatorio
- Se pasa de servicios administrados a más control directo y mayor responsabilidad
Beneficios esperados y ganancias reales de una nube europea
- La migración a proveedores europeos (Hetzner, OVHcloud) aportó beneficios inmediatos en soberanía de datos, GDPR e ISO 27001
- Comunicación transparente con clientes y respuesta a auditorías al poder demostrar una verdadera residencia de datos
- Ahorros inesperados del 90% y mayor transparencia presupuestaria
- Aunque se dejó atrás la comodidad de AWS, se obtuvo una automatización técnicamente más sólida (configuración con Ansible) y mejoras de seguridad
- En comparación con antes, se consiguió más autonomía, capacidad de innovación e infraestructura verificable
Estrategia concreta de migración y principales lecciones
- Automatización del cumplimiento con Ansible
- Se logró una gestión de infraestructura autodocumentada en la que toda configuración de servidores se vincula directamente con los controles del Anexo A de ISO 27001
- Construcción de un sistema de monitoreo alternativo a AWS
- Con la combinación de Prometheus, Grafana y Loki, fue posible alcanzar monitoreo de nivel empresarial comparable a AWS CloudWatch y una respuesta rápida a incidentes
- Implementación de security-by-design para reforzar la arquitectura de seguridad
- Ante la ausencia de herramientas de seguridad administradas, la automatización con Ansible permitió fortalecer el ISMS y facilitar el cumplimiento para los desarrolladores
Efectos estratégicos más allá de la tecnología
- Minimización del riesgo de cumplimiento derivado de las leyes de vigilancia de EE. UU.
- Uso de una infraestructura de hosting europea como punto de diferenciación comercial, elevando la confianza y el valor de marca
- Creación de una estructura para reinvertir en el negocio principal el 90% ahorrado en costos de nube
Guía para aplicar la estrategia de migración
- Con base en la experiencia de migrar desde infraestructura en AWS a una nube europea con soberanía y mantener ISO 27001, se pueden ofrecer lineamientos reproducibles
- Para CTOs y fundadores que estén considerando pasar de AWS a una nube europea, se puede brindar asesoría personalizada sobre análisis de costos, riesgo de cumplimiento y cronograma de ejecución
- En una hora es posible ordenar la diferencia de costos, los principales riesgos legales y las etapas iniciales de la migración
1 comentarios
Opiniones en Hacker News
Reducimos costos reimplementando nosotros mismos funciones clave de AWS, pero mucha gente pasa por alto el costo real del hosting estilo DIY, sobre todo cosas como soporte 24/7. Si intentas montarlo tú mismo, en realidad puede salir bastante caro. Un gasto anual de $24,000 en AWS equivale a 1 o 2 meses de un excelente freelancer de DevOps, o alrededor de 1/3 de FTE de un desarrollador de bajo salario, y con ese presupuesto es difícil esperar soporte de respuesta 24/7. Claro, esta decisión puede ser razonable, pero da pena que no se transparenten con honestidad todos los costos reales, como el tiempo de desarrollo o la administración. Yo también estoy considerando una decisión parecida, aunque más por requisitos de negocio, como clientes alemanes, que por ahorro de costos. Pero sería más complejo y también haría falta ampliar el equipo. Como CTO, mi tiempo es limitado, y meterme personalmente en este trabajo es de las peores formas de usarlo. Creo que debería enfocarme más en el crecimiento de la empresa y del producto. Personalmente, para algo tan pequeño, Terraform me parece excesivo, y siento que Ansible encaja mejor en un caso YAGNI (You Ain’t Gonna Need It).
La gente cree por error que los grandes proveedores cloud como AWS, Azure o GCP realmente te dan soporte 24/7 para la aplicación, pero en la práctica no es así. Lo único es que la infraestructura funciona “más o menos” bien, y aun así necesitas expertos para usarla correctamente y revisar por tu cuenta problemas de integración o facturas explosivas. La idea de que la factura cloud representa el TCO (costo total de propiedad) es un mito completamente falso
Si replicas al 100% las funciones de AWS puede salir caro, pero si solo necesitas el 80%, la situación cambia. Tampoco hay que ignorar el esfuerzo de configurar AWS y mantener afiladas esas habilidades. Por ejemplo, en vez del dashboard de AWS podrías usar herramientas mejores como Grafana. Al final depende de la escala y variedad de los requisitos. El martillo más caro no siempre es la respuesta correcta
Viéndolo solo por ahorro, estarías recortando $21,600 al año, que es el 90% de $24,000. Pero con ese presupuesto no contratas a un ingeniero SRE/DevOps en Europa. Más bien creo que, con el tiempo, el costo total de propiedad va a subir porque tendrás que gestionar toda la infraestructura por tu cuenta. Aun así, apoyo el reto
Si consideras el riesgo de que el gobierno de EE. UU. obligue a Amazon a suspender una cuenta, usar AWS puede ser riesgoso. Más todavía en un contexto donde últimamente incluso se habla de guerra entre EE. UU. y Europa (Groenlandia)
Me parece demasiado ingenua esa cuenta simple de $24,000 al año. Siento que faltan estimaciones concretas de costos de personal, como cuánta gente hace falta para montar estos servicios en AWS, o cuántas personas necesitarías para bajar algo que originalmente cuesta entre $48,000 y $100,000 a $24,000
Creo que solo con la combinación de Prometheus, Grafana y Loki pudimos replicar por nuestra cuenta, o incluso superar, el nivel de monitoreo que teníamos en AWS. Siempre me sorprende que, con herramientas tan buenas como esas, los servicios de monitoreo de AWS sigan siendo caros, lentos y con una UX decepcionante. De hecho, el costo del monitoreo fue la parte más rápida y desagradable de toda mi experiencia con AWS
La principal desventaja de Hetzner es la contaminación de IPs por usuarios maliciosos, además de la necesidad de lidiar con fallas de hardware y upgrades. Me pregunto si eso no les preocupó. También me interesa saber cómo resolvieron los problemas de consumo excesivo de memoria de Loki, o si hay otras alternativas
El problema de IPs contaminadas se resuelve poniendo el acceso de usuarios detrás de un proxy con Cloudflare, y configurando el firewall (ufw) para permitir solo fuentes autorizadas y las IPs de Cloudflare, bloqueando de hecho el acceso externo directo. Las fallas o upgrades de hardware se resuelven rápido con una configuración de Terraform que permite reemplazo y ampliación de capacidad en poco tiempo. Monitoreamos el hardware con Prometheus y node exporter, recibimos alertas tempranas y en 9 meses no hubo incidentes. La app casi no tiene datos y la base de datos se somete a pruebas frecuentes de recuperación. El problema de memoria de Loki se resolvió combinando varias medidas: políticas de retención y separación de índices, ajuste de concurrencia de consultas y límites de memoria, adopción de etiquetas tipo promtail y logging estructurado, y para registros antiguos usar respaldo en object storage o incluso
grepLos problemas que tuvimos con Loki se deben a que configuraciones de despliegue por defecto, como helm, no vienen lo bastante optimizadas. Aplicamos los consejos de rendimiento mencionados en el blog, como reinicializar índices, agregar instancias de solo lectura y seguir otras recomendaciones, y sí vimos una mejora clara. Creo que la intención es empujarte hacia su servicio cloud propio en vez del open source, así que al principio toca batallar un poco
Como alternativa a Loki, recomiendo Victoria. Es mucho más rápido y tiene muy buena reputación, pero nosotros elegimos Loki considerando la diversidad de mantenedores del proyecto. Compensamos las desventajas con los métodos mencionados arriba
Comparto este enlace: https://en.wikipedia.org/wiki/Sybil_attack. Los proveedores cloud caros tienen la ventaja de construir reputación de IP de una forma parecida a un esquema PoW (prueba de trabajo)
ISO 27001 es un estándar internacional de gestión de seguridad, una guía muy popular en Europa. En EE. UU. casi no se usa, y muchas empresas europeas no terminan de aceptar bien esa diferencia. La base de los estándares de seguridad en EE. UU. es SOC 2, que es menos estricto que ISO 27001 y más familiar para el mercado estadounidense
ISO 27001 en realidad no es un estándar tan rígido o severo; por lo general pide lo básico que deberías hacer al usar software. Lo complicado es demostrarlo documentalmente, mientras que SOC 2 tiene una carga de documentación bastante menor
Habiendo pasado por auditorías de SOC 2 e ISO 27001, me decepciona que la auditoría SOC 2 dependa mucho más de la capacidad e intuición del auditor que de controles prácticos reales. ISO 27001 me parece una auditoría mucho más clara y justa
Pido que mencionen una sola gran empresa cloud de EE. UU. que no tenga certificación ISO 27001
Yo también hice algo parecido con Azure y reduje costos en 90%. Siento que las grandes empresas te fuerzan intencionalmente a una experiencia de abstracción de servicios compleja, haciendo cada vez más difícil operar de forma simple
Una de las razones para pagar AWS es que reduce la carga operativa, y de hecho al usar bases de datos administradas de AWS ya no siento el estrés de antes al actualizar clústeres de mysql. Claro, eso por sí solo no justifica el alto costo, pero sí tiene bastante valor
Los números no me cuadran. Si reduces 90% desde $24,000 al año, quedarías en $200 al mes, que apenas alcanza para un solo servidor en Hetzner. En ese caso parecería que incluso podrías operar sin sistema distribuido y usar solo un servidor. Me da curiosidad el volumen real de requests por segundo o la cantidad de usuarios
Para cumplir con ISO 27001 no puedes operar con un solo servidor; también necesitas un servidor aparte dedicado a logs y monitoreo. Sin importar la carga, la complejidad es obligatoria. Los empleados no inician sesión todos los días, y por la naturaleza de una app de programación de turnos, a veces solo la revisan 1 o 2 veces por semana. El DAU está entre 10,000 y 20,000, el pico de concurrencia entre 1,500 y 2,000 usuarios, y la concurrencia promedio entre 50 y 150. El costo cloud sube porque la app tiene mucha carga de procesamiento de datos por funciones en tiempo real y reglas laborales complejas. Por ejemplo, la asignación de turnos incluye reglas distintas hasta para el cálculo de bonos, y la optimización de horarios también requiere bastante cómputo
Corrigen que no son $2,400 sino $200
Me pregunto cómo hacen el cifrado de disco. En AWS es automático, pero no he visto una buena forma de implementarlo con proveedores de hosting comunes. También señalan que guardar la clave de cifrado en la partición de arranque lo vuelve inútil
Me gusta muchísimo Hetzner; hasta mi buscador corre ahí. Creo que usar servidores físicos es lo mejor
Además de OVH y Hetzner, también quiero recomendar UpCloud dentro de los clouds europeos. Una ventaja de UpCloud es que sus CPU cores parecen ser todos núcleos reales y no vCPU (basadas en hilos). Eso sí, es una lástima que falten referencias oficiales. Comparar OVH, Hetzner y los hyperscalers no es fácil, pero en el caso de Hetzner hay diferencias porque la mayoría usa componentes de consumo. Introducción a UpCloud