El problema con los "quick wins" de coste

Atacar el gasto cloud con una lista de cambios sueltos es tentador, pero peligroso: se aplican cambios manuales que Terraform luego revierte o contradice, se optimizan recursos con dependencias que nadie vio venir y se compromete producción sin un rollback claro. Mi premisa fue justo la contraria: inventariar antes de ejecutar.

El primer entregable no es una lista de acciones, sino un inventario completo y trazable que permita saber qué recursos existen de verdad, cuánto cuestan, su criticidad y dependencias, y cómo se comparan con lo declarado en Terraform.

El método, en ocho pasos

1. Inventario de AWS real (por entorno, perfil y región; salida en JSON).
2. Inventario de lo declarado en Terraform.
3. Normalización por recurso a un esquema común.
4. Matriz AWS real vs Terraform.
5. Estimación de coste y ahorro (apoyada en Cost Explorer).
6. Priorización por impacto, riesgo y velocidad.
7. Backlog de cambios Terraform por repositorio.
8. Ejecución por oleadas.

Inventario normalizado y cruce con Terraform

Cada recurso se registra con campos homogéneos —entorno, región, tipo, tamaño/clase, estado, coste mensual estimado, ahorro potencial, criticidad y confianza— y se cruza con Terraform mediante un drift_status explícito:

• consistent — AWS y Terraform coinciden.
• different — existe en ambos pero con diferencias.
• only_in_aws — recurso creado fuera de IaC (deuda y riesgo de drift).
• only_in_terraform — declarado pero no presente.
• partial / unknown — cuando no hay acceso a state y se hace inventario estático del .tf.

El cruce señala además la acción Terraform esperada (crear, actualizar, importar, eliminar, refactorizar) y qué acción manual previa o posterior hace falta.

Priorización por riesgo

La pieza que evita cambios ciegos en producción es clasificar cada acción por nivel de riesgo, no solo por ahorro:

• P0 — seguro y rápido: reversible y de baja dependencia. EBS gp2 → gp3, borrar volúmenes available y snapshots huérfanos tras validar, ajustar lifecycle de S3 para logs/datos fríos.
• P1 — producción con control: ahorro claro pero requiere ventana y rollback. Redimensionar o recrear el bastión con menos volumen, revisar ELB/NLB sin tráfico, reducir retención de logs de CloudWatch.
• P2 — migración o cambio de arquitectura menor: migrar EC2/RDS a Graviton, quitar Multi-AZ donde no aplique, automatizar o sustituir NAT Gateway en no-producción, llevar ASG no productivos a min=0.
• P3 — rediseños posteriores: mover dev/staging a contenedores/serverless bajo demanda, sustituir ETL legacy por servicios gestionados.

Criterios de ejecución y validación

Una acción solo se ejecuta cuando tiene recurso identificado, coste/ahorro estimado, criticidad, estado Terraform, rollback claro, responsable y —si toca producción— ventana definida. Y cada cambio cierra con evidencia antes/después, el terraform plan usado, la métrica/estado de AWS tras el cambio y una fecha para revisar el ahorro real en Cost Explorer.

Resultado e impacto

• Inventario AWS real y de Terraform por entorno, con matriz de drift y recursos caros o sobredimensionados identificados.
• Backlog de ahorro priorizado (P0–P3) y mapa de cambios por proyecto Terraform, listo para ejecutar quick wins sin depender de suposiciones.
• Una base FinOps reutilizable: une coste, operativa, IaC y riesgo de negocio en un mismo proceso repetible.