FinOps por inventario

Diseñé un proceso FinOps que no ataca el coste a ciegas: primero inventaría AWS, lo cruza con Terraform y después prioriza el ahorro por riesgo.

El punto de partida

Atacar el gasto cloud con una lista de cambios sueltos es tentador, pero peligroso. Un cambio manual puede acabar revertido o contradicho por Terraform. Se optimizan recursos con dependencias que nadie vio venir, y producción queda sin un rollback claro.

Qué hice

Partí de la premisa contraria: inventariar antes de ejecutar. Diseñé un proceso para producción, staging y desarrollo cuyo primer entregable no es una lista de acciones. Es un inventario trazable de qué existe de verdad, cuánto cuesta, su criticidad y cómo se compara con lo declarado en Terraform.

Cómo lo hice

Inventario normalizado

Inventarié AWS por entorno, perfil y región, y también lo declarado en Terraform. Cada recurso pasa a un esquema común: tipo, tamaño, estado, coste mensual estimado, ahorro potencial, criticidad y confianza.

Matriz de drift

Cada recurso lleva un drift_status explícito:

• consistent: AWS y Terraform coinciden.
• different: existe en los dos, con diferencias.
• only_in_aws: creado fuera de IaC.
• only_in_terraform: declarado, pero no presente.
• partial / unknown: sin acceso al state, con inventario estático del .tf.

El cruce indica además la acción Terraform esperada (crear, actualizar, importar, eliminar, refactorizar) y la acción manual previa o posterior.

Prioridad por riesgo

Clasifiqué cada acción por riesgo, no solo por ahorro. P0 es reversible y de baja dependencia, como pasar EBS de gp2 a gp3. P1 toca producción y pide ventana y rollback. P2 son migraciones menores, como llevar EC2 o RDS a Graviton. P3 son rediseños posteriores.

Criterios de ejecución

Una acción solo se ejecuta con recurso identificado, ahorro estimado, estado Terraform, rollback, responsable y, si toca producción, ventana. Cada cambio cierra con evidencia antes y después, el terraform plan usado y una fecha para revisar el ahorro real en Cost Explorer.

Resultado

El proceso dejó una matriz de drift por entorno y un backlog de ahorro priorizado de P0 a P3, listo para ejecutarse por oleadas.

Los recursos caros o sobredimensionados quedaron identificados, con un mapa de cambios por proyecto Terraform. Los quick wins se pueden aplicar sin depender de suposiciones.

Qué me llevo

Un ahorro que Terraform revierte en el siguiente apply no es ahorro. Cruzar el inventario con la IaC antes de tocar nada es lo que convierte una lista de ideas en un proceso repetible.