FinOps está roto. No porque AWS no te dé los datos — Cost Explorer, Compute Optimizer, Trusted Advisor, Cost Optimization Hub — los datos están ahí. El problema es que nadie los abre.
Auditamos suficientes equipos de ingeniería como para reconocer el patrón. La revisión de FinOps sucede una vez al mes, después de que llega la factura, impulsada por un VP haciendo preguntas incómodas. Para entonces, lo que causó el spike tiene tres semanas de frío. Los engineers no entran a Cost Explorer de forma proactiva porque la interfaz está construida para finanzas, no para la persona que desplegó el servicio.
La brecha entre tener la información y actuar sobre ella — ese es el verdadero problema de FinOps. Así que construimos algo para cerrarla.
Lo Que Lanzamos: Una Interfaz de Chat para tu Cuenta AWS
La FinOps Intelligence Platform es un agente basado en Claude con acceso de solo lectura a tu cuenta AWS. Abrís un browser, escribís una pregunta en castellano, y obtenés una respuesta con números reales de tu cuenta real — en aproximadamente diez segundos.
Preguntas como:
- "¿Cuál es mi mayor costo esta semana y por qué?"
- "¿Cuánto estoy pagando por NAT Gateway en todas las regiones?"
- "¿Qué instancias EC2 están sobredimensionadas y cuánto ahorraría al right-sizearlas?"
- "¿Qué anomalías aparecieron en los últimos 30 días?"
- "¿Qué equipo está gastando más, desglosado por tag de environment?"
El agente se conecta a Cost Explorer, Compute Optimizer, Cost Optimization Hub y las APIs de EC2/RDS. Correlaciona datos entre servicios y responde con números concretos y recomendaciones accionables — no resúmenes de alto nivel, no rangos de porcentajes, montos en dólares reales atados a recursos específicos.
El código es open source: github.com/devops-arg/finops-agent — licencia MIT, backend Python, frontend JS vanilla, docker-compose para levantarlo.
Un Tour Rápido del Producto
Seis pantallas hacen todo el trabajo. Todas las capturas de abajo usan el perfil mock de la fintech ficticia "Ribbon" que viene en modo demo — no hay data real de AWS, safe para mostrar en cualquier contexto.
1. Preguntá en castellano
Tipeás una pregunta, obtenés una respuesta estructurada con números reales en ~10 segundos. El panel de la derecha streamea el reasoning trace en vivo — ves cada tool call que hace el agente antes de sintetizar la respuesta final.
2. Andá a fondo con preguntas en capas
Las preguntas multi-capa disparan múltiples rounds de tools. Preguntá "¿cuánto tráfico está fluyendo cross-AZ a través de NAT Gateway en lugar de quedarse intra-AZ?" y el agente cuantifica el impacto, calcula el ahorro mensual del fix concreto (endpoints de PrivateLink), y te muestra el trabajo — sin que saltes entre cinco tabs de Cost Explorer.
3. Dashboard de Cost Overview
La landing del tab dashboard: gasto de los últimos 7 días, proyección mensual, total de savings identificados, count de servicios activos, chart de trend de 4 semanas, donut de breakdown por servicio, y las últimas anomalías de costo detectadas por AWS.
4. Breakdown de servicios
Cada servicio AWS activo con última-semana / esta-semana / proyección mensual, más un sparkline de 4 semanas. Click en un servicio y se abre una sesión de chat filtrada sobre esa sola línea de costo.
5. Estado de infraestructura en vivo
Cards de EC2, RDS, EKS, ElastiCache, OpenSearch y S3 con costo mensual e indicador de salud. Los warnings son específicos: "Primary al 80% CPU, candidato a downsize", "6 buckets sin lifecycle policies — Intelligent-Tiering auto-mueve cold data". Cambiás entre una región específica y todas las regiones en paralelo desde un dropdown.
6. Recomendaciones de optimización
Resultados de Cost Optimization Hub rankeados por savings mensuales. Cada card tiene el cambio, el ahorro estimado, un tag de dificultad, y un botón Ask AI → que abre el chat pre-cargado con esa recomendación como contexto — así podés preguntar "¿por qué esa clase de instancia específica?" antes de ejecutar.
Lo Que el Agente Sabe Responder
La barra lateral viene con 27 queries pre-construidas organizadas por categoría. Acá hay una muestra de cada una:
Networking
NAT Gateway es el costo oculto más común que encontramos en las auditorías de AWS. Los equipos pagan el fee de data processing ($0.045/GB) por cada byte que sus pods mandan a través de NAT para llegar a S3, ECR, STS o CloudWatch — y no tienen idea. El agente sabe cómo desarmarlo:
Query: "¿Cuánto tráfico cross-AZ está pasando por NAT Gateway, y qué VPC endpoints me están faltando?"
El agente consulta Cost Explorer para los ítems de línea de NAT Gateway por VPC, correlaciona contra la cobertura de VPC endpoints, y devuelve algo así:
| Problema | Costo mensual | Solución | Ahorro estimado |
|---|---|---|---|
| Image pulls de ECR via NAT | $420/mes | ECR VPC endpoint | $400/mes |
| Transferencias S3 via NAT | $310/mes | S3 gateway endpoint (gratis) | $310/mes |
| CloudWatch via NAT | $180/mes | CloudWatch interface endpoint | $170/mes |
| Tráfico cross-AZ (us-east-1a → 1b) | $290/mes | Topology-aware routing | $200/mes |
Compute
Query: "¿Qué instancias EC2 puedo migrar a Graviton, y cuánto ahorraría por mes?"
El agente lee de Compute Optimizer y Cost Optimization Hub — el servicio de AWS que unifica recomendaciones de Compute Optimizer, Trusted Advisor y el motor de RI/SP. Cada recomendación viene con un monto de ahorro concreto que AWS ya calculó:
Oportunidades de migración a Graviton:
m5.2xlarge (api-server, us-east-1) → m7g.2xlarge ahorra $87/mes
c5.xlarge (worker-pool, eu-west-1) → c7g.xlarge ahorra $54/mes
r5.large (analytics, us-east-1) → r7g.large ahorra $41/mes
Total de ahorros posibles: $182/mes ($2.184/año)
Riesgo de migración: BAJO (workloads stateless, imágenes ARM64 disponibles)
Commitments
Query: "¿Cuánto ahorraría con un Savings Plan de 1 año basado en mi uso actual?"
El agente extrae tu cobertura de Savings Plans de Cost Explorer y corre la recomendación contra tu patrón real de gasto On-Demand. Desglosa el monto del commitment, el porcentaje de cobertura y el ahorro neto esperado — no como un rango, sino como un número real de tu cuenta.
Detección de Anomalías
Query: "¿Qué anomalías de costo ocurrieron en los últimos 30 días y cuál fue la causa?"
El motor de detección de anomalías de Cost Explorer marca eventos de gasto, pero no los explica. El agente lee los registros de anomalías, correlaciona el timestamp contra el historial de deploys (via CloudTrail) y propone una causa probable:
Anomalía detectada: EKS compute +$1.840 del 22 al 24 de marzo
Línea de tiempo:
- 14:32 UTC: Nuevo node group agregado (production-ml-workloads)
- Capacidad máxima del node group seteada a 20 nodos (era 5)
- Auto-scaling disparado el 22 de marzo a las 14:45 UTC
- 47 nodos m5.4xlarge corrieron por ~48h
Causa probable: cambio de max capacity sin HPA limits correspondientes.
Recomendación: setear maxReplicas explícito en los deployments de ML,
revisar las políticas de scaling del node group.
Atribución por Tags
Query: "¿Qué equipo está gastando más este mes, desglosado por environment?"
Esta solo funciona si el tagging es consistente, pero cuando lo es, es la pregunta que cambia el comportamiento más rápido. Cuando el equipo de payment-service ve su nombre en la barra más cara del gráfico, empieza a preocuparse por los costos de una manera que ningún documento de política jamás logró.
Por Qué Es Seguro: IAM Read-Only por Diseño
Lo primero que ejecutás al configurar la plataforma es create-read-only.sh. Tarda unos 30 segundos y hace tres cosas:
# Lo que hace create-read-only.sh (simplificado)
# 1. Crear usuario IAM con ReadOnlyAccess administrada por AWS
aws iam create-user --user-name finops-agent-readonly --profile $ADMIN_PROFILE
aws iam attach-user-policy \
--user-name finops-agent-readonly \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess \
--profile $ADMIN_PROFILE
# 2. Generar y guardar access keys
KEYS=$(aws iam create-access-key \
--user-name finops-agent-readonly \
--profile $ADMIN_PROFILE)
echo "AWS_ACCESS_KEY_ID=$(echo $KEYS | jq -r .AccessKey.AccessKeyId)" >> .env
echo "AWS_SECRET_ACCESS_KEY=$(echo $KEYS | jq -r .AccessKey.SecretAccessKey)" >> .env
# 3. Verificar que el agente NO PUEDA escribir — espera 403
RESULT=$(aws s3 mb s3://finops-readonly-verify-$(date +%s) \
--profile finops-agent-readonly 2>&1)
if echo "$RESULT" | grep -q "AccessDenied"; then
echo "✓ Read-only verificado. El agente no puede escribir en tu cuenta."
else
echo "✗ Setup fallido. Se esperaba 403, se obtuvo: $RESULT"
exit 1
fiEl usuario IAM obtiene ReadOnlyAccess — una política administrada por AWS que otorga Describe*, List*, Get* y los métodos de lectura de las APIs de billing. Deniega explícitamente toda acción mutante. El paso de verificación no es opcional. Si el comando s3 mb no devuelve un 403, el script sale con error y no escribe las credenciales en .env.
El agente nunca ve credenciales de admin. Se conecta a tu cuenta únicamente a través de las keys creadas por este script.
Multi-Región: Porque tus Costos No Viven en un Solo Lugar
Un error común en las herramientas de FinOps caseras es escanear solo us-east-1. Cost Explorer te da totales globales, pero si querés saber cuáles instancias EC2 en eu-west-2 están sobredimensionadas, necesitás llamar a la API de EC2 en esa región.
La plataforma escanea las 18 regiones AWS activas en paralelo cuando responde preguntas de compute y base de datos:
const ACTIVE_REGIONS = [
'us-east-1', 'us-east-2', 'us-west-1', 'us-west-2',
'eu-west-1', 'eu-west-2', 'eu-west-3', 'eu-central-1',
'eu-north-1', 'ap-southeast-1', 'ap-southeast-2',
'ap-northeast-1', 'ap-northeast-2', 'ap-northeast-3',
'ap-south-1', 'ca-central-1', 'sa-east-1', 'me-south-1'
];
// Todas las regiones consultadas en paralelo — tiempo de scan típicamente menor a 8 segundos
const regionalData = await Promise.all(
ACTIVE_REGIONS.map(region => scanRegion(region, credentials))
);Esto importa sobre todo para los equipos que fueron expandiendo regiones con el tiempo y nunca volvieron a revisarlas. Regularmente encontramos instancias EC2 olvidadas, snapshots de RDS ociosos y volúmenes EBS huérfanos en regiones que se usaron para un proyecto hace dieciocho meses.
Modo Demo: Seguro para Screencasts y Pitches
No toda conversación sobre costos debería ocurrir contra una cuenta en vivo. Para demos, llamadas de onboarding y pitches internos, USE_MOCK_DATA=true en .env carga una cuenta AWS ficticia llamada Ribbon — una fintech con patrones de gasto representativos en EC2, RDS, networking y servicios administrados.
Las 27 queries funcionan de forma idéntica en modo demo. Los números son representativos de un startup real en etapa intermedia. Sin credenciales AWS reales involucradas, sin riesgo de exponer la estructura de tu cuenta durante una pantalla compartida.
Bajo el Capot: Reasoning Multi-Round
La mayoría de las demos de "chat con tu data" usan una sola llamada al LLM y cruzan los dedos. Las preguntas de FinOps son en capas, así que armamos un loop agéntico multi-round con reflexión. El panel de trace a la derecha del chat lo hace visible — ves exactamente qué está pensando el agente.
El engine:
- Recibe la query del usuario + 14 definiciones de tools
- Round 1: el LLM llama tools (típicamente
get_current_date→query_aws_costs) - Reflection: el engine pregunta "¿tenés suficiente data? Si no, ¿qué va después?"
- Rounds 2-4: tool calls adicionales (períodos de comparación, drill-downs, cross-references)
- Síntesis final como markdown estructurado
Hard cap en 4 rounds para controlar el costo. Si una tool devuelve nada, el agente lo dice explícitamente en vez de alucinar — esta es la pieza que la mayoría de las demos de LLMs se olvidan.
Cómo Empezar: Cuatro Comandos
git clone https://github.com/devops-arg/finops-agent
cd finops-agent
cp .env.example .env
# Seteá ANTHROPIC_API_KEY en .env, luego:
./create-read-only.sh tu-admin-profile # ~30 segundos
docker compose up --build
# Abrí http://localhost:3000La plataforma corre íntegramente en tu máquina. Tus credenciales AWS y tus datos de costos nunca salen de tu entorno — el agente corre en local, llama directamente a las APIs de AWS y a la API de Anthropic.
Cost Optimization Hub necesita estar habilitado en tu consola de AWS antes de que las queries de recomendaciones devuelvan datos (Billing → Cost Optimization Hub → Enable). Es gratis, tarda unos 30 segundos activarlo, y las recomendaciones tardan 24-48 horas en popularse por primera vez.
Resumen: Qué Cubre la Plataforma
| Categoría | Fuente de datos |
|---|---|
| NAT Gateway, VPC endpoints, cross-AZ traffic | Cost Explorer + EC2 API |
| Right-sizing, Graviton, Spot Fleet | Compute Optimizer + Cost Optimization Hub |
| Savings Plans, Reserved Instances | Cost Explorer |
| Anomalías + correlación con deploys | Cost Explorer + CloudTrail |
| Gasto por equipo y por environment | Cost Explorer (tags) |
| Recursos ociosos en las 18 regiones | EC2 + RDS APIs |
Qué Haríamos Diferente
Lanzar primero la capa de lenguaje natural, no las queries pre-construidas. Construimos 27 queries específicas antes de terminar el chat libre, y las lanzamos como la interfaz principal. En la práctica, los usuarios inmediatamente empezaron a hacer preguntas que no habíamos anticipado. El chat libre es donde está el valor real — las 27 queries son rueditas de entrenamiento.
Armar el timeline de anomalías antes. La query de detección de anomalías es la funcionalidad más sorprendente para los usuarios — nunca esperaban que el agente correlacionara un spike de gasto con un evento de deploy. Tendríamos que haberle dado mayor prioridad en el roadmap. La mayoría de las preguntas de seguimiento ("¿por qué subió mi factura el 22 de marzo?") vienen de eventos de anomalías más que de cualquier otro disparador.
Agregar caché para las llamadas a la API de Cost Explorer. Cost Explorer tiene un rate limit y no es gratis llamarlo con alta frecuencia ($0.01 por API request, con los primeros 100K gratis por cuenta por mes). Durante el desarrollo quemamos el free tier rápido. La solución es directa — cachear las respuestas de Cost Explorer por 4-6 horas ya que los datos no cambian más rápido que eso — pero tendríamos que haberlo construido desde el arranque.
Si querés conectar la FinOps Intelligence Platform a tu cuenta, o si necesitás una versión custom integrada con tu modelo de tagging interno, hablemos — lo dejamos funcionando en una tarde.