¿Cuánto commitment de AWS Savings Plans es el correcto? El problema del dimensionamiento y cómo dejar de adivinar

La respuesta corta

Si te quedas con una sola idea de este artículo: comprométete en función de tu base estable —el cómputo que realmente está encendido las 24 horas—, no de la semana promedio ni del pico. Convierte eso en una política de cobertura que puedas defender (qué porcentaje de tu gasto quieres bajo compromiso, más un techo que no vas a cruzar), y luego agrega compromiso en pasos pequeños hacia esa meta en lugar de hacerlo en una sola compra grande.

Todo lo que sigue explica por qué esa es la respuesta correcta, por qué el proceso habitual lo hace difícil y cómo ejecutarlo de forma continua sin tener que vigilar una hoja de cálculo.

Por qué el "cuánto" es genuinamente difícil

Empecemos con dos palabras que la gente usa como sinónimos y no debería: cobertura y utilización.

• La cobertura es cuánto de tu gasto on-demand elegible está bajo un compromiso. Si estás corriendo unos $80/hora en cómputo elegible para Savings Plans y $60/hora están cubiertos, tienes un 75% de cobertura.
• La utilización es cuánto del compromiso que compraste realmente se usa. Si te comprometes a $70/hora y solo aparecen $60/hora de uso que coincida, estás en ~86% de utilización, y sigues pagando el precio comprometido por el 14% que quedó ocioso.

Aquí viene la parte incómoda: estas dos métricas se mueven en direcciones opuestas cuando las presionas. Persigue una cobertura más alta y compras más compromiso, lo que facilita que la utilización se deslice si el uso baja. Protege la utilización comprando de forma conservadora y tu cobertura —y tus ahorros— se quedan bajos. Dimensionar un compromiso es el acto de elegir dónde ubicarte en ese sube y baja. La mayoría de los equipos nunca toma esa decisión de forma explícita; solo reacciona.

Luego están las palancas, y cada una cambia el cálculo:

Decisión	Opciones	El tradeoff
Plazo	1 año vs. 3 años	El de 3 años aumenta el descuento, pero triplica el lock-in al que estás apostando.
Pago	Sin pago inicial / Parcial / Todo por adelantado	Pagar más por adelantado consigue un precio ligeramente mejor, pero inmoviliza efectivo y sube el costo de equivocarse.
Tipo de plan	Compute SP vs. EC2 Instance SP	El Compute SP (hasta ~66% de descuento) se aplica con flexibilidad a cualquier familia de instancias, tamaño, región, SO, tenencia e incluso a Fargate/Lambda. El EC2 Instance SP (hasta ~72% de descuento) ofrece un descuento algo mayor, pero te ata a una familia de instancias en una región. Flexibilidad vs. descuento, otra vez.

Para ver cuánto valen estas decisiones, mira lo que le hacen al precio de una sola instancia: la misma c6a.8xlarge, en una región, cotizada en distintos plazos y opciones de pago de Compute Savings Plans (más on-demand):

La diferencia es enorme: la misma máquina cuesta desde unos $1.22/hora on-demand hasta ~$0.54/hora con un Compute Savings Plan de tres años; una variación de ~56% decidida por completo por cómo compras. Y las diferencias no están repartidas de forma pareja: pasar de un plazo de 1 año a uno de 3 casi reduce el precio a la mitad, mientras que la opción de pago inicial (Sin / Parcial / Todo) apenas lo mueve un par de puntos. La palanca que parece letra chica —la duración del plazo— es la que realmente mueve el dinero.

Cada una de esas decisiones asume que sabes cómo se verá tu workload durante todo el plazo. En un plan EC2 Instance de tres años con pago total por adelantado, no estás dimensionando un compromiso: estás haciendo una predicción sobre tu arquitectura en 2028. Esa es la verdadera dificultad. El número no es difícil de calcular. Lo difícil de conocer es el futuro del que depende.

Las cinco fuerzas que no dejan de mover el blanco

Si tu uso fuera una línea plana, esto sería un ejercicio de hoja de cálculo. Nunca lo es. Cinco fuerzas siguen arrastrando el número "correcto" de un lado a otro después de que te comprometiste.

1. El uso no es plano. El gasto real de cómputo oscila semana a semana: batch jobs, lanzamientos, tráfico estacional, el onboarding de un cliente grande. Un compromiso dimensionado para una buena semana se convierte en sobrecompromiso en una semana tranquila. Dimensiona para una semana ocupada a $70/hora cuando tu base estable en realidad es de $60/hora, y en cuanto las cosas se calmen, esos $10/hora extra son compromiso ocioso: unos $87,600 al año pagados por capacidad que no estás usando. El descuento que perseguías es más pequeño que la pérdida que creaste.

2. El right-sizing y las migraciones encogen la base. Esta es la que más dinero deja varado en silencio. Te comprometes al uso de hoy, y luego tu equipo hace su trabajo: aplica right-sizing a instancias sobredimensionadas, mueve un servicio a Graviton, refactoriza un monolito. Tu uso baja, y tu compromiso no. Te comprometes a tu base de $60/hora, luego tu equipo migra a Graviton y la base se asienta en $50/hora. De la noche a la mañana, esos ~$10/hora de compromiso no tienen dónde aterrizar, con unos dos años restantes en un plan de tres años: aproximadamente $175K varados. Hiciste lo correcto desde la ingeniería y saliste castigado. La jugada correcta es el orden inverso: primero right-sizing, luego comprometerse al estado estable más ajustado. Casi nadie lo hace, porque el compromiso y el right-sizing viven en los backlogs de equipos distintos.

3. Los compromisos expiran, y las expiraciones llegan en tandas. Un Savings Plan que compraste hace un año vence en un día específico. Si compraste varios de una sola vez, expiran todos juntos, y tu cobertura se desploma de la noche a la mañana. Renovar significa repetir todo el ejercicio de dimensionamiento, justo en el momento en que es menos probable que estés mirando. Si se te pasa, vuelves a pagar precios on-demand completos por la porción expirada.

4. Una meta de cobertura no es un resultado de utilización. Puedes apuntar a un 80% de cobertura y aun así terminar con mala utilización si el uso baja después de comprar. Las metas se fijan sobre la historia; la utilización se materializa en el futuro. La brecha entre ambas es pérdida pura, y no la ves hasta que llega la factura.

5. El tiempo mismo. Cada día que esperas tener "suficiente certeza" para comprometerte es un día a precios on-demand. Hay equipos que retrasan sus compromisos durante meses persiguiendo una confianza que nunca llega, y el descuento que postergan se pierde para siempre. Como lo dijimos en el artículo sobre errores con commitments: incluso durante migraciones e incertidumbre, comprometer alguna porción es mejor que no comprometer nada.

Fíjate que ninguna de estas es una falla de planificación. Son simplemente la realidad. Tu infraestructura está hecha para cambiar. El problema no es que el blanco se mueva, sino que la mayoría de los procesos de compromiso están construidos como si no lo hiciera.

Por qué el enfoque manual se rompe

Así es como suele hacerse el dimensionamiento en la práctica.

Una vez por trimestre, alguien abre la recomendación de compra de Savings Plans de AWS. AWS mira hacia atrás en una ventana —puedes elegir 7, 30 o hasta 60 días— y te entrega un único compromiso por hora sugerido, optimizado para el máximo ahorro. Alguien lo revisa por encima, quizás lo recorta "por seguridad", consigue una aprobación y compra.

Hay tres problemas incorporados en ese flujo.

Primero, es un solo número a partir de una sola ventana retrospectiva. Las recomendaciones de máximo ahorro asumen que tu pasado reciente es tu futuro y empujan la cobertura hacia arriba. Genial cuando el uso es estable; caro en el momento en que deja de serlo.

Segundo, es una compra de un solo golpe. Tomas la decisión de compromiso de todo el trimestre y la ejecutas en una sola transacción, en un solo día. Si ese día cae justo en la cima de un pico de uso, acabas de anclar un año de compromiso a un pico.

Tercero, ya está desactualizada. Para cuando la recomendación se revisa, se aprueba y se compra, han pasado días o semanas y el uso ya se movió. No te estás comprometiendo con tu realidad actual: te estás comprometiendo con una foto de una realidad que ya no existe.

El problema de fondo es la cadencia. El uso cambia de forma continua; el proceso manual se dispara cada trimestre. Estás muestreando una señal en movimiento cuatro veces al año y actuando sobre cada muestra con semanas de retraso. Ninguna cantidad de rigor en la hoja de cálculo arregla un problema de frecuencia de muestreo.

Un mejor modelo mental: dimensiona a la base y luego escalona hacia ella

La solución en realidad son dos trabajos separados, y ayuda ponerles nombre: dimensionar (elegir el número correcto) y escalonar (llegar a él de forma segura). Dos cambios en cómo piensas cada uno.

Cambio uno — dimensionar: ancla en la base estable. Este es el trabajo de elegir el número. En lugar de "cuál es el monto correcto en dólares", decide cuánto de tu gasto elegible quieres cubrir —anclado en la base estable, la parte que corre las 24 horas— y deja que el monto en dólares se derive de ahí. Así conviertes una adivinanza sin límites en una política sobre la que puedes razonar:

• Conservadora (~65% de cobertura). Proteges la utilización y mantienes flexibilidad. Dejas algunos ahorros sobre la mesa a propósito. Buena para usos volátiles o que cambian rápido.
• Balanceada (~80% de cobertura). La opción por defecto para la mayoría de los workloads de producción estables: ahorros significativos con un colchón cómodo contra las caídas.
• Agresiva (~90% de cobertura). Máximo ahorro, colchón mínimo. Solo apropiada cuando tu base es genuinamente estable y predecible.

¿Por qué no elegir siempre la agresiva? Porque la cobertura tiene rendimientos decrecientes, y la última porción es la peligrosa. El fondo de tu uso —la parte que está encendida 24/7/365— es lo más seguro de cubrir, y ahí el descuento es prácticamente dinero gratis. A medida que empujas la cobertura más arriba, empiezas a comprometer gasto de la parte variable de tu uso: las horas que solo existen durante los picos. Ese gasto marginal es exactamente el gasto con más probabilidades de desaparecer, lo que significa que la cobertura que agregas por encima del ~80% carga con la mayor parte del riesgo de sobrecompromiso mientras aporta los ahorros menos confiables. La postura correcta no es "cubrirlo todo", sino "cubrir la base estable de forma agresiva y la cima volátil con cautela".

Cambio dos — escalonar: llega en pasos pequeños. Este es un trabajo distinto: no cuánto comprometer, sino cómo llegar ahí. En lugar de una gran compra, divide la distancia hasta tu meta en una serie de compromisos pequeños y escalonados en el tiempo. El escalonamiento resuelve varias de las cinco fuerzas a la vez:

• Pasos pequeños y frecuentes significan que ninguna compra individual queda anclada a un pico. Estás promediando tu entrada al compromiso, igual que promediarías el costo al entrar en una posición de inversión.
• Fechas de inicio escalonadas significan expiraciones escalonadas: sin caídas abruptas al renovar, porque tus planes se van venciendo de a pocos en lugar de todos a la vez.
• Comprometerte de forma gradual significa que puedes frenar o desacelerar en el momento en que el uso baje, en lugar de descubrir el sobrecompromiso un año después, dentro de un contrato bloqueado.

Pero mantén los dos trabajos separados. El escalonamiento gestiona el timing —la concentración de compras y las caídas abruptas por expiración—, no el dimensionamiento. No puede rescatar una meta demasiado agresiva: escalona lentamente hacia el número equivocado y aun así terminarás sobrecomprometido, solo que unas semanas más tarde. Primero acierta con la base; después escalona hacia ella.

El problema: dimensionar contra una base en movimiento, revisar la cobertura cada semana, ajustar por expiraciones y pausar en las bajadas es un trabajo genuinamente continuo. Hecho a mano, es un rol de medio tiempo que nadie tiene. Ese es exactamente el vacío que la automatización viene a cubrir.