AWS Savings Plans: estrategia para no perder plata
La AWS Savings Plan estrategia correcta no es una compra sino una decisión de portafolio que se revisa constantemente. Según un análisis publicado en mayo de 2026, los equipos que mal calibran sus compromisos en solo un 15% sobre una factura de USD 2M/mes pierden o desperdician USD 180.000 mensuales, un swing de USD 2,16 millones en un año.
En 30 segundos
- Los Compute Savings Plans dan hasta 66% de descuento sobre EC2, Fargate y Lambda y son el punto de partida por su flexibilidad.
- Los EC2 Instance Plans llegan a 72% de descuento pero te atan a una familia de instancias y región específica.
- Solo tres variables determinan el resultado: qué tipo comprás, cuánto compromiso asumís, y cuándo lo hacés.
- El error más común es tratar la compra como un evento único en vez de una gestión continua de portafolio.
- Renovar 60-90 días antes del vencimiento evita la caída automática a precios on-demand.
Por qué la mayoría de los equipos la está pifiando
Un AWS Savings Plan es un modelo de precios que te ofrece descuentos a cambio de comprometerte a un gasto horario mínimo durante 1 o 3 años. Existen tres variantes: Compute (cubre EC2, Fargate y Lambda con hasta 66% de descuento), EC2 Instance (hasta 72% pero atado a familia e instancia específica), y Database (20-35% sobre RDS, ElastiCache y DocumentDB).
Ahora bien, el problema no es no conocer los planes. El problema es que casi todos los equipos los tratan como una compra anual de la que nadie se acuerda hasta que vence. Y ahí es donde se pierden 10 a 20 puntos porcentuales de ahorro realizado, según el análisis publicado en mayo de 2026.
Hay dos fallas simétricas. Over-commit: comprás demasiado, tu workload decrece o migra, y pagás un compromiso que nadie está usando. Under-commit: comprás poco, tu baseline predecible sigue corriendo a precio on-demand cuando podría estar descontado. Los dos errores cuestan plata real.
Los 3 tipos de Savings Plans: cuál va para qué
| Tipo | Descuento máximo | Servicios cubiertos | Flexibilidad | Mejor para |
|---|---|---|---|---|
| Compute Savings Plan | Hasta 66% | EC2, Fargate, Lambda | Alta (cambiás familia, región, OS) | Base del portafolio, workloads que evolucionan |
| EC2 Instance Plan | Hasta 72% | EC2 (familia+región fija) | Baja (atado a instancia específica) | Apps legacy estables, instancias predecibles |
| Database Savings Plan | 20-35% | RDS, ElastiCache, DocumentDB | Media | Bases de datos sobredimensionadas y estables |
El 6% de diferencia entre Compute (66%) y EC2 Instance (72%) puede sonar tentador, pero ese descuento extra te cuesta flexibilidad total. Si tu equipo decide en seis meses migrar de m5.xlarge a m6i o pasarse a Graviton, el EC2 Instance Plan no te sigue. El Compute Plan sí.
Las 3 variables que controlan el resultado
Ponele que tenés una factura de AWS de USD 2M/mes y el 60% del gasto es elegible para Savings Plans. Eso es USD 1,2M/mes en juego. Errar el commitment level en un 15% en cualquier dirección significa USD 180.000 mensuales en compromisos desperdiciados o en ahorros no realizados.
Tres variables controlan el 95% del resultado:
- Tipo de plan: qué tan atado querés estar a una arquitectura específica.
- Sizing del commitment: cuánto de tu baseline real comprometés por hora.
- Timing de compra: cuándo comprás y cómo secuenciás las renovaciones.
No hay una cuarta variable que “desempate”. Si acertás en estas tres, el ahorro se produce. Si fallás en una, las otras dos no lo compensan.
Estrategia en capas: cómo construir el portafolio
La secuencia que recomienda el análisis es empezar siempre por Compute Savings Plans. Máxima flexibilidad, cobertura más amplia, y absorbe los shifts entre familias de instancias y servicios sin requerir ajustes. Es la base.
La proporción recomendada: comprometés entre el 60% y el 70% de tu spend baseline (el que corre 24/7 y que no va a desaparecer) con Savings Plans. El otro 20-30% lo dejás en on-demand para absorber estacionalidad y picos imprevistos. Si cubrís el 100% con compromisos, te quedás sin margen cuando llega el pico de diciembre o la campaña que nadie anticipó.
¿Y qué pasa si tenés workloads muy distintos? Ahí viene el segundo layer. Sobre la base de Compute, podés agregar EC2 Instance Plans solo para las instancias que sabés que no van a cambiar en el año. Una app legacy que lleva tres años corriendo en r5.2xlarge en us-east-1 y que nadie va a tocar es candidata. Pero ojo con esto: si hay aunque sea un 20% de chances de que migren o redimensionen, no vale el riesgo del lock-in por 6% adicional de descuento.
Cómo calcular el commitment correcto sin sobrepasarte
La herramienta de base es AWS Cost Explorer. AWS tiene una sección de recomendaciones de Savings Plans que analiza el historial de uso y te sugiere un commitment horario. El problema es que esas recomendaciones son agresivas por defecto: asumen que el pasado se repite.
El proceso manual que funciona mejor:
- Mirá los últimos 90 días de uso horario en Cost Explorer, no el promedio mensual. Los promedios esconden picos.
- Identificá tu “piso real”: cuál es el mínimo de uso sostenido en las últimas 8 semanas, sin picos.
- Comprometés el 80-85% de ese piso. El 15-20% restante del baseline lo dejás como buffer.
- Proyectá crecimiento o decrecimiento orgánico de los próximos 12 meses con el equipo de ingeniería, no solo con finanzas.
El error que te van a contar si preguntás en cualquier equipo de plataforma: compraron basados en el pico del mes anterior (campaña, lanzamiento, evento), asumieron que era el nuevo baseline, y terminaron con un over-commit del 40% por doce meses.
Otro error clásico: no actualizar el modelo cuando hay cambios tecnológicos. Si el equipo está migrando a serverless o a contenedores, el perfil de uso de EC2 va a caer. Un commitment calculado sobre la arquitectura vieja va a sobrar cuando la nueva tome volumen (spoiler: ese proceso suele tardar más de lo planeado, pero igual pasa).
Timing de compra y renovación: lo que nadie documenta bien
La renovación es donde se pierde más plata de forma silenciosa. Un Savings Plan que vence un martes a las 3 AM y que nadie renovó vuelve automáticamente a precios on-demand. Nadie lo nota hasta que llega la factura del mes. Cubrimos ese tema en detalle en estrategias comprobadas para optimizar costos cloud.
La regla es renovar 60 a 90 días antes del vencimiento. Ese tiempo alcanza para revisar si el commitment actual sigue siendo correcto, ajustar el tamaño si hubo cambios en el workload, y hacer la compra sin apuro.
Lo que tampoco ve mucha gente: si todos tus plans vencen el mismo mes, tenés un problema de concentración. Una renegociación fallida o un cambio de arquitectura mal timed te deja sin cobertura en todo el portafolio al mismo tiempo. Lo ideal es escalonar los vencimientos deliberadamente cuando hacés compras nuevas, para que nunca más del 30-40% del portafolio expire en el mismo trimestre.
Comprás en períodos de estabilidad, no en medio de una migración. Si el equipo está en plena transición a Kubernetes o evaluando mover cargas a Fargate, esperás. Un Savings Plan comprado sobre una arquitectura que va a cambiar en tres meses es un compromiso que va a sobrar.
Casos concretos: dónde se pierden más ahorros
Startups en crecimiento acelerado
Startup con factura de USD 50.000/mes en EC2 que creció 3x en 18 meses. Compraron EC2 Instance Plans sobre las instancias del momento. Seis meses después necesitaron instancias más grandes, la familia cambió, y el plan no cubría nada relevante. El Compute Plan hubiera seguido la migración automáticamente. Lección: cuando el crecimiento es incierto, la flexibilidad del Compute Plan vale más que el 6% extra del EC2 Instance Plan.
Apps legacy con bases de datos sobredimensionadas
Empresa con un RDS PostgreSQL que lleva cinco años corriendo en db.r5.4xlarge porque “en algún momento vamos a necesitarlo”. Nunca lo necesitaron. El Database Savings Plan con un 25-30% de descuento sobre ese gasto fijo y predecible es un ahorro directo sin ningún riesgo. El sobredimensionamiento es un problema separado (y sí, habría que reducir la instancia), pero mientras tanto el descuento existe y no costaba nada aprovecharlo.
Spikes estacionales: el error de cubrir el pico
E-commerce que tiene un tráfico 4x en noviembre-diciembre. Calcularon el commitment basándose en el Q4. Los primeros nueve meses del año pagaron un over-commit de 75%. La estrategia correcta era cubrir el baseline de los meses normales con Savings Plans y dejar el volumen de Q4 en on-demand o Spot donde sea posible. El ahorro neto del año hubiera sido mayor.
Qué significa esto para equipos en Latinoamérica
El impacto de una mala estrategia de Savings Plans es proporcionalmente más alto en equipos con presupuestos ajustados. Si tu empresa tiene una factura de AWS de USD 30.000/mes y podés pasar del 25% de savings al 45% de savings con una estrategia mejor calibrada, estás hablando de USD 6.000/mes de diferencia, USD 72.000/año. No es el USD 2,16M del ejemplo grande, pero para la mayoría de los equipos de la región es presupuesto real.
Para los equipos que también usan infraestructura local o híbrida, o que tienen su stack web en proveedores locales como donweb.com, la gestión de Savings Plans aplica específicamente a la parte cloud de AWS y conviene tratarla como un bloque separado del gasto total de infraestructura.
Errores comunes que cuestan plata real
- Comprar sobre el promedio mensual en vez del piso real: los promedios incluyen picos que no se repiten. Mirá el mínimo sostenido de las últimas 8 semanas.
- Usar solo EC2 Instance Plans por el descuento mayor: el 6% adicional no justifica perder la capacidad de mover workloads entre familias o servicios sin perder cobertura.
- No escalonar vencimientos: si todo vence el mismo mes, una distracción operativa puede dejarte sin cobertura en todo el portafolio simultáneamente.
- Ignorar los Database Savings Plans: muchos equipos optimizan EC2 y dejan RDS en on-demand cuando hay bases de datos predecibles que califican para 20-35% de descuento.
- No revisar el commitment cuando cambia la arquitectura: una migración a serverless o contenedores cambia el perfil de uso. El commitment calculado sobre la arquitectura vieja sobra cuando la nueva toma volumen.
Preguntas Frecuentes
¿Cómo reduzco costos en AWS sin perder flexibilidad?
Empezá por Compute Savings Plans, que cubren EC2, Fargate y Lambda con hasta 66% de descuento y te permiten cambiar de familia de instancias, región y OS sin perder el descuento. Comprometés el 60-70% de tu baseline real y dejás el resto en on-demand para absorber variabilidad. Esa combinación da ahorros significativos sin atarte a una arquitectura específica.
¿Cuánto commitment debo asumir en un Savings Plan?
Calculá tu “piso real” mirando el uso horario mínimo sostenido de las últimas 8 semanas en AWS Cost Explorer, y comprometés entre el 80% y el 85% de ese valor. Nunca uses el promedio mensual porque incluye picos que inflan el número. La documentación oficial de AWS tiene una herramienta de recomendaciones, pero tomala como punto de partida, no como número final.
¿AWS Savings Plan o instancias reservadas: cuál es mejor?
Para la mayoría de los casos en 2026, los Savings Plans son la opción preferida porque ofrecen descuentos comparables con mayor flexibilidad. Las instancias reservadas siguen teniendo sentido para casos muy específicos como bases de datos en RDS con configuraciones fijas de larga duración, o cuando necesitás reserva de capacidad garantizada en una zona de disponibilidad. Si tu arquitectura evoluciona o tenés diversidad de servicios, los Savings Plans ganan.
¿Qué pasa si mi workload cambia después de comprar el Savings Plan?
Los Savings Plans no se pueden cancelar ni modificar una vez comprados. Si el workload cambia y el plan queda sobredimensionado, seguís pagando el commitment aunque no lo uses completamente. Por eso el sizing conservador (80-85% del piso real) y el uso de Compute Plans en vez de EC2 Instance Plans son las mejores coberturas contra ese riesgo. El Compute Plan al menos sigue siendo aplicable aunque cambies de familia de instancias o muevas cargas a Fargate.
¿Cuándo debo renovar un Savings Plan que está por vencer?
Iniciá el proceso de renovación 60 a 90 días antes del vencimiento. Ese tiempo te permite revisar si el commitment actual sigue siendo correcto, ajustar el sizing si el workload cambió, y hacer la compra sin apuro. Un plan que vence sin renovar cae automáticamente a precios on-demand, y si nadie lo nota hasta la factura del mes siguiente, el costo es real e irrecuperable.
Conclusión
La AWS Savings Plan estrategia efectiva no es complicada, pero requiere disciplina de portafolio: Compute Plans primero, sizing sobre el piso real (no el promedio), renovaciones planificadas con 60-90 días de anticipación, y vencimientos escalonados para no concentrar riesgo. El gap entre hacerlo bien y hacerlo mal es, literalmente, cientos de miles de dólares anuales para cualquier empresa con una factura de AWS de mediana escala. No necesitás herramientas de terceros para empezar: Cost Explorer tiene lo que necesitás. Lo que sí necesitás es no tratar esto como una tarea anual que se delega y se olvida.
Fuentes
- Aman Singh en Dev.to — AWS Savings Plan Buying Strategy: How to Layer, Size, and Time Commitments (mayo 2026)
- AWS Docs — Guía oficial de compra de Savings Plans
- AWS Savings Plans — página oficial con tipos y descuentos
- Clouxter Blog — Savings Plans vs Reserved Instances vs Spot: guía comparativa
- Donde Aprendo AWS — Ahorro de costos con instancias reservadas y Savings Plans
