La nube se vende como una forma de gastar menos. En buena parte de los equipos a los que entramos pasó lo contrario: la migración cerró en tiempo, el hardware ya no está, y la factura mensual es más grande que la que reemplazó. Nadie les mintió. El ahorro era real en el papel y se evaporó en la operación.
El patrón se repite lo suficiente como para valer la pena escribirlo.
A dónde se va realmente el dinero
En casi todos los entornos que revisamos, cuatro cosas explican la mayor parte de la sorpresa.
- Recursos que nadie redimensionó. Instancias de cómputo, bases de datos gestionadas y almacenamiento provisionados para el pico de una carga que nunca llegó, corriendo veinticuatro horas porque nada los apaga.
- Configuración elegida el primer día y nunca revisada. Una clase de almacenamiento, un nivel de base de datos o una opción de redundancia que se escogió durante el corte, cuando la prioridad era terminar, y ahí se quedó.
- Datos moviéndose entre regiones y zonas de disponibilidad. El concepto que nadie modela antes de migrar y todos descubren después, porque es invisible en un mundo on-premise donde la red ya estaba pagada.
- Servicios gestionados y premium comprados por comodidad. Sí quitan carga operativa, y traen un sobreprecio que tiene que ser una decisión y no un default.
Ninguna de estas es una falla de capacidad. Son el residuo de un proyecto que se midió por terminar, no por operar.
El primer arreglo es un cambio de postura
El hábito que más dinero cuesta es administrar una cuenta de nube como se administraba un centro de datos: provisionar una vez, dimensionar para el peor caso, y no tocar porque cambiar es riesgoso. En un centro de datos eso era prudente, porque el capital ya estaba gastado. En la nube esa misma prudencia factura por hora.
Una migración no es la meta. Es el primer día de una disciplina de operación que antes no existía.
Lo que significa que el plan de migración y el plan de costo no pueden ser el mismo documento, ni terminar el mismo día.
FinOps es una práctica permanente, no un proyecto
La gestión financiera de la nube funciona cuando finanzas y el equipo técnico ven los mismos números con la misma cadencia. No un reporte trimestral que llega demasiado tarde para cambiar algo: un ciclo corriente de planear, medir y ajustar, donde un ingeniero puede ver lo que cuesta una decisión antes de tomarla y finanzas puede ver qué compró después.
Eso exige antes dos cosas nada glamorosas. Etiquetar todo lo que cuesta, porque sin etiquetado no hay atribución y sin atribución no hay conversación con finanzas. Y publicar el gasto por área, por unidad de negocio o por entorno, porque un solo número agregado es exactamente lo que vuelve ingobernable el gasto de nube.
De pagar por lo que usas a pagar por lo que necesitas
El nivel de entrada del control de costo es pagar solo por lo que corre. Los entornos que no son producción son el lugar más barato para empezar: desarrollo, pruebas y staging rara vez necesitan existir a las tres de la mañana de un domingo, y apagarlos fuera de horario laboral quita alrededor de tres cuartas partes de sus horas de la factura. Es aritmética, no una promesa.
El siguiente nivel es el compromiso. La capacidad reservada y los savings plans descuentan la base que sabes que vas a correr, y sobre las tarifas publicadas por los propios proveedores eso llega hasta setenta y dos por ciento contra demanda. La condición es conocer tu base, y por eso este paso va segundo y no primero.
Detectar la anomalía antes de la factura
Cuando una sorpresa de costo llega a una factura, ya tiene un mes de vida. Las herramientas para evitarlo ya existen en las dos nubes y la mayoría de los equipos nunca las ha encendido: exploradores de costo y tableros para visibilidad granular, y detección de anomalías que marca un patrón de gasto inusual en días en lugar de al cierre del mes.
En AWS eso es Cost Explorer, los Cloud Intelligence Dashboards y Cost Anomaly Detection. En Azure es Cost Management and Billing junto con Advisor y las recomendaciones de reservas. Los nombres cambian, la disciplina no.
Cómo se ve esto cuando funciona
Un equipo que ya tiene esto puede contestar tres preguntas sin prepararse: cuánto gastamos el mes pasado y en qué, cuánto de eso era desperdicio y cuánto era estructura, y cuánto vamos a gastar el mes que entra si nada cambia. La mayoría no puede contestar la segunda, y ahí está toda la brecha.
En Farus arrancamos con una revisión que termina en una lista de hallazgos ordenada por lo que cada uno cuesta, separamos el desperdicio que se quita esta semana de lo estructural que necesita arquitectura, y después operamos la disciplina mes contra mes. Solo en replicación y standby normalmente encontramos entre diez y veinticinco por ciento de ese gasto.
Más sobre esto: FinOps