Una startup SaaS B2B con 3.000 clientes activos y un equipo de 20 personas llevaba dos años creciendo sin prestar demasiada atención a la factura de AWS. Cuando eran pequeños, la factura era asumible. Pero el crecimiento del producto y de la base de clientes había llevado el gasto mensual a 45.000 dólares, y la tendencia era claramente ascendente.
El CTO sabía que estaban pagando de más, pero no sabía exactamente cuánto ni dónde. No tenían etiquetas de coste en los recursos, no usaban herramientas de monitorización de gastos y nunca habían contratado Reserved Instances ni Savings Plans. La infraestructura se había construido reactivamente: cada vez que algo era lento, se añadía una instancia más grande. Cada vez que faltaba espacio, se creaba un volumen más grande. Sin análisis. Sin limpieza.
El desafío
Factura creciente sin visibilidad
La factura de AWS crecía un 15% cada trimestre, significativamente por encima del crecimiento de ingresos (8% trimestral). A ese ritmo, el coste de infraestructura amenazaba con consumir los márgenes del negocio en 12-18 meses. Pero sin etiquetas de coste ni cost allocation, nadie podía señalar con precisión qué estaba generando el gasto.
Instancias sobredimensionadas
El equipo de infraestructura (una persona a tiempo parcial) seguía una regla no escrita: ante cualquier problema de rendimiento, escalar hacia arriba. Instancias EC2 con 64 GB de RAM para servicios que consumían 8 GB. Instancias RDS con provisión de IOPS que nunca se aprovechaban. El resultado era una infraestructura con un 70% de capacidad inutilizada.
Recursos huérfanos
Dos años de desarrollo significaban dos años de recursos olvidados: volúmenes EBS de instancias EC2 que ya no existían, snapshots diarios que nadie había configurado para expirar, direcciones Elastic IP sin asociar, buckets S3 con datos de entornos de staging ya desmantelados, y load balancers que no apuntaban a ningún servicio activo.
Sin plan de ahorro
La startup nunca había explorado Reserved Instances, Savings Plans ni Spot Instances. Todo corría bajo precios on-demand, que son entre un 30% y un 60% más caros que las alternativas con compromiso. Para una factura de 45.000 dólares, eso representaba entre 13.500 y 27.000 dólares anuales de sobrecoste evitable.
Transferencia de datos sin optimizar
Los servicios se comunicaban entre sí a través de internet pública en lugar de usar endpoints VPC. Cada byte transferido entre servicios generaba costes de transferencia de datos que habrían sido gratuitos con la configuración correcta. La transferencia de datos representaba el 18% de la factura mensual.
La solución
Ejecutamos el proceso en tres fases: auditoría, optimización inmediata y rediseño sostenible. El objetivo no era simplemente recortar costes, sino construir una infraestructura que fuera más eficiente, más rápida y con mecanismos para mantener los costes controlados a largo plazo.
Fase 1: auditoría completa (semana 1)
Realizamos una auditoría exhaustiva de cada recurso AWS utilizando una combinación de AWS Cost Explorer, Trusted Advisor, Compute Optimizer y nuestras propias herramientas de análisis.
El resultado fue un informe de 47 páginas con cada recurso, su utilización real, su coste y nuestra recomendación. Clasificamos los hallazgos en tres categorías:
- Ahorro inmediato (sin riesgo): recursos huérfanos, instancias paradas que generan coste, snapshots expirados. Valor: $8.200 mensuales.
- Ahorro con right-sizing (riesgo bajo): instancias sobredimensionadas que podían reducirse sin impacto en rendimiento. Valor: $11.500 mensuales.
- Ahorro estructural (requiere rediseño): cambios de arquitectura para eliminar costes de transferencia de datos, adopción de Savings Plans y migración a servicios serverless. Valor: $7.300 mensuales.
Total identificado: $27.000 mensuales de ahorro potencial. El 60% de la factura.
Fase 2: optimización inmediata (semanas 2-3)
Empezamos por los ahorros sin riesgo porque generan confianza y financian el resto del proyecto.
Limpieza de recursos huérfanos. Eliminamos 23 volúmenes EBS sin instancia asociada, 340 snapshots que llevaban más de un año sin política de expiración, 7 Elastic IPs sin asociar, 3 load balancers sin targets y 2 buckets S3 de entornos de staging eliminados hacía meses. Ahorro: $8.200 al mes.
Right-sizing de instancias EC2. Utilizamos AWS Compute Optimizer para identificar las instancias cuyo uso real era inferior al 30% de su capacidad. Cada instancia se analizó individualmente: algunas se redujeron de tamaño, otras se migraron a instancias de generación más reciente (que ofrecen mejor rendimiento a menor precio) y tres se eliminaron al descubrir que ejecutaban servicios que ya no se usaban. Ahorro: $7.800 al mes.
Right-sizing de RDS. La instancia principal de PostgreSQL era una db.r5.4xlarge (128 GB RAM, 16 vCPU) con una utilización media de CPU del 12% y uso de memoria del 35%. La migramos a una db.r6g.2xlarge (64 GB RAM, 8 vCPU) basada en Graviton, que además ofrecía mejor rendimiento en las operaciones de lectura. Ahorro: $3.700 al mes.
Fase 3: rediseño sostenible (semanas 4-8)
Con los ahorros inmediatos materializados, abordamos los cambios estructurales que requerían más planificación.
VPC Endpoints para tráfico interno. Configuramos endpoints VPC para S3, DynamoDB y otros servicios AWS que los microservicios consumían frecuentemente. Todo el tráfico que antes salía por internet pública y generaba costes de transferencia de datos pasó a circular por la red interna de AWS sin coste adicional. Ahorro: $3.100 al mes.
Savings Plans con compromiso de 1 año. Analizamos el consumo estable de compute durante los últimos 6 meses y contratamos Compute Savings Plans con compromiso de 1 año para la baseline de consumo. Esto cubrió el 70% del consumo de EC2 y Fargate con un descuento del 35% sobre precios on-demand. Ahorro: $4.200 al mes.
Migración parcial a Fargate. Dos servicios que corrían en EC2 con escalado manual se migraron a ECS Fargate con auto-scaling. Esto no solo redujo el coste (Fargate escala a cero cuando no hay tráfico) sino que eliminó la necesidad de gestionar las instancias subyacentes.
Sistema de alertas y governance. Implementamos AWS Budgets con alertas en el 80%, 90% y 100% del presupuesto mensual. Configuramos etiquetas de coste obligatorias para cada recurso nuevo (equipo, entorno, servicio). Creamos un dashboard en CloudWatch con el coste diario por servicio visible para todo el equipo de ingeniería.
Resultados
Tras 8 semanas de trabajo:
- Factura AWS: de $45.000 a $18.000 mensuales. Una reducción del 60%, equivalente a $324.000 de ahorro anual.
- Tiempos de respuesta de la API: mejora del 40%. Las instancias de nueva generación (Graviton) y la eliminación de la latencia por tráfico a través de internet pública resultaron en mejoras de rendimiento significativas. Optimizar costes y mejorar rendimiento no son objetivos contradictorios.
- Cero downtime durante todo el proceso. Cada cambio se planificó, se ejecutó en horario de bajo tráfico y se monitorizó en tiempo real. Ningún cliente experimentó interrupciones.
- Sistema de governance activo. Las alertas de presupuesto, las etiquetas obligatorias y el dashboard de costes aseguran que los ahorros se mantengan en el tiempo.
- Capacidad liberada del equipo. La persona que dedicaba tiempo parcial a gestionar infraestructura manualmente pudo redirigir ese tiempo a tareas de mayor valor. La automatización redujo las tareas operativas manuales en un 70%.
Lecciones aprendidas
La auditoría es la mejor inversión con la que empezar
Antes de la auditoría, el CTO estimaba que estaban desperdiciando “un 20%, quizá 25%” de la factura. La realidad era un 60%. Sin datos precisos, las decisiones de optimización son adivinanzas. La auditoría se amortiza en el primer mes con los ahorros inmediatos.
Los recursos huérfanos se acumulan silenciosamente
Nadie crea un volumen EBS huérfano a propósito. Pero sin un proceso de limpieza periódica, cada sprint deja residuos: una instancia de prueba que se para pero no se elimina, un snapshot que se crea “por si acaso” y nunca se borra, un load balancer de una demo que se olvida. En dos años, esos residuos sumaban 8.200 dólares al mes.
Right-sizing no es recortar, es ajustar
La reacción instintiva ante la palabra “optimización” es pensar en recortar recursos y aceptar peor rendimiento. En la práctica, el right-sizing frecuentemente mejora el rendimiento: instancias de generación reciente son más rápidas y más baratas que las anteriores. No se trata de pagar menos por lo mismo. Se trata de pagar menos por algo mejor.
La governance de costes debe ser automática
Las optimizaciones puntuales se degradan con el tiempo si no hay mecanismos automáticos que las mantengan. Un equipo que optimiza su infraestructura una vez al año pierde el 30% de los ahorros en los 12 meses siguientes. Las alertas, las etiquetas obligatorias y los dashboards visibles convierten la optimización en un hábito, no en un evento.
Si tu factura de AWS crece más rápido que tu negocio, o si no tienes visibilidad de dónde va cada euro, podemos ayudarte. Solicita una auditoría gratuita y en una semana sabrás exactamente cuánto puedes ahorrar.