FinOps no es ahorrar. Es saber qué pagás.

La factura de la nube tiene una propiedad incómoda: no miente, pero tampoco explica. Dice cuánto, no por qué. Y como se cobra por uso, cada deploy, cada rama de prueba y cada snapshot «por las dudas» la mueve un poco.

FinOps es la práctica de cerrar esa brecha. No es un equipo de finanzas mirando dashboards ni una negociación anual de descuentos. Es que la gente que decide el gasto —la que hace deploy— pueda ver el número, entenderlo y actuar. El ahorro llega solo después.

Este artículo es la parte práctica: qué mirar, con qué herramienta y con qué umbral, en AWS, Google Cloud y DigitalOcean.

01 · Primero ver, después tocar

El error más común es empezar apagando cosas. Sin visibilidad, cada apagado es una apuesta, y el primer incidente que cause termina con la iniciativa. Antes de optimizar hay tres cosas que tienen que existir.

Etiquetas obligatorias

Tres como mínimo: equipo, servicio y entorno. Si un recurso no se puede asignar a alguien, no se puede corregir. Y las etiquetas no se piden por convención: se exigen por política.

AWS

Activá las etiquetas como cost allocation tags en Billing (si no, no aparecen en los reportes). Usá una regla required-tags de AWS Config para marcar lo que nace sin etiqueta, y una Service Control Policy para bloquear la creación de EC2/RDS sin ellas.

GCP

Se llaman labels. Pero la unidad de aislamiento más útil es el proyecto: un proyecto por servicio y entorno te da la asignación casi gratis. Las etiquetas quedan para cortar más fino.

Tags en Droplets, Volumes y bases, y Projects para agrupar por producto. No hay enforcement nativo: el control es un script con doctl que lista lo que no tiene tag y lo publica en Slack cada lunes.

La factura en una base de datos

Las consolas de costos sirven para mirar. Para preguntar («¿cuánto nos cuesta el entorno de staging del equipo de pagos por día?») necesitás la data cruda en algo consultable.

AWS

Cost and Usage Report (CUR) exportado a S3 y consultado con Athena. Cost Explorer para lo cotidiano. Es la fuente de verdad de todo lo demás.

GCP

Billing export a BigQuery (el detallado, con uso por SKU). Es la mejor implementación de los tres: se activa en dos clics y se consulta con SQL al minuto.

No hay export granular. La factura es simple y predecible (precio fijo por mes por recurso), así que el inventario de la API multiplicado por la lista de precios es tu modelo de costos. Un script, una tabla, listo.

Alertas antes de la factura

Un presupuesto por equipo con aviso al 80% y al 100% del esperado, y detección de anomalías para lo que ningún presupuesto anticipa. En AWS: Budgets más Cost Anomaly Detection (gratis, aprende el patrón por servicio y avisa cuando algo se sale). En GCP: Budgets & alerts por proyecto, con notificación a Pub/Sub si querés automatizar. En DigitalOcean: billing alerts por monto; es básico, pero evita la sorpresa.

02 · Las cuatro fugas y cómo detectarlas

Con visibilidad, el desperdicio tiene formas conocidas. Casi todo lo que vas a encontrar cae en una de estas cuatro. Para cada una: la señal, la herramienta y el umbral que usamos de verdad.

Fuga 1 · Lo que quedó encendido

Entornos de desarrollo y pruebas que corren 168 horas por semana para ser usados 45. Es la fuente más grande de desperdicio en equipos chicos y medianos, y la más fácil de cerrar.

Señal: CPU promedio por debajo del 5% y tráfico de red casi nulo durante 14 días. En AWS, Trusted Advisor ya calcula «Low Utilization EC2» con un criterio parecido, y Compute Optimizer marca instancias idle; en GCP, el Idle VM recommender hace lo mismo y aparece directo en la consola de Compute; en DigitalOcean, los gráficos del agente de monitoreo más una consulta a la API de métricas.

Acción: horarios. Todo lo que no sea producción se apaga de noche y fines de semana. En AWS, la solución Instance Scheduler (oficial, desplegable con CloudFormation) lo hace por etiqueta. En GCP, Instance schedules es una política nativa de Compute Engine. En DigitalOcean, un cron con doctl compute droplet-action power-off. Apagar 13 horas por día más fines de semana recorta cerca del 65% de ese costo sin tocar nada de arquitectura.

Fuga 2 · Lo que pediste de más

Se dimensiona para el pico que imaginamos, no para el uso que medimos. Una instancia grande con 12% de CPU promedio es la norma, no la excepción.

Señal: el p95 de CPU y memoria en 14 días. Si el p95 está por debajo del 40%, hay un tamaño menos. AWS Compute Optimizer da la recomendación concreta para EC2, Auto Scaling, EBS, Lambda, ECS Fargate y RDS, con el riesgo de rendimiento estimado; para memoria necesita el agente de CloudWatch instalado. GCP tiene el rightsizing recommender por VM y lo muestra al lado de cada máquina. En DigitalOcean no hay recomendador: mirás los gráficos del Droplet y bajás un escalón; cambiar el plan es un resize con reinicio.

Acción: un escalón por vez, con una semana entre cambios. Y aprovechá el movimiento: en AWS pasar a Graviton (ARM) suele dar 20% menos de precio por rendimiento; en GCP la familia Tau T2A o E2 según la carga; en DigitalOcean la pregunta es si necesitás CPU dedicada o alcanza con compartida, que cuesta la mitad.

Las bases de datos son el sobredimensionamiento más caro y el que menos se toca. Mirá RDS y Cloud SQL antes que las instancias.

Fuga 3 · Lo que quedó huérfano

Recursos que sobrevivieron a lo que los usaba. No aparecen en ningún dashboard de rendimiento porque no hacen nada. Sí aparecen en la factura.

AWS

Volúmenes EBS en estado available (sin instancia). Snapshots de más de 90 días sin AMI asociada. Elastic IPs sin asociar (se cobran por hora). Load balancers sin targets sanos. NAT Gateways en VPCs sin tráfico: cuestan por hora aunque no muevan un byte. Todo esto lo lista Trusted Advisor; para automatizar la limpieza, Cloud Custodian con una política por tipo.

GCP

Discos persistentes sin VM (hay un recomendador específico), direcciones IP estáticas reservadas sin usar, snapshots sin política de retención, y el clásico: proyectos enteros que nadie recuerda. El Unattended project recommender los encuentra por falta de actividad de API.

Volumes sin Droplet, Reserved IPs sin asignar (se cobran justamente cuando no están asignadas), snapshots acumulados a precio por GB y Load Balancers de proyectos que ya no existen. doctl compute volume list y doctl compute snapshot list en un cron semanal bastan.

Proceso: un reporte semanal automático con la lista de huérfanos, el dueño según etiqueta y el costo mensual. Lo que lleva dos semanas en la lista sin respuesta, se etiqueta borrar-el con fecha y se borra. Snapshot previo, siempre.

Fuga 4 · Lo que viaja

La transferencia de datos es la línea de la factura que nadie decidió. Nadie «pide» egress: pasa, como consecuencia de cómo está armada la red.

En AWS los sospechosos de siempre son tres: el NAT Gateway, que cobra por cada GB procesado (los gateway endpoints para S3 y DynamoDB son gratis y sacan ese tráfico del NAT); el tráfico entre zonas de disponibilidad, que se paga en ambos sentidos y que generan sin querer las réplicas y los clusters mal distribuidos; y el egress a internet, que se abarata pasando por CloudFront. Cost Explorer filtrado por usage type con «DataTransfer» te muestra en cinco minutos cuál de los tres es.

En GCP: tráfico entre regiones (mantener servicios y sus datos en la misma región no es solo latencia), Private Google Access para que las VMs sin IP pública lleguen a las APIs de Google sin NAT, y Cloud CDN delante de lo que sirva archivos. En DigitalOcean la transferencia está incluida en un pool compartido entre Droplets y rara vez es problema; cuando lo es, Spaces trae CDN sin costo extra.

03 · Almacenamiento y logs

El almacenamiento crece solo y nunca baja solo. Dos reglas resuelven la mayor parte.

Que la plataforma mueva lo frío. S3 Intelligent-Tiering en AWS y Autoclass en Cloud Storage hacen el escalonado por acceso real sin que tengas que adivinar; para lo que sabés que es archivo, una regla de lifecycle a Glacier o Archive y otra de expiración. S3 Storage Lens te dice por bucket dónde está el volumen. En DigitalOcean, Spaces tiene lifecycle para expirar objetos; para snapshots de Droplets, retención máxima de 7 días en no productivo.

Los logs tienen fecha de vencimiento. CloudWatch Logs crea los grupos con retención «nunca expira» por defecto, y a los dos años eso es una línea seria de la factura: fijá 30 días en desarrollo y 90 en producción, y mandá a S3 lo que haya que guardar más. En GCP, Cloud Logging cobra por ingesta: los exclusion filters para logs de health checks y balanceadores suelen recortar la mitad del volumen. Y si pagás ingesta en Datadog, Grafana Cloud o similar, el mismo filtro rinde doble.

04 · Recién ahora: compromisos

Los descuentos por compromiso se firman al final, no al principio. Si comprás un año de capacidad y después apagás la mitad, pagaste por aire. El orden es: cerrar fugas, ajustar tamaños, medir un mes estable y entonces comprometer la base.

AWS

Compute Savings Plans a un año sin pago adelantado, cubriendo entre el 60 y el 70% del uso mínimo de los últimos 30 días (Cost Explorer calcula la recomendación). Son flexibles entre familias, regiones y hasta Fargate y Lambda. Reserved Instances solo para RDS y ElastiCache, donde no hay alternativa. Spot para lo que tolera interrupciones: colas, batch, CI.

GCP

Los descuentos por uso sostenido se aplican solos. Encima van los Committed Use Discounts: los basados en gasto (flexibles entre familias) para la capa general y los basados en recursos para lo que seguro no cambia. Spot VMs para cargas interrumpibles. El recomendador de CUDs en Billing te dice cuánto comprometer.

No hay compromisos ni Spot: el precio ya es el precio. Toda la optimización es tamaño correcto, apagado y limpieza. Es menos sofisticado y, para equipos chicos, muchas veces es la ventaja.

05 · Kubernetes

Un cluster convierte la factura en una caja negra: la nube te cobra nodos, pero vos despliegas pods. Para asignar costo a servicios hace falta algo que mida dentro del cluster. OpenCost (CNCF, gratis) o Kubecost cruzan el uso de cada namespace con el precio del nodo y te dan costo por servicio y por equipo. Es lo primero que se instala.

El desperdicio en Kubernetes casi siempre es la brecha entre requests y uso real: los pods reservan el doble de lo que consumen y el cluster escala nodos para sostener reservas vacías. La métrica a vigilar es la eficiencia de CPU y memoria por namespace (uso dividido por request); por debajo del 50% hay que ajustar. Para la capa de nodos, Karpenter en EKS elige el tamaño justo y consolida; GKE Autopilot directamente cobra por pod y elimina el problema; en DOKS, el autoscaler del node pool con un mínimo bajo y Spot no existe, así que la eficiencia de requests es todo lo que tenés.

06 · El proceso que hace que no vuelva

Una limpieza puntual recupera un 20 o 30% y a los seis meses el gasto volvió. Lo que lo sostiene es un ritual chico con dueños claros. Esto es lo que funciona en la práctica:

Semanal, 30 minutos. Anomalías de la semana, reporte de huérfanos y recursos sin etiqueta. Lo lee quien está de guardia. No se discute: se asigna.
En cada retro del equipo. El costo del servicio al lado de las métricas de producto. No en el cierre contable, un mes después, cuando nadie recuerda qué cambió.
Mensual, una hora. Los diez servicios más caros, la variación contra el mes anterior y una lista de acciones con nombre y fecha. Nunca más de cinco acciones.
Trimestral. Cobertura de compromisos (qué porcentaje del uso está cubierto y cuánto se desperdicia) y revisión de los umbrales.
El costo entra en el pull request. Infracost comenta en cada PR de Terraform cuánto cambia la factura mensual con ese cambio. Es la herramienta con mejor relación esfuerzo/resultado de toda la lista: el costo se discute antes de existir.

Y una métrica por encima de todas: el costo por unidad. Por transacción, por cliente activo, por pedido, lo que mida tu negocio. Un gasto que sube porque el negocio crece y uno que sube solo se ven idénticos en la factura total. Por unidad, no. Es el número que se le muestra a la dirección, y el que convierte a FinOps de «ahorro» en ingeniería.

Quien despliega, gasta. Quien gasta, tiene que ver el número. Todo el proceso existe para que eso pase.

07 · La primera semana

Si no hiciste nada de esto todavía, el orden importa. Esto es lo que haría en los primeros cinco días:

DÍA 1

Activar el export de billing (CUR o BigQuery) y las etiquetas de asignación. Definir las tres etiquetas obligatorias.

DÍA 2

Un presupuesto por equipo con alerta al 80%. Anomaly Detection encendido. Retención de logs fijada.

DÍA 3

Correr Trusted Advisor, Compute Optimizer o los Recommenders. Listar huérfanos. Borrar lo evidente, con snapshot.

DÍA 4

Horarios de apagado para todo lo no productivo. Infracost en el pipeline.

DÍA 5

Definir el costo por unidad y agendar el ritual semanal. Compromisos: recién en 30 días.

Nada de esto requiere comprar una herramienta. Las tres nubes incluyen lo necesario para ver, detectar y actuar; lo que suele faltar es el hábito de mirar. FinOps empieza ahí.