Todas las conversaciones sobre si dejar AWS en las que he estado empiezan igual: una hoja de cálculo comparando el coste del hardware por vCPU con el precio bajo demanda. Esa hoja de cálculo normalmente no se equivoca, y aun así es la parte menos importante de la decisión. El coste real de gestionar tu propia infraestructura no aparece en una comparativa de precio por núcleo. Aparece ocho meses después, a las 3 de la madrugada, cuando un disco falla de una forma que tu runbook no contemplaba.
Esta es la checklist que uso de verdad con clientes que se plantean pasarse a una nube privada o a Kubernetes sobre servidores bare metal, en lugar de quedarse en un hyperscaler. No es exhaustiva, y la iré ampliando según nos vayamos encontrando con nuevos modos de fallo que merezca la pena añadir, porque una lista que se escribe una vez y se deja quieta deja de servir en cuanto se equivoca por primera vez.
El checklist
| Aspecto a considerar | Qué implica en la práctica | Qué te cuesta si lo pasas por alto |
|---|---|---|
| Fallos de almacenamiento | Tu capa de almacenamiento (Ceph, NVMe local, lo que sea) tiene sus propios modos de fallo, sus propios tiempos de reconstrucción y sus propios procedimientos de recuperación, que no tienen nada que ver con los de tu aplicación | Perder un nodo durante una ventana de reconstrucción y descubrir que tus cálculos de redundancia daban por hecho una velocidad de reconstrucción que en realidad no tienes |
| Tiempos de restauración de copias de seguridad | Las copias de seguridad existen; los simulacros de restauración, casi nunca | Responder «tenemos copias de seguridad» en mitad de un incidente y acabar con una restauración de 11 horas porque nadie la había cronometrado nunca |
| Rutas de actualización | Kubernetes, tu CNI, tu driver de almacenamiento y tu sistema operativo tienen cada uno su propio ritmo de versiones y su propia matriz de compatibilidad | Un parche de seguridad que no puedes aplicar sin actualizar antes otros tres componentes que no pensabas tocar este trimestre |
| Margen de capacidad | Ahora eres tú quien tiene que comprar por adelantado a la demanda, en lugar de escalar automáticamente según llega | Un plazo de entrega de hardware de entre seis y doce semanas, justo entre tú y el pico de tráfico que está pasando ahora mismo |
| Guardias | Ahora alguien es responsable del hardware, no solo de la aplicación | Un aviso a las 2 de la madrugada por una fuente de alimentación estropeada, dirigido a los mismos tres ingenieros que ya llevaban las guardias de aplicación |
| Salida de datos (egress) | Sacar datos de tu propia infraestructura suele ser lo único que realmente sale más barato al dejar AWS, pero solo si de verdad rediseñaste la arquitectura pensando en ello | Acabar con una arquitectura híbrida que sigue enrutando tráfico a través del proveedor cloud del que precisamente intentabas escapar para ahorrar |
| Latencia entre centros de datos | Esa idea de que «la base de datos está cerca» puede que solo fuera cierta porque estabas en una única región de AWS | Una regresión de latencia en el p99 que aparece en producción y en ningún sitio de preproducción, porque preproducción nunca llegó a cruzar una red WAN de verdad |
| Cumplimiento normativo | Parte de tu postura de cumplimiento dependía de la certificación SOC 2 de AWS, y al pasarte a tus propios racks no heredas nada de eso | Un hallazgo de auditoría que da por hecho controles que antes vivían enteramente en el modelo de responsabilidad compartida de otra empresa |
Lo que de verdad pilla a los equipos
El almacenamiento es, para mí, lo que más se suele infravalorar. Los equipos dimensionan su clúster de almacenamiento por capacidad e IOPS, hacen sus cuentas y dan el tema por cerrado. Lo que no hacen es simular una reconstrucción bajo carga real de producción. Un Ceph reconstruyendo un OSD caído mientras tu aplicación le sigue metiendo lecturas se comporta de forma completamente distinta a un Ceph en reposo, y la mayoría de los equipos lo descubre durante un fallo de verdad, no durante una prueba.
Los tiempos de restauración de copias de seguridad van justo detrás, y por una razón un poco tonta: es fácil comprobar que una copia existe, y difícil comprobar que funciona. Un aws backup o un pg_dump nocturno que aparece en verde en tu monitorización te dice que la copia se ha ejecutado. No te dice nada sobre cuánto tarda una restauración, ni sobre si el procedimiento de restauración todavía coincide con tu esquema actual. A mis clientes les pregunto cuándo fue la última vez que restauraron de verdad una copia en un entorno limpio, y en la mitad de los casos, la respuesta sincera es «nunca».
El margen de capacidad es el que pilla a la gente desprevenida porque, en el fondo, no es un problema técnico: es un cambio en quién responde de una decisión que antes era invisible. En un hyperscaler, la capacidad es problema de otro, y tú pagas un sobreprecio precisamente para no tener que pensar en ello. Con tu propio hardware, quedarte corto de capacidad significa un pedido de compra, un plazo de entrega, y una persona cuyo trabajo pasa a ser vigilar una gráfica y encargar servidores antes de necesitarlos. He visto equipos equivocarse justo al revés: sobreaprovisionar por triplicado por miedo, y acabar dándole sin querer la razón a quien decía que mejor se hubieran quedado en AWS.
La salida de datos (egress) es el caso raro, porque es de verdad el mejor argumento para dejar AWS, y también el que más fácilmente se acaba deshaciendo sin que nadie se dé cuenta. He visto a un cliente montar toda una infraestructura privada específicamente para librarse de los costes de egress, y luego seguir enrutando parte de su pipeline de datos a través de su antigua cuenta de AWS porque una integración de terceros solo sabía hablar con S3. Seis meses después, estaba pagando egress en dos nubes a la vez y ni se había dado cuenta.
El cumplimiento normativo merece más atención de la que recibe en estas conversaciones, porque aquí el coste no es operativo, es organizativo. Cuando estás en AWS, buena parte de tu discurso de cumplimiento se resume en una frase: «AWS tiene la certificación SOC 2 Tipo II, aquí está el informe.» Múdate a tu propia infraestructura, y esa frase desaparece de tu respuesta ante una auditoría. Controles de acceso físico, monitorización ambiental, procedimientos de desecho del hardware: alguien de tu equipo tiene ahora que documentar y demostrar todo eso, y esa persona normalmente no se identifica hasta que la auditoría ya está programada.
Para qué sirve esta lista
Nada de esto es un argumento en contra de la nube privada. He llevado esta misma migración con clientes para los que era claramente la decisión correcta, y en los que la factura de AWS que venían pagando era, sinceramente, una barbaridad para su carga de trabajo. Es un argumento en contra de tomar la decisión solo por una comparativa de coste de hardware, porque cada fila de la tabla de arriba es un coste operativo real que una comparativa de euros por núcleo nunca te va a enseñar.
Si estás en medio de esta decisión, lo honesto es repasar cada fila y anotar, con nombre y apellido, quién en tu equipo es responsable de ella hoy y quién lo sería después del cambio. Si una fila se queda sin dueño, eso no es motivo para quedarte en AWS. Es, simplemente, el coste real de la decisión que estás a punto de tomar, y mejor conocerlo antes que después.