Cada mes llega el mismo documento y provoca la misma conversación. El total subió, alguien pregunta por qué, y la respuesta tarda dos semanas en llegar incompleta.
El problema no es el monto. La factura responde una pregunta que nadie tiene: cuánto. La que sí importa es en qué se desperdició.
La factura es un mal instrumento de diagnóstico
Está organizada por servicio y por cuenta: cuánto gastaste en cómputo, en almacenamiento, en transferencia de datos. Esa estructura sirve para pagar, no para decidir.
Un director no opera servicios. Opera productos, equipos y ambientes. Ninguna de esas dimensiones existe en la factura de forma nativa: hay que construirlas. Sin ellas la discusión no tiene árbitro —plataforma culpa a las aplicaciones y las aplicaciones a plataforma.
Antes de tocar una instancia, define las dimensiones con las que vas a leer el gasto: producto, equipo, ambiente, centro de costo. Lo que no nombras, no lo mides.
El etiquetado es la precondición
Sin etiquetas no hay FinOps. Hay opiniones bien intencionadas.
La etiqueta convierte una línea de facturación en información de negocio. Los tres proveedores mayores exponen el costo a nivel de recurso —Cost and Usage Report en AWS, exportación de costos en Azure, exportación a BigQuery en GCP— pero ese detalle solo es legible si cada recurso carga sus etiquetas.
Cuatro bastan para empezar: producto, equipo, ambiente y centro-costo. Más de seis y nadie las mantiene.
El etiquetado manual no sobrevive al segundo trimestre. Se sostiene aplicándolo desde la infraestructura como código, bloqueando en CI el recurso que llegue sin etiquetas obligatorias, y midiendo la cobertura de etiquetado sobre el gasto atribuible, no sobre el conteo de recursos: un recurso sin etiqueta puede ser trivial o la mitad de tu cuenta.
Acción concreta: dale dueño y revisión semanal a la cobertura de etiquetado, y trata cada punto no atribuible como deuda.
Palancas, ordenadas por impacto sobre esfuerzo
Apagado programado de ambientes no productivos
Desarrollo, QA y staging suelen correr 168 horas por semana para atender una jornada laboral. El mecanismo es trivial —un scheduler que apaga y prende por etiqueta— y el cómputo bajo demanda se cobra por tiempo encendido.
Dos advertencias: los discos siguen facturando aunque la instancia esté apagada, y las bases de datos administradas tienen reglas propias de reinicio automático. Mide el efecto comparando horas-instancia facturadas antes y después, no el total del mes.
Recursos huérfanos
Es la limpieza de menor riesgo y casi nadie la hace de forma sistemática. Cuatro familias: volúmenes de bloque sin adjuntar, IPs públicas reservadas sin asociar, snapshots e imágenes fuera de retención, y balanceadores sin targets sanos. Todos facturan por existir, no por usarse: un volumen desasociado cobra capacidad aprovisionada igual que uno en producción.
Acción concreta: corre el inventario, define una ventana de cuarentena antes de borrar y automatiza la detección para que no sea un evento anual.
Rightsizing por percentiles, no por promedios
Aquí se pierden más decisiones que en ninguna otra palanca, y la causa es estadística.
El promedio miente en las dos direcciones. Una instancia con CPU promedio muy baja puede saturarse en el cierre contable o en el batch nocturno: dimensionarla al promedio provoca un incidente. Otra con promedio alto y carga plana está sobredimensionada igual, porque no hay pico que justificar. El promedio colapsa la distribución en un número y borra justo lo que necesitas: la forma de la demanda.
Trabaja con percentiles. Toma p95 y p99 de CPU, memoria, IOPS y throughput de red sobre una ventana que cubra el ciclo real del negocio —mínimo un mes, con cierre mensual o temporada alta incluidos. Dimensiona contra p95 más un margen explícito, y usa p99 y el máximo para verificar que el pico sigue cabiendo.
Dos detalles rompen el ejercicio: la memoria no se reporta por defecto en ninguna de las tres nubes —necesitas el agente— y en Kubernetes el análisis va sobre los requests de los pods, no sobre la instancia.
Compromisos: Savings Plans, Reserved Instances y CUDs
Cambian el precio, no el consumo: un descuento a cambio de garantizar gasto durante uno o tres años. Son la palanca con más riesgo, y el riesgo no es financiero sino arquitectónico. Si vas a migrar a contenedores, a serverless o a otra familia de procesador, un compromiso rígido te ancla a la arquitectura que querías dejar atrás.
Reglas de operación: compromete sobre el piso de consumo estable, nunca sobre el pico; prefiere los instrumentos flexibles sobre los atados a una familia o región; y escalona las compras en tramos con vencimientos distintos.
Mide dos indicadores distintos. Cobertura: qué porción de tu consumo elegible está bajo compromiso. Utilización: qué porción de lo comprometido realmente usas. Utilización baja significa que pagas capacidad que no consumes.
Regla de secuencia: apaga, limpia y dimensiona primero. Comprometerte sobre una base inflada congela el desperdicio a tres años.
Egress y tráfico entre zonas de disponibilidad
Es el costo que más sorprende porque no está asociado a ningún recurso que puedas apagar.
Tres focos: la salida a internet, que se cobra por GB; el tráfico entre zonas de disponibilidad, que en arquitecturas distribuidas —Kafka, Cassandra, réplicas de base de datos— puede volverse la línea dominante sin que nadie lo diseñara así; y los NAT Gateways, que cobran por hora y además por GB procesado.
Se reduce con endpoints privados para que el tráfico al almacenamiento de objetos no cruce el NAT, afinidad de zona en el tráfico interno, y caché o CDN al frente de lo que sale.
Acción concreta: activa los flow logs y clasifica el tráfico por origen, destino y zona antes de proponer cambios.
Clases de almacenamiento y ciclo de vida
El almacenamiento crece por acumulación y nadie lo revisa porque cada objeto es barato.
Aplica reglas de ciclo de vida por edad y patrón de acceso, define retención real para snapshots y respaldos, y mueve a acceso infrecuente lo que no se lee. Cuidado con el tiering automático si tienes millones de objetos pequeños: cobra monitoreo por objeto y puede ir en tu contra.
Acción concreta: perfila tu almacenamiento por edad y frecuencia de acceso antes de escribir la primera regla.
Comparativa de palancas
| Palanca | Esfuerzo | Riesgo operativo | Velocidad de retorno |
|---|---|---|---|
| Apagado programado (no productivos) | Bajo | Bajo | Días |
| Recursos huérfanos | Bajo | Muy bajo | Días |
| Rightsizing por percentiles | Medio | Medio | Semanas |
| Clases de almacenamiento y ciclo de vida | Medio | Bajo | Semanas |
| Egress y tráfico entre zonas | Alto | Medio | Semanas a meses |
| Compromisos (SP · RI · CUD) | Bajo de ejecutar, alto de decidir | Alto si la arquitectura cambia | Inmediato, pero se paga por 1 a 3 años |
FinOps es una práctica, no un proyecto
Un proyecto de optimización baja el gasto una vez. Seis meses después vuelve, porque la causa —decisiones diarias sin retroalimentación de costo— sigue intacta.
La práctica se sostiene con tres piezas: presupuestos por producto y por equipo sobre las dimensiones que construiste con etiquetas; alertas por desviación contra el pronóstico y por anomalía, no solo por umbral absoluto —el umbral fijo se entera tarde y siempre—; y revisión mensual con dueños nombrados, donde cada desviación tiene explicación técnica o acción con fecha.
La métrica que vuelve esto conversación de negocio es el costo unitario: por pedido procesado, por transacción, por usuario activo. El gasto absoluto puede subir mientras el costo unitario baja, y eso es crecimiento sano. Sin esa métrica, cualquier aumento parece un problema.
Acción concreta: elige una unidad de negocio, calcúlala cada mes y preséntala junto al total. Una métrica sostenida vale más que un tablero con cuarenta.
Tres preguntas para mañana
- ¿Qué porcentaje del gasto del mes pasado podemos atribuir a un producto y a un equipo sin suponer nada? Si la respuesta no es un número, el problema es etiquetado.
- ¿Cuál es nuestro costo por unidad de negocio y cómo se movió en los últimos tres meses? Si nadie lo calcula, no medimos eficiencia: miramos un total.
- ¿Sobre qué base están hechos nuestros compromisos vigentes, cuál es su utilización y qué pasa con ellos si cambiamos de arquitectura este año?
Las tres se responden con datos que ya existen en tu cuenta. Lo que falta es la estructura para leerlos.