¿Cómo bajé 30% el costo de infraestructura AWS de un SaaS sin tocar el uptime?
Como Head of Tech de Vexels —plataforma global de diseño con +500k usuarios y millones de requests al mes— mi trabajo abarca arquitectura, equipo y las decisiones técnicas del producto. Pero acá quiero contar un proyecto puntual dentro de ese rol, porque ilustra una idea que me importa: un −30% en costos de infraestructura suena a logro de DevOps, pero presentado bien es un argumento de negocio. Cada punto de gasto que sacás de AWS sin romper nada es margen que vuelve al producto. Bajé ese gasto un 30% manteniendo 99.9% de uptime durante toda la migración — y este post es cómo se estructura un trabajo de FinOps para que el ahorro sea defendible y, sobre todo, qué habilitó para el negocio.
FinOps no es "gastar menos en AWS". Es decidir, con datos, dónde el gasto compra crecimiento y dónde solo compra recursos ociosos.
¿Qué es FinOps y en qué se diferencia de "bajar la factura"?
Bajar la factura es un evento: apagás algo, ahorrás un mes. FinOps es una disciplina: instrumentás el costo como instrumentás el performance, lo atás a unidades de negocio (costo por request, costo por usuario activo) y tomás decisiones recurrentes con ese dato. La diferencia práctica es que un recorte ciego se nota en el próximo incidente; un trabajo de FinOps deja el sistema más barato y igual de confiable.
El marco que sigo tiene cuatro pasos, y es el mismo con el que estructuro cualquier caso: baseline → intervención → resultado → impacto de negocio.
1. Baseline: ¿cuánto cuesta y por qué?
No se optimiza lo que no se mide. El primer trabajo no es tocar nada, es entender la forma del gasto:
- Costo por unidad de negocio, no total. "Gastamos X al mes" no dice nada; "gastamos Y por cada 1.000 requests" sí, porque te dice si escalar es rentable o te está fundiendo.
- Dónde está el gasto ocioso. Recursos sobredimensionados, instancias prendidas sin tráfico, entornos de staging que nadie apagó, almacenamiento que ya nadie lee.
- El patrón de carga real. Picos, valles, qué es predecible y qué es bursty. Esto define qué conviene reservar y qué conviene que escale solo.
En Vexels el baseline mostró lo de siempre: una parte grande del gasto no estaba comprando crecimiento, estaba comprando capacidad ociosa reservada "por las dudas".
2. Intervención: las palancas, ordenadas por riesgo
Acá está la clave de hacerlo sin tocar el uptime: se mueve de menor a mayor riesgo, midiendo después de cada paso. Las palancas que apliqué:
- Rightsizing. Achicar lo sobredimensionado al tamaño que el tráfico real pide. Es el ahorro más grande y el de menor riesgo: nadie nota que una instancia pasó de holgada a ajustada si los números de carga lo respaldan.
- Limpieza de recursos ociosos. Apagar lo que está prendido sin trabajo: entornos zombi, volúmenes huérfanos, snapshots viejos. Cero impacto en producción, ahorro inmediato.
- Migración a ECS + Lambda según el patrón de carga. Las cargas constantes viven mejor en contenedores (ECS); las bursty o event-driven, en Lambda, donde no pagás por el idle. Mover cada workload al modelo que matchea su patrón es lo que más mejora el costo por request. (Cuándo conviene cada uno lo desgloso acá.)
- Autoscaling preciso. Ajustar las políticas para que la capacidad siga a la demanda de verdad, en vez de reaccionar tarde y dejar headroom caro "por seguridad".
Cada cambio se valida contra los Core Web Vitals y los SLOs antes del siguiente. Si algo degrada latencia o error rate, se revierte. Por eso el 99.9% no se movió.
3. Resultado: los números
Costo de infra por mes — índice base 100 (el delta es real; el monto absoluto no es público). p95 estable y 99.9% de uptime mantenidos durante toda la migración.
- −30% de gasto mensual de infraestructura.
- 99.9% de uptime mantenido durante toda la migración.
- Millones de requests/mes procesados sin degradación de latencia.
- Costo por request a la baja, que es la métrica que importa: ahora escalar cuesta menos por cada usuario nuevo.
El último punto es el que convierte un recorte en una ventaja estructural: no es que gastamos menos una vez, es que crecer se volvió más barato.
4. Impacto de negocio: ¿para qué sirvió ese 30%?
Esta es la pregunta que un founder hace y que un reporte técnico casi nunca responde. El ahorro de infra no es el objetivo, es el medio. Un −30% sostenido es margen que deja de irse en servidores ociosos y puede financiar lo que sí mueve la aguja: más runway, una contratación, una feature que estaba trabada por presupuesto. Reliability y costo no compiten con el crecimiento: lo financian.
El vocabulario que conviene usar (y entender)
Si vas a hablar de esto con un técnico o defenderlo ante un board, estos son los términos 2026 que ordenan la conversación:
| Término | Qué significa en la práctica |
|---|---|
| Cost per request / per user | El costo unitario real. La única métrica que dice si escalar es rentable. |
| Idle compute | Capacidad que pagás sin que haga trabajo. El primer lugar donde buscar. |
| Rightsizing | Ajustar el recurso al tamaño que el tráfico real pide, ni más ni menos. |
| Commitment / Savings Plans | Comprometer uso predecible a cambio de descuento. Aplica a la carga base, no a la bursty. |
| Anomaly detection | Alertas sobre saltos de gasto inesperados — un bug de costo se detecta como un bug de performance. |
La lección de growth
Un SaaS que gasta el doble de lo necesario en infra tiene la mitad del oxígeno para crecer. Hacer FinOps en serio —baseline honesto, intervención por riesgo, resultado medido y atado al negocio— es trabajo de Growth Engineering tanto como optimizar un funnel. La diferencia es que este ahorro no se ve en el producto: se ve en cuánto más lejos llega cada dólar que entra.
¿Tenés la sensación de que tu factura de AWS crece más rápido que tus ingresos? Es exactamente el síntoma con el que empieza un Growth Audit. Escribime y lo miramos.