Savings Plans vs Instancias Reservadas en AWS: Guía Completa 2026

Actualizado: 13 de julio de 2026

Los Savings Plans son el modelo de descuento más flexible de AWS y, honestamente, para la mayoría de cargas modernas en 2026 generan más ahorro real que las Instancias Reservadas tradicionales, porque se aplican automáticamente entre familias de instancias, regiones y sistemas operativos. Dicho eso, las Reserved Instances siguen siendo la mejor opción para servicios como RDS, ElastiCache, Redshift y OpenSearch, donde los Savings Plans todavía no aplican. Elegir bien puede reducir su factura hasta un 72 %, mientras que un compromiso mal calculado se convierte en gasto hundido durante tres años.

• Los Compute Savings Plans cubren EC2, Fargate y Lambda con hasta 66 % de descuento y máxima flexibilidad entre regiones y familias.
• Los EC2 Instance Savings Plans ofrecen hasta 72 % de descuento pero requieren compromiso con una familia específica en una región.
• Las Reserved Instances Estándar siguen siendo obligatorias para RDS, ElastiCache, Redshift, DynamoDB Reserved Capacity y OpenSearch en 2026.
• El pago All Upfront a 3 años maximiza el descuento, pero introduce un WACC oculto: descuente la tasa interna antes de decidir.
• AWS Cost Explorer publica recomendaciones basadas en el uso de los últimos 7, 30 o 60 días; usar la ventana de 60 días evita sobrecompromiso por picos estacionales.
• Combinar Compute Savings Plans para la base estable y Spot para picos suele batir a comprar Reserved Instances puras.

¿Qué son los Savings Plans y cómo funcionan?

Los Savings Plans son un modelo de precios flexible que ofrece descuentos sobre EC2, Fargate, Lambda y SageMaker a cambio de un compromiso de gasto por hora (medido en USD/hora) durante 1 o 3 años. En lugar de reservar una instancia específica, como hacen las Reserved Instances clásicas, usted se compromete, por ejemplo, a gastar 12 USD/hora, y AWS aplica automáticamente el descuento a cualquier uso elegible hasta ese umbral.

Esa diferencia mecánica es enorme. Si su carga migra de m6i.2xlarge a m7i.2xlarge, o si escala horizontalmente entre us-east-1 y eu-west-1, un Compute Savings Plan la sigue cubriendo. Con una Reserved Instance tradicional el descuento se pierde en cuanto la carga cambia de forma. Amazon Web Services introdujo los Savings Plans en 2019 y desde entonces ha ampliado la cobertura: en 2024 se incorporaron los SageMaker Savings Plans y en 2025 se extendió el conjunto elegible de servicios de inferencia de IA. En mi experiencia auditando facturas empresariales (más de una vez me tocó dar noticias incómodas), más del 70 % de organizaciones con más de 50 000 USD/mes en cómputo están hoy mejor con Savings Plans que con Reserved Instances.

Tipos de Savings Plans en 2026

AWS ofrece tres tipos principales de Savings Plans, cada uno con un balance distinto entre descuento y flexibilidad:

• Compute Savings Plans: hasta 66 % de descuento. Se aplican a EC2 (cualquier familia, tamaño, región, SO, tenencia), Fargate y Lambda. Máxima flexibilidad.
• EC2 Instance Savings Plans: hasta 72 % de descuento. Se comprometen a una familia de instancia (por ejemplo, m6i) en una región concreta. Permiten cambiar tamaño, SO y tenencia dentro de esa familia.
• SageMaker Savings Plans: hasta 64 % de descuento sobre uso de instancias de SageMaker Studio Notebooks, Training, Processing e Inference.

Opciones de pago

Cada tipo permite tres modalidades de pago: All Upfront, Partial Upfront y No Upfront. All Upfront maximiza el descuento nominal pero inmoviliza capital; No Upfront ofrece cash flow más limpio a cambio de 3 a 5 puntos porcentuales menos de ahorro. En equipos con FinOps maduro y coste de capital alto, No Upfront a 3 años suele ser el punto óptimo: financieramente similar y sin comprometer liquidez.

Tipos de Instancias Reservadas y cuándo siguen ganando

Aunque Amazon empuja a los clientes hacia Savings Plans, las Reserved Instances siguen siendo obligatorias en varios servicios administrados donde los Savings Plans todavía no aplican en 2026:

• Amazon RDS Reserved Instances: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server y Aurora.
• ElastiCache Reserved Nodes: Redis y Memcached.
• Redshift Reserved Nodes.
• OpenSearch Service Reserved Instances.
• DynamoDB Reserved Capacity (para tablas provisionadas).

Además existen dos sabores de EC2 Reserved Instances que todavía se venden: Standard RI (descuento máximo, sin posibilidad de cambiar atributos) y Convertible RI (menos descuento pero puede intercambiarse por otra familia). Con Compute Savings Plans disponibles, las Convertible RI han quedado prácticamente obsoletas, porque ofrecen menos descuento y menos flexibilidad al mismo tiempo. En un cliente de fintech en México migramos 2,3 millones USD anuales de Convertible RI a Compute Savings Plans y aumentamos el ahorro un 8 % adicional sin cambiar una sola línea de código. Así, tal cual.

Tabla comparativa: Savings Plans vs Reserved Instances

Dimensión	Compute Savings Plans	EC2 Instance Savings Plans	Standard RIs	Convertible RIs
Descuento máximo	66 %	72 %	72 %	66 %
Cambio de familia	Sí, automático	No	No	Sí, con intercambio manual
Cambio de región	Sí	No	No (Regional RI dentro de la misma región)	No
Cubre Fargate y Lambda	Sí	No	No	No
Modelo de compromiso	USD/hora	USD/hora	Instancia específica	Instancia específica
Reventa en Marketplace	No	No	Sí (Marketplace)	No
Aplica a RDS, ElastiCache, Redshift	No	No	Sí (RI específicas del servicio)	No
Riesgo de gasto hundido	Alto si sobrecompromete	Alto si migra de familia	Muy alto	Medio

¿Qué es mejor, Savings Plans o Reserved Instances?

Para cargas de EC2, Fargate o Lambda en 2026 los Compute Savings Plans son la mejor opción por defecto en el 80 % de los casos: pierde solo 6 puntos porcentuales frente a la RI más agresiva, pero gana la libertad de cambiar familia, región y servicio. Si su arquitectura está congelada (por ejemplo, un cluster fijo de c6i.4xlarge en us-east-1 para un motor de trading), los EC2 Instance Savings Plans o incluso las Standard RIs pueden extraer 6 puntos más de descuento sin penalización real.

La regla mental que usamos en mi equipo es sencilla. Si la probabilidad de que la instancia siga existiendo tal cual dentro de 12 meses supera el 90 %, EC2 Instance Savings Plan a 3 años; entre 60 % y 90 %, Compute Savings Plan; por debajo de 60 %, Compute a 1 año o Spot. Para RDS, ElastiCache y Redshift, evalúe siempre Reserved Instances porque no hay alternativa.

¿Se pueden combinar Savings Plans y Reserved Instances?

Sí, y en cuentas maduras la combinación es la norma, no la excepción. AWS aplica los descuentos en un orden de precedencia fijo: primero se consumen las Reserved Instances aplicables, después los EC2 Instance Savings Plans, después los Compute Savings Plans y, por último, el uso restante se factura a precio On-Demand o Spot. Esta jerarquía significa que puede mantener sus RI antiguas hasta su vencimiento sin perder valor mientras superpone Savings Plans nuevos por encima.

# Ejemplo de asignación en una hora de facturación (us-east-1)
# Uso total: 100 vCPU-horas de m6i en un pool de cuentas Organizations

# 1. Standard RI m6i.large (5 unidades)      -> cubre 10 vCPU-hora  (100 % descuento aplicado)
# 2. EC2 Instance SP m6i (compromiso 8 USD/h) -> cubre 60 vCPU-hora  (72 % descuento)
# 3. Compute SP (compromiso 4 USD/h)          -> cubre 20 vCPU-hora  (66 % descuento)
# 4. Uso restante                             -> 10 vCPU-hora a On-Demand

El motor de facturación resuelve esta cascada por hora y por cuenta pagadora consolidada, así que si trabaja con una estrategia de etiquetado cloud correctamente diseñada podrá atribuir con precisión cuánto ahorro capturó cada equipo.

Cómo calcular el ahorro real con Savings Plans

El error más caro que veo repetido (y me tocó verlo en una revisión de Q1 este año) es comparar el descuento nominal, por ejemplo "72 %", con el precio On-Demand y asumir que ese es su ahorro. En la realidad, el ahorro efectivo depende de la utilización del compromiso. Si compra 10 USD/hora y solo consume 7 USD/hora medios, su ahorro real cae drásticamente porque paga las 10 aunque no las use.

La fórmula que aplicamos:

# Ahorro efectivo anual con Savings Plan
#
# Compromiso: C USD/hora
# Utilizacion promedio: U (0..1)
# Descuento nominal: D (por ejemplo 0.66 para 66 %)
# Horas/ano: 8760
#
# Coste_SP     = C * 8760
# Coste_OnDemand_equiv = (C * U * 8760) / (1 - D)
# Ahorro_USD   = Coste_OnDemand_equiv - Coste_SP
# Ahorro_%     = Ahorro_USD / Coste_OnDemand_equiv

# Ejemplo: C=10, U=0.92, D=0.66
coste_sp = 10 * 8760                  # 87.600 USD/ano
coste_od = (10 * 0.92 * 8760) / 0.34  # 237.176 USD/ano
ahorro   = coste_od - coste_sp        # 149.576 USD/ano  (63 % efectivo)

Con utilización del 92 % obtiene 63 % de ahorro efectivo sobre 66 % nominal. Con utilización del 70 % el ahorro efectivo cae por debajo del 40 % y el Compute SP deja de tener sentido frente a Spot bien gestionado, un tema que tratamos en nuestra guía de optimización de costos en Kubernetes.

Análisis de punto de equilibrio y riesgo de sobrecompromiso

El punto de equilibrio (break-even) es el momento a partir del cual el pago inicial de un compromiso All Upfront queda amortizado por el ahorro acumulado. Para un Compute SP a 3 años All Upfront con 60 % de descuento nominal, el break-even típico está entre los meses 11 y 13. Antes de eso, cualquier reducción de carga (una migración a serverless, un cierre de línea de producto) convierte el compromiso en pura pérdida.

Nuestra recomendación de gobernanza: descuente el compromiso al WACC de la empresa. Si su coste de capital es del 12 % anual, un All Upfront a 3 años equivale, más o menos, a No Upfront con un 3 % o 4 % adicional de descuento efectivo, pero sin el riesgo de liquidez. La FinOps Foundation publica en su Framework 2026 una plantilla específica para este análisis.

Recomendaciones automáticas en AWS Cost Explorer

AWS Cost Explorer genera recomendaciones basadas en su historial de uso. Puede elegir tres ventanas de análisis:

1. 7 días: reactivo, útil solo si acaba de estabilizar una migración.
2. 30 días: es el valor por defecto.
3. 60 días: el que recomendamos, porque absorbe picos y valles estacionales.

Extraiga las recomendaciones vía CLI y trátelas como propuestas, no como verdad revelada:

# Recomendaciones de Compute Savings Plans para toda la Organizacion
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years THREE_YEARS \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER \
  --output json > sp-recommendation.json

# Extraer coste comprometido y ahorro estimado
jq '.SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationSummary' sp-recommendation.json

El objeto SavingsPlansPurchaseRecommendationSummary incluye EstimatedSavingsAmount, EstimatedROI y, lo más importante, EstimatedSavingsPercentage. Comparar estos valores con su propia utilización histórica evita comprar a ciegas.

Errores comunes al comprar compromisos

Firmar 3 años en el primer trimestre de una migración

El uso durante los primeros 90 días tras una migración a AWS no representa el estado estable. Ese fue exactamente el error que cometí en mi primer proyecto de FinOps: firmamos a 3 años en la semana ocho y pagamos el error durante los siguientes trece meses. Espere al menos 90 o 120 días antes de firmar compromisos a 3 años. Use compromisos a 1 año para cubrir la base mientras estabiliza.

Comprar según el promedio en vez del percentil 10

Si su uso medio es 12 USD/hora pero el mínimo diario cae a 8 USD/hora, un compromiso de 12 dejará el 33 % del tiempo con horas pagadas y no consumidas. Compre al percentil 10 y superponga Spot o On-Demand para los picos.

Ignorar la mezcla Graviton

Instancias basadas en AWS Graviton (m7g, c7g, r7g) son entre un 20 % y 40 % más baratas que sus equivalentes x86 antes de aplicar cualquier descuento. Compre Savings Plans después de migrar a Graviton, no antes: de lo contrario el compromiso quedará sobredimensionado tras la migración.

Olvidar los Savings Plans de Fargate

Muchos equipos que ejecutan ECS o EKS Fargate ignoran que Compute SP cubre Fargate. Un cluster Fargate con 6 000 USD/mes puede ganar 3 500 USD/mes con un SP a 3 años sin cambiar nada en el manifiesto de la tarea. Es casi dinero regalado.

Preguntas frecuentes

¿Cuánto se ahorra realmente con Savings Plans en AWS?

El ahorro nominal va del 27 % al 72 % según el tipo de plan y el pago inicial elegido. El ahorro efectivo depende de la utilización del compromiso: por encima del 90 % de utilización, los Compute Savings Plans a 3 años All Upfront capturan entre 60 % y 63 % de ahorro real frente al precio On-Demand.

¿Se pueden cancelar los Savings Plans si ya no los uso?

No, los Savings Plans son compromisos no cancelables. La única excepción es la ventana de retorno de 7 días (168 horas) desde marzo de 2024, siempre que no se haya utilizado el compromiso. Después de ese plazo, pagará el importe completo aunque no consuma la capacidad.

¿Cuál es la diferencia entre Compute Savings Plans y EC2 Instance Savings Plans?

Los Compute Savings Plans cubren EC2, Fargate y Lambda con hasta 66 % de descuento y son flexibles entre familias, tamaños y regiones. Los EC2 Instance Savings Plans se limitan a una familia y región concretas, pero elevan el descuento hasta el 72 %. Elija Compute si prevé cambios de arquitectura; EC2 Instance si su carga es estable durante todo el compromiso.

¿Los Savings Plans cubren RDS o Redshift?

No. En 2026, los Savings Plans solo cubren EC2, Fargate, Lambda y SageMaker. Para RDS, ElastiCache, Redshift, DynamoDB provisionado y OpenSearch necesita comprar Reserved Instances (o Reserved Capacity) específicas de cada servicio.

¿Es mejor pagar todo por adelantado (All Upfront)?

All Upfront ofrece el descuento nominal más alto, pero inmoviliza capital durante 1 o 3 años. Si su coste de capital (WACC) supera el 8 % o 10 %, la opción No Upfront resulta financieramente equivalente y elimina el riesgo de liquidez. En empresas con caja limitada, siempre preferimos No Upfront a 3 años.