FinOps en AWS: la guía para auditar y recortar 30-40% de tu factura sin tocar el rendimiento

FinOps en AWS: la guía para auditar y recortar 30-40% de tu factura sin tocar el rendimiento

Cada vez que hacemos una auditoría seria a una cuenta de AWS de una empresa mexicana mediana, encontramos lo mismo: entre 30% y 40% de la factura es grasa. Instancias EC2 que llevan meses sin recibir tráfico, NAT Gateways pagando egress innecesario, snapshots de hace tres años que nadie reclama, RDS sobreaprovisionado, S3 sin lifecycle policies, ambientes de desarrollo prendidos los fines de semana.

La buena noticia es que el ahorro no requiere comprar nada nuevo. Requiere disciplina, un marco operativo y unas cuantas semanas de trabajo metódico. Compartimos el marco que aplicamos en ALCA, dividido en tres fases de 30 días.

Por qué FinOps importa ahora

Tres factores se sumaron en los últimos 18 meses:

  • Tipo de cambio: una factura USD pesa más en pesos.
  • IA generativa: el costo de inferencia y de almacenar embeddings se acumula rápido.
  • Crecimiento de servicios gestionados: cada equipo prende lo que necesita sin gobernanza central.

El resultado es que muchas empresas mexicanas pasaron de 5,000 USD mensuales a 25,000-50,000 USD en cosa de dos años, sin haber crecido en la misma proporción. FinOps deja de ser hobby de empresas grandes y pasa a ser higiene operativa para cualquiera con factura arriba de 5,000 USD al mes.

Día 1-15: inventario y tagging

Antes de cortar, hay que ver. La primera quincena es de levantamiento, no de acción.

Inventario:

  • Listar todas las cuentas AWS vinculadas (Organizations, accesos cruzados).
  • Exportar uso por servicio del último trimestre desde Cost Explorer.
  • Identificar el top 10 de servicios por costo. Casi siempre EC2, RDS, S3, Data Transfer, NAT Gateway y CloudWatch concentran el 80%.
  • Mapear propietarios de cada workload: equipo, producto, ambiente.

Tagging obligatorio:

Esto es la base de todo lo demás. Sin tags consistentes, no puedes asignar costos ni decidir qué apagar. Recomendamos un esquema mínimo:

  • Environment: prod, staging, dev, test
  • Team: el equipo dueño
  • Project: producto o iniciativa
  • CostCenter: centro de costo contable
  • ExpiresOn: fecha tentativa de baja (especialmente para entornos de prueba)

Activa Cost Allocation Tags en la consola y configura Tag Policies desde Organizations para que sea imposible crear recursos sin etiquetar.

Día 15-45: quick wins

Esta es la fase donde se ve dinero rápido. Casi todo se resuelve sin tocar arquitectura.

EC2 huérfanas y rightsizing:

  • Identificar instancias con CPU promedio menor al 5% durante 30 días. Casi siempre se pueden apagar o downsizear.
  • Revisar EBS volumes no asociados y snapshots viejos.
  • Migrar de instancias previa generación a actual (m5 a m7i, por ejemplo). Mismo costo, más rendimiento.

RDS:

  • Reducir tamaño de instancias en ambientes que no son producción.
  • Activar scheduled stop/start para RDS de desarrollo (apagar fin de semana).
  • Revisar storage allocado vs usado. Bajar storage allocado donde sobre.

S3:

  • Configurar lifecycle policies: pasar a Standard-IA después de 30 días, Glacier después de 90, eliminar después de N días.
  • Intelligent-Tiering para buckets grandes con patrones impredecibles.
  • Eliminar multipart uploads incompletos (regla de lifecycle de 7 días).

NAT Gateway:

Este es el silencioso. Muchas empresas pagan miles de dólares en NAT Gateway por egress de servicios que podrían usar VPC Endpoints (gratis o muy baratos para S3, DynamoDB, ECR, Secrets Manager). Auditar tráfico que sale por NAT y mover a endpoints suele recortar 20-30% del costo de Data Transfer.

Ambientes no productivos:

Implementar AWS Instance Scheduler o un script de Lambda que apague EC2 y RDS de dev/staging fuera de horario laboral. Un dev environment apagado 16 horas al día y todos los fines de semana cuesta 30% de lo que cuesta prendido siempre.

Día 45-90: arquitectura y compromisos

Una vez limpio el inventario y aplicados los quick wins, viene la parte estructural.

Reserved Instances y Savings Plans:

  • Para cargas estables (RDS, EC2 que sabes que van a estar mínimo un año), comprar Compute Savings Plans de 1 año, pago todo upfront si hay flujo, o sin upfront si no.
  • Empezar conservador: cubrir el 60-70% del baseline, no el 100%. Te deja flexibilidad.
  • Revisar trimestralmente y ajustar.

Spot Instances:

Para cargas tolerantes a interrupción (procesamiento batch, jobs CI/CD, training de modelos), Spot puede recortar hasta 70%. Combina bien con EKS y Fargate Spot.

Arquitectura:

Aquí entran decisiones más profundas:

  • Serverless donde aplique (Lambda + DynamoDB para cargas con picos). Pagas por uso, no por capacidad.
  • Caching agresivo con CloudFront, ElastiCache o DAX para reducir hits a backends caros.
  • Compresión en transit y at rest para bajar costos de Data Transfer y storage.
  • Multi-región solo donde aporta: muchas empresas replican sin necesidad real.

Herramientas que recomendamos

No necesitas comprar plataformas caras. El stack mínimo:

  • AWS Cost Explorer y Cost Anomaly Detection (gratis, ya viene).
  • AWS Compute Optimizer (gratis, recomendaciones automáticas).
  • Vantage o CloudHealth para visualización mejorada (de pago, vale para cuentas grandes).
  • Komiser o Infracost (open source, buenos para CI/CD y reportes).

Cómo crear cultura FinOps sin convertirte en el enemigo

El error clásico es que el equipo de finanzas o de plataforma quiere recortar y los equipos de producto sienten que les están frenando. La forma de evitarlo:

  1. Visibilidad antes que recorte. Dashboards de costo por equipo y producto, accesibles a todos.
  2. Metas conjuntas. No "recortar 30%" sino "mismo rendimiento con 30% menos costo".
  3. Showback antes que chargeback. Mostrar el costo a cada equipo antes de empezar a cobrarles internamente.
  4. Celebrar ahorros. Compartir wins, dar visibilidad a los equipos que optimizan.
  5. Integrar al ciclo de desarrollo. Estimación de costo en cada feature nuevo, no como auditoría posterior.

El objetivo no es ser el departamento que dice no. Es ser el departamento que da contexto financiero para que el equipo tome mejores decisiones técnicas.

Resultados esperados

Con este marco aplicado a 90 días, lo que vemos en empresas mexicanas medianas:

  • 15-25% de ahorro en los primeros 30 días (puro inventario y huérfanas).
  • 25-35% acumulado a 60 días (rightsizing, S3, ambientes no productivos).
  • 30-40% acumulado a 90 días (Savings Plans, arquitectura).

Y lo más importante: una vez instalada la disciplina, el ahorro se mantiene. No vuelves a la grasa anterior.


Descarga la plantilla: 90 días de FinOps. Mandamos el template de Excel con checklist por semana, queries SQL para Cost Explorer y plantillas de tagging. Solicítala aquí.

Artículos relacionados