Por Dima Kramskoy — Senior Cloud Architect en DoiT International
La pregunta que casi todos plantean mal
Cuando me dedicaba a resolver tickets de optimización en la nube, esta era la pregunta número uno que recibía de los clientes: "¿Deberíamos usar Savings Plans o Reserved Instances?". La escuchaba tres o cuatro veces por semana, de clientes distintos.
Es la pregunta equivocada.
La correcta es: ¿cómo lucirá tu workload dentro de 12 meses?
Te explico por qué importa este giro: una organización que tiene en planes migrar a Graviton va a tirar el dinero en Standard RIs que no pueden seguir a sus workloads hacia nuevas familias de instancias. Y un equipo con un cluster RDS sólido como una roca, que no ha tocado su configuración en dos años, está dejando dinero sobre la mesa con Compute Savings Plans cuando una Standard RI le daría entre 6 y 9 puntos porcentuales más de descuento.
La decisión SP-vs-RI no se trata de productos, sino de dirección arquitectónica. Tu estrategia de commitments debe acompañar tu roadmap de infraestructura, no al revés.
Y aquí va la verdad incómoda: la mayoría de los clientes con los que trabajo no sabe cómo lucirá su workload dentro de 12 meses. No tienen claro si migrarán a Graviton el próximo trimestre, si pasarán a contenedores o si duplicarán su compute. Eso no es una falla de planificación, es la realidad. Si no sabes hacia dónde va tu workload, ESA es tu respuesta. Incertidumbre = flexibilidad. Elige al menos Compute Savings Plans, o mejor aún, deja que una herramienta asuma por completo el riesgo del commitment (más sobre esto al final).
Te comparto el marco que aplico con clientes enterprise, actualizado con todo lo que cambió en 2025–2026.
Respuesta rápida: diagrama de decisión
Antes de profundizar, este es el camino corto:
INICIO: ¿Cuál es tu workload principal de compute?│├─ Solo EC2, una sola familia de instancias, estable 12+ meses│ └─ → EC2 Instance Savings Plan o Standard RI│ ├─ ¿Necesitas reserva de capacidad? → Zonal Standard RI│ └─ ¿Prefieres una gestión más simple? → EC2 Instance SP│├─ EC2 en varias familias de instancias│ └─ → Compute Savings Plan│├─ Planeas migración a Graviton (x86 → arm64)│ └─ → Compute Savings Plan (se auto-aplica a la nueva familia)│├─ Fargate, Lambda o serverless-first│ └─ → Compute Savings Plan (el único tipo que los cubre)│├─ RDS / Aurora / capa de base de datos│ └─ Config estable, ¿máximo descuento? → Standard RI (hasta 69%)│ └─ Multi-engine, Gen 7+, ¿flexibilidad? → Database SP (hasta 35%)│└─ En plena re-arquitectura o migrando fuera de AWS └─ → No te comprometas. Usa On-Demand/Spot hasta estabilizar.Tabla comparativa rápida
| Tipo | Descuento máx. | Flexibilidad | Ideal para |
|---|---|---|---|
| Compute SP | Hasta 66% | Cualquier región, familia, OS, servicio | Organizaciones en modernización, serverless, multi-región |
| EC2 Instance SP | Hasta 72% | Cualquier tamaño/OS dentro de familia + región fija | Familia EC2 estable, gestión simple |
| Standard RI | Hasta 72–75% | Tipo + región fijos (flexibilidad de tamaño con Regional RI) | Workloads ultra estables, reserva de capacidad |
| Convertible RI | Hasta 54–58% | Familia/OS intercambiables (misma región) | Necesidades de flexibilidad legacy, en gran parte superadas por los SPs |
| Database SP | Hasta 35% | Cualquier motor de BD elegible (solo Gen 7+) | Parques de BD multi-engine, Aurora Serverless |
Qué cambió en 2025–2026
Cuatro novedades importantes desde mi última revisión de optimización de costos:
1. Lanzamiento de Database Savings Plans (diciembre de 2025)
El mayor anuncio de re:Invent 2025 para FinOps. Los Database Savings Plans cubren 10 servicios: Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS y OpenSearch.
La letra chica: solo plazos de 1 año (no hay opción a 3 años), únicamente No Upfront, y requieren instancias Gen 7+ (db.r7g, db.m7g). El descuento máximo es de ~35%, muy por debajo del 69% que se obtiene con Standard RDS RIs. No son un reemplazo de los DB RIs, sino una apuesta por la flexibilidad para organizaciones con parques de bases de datos diversos y en evolución.
2. Restricciones para compartir RI/SP (junio de 2025)
AWS les prohibió a los MSPs y revendedores compartir descuentos de RI/SP entre varios clientes finales. Si compras a través de un partner, tus commitments quedan restringidos solo a tu uso. A los compradores enterprise directos no les afecta mayormente.
3. Group Sharing — GA (noviembre de 2025)
Esta pasó desapercibida, pero resuelve un dolor real. Ya puedes controlar exactamente qué cuentas de tu Organization se benefician de los commitments compartidos, con dos modos:
- Prioritized Group Sharing: el commitment se aplica primero al grupo designado y luego se derrama al resto de la organización.
- Restricted Group Sharing: aislamiento total; solo se beneficia el grupo designado.
Esto acaba con el clásico problema de "el equipo equivocado se está beneficiando de nuestra RI" que afectó a la facturación consolidada durante años. Se usan Cost Categories para definir los grupos. Si manejas una organización multi-BU con modelos de chargeback, esto cambia las reglas del juego.
4. Las RIs NO están descontinuadas
A pesar de las especulaciones recurrentes, las Reserved Instances siguen plenamente soportadas. Las páginas de Precios de AWS se mantienen activas (última actualización en mayo de 2026), Cost Explorer sigue proponiendo recomendaciones de RI y RI Marketplace sigue operativo. AWS claramente le da prioridad a los Savings Plans en el desarrollo de nuevas funciones y en la documentación, pero las RIs no van a ningún lado.
Un detalle más: los Savings Plans con commitments superiores a $100/hora no se pueden devolver. Por debajo de $100/hora, dispones de una ventana de 7 días dentro del mismo mes calendario, con un máximo de 10 devoluciones al año. A escala enterprise, estos commits son permanentes. Planifica en consecuencia.
A fondo: Compute SP vs EC2 SP vs Standard RI vs Convertible RI
Esta es la comparación completa que me hubiera gustado tener cuando tomaba estas decisiones:
| Dimensión | Compute SP | EC2 Instance SP | Standard RI | Convertible RI |
|---|---|---|---|---|
| Descuento máx. | 66% | 72% | 72–75% | 54–58% |
| Base del commitment | $/hora (cualquier compute) | $/hora (familia + región) | Tipo de instancia + región + OS + tenancy | Familia de instancia + región |
| Familia de instancia | Cualquiera — auto-aplica | Fija por plan | Fija | Intercambiable |
| Tamaño de instancia | Cualquiera — auto-aplica | Cualquiera — auto-aplica | Flexible (Regional RI) | Flexible |
| Flexibilidad de OS | Cualquiera | Cualquiera | Fijo | Intercambiable |
| Región | Cross-región ✅ | Región fija | Región fija | Región fija |
| Lambda/Fargate | ✅ | ❌ | ❌ | ❌ |
| Reserva de capacidad | ❌ | ❌ | ✅ (Zonal RI) | ❌ |
| Revendible | ❌ | ❌ | ✅ (RI Marketplace*) | ❌ |
| Cancelable | Limitado (≤$100/hr, 7 días) | Limitado | ❌ | ❌ |
| Carga de gestión | Baja | Baja | Alta | Media |
*Los clientes EDP no pueden vender en RI Marketplace.
Orden de aplicación en la facturación (esto importa)
AWS aplica los descuentos en este orden de prioridad:
- Las Reserved Instances se aplican primero (al uso que coincide).
- Los EC2 Instance Savings Plans se aplican en segundo lugar.
- Los Compute Savings Plans se aplican al final (red más amplia).
Dentro de cada nivel, se cubre primero el uso con mayor porcentaje de ahorro. Esto significa que puedes apilar los tres con tranquilidad, sin conflictos: AWS optimiza la aplicación de forma automática.
Portabilidad del workload: cuando la flexibilidad le gana al descuento
La brecha de descuento entre Compute SP (66%) y EC2 Instance SP (72%) es de unos 6 puntos porcentuales. En condiciones enterprise típicas (1 año, no-upfront), se reduce a 2–4 puntos. Te muestro cuándo pagar esa "prima por flexibilidad" es claramente la decisión correcta.
Migración a Graviton
Migrar de x86 (m5, c5, r5) a Graviton (m7g, c7g, r7g):
- Compute SP: sin fricciones. El descuento se auto-aplica a las instancias Graviton apenas las lanzas.
- EC2 Instance SP: se rompe. m5 ≠ m7g, son familias de instancia distintas.
- Standard RI: completamente inutilizable para las instancias nuevas. Commitment varado.
- Convertible RI: requiere un intercambio manual, de valor igual o mayor, y queda atado a la región.
Si vas camino a la migración a Graviton (y deberías estarlo: ofrece entre 20% y 40% mejor relación precio-rendimiento), los Compute SPs son estructuralmente superiores.
Transición a contenedores / serverless
Migrar de EC2 a ECS/Fargate o Lambda:
- Compute SP: cubre Fargate y Lambda automáticamente. Tu descuento te sigue.
- Todo lo demás: cero cobertura para compute en contenedores o serverless.
Expansión cross-región
Abrir una nueva región o consolidar de 4 regiones a 2:
- Compute SP: el descuento se aplica globalmente en todas las regiones.
- Todos los demás: atados a la región. La consolidación deja varados tus commitments.
Los números
Sobre un gasto anual de compute de $5M, una brecha de 6 puntos porcentuales cuesta cerca de $300K en 3 años. Suena significativo, hasta que te das cuenta de que una migración a Graviton fallida (porque no puedes permitirte salir de las RIs bloqueadas) te cuesta la mejora de rendimiento del 20–40% en toda tu flota. La prima por flexibilidad es un seguro, y es un seguro barato.
Los anti-patrones (qué pasa cuando lo haces mal)
En más de 10 años de optimización de costos en la nube, he visto cómo estos errores les cuestan millones a las organizaciones. Estos son los cinco más caros:
Anti-patrón 1: comprometerse al pico en lugar de a la base
El error: comprar commitments con base en el uso máximo observado.
Qué pasa: te comprometes a $50/hora porque ese es tu pico de los lunes por la mañana. Tu base sostenida es de $35/hora. Estás corriendo al 70% de utilización sobre tu commitment, y el otro 30% es pura pérdida.
El costo: sobre un commit de $50/hora, un 30% de pérdida = $131K/año quemados.
La solución: comprométete al 70–80% de tu piso sostenido (usa 60 a 90 días de datos). Cubre los picos con Spot y On-Demand.
Anti-patrón 2: Standard RIs para workloads a punto de migrar
El error: comprar Standard RIs a 3 años para una flota m5 con una migración a Graviton en el roadmap.
Qué pasa: seis meses después, estás listo para mover todo a m7g. Tus Standard RIs no te pueden seguir. No son convertibles. Si eres cliente EDP, tampoco las puedes vender en el Marketplace. Estás pagando por instancias que ya no corres.
El costo: una RI a 3 años varada en r5.4xlarge: ~$278/mes de commitment generando cero beneficio durante los 30 meses restantes = $8.340 perdidos por instancia. Escálalo a toda una flota.
La solución: si tienes algún cambio arquitectónico planeado dentro de la ventana del commitment, ve por Compute SPs.
Anti-patrón 3: dejar que los commitments expiren en silencio
El error: no monitorear vencimientos ni dejar encoladas las renovaciones.
Qué pasa: un lote de RIs vence un martes. Nadie se da cuenta hasta que llega la factura de fin de mes. Tu tarifa efectiva salta de $278/mes a $736/mes por r5.4xlarge: un aumento de costo de más del 62% de la noche a la mañana.
El costo: una flota de 20 instancias revirtiendo a On-Demand por un solo mes: ~$9.160 en gasto inesperado.
La solución: alertas de vencimiento con AWS Budgets + compras de Savings Plan encoladas antes de la fecha de expiración.
Anti-patrón 4: ignorar el compute fuera de EC2
El error: comprometerse solo contra EC2, mientras más del 40% del gasto en compute vive en Lambda, Fargate o EKS.
Qué pasa: un gasto significativo en serverless/contenedores se queda pagando tarifas On-Demand completas. Las organizaciones que solo optimizan los commitments de EC2 creen que "ya terminaron", mientras dejan entre 20% y 30% de ahorros sobre la mesa en sus workloads de mayor crecimiento.
El costo: $200K/año en Lambda + Fargate a On-Demand, cuando un Compute SP ahorraría entre 20% y 66% = $40K–$132K/año en ahorros perdidos.
La solución: audita TODOS los servicios elegibles. Un solo Compute SP cubre EC2, Lambda y Fargate al mismo tiempo.
Anti-patrón 5: comprometerse durante una re-arquitectura activa
El error: comprar commitments mientras haces right-sizing, re-platforming o estás migrando.
Qué pasa: hoy te comprometes a $80/hora. En los próximos 6 meses, la optimización reduce tu base a $55/hora. Quedas atrapado con $25/hora de pérdida por el resto del plazo.
El costo: $25/hora × 8.760 horas restantes en un plazo de 1 año = $219K en commitment varado.
La solución: estabiliza primero, comprométete después. Usa commitments escalonados que coincidan con tu nivel de confianza: commits pequeños durante la migración, commits mayores una vez que los patrones de uso se consoliden.
Marco de decisión
Esta es la tabla para guardar como screenshot:
| Si tu workload se ve así… | Elige | Por qué |
|---|---|---|
| Flota EC2 estable, una sola familia, sin cambios planeados a 12+ meses | EC2 Instance SP o Standard RI | Descuento máximo (72–75%) con bajo riesgo de quedar varado |
| Flota EC2 con migración a Graviton planeada en 12 meses | Compute SP | Se auto-aplica a la nueva familia de instancia sin intervención |
| Arquitectura multi-región o expansión de regiones planeada | Compute SP | El único tipo de commitment que funciona cross-región |
| Gasto creciente en Lambda/Fargate (>20% del compute) | Compute SP | El único tipo que cubre compute serverless + contenedores |
| Cluster RDS/Aurora, misma config por 18+ meses | Standard RI | El mayor descuento de BD (hasta 69%) para bases de datos comprobadamente estables |
| Múltiples motores de base de datos, instancias Gen 7+, parque de BD en evolución | Database SP | Flexibilidad en 10 servicios, cubre Aurora Serverless |
| Necesitas capacidad garantizada por compliance/SLA | Zonal Standard RI | El único tipo de commitment que ofrece reserva de capacidad |
| Re-arquitectura activa, migración en curso | No te comprometas | Espera a que el uso se estabilice; usa On-Demand/Spot |
La estrategia por capas (lo que recomiendo para la mayoría de las organizaciones)
No elijas un solo tipo. Apílalos:
- Capa 1 — Compute SPs (60–80% de la base): cubre tu piso mínimo de compute con la máxima flexibilidad.
- Capa 2 — EC2 Instance SPs: agrégalos encima para las familias en las que tienes confianza (capturan 6 pp extra de descuento).
- Capa 3 — Standard RIs: resérvalos para workloads ultra estables de la capa de datos + necesidades de capacidad.
- Capa 4 — On-Demand/Spot: mantén sin commitment los workloads variables e inciertos.
Empieza con plazos de 1 año para validar patrones. Después de 12 meses con datos de uso estables, apila plazos de 3 años para tu base comprobada (15–22 puntos porcentuales más de descuento).
Cómo DoiT automatiza todo esto
¿Recuerdas lo que dije sobre la incertidumbre? La mayoría de los clientes no sabe cómo lucirá su workload dentro de 12 meses. Para exactamente ese caso se construyó FlexSave for Compute.
El pitch en una frase: obtienes tasas de descuento de Savings Plan a 1 año sin compromiso alguno de tu parte. DoiT asume el riesgo.
Esto es lo que hace:
- Monitorea tu uso on-demand: analiza qué está corriendo, qué es estable y qué está cambiando.
- Aplica automáticamente los mecanismos de descuento óptimos: cubre los workloads elegibles que aún no están cubiertos por tus propias RIs/SPs.
- Se ajusta en forma continua: ¿migrando a Graviton? ¿Reduciendo escala? ¿Pasando a Fargate? FlexSave se adapta sin que tengas que tocar una sola hoja de cálculo.
- Cero compromiso de tu parte: DoiT asume el riesgo del commitment. Tú te quedas con el descuento. Te puedes ir cuando quieras.
- Cubre todo el stack de compute: EC2, ECS, EKS, Fargate, Lambda, SageMaker (no solo EC2).
Para bases de datos: los nuevos Database Savings Plans de AWS (dic. 2025) son tu mejor apuesta para RDS y Aurora. FlexSave se enfoca en compute, que es donde la incertidumbre y la necesidad de flexibilidad son mayores.
Para ganar visibilidad sobre todo tu portfolio de commitments, DoiT Cloud Analytics te entrega métricas de utilización, cobertura y pérdida en un solo lugar, para que siempre sepas si tu estrategia está funcionando.
La combinación resuelve ambos problemas: FlexSave se encarga de la ejecución del "no sé qué viene después", y Cloud Analytics aporta la supervisión. La incertidumbre deja de ser un problema cuando tus herramientas se adaptan contigo.
TL;DR
Los Compute SPs son la opción por defecto para la mayoría de las organizaciones: la prima por flexibilidad (2–4 pp en plazos típicos) casi siempre vale la pena para equipos con cualquier cambio arquitectónico en el roadmap.
Las Standard RIs siguen ganando para workloads ultra estables: capas de bases de datos, reservas de capacidad por compliance y workloads con 18+ meses de estabilidad comprobada.
Los Database Savings Plans (nuevos desde dic. 2025) son una apuesta por la flexibilidad, no por el descuento: 35% vs. 69% de las Standard RIs. Elígelos para parques multi-engine con Gen 7+.
Apila tus commitments: Compute SP como base, EC2 Instance SP para las familias en las que tienes confianza, Standard RIs para bases de datos estables y On-Demand para todo lo demás.
Nunca te comprometas durante una migración activa: estabiliza primero, comprométete después. El costo de los commitments varados siempre supera el costo de esperar.
La estrategia correcta de commitments no se trata de maximizar el descuento, sino de alinear tu commitment con tu dirección arquitectónica.
¿Listo para dejar de gestionar esto a mano? Agenda una demo y descubre cómo FlexSave optimiza tus commitments de AWS de forma automática.
Dima Kramskoy es Senior Cloud Architect en DoiT International, con más de 20 años en ingeniería de software, 10 certificaciones de AWS y AWS Community Builder (2026). Se especializa en FinOps y optimización de costos en la nube para organizaciones enterprise.