MercadoFresco ha apagado lo que sobraba, ha borrado lo que nadie usaba y ha puesto límites a lo que puede crecer. La factura está en 1.749,60 USD al mes y cada línea tiene una explicación. Queda una palanca sin usar, y es la única que reduce el gasto sin cambiar absolutamente nada de la arquitectura: todo lo que está funcionando se paga a precio bajo demanda, es decir, al precio de quien podría marcharse mañana. Y hay una parte de ese consumo que seguirá ahí dentro de un año con total seguridad.

Esta lección va de convertir esa certeza en descuento. Verás los cuatro modelos de compra con su descuento, su compromiso y su riesgo; los Savings Plans en sus tres variantes, con plazos y formas de pago; cómo funciona el compromiso por dólar-hora con un ejemplo numérico paso a paso; qué cubre cada tipo —crítico en una arquitectura como esta, mayoritariamente sin servidor—; las instancias reservadas para lo que los Savings Plans no alcanzan; cómo se identifica la base estable frente a la parte elástica; el plan de compra concreto de MercadoFresco con su ahorro; y el seguimiento con cobertura y utilización, que son dos cosas distintas y se confunden constantemente.

Aviso de coste. Los Savings Plans y las instancias reservadas no cuestan nada por sí mismos: son una forma distinta de pagar lo que ya se consume. El riesgo no es un cargo inesperado, es comprometerse de más: un plan a 3 años con pago total por adelantado no se puede cancelar, ni devolver, ni reducir. Lo que se compra, se paga. Los porcentajes de descuento de esta lección son orientativos, varían por región, servicio y fecha, y deben comprobarse siempre en la calculadora oficial antes de comprar. Datos e identificadores ficticios.

1. Por qué existe el descuento por compromiso
2. Los cuatro modelos de compra
3. Los tres tipos de Savings Plans
4. Plazos y formas de pago
5. Cómo funciona el compromiso por dólar-hora
6. Un ejemplo numérico paso a paso
7. Qué cubre cada plan y qué no
8. Instancias reservadas: lo que los Savings Plans no alcanzan
9. Estándar frente a convertible, alcance y capacidad reservada
10. Spot, revisado desde el coste
11. Identificar la base estable frente a la parte elástica
12. Las recomendaciones automáticas y por qué no son decisiones
13. El plan de compra de MercadoFresco
14. El antes y el después
15. Cobertura y utilización: dos cosas distintas
16. Seguimiento y alarmas
17. Qué hacer si la arquitectura cambia
18. Reparto de compromisos entre cuentas
19. Errores caros
20. Errores comunes y consejos
21. Ejercicios
22. Conclusión

La lógica de negocio de AWS es la misma que la de cualquier proveedor con infraestructura física: los centros de datos se construyen por adelantado. Un servidor comprado hoy hay que amortizarlo durante años, y para eso hace falta previsión de demanda.

Un cliente que paga bajo demanda no aporta ninguna previsión: puede irse mañana. Un cliente que se compromete por escrito a gastar una cantidad concreta durante uno o tres años sí la aporta, y AWS le devuelve parte de ese valor en forma de descuento.

De ahí se deduce todo lo demás, sin necesidad de memorizar tablas:

• A más plazo, más descuento: tres años valen más que uno.
• A más pago por adelantado, más descuento: el dinero hoy vale más que el dinero dentro de un año.
• A menos flexibilidad, más descuento: comprometerse a una familia de instancias concreta vale más que comprometerse a «cómputo en general».
• El riesgo se traslada al cliente: si dejas de usarlo, lo pagas igual.

Ese último punto es el que hay que tener presente durante toda la lección. Un compromiso es una apuesta sobre el futuro, y como toda apuesta se dimensiona por lo que se puede perder, no por lo que se puede ganar.

Los cuatro se combinan, y la combinación es lo normal en una arquitectura madura. El orden mental correcto para decidir:

MercadoFresco ya usa el primer camino desde 10-02: los trabajadores corren en Fargate Spot porque su trabajo se reintenta solo. Lo que falta es recorrer los otros dos.

La comparación que importa para casi todo el mundo es entre los dos primeros:

• El EC2 Instance da unos 6-8 puntos porcentuales más de descuento, pero te ata a la familia m6g en eu-west-1. El día que quieras pasar a m7g, a otra región o a contenedores, el compromiso deja de servirte y sigues pagándolo.
• El Compute da algo menos y sobrevive a casi cualquier cambio de arquitectura. Sigue aplicando si migras de EC2 a Fargate, si cambias de región, si pasas parte del trabajo a Lambda.

Para MercadoFresco no hay debate: el EC2 Instance Savings Plan no le sirve para nada, porque no tiene prácticamente EC2. Su cómputo está en Fargate y en Lambda, y ambos solo los cubre el Compute Savings Plan. Este es exactamente el tipo de detalle que hace que las recomendaciones automáticas haya que leerlas con criterio.

Y una advertencia de vocabulario que ahorra confusiones: existe también un tercer producto llamado Savings Plans de bases de datos en algunas comunicaciones comerciales, pero la cobertura de RDS, Aurora, ElastiCache o Redshift se compra con instancias reservadas, no con Savings Plans de cómputo. Confundirlo lleva a comprar un compromiso que no cubre nada de lo que se pretendía.

Dos ejes independientes que se combinan en seis opciones:

Dos lecturas de esta tabla, y ambas son importantes:

1. La forma de pago aporta poco. Entre «sin pago inicial» y «total por adelantado» a un año hay unos 4 puntos porcentuales. Para MercadoFresco, 4 puntos sobre un compromiso pequeño son unos pocos dólares al mes a cambio de inmovilizar todo el importe anual. No compensa. Para una empresa que compromete cientos de miles de dólares, esos 4 puntos sí son mucho dinero, y la decisión es financiera: depende del coste de oportunidad del capital.
2. El plazo aporta mucho. Duplicar el descuento del 20 % al 40 % pasando de uno a tres años es una diferencia real. Y también lo es el riesgo: tres años es más de lo que ha durado la mitad de las decisiones de arquitectura de este curso.

La regla que MercadoFresco adopta y que sirve para la mayoría de empresas pequeñas y medianas: primer compromiso a 1 año y sin pago inicial. Se aprende cómo funciona, se comprueba que la previsión era buena, y al renovarlo —con un año de datos reales— se puede plantear tres años sobre la parte que haya demostrado ser estable.

Aquí está el concepto que más se malinterpreta. Un Savings Plan no compra instancias: compra un gasto por hora a precio rebajado.

Cuando contratas un Compute Savings Plan de 0,17 USD/hora, lo que estás diciendo es:

«Me comprometo a gastar 0,17 USD cada hora, durante un año, en cómputo elegible. A cambio, ese gasto se factura a tarifa de Savings Plan en lugar de a tarifa bajo demanda.»

El funcionamiento hora a hora:

1. AWS mira tu consumo de cómputo elegible en esa hora y lo valora a tarifa de Savings Plan.
2. Aplica el compromiso hasta agotarlo, empezando por el uso con mayor porcentaje de descuento —lo hace automáticamente para maximizar tu ahorro—.
3. El uso que quede por encima del compromiso se factura a precio bajo demanda.
4. Si el consumo no llega al compromiso, la diferencia se paga igualmente. Ese es el riesgo, y es la única forma de perder dinero con un Savings Plan.

Tres consecuencias prácticas que conviene tener claras:

• El compromiso se expresa en dinero, no en capacidad. Si AWS baja los precios, tu compromiso cubre más máquinas.
• Es horario, no mensual. No hay compensación entre horas: una hora sin consumo no se recupera con una hora de mucho consumo. Por eso se dimensiona sobre el mínimo sostenido, no sobre la media.
• No reserva capacidad. Un Savings Plan no garantiza que haya máquinas disponibles; solo cambia el precio. Para garantizar capacidad hacen falta reservas zonales o bloques de capacidad.

Supongamos un compromiso de 0,17 USD/hora en un Compute Savings Plan a 1 año, con un descuento del 20 % sobre Fargate. Eso significa que 1 USD de uso bajo demanda cuesta 0,80 USD a tarifa de plan, y por tanto el compromiso de 0,17 USD/h cubre 0,2125 USD/h de uso a precio bajo demanda (0,17 ÷ 0,80).

Hora A: consumo exactamente igual al compromiso.

Hora B: consumo por encima del compromiso (pico del viernes, el doble de tareas).

Lección: el excedente no se penaliza, simplemente se paga a precio normal. Quedarse corto en el compromiso no tiene ningún castigo; solo significa que no aprovechas el descuento en esa parte.

Hora C: consumo por debajo del compromiso (madrugada de domingo, entornos apagados).

Aquí está todo el riesgo condensado. Esa hora ha costado un 70 % más de lo que habría costado sin el plan. Y no es una hipótesis rebuscada: es exactamente lo que pasa las noches y los fines de semana en cuanto se apagan los entornos no productivos, que es justo lo que MercadoFresco acaba de hacer en 11-03.

De ahí sale la regla de dimensionado que gobierna toda la decisión: el compromiso se fija por debajo del consumo mínimo sostenido de la hora más floja de la semana, no por la media y mucho menos por el pico.

Esta tabla es la que hay que consultar antes de comprar nada, y la que explica por qué MercadoFresco va a ahorrar menos de lo que esperaba:

Y aquí llega la conclusión incómoda para MercadoFresco, que conviene decir sin adornos porque es una lección general:

Una arquitectura mayoritariamente sin servidor tiene mucho menos margen de descuento por compromiso que una basada en instancias.

El detalle concreto: aurora-mercadofresco-pedidos funciona en Aurora Serverless v2, que se factura por ACU-hora y no admite instancias reservadas. Lo mismo ocurre con wg-mercadofresco-analitica, que es Redshift Serverless. Entre las dos suman 447,10 USD al mes que no se pueden comprometer de ninguna forma.

Esto no es una mala noticia disfrazada: es el otro lado de una decisión que ya rindió. Serverless ya ahorró antes, escalando a cero cuando no hay carga —recuérdese la comparación de 06-04, donde Redshift provisionado costaba 1.586 USD al mes frente a 16 de Serverless—. No se puede cobrar dos veces el mismo ahorro. Un clúster de Redshift provisionado con reserva a tres años saldría más barato por hora y muchísimo más caro al mes, porque estaría encendido las 730 horas.

Para lo que no cubren los Savings Plans y sí es provisionado, existen las instancias reservadas (RI). Funcionan de forma parecida pero se comprometen a recursos concretos, no a dinero por hora.

Lo que MercadoFresco puede reservar:

Solo una fila es accionable, y es la de ElastiCache. Los nodos de caché llevan meses encendidos las 730 horas del mes, su tamaño está validado y no hay ningún plan de cambiarlos: es el caso de libro para una reserva.

Las opciones que hay que decidir al comprar una reserva:

Dos avisos que evitan decepciones:

• Los Savings Plans no se pueden vender ni cancelar. El mercado de reventa existe solo para reservas estándar de EC2. Si compras un Compute Savings Plan y te sobra, te sobra durante todo el plazo.
• La flexibilidad de tamaño solo funciona dentro de la misma familia y sistema operativo. Una reserva de cache.t4g.medium cubre cache.t4g.small a media potencia, pero no cubre cache.r7g.large.

Para MercadoFresco: reserva de ElastiCache, estándar, regional, 1 año, pago parcial. Estándar porque el tamaño está validado y no hay intención de cambiar de familia; regional porque no hace falta garantizar capacidad; un año por la misma razón que el Savings Plan.

Spot es capacidad sobrante de AWS vendida con hasta un 90 % de descuento a cambio de poder retirarla con dos minutos de aviso. No hay compromiso ni plazo: es un precio, no un contrato.

MercadoFresco ya lo usa desde 10-02, con el reparto base=1, weight 1:4 en svc-mercadofresco-trabajadores: una tarea siempre bajo demanda y el resto mayoritariamente en Fargate Spot. El criterio que decidió dónde entra sigue siendo válido y merece repetirse, porque es el que evita el desastre:

Spot entra solo donde una interrupción con dos minutos de aviso se reintenta sola y nadie se entera.

Cargas que lo admiten en una arquitectura como esta:

Y una relación importante con lo anterior: el uso de Spot no consume el compromiso de un Savings Plan de cómputo, porque ya se factura con su propio descuento. Por tanto, al calcular la base estable sobre la que comprometerse, el consumo Spot se resta. Olvidarlo lleva a comprometer de más.

Este es el trabajo analítico que precede a cualquier compra. La pregunta: ¿cuánto cómputo elegible está encendido en la hora más floja de la semana?

La herramienta es la vista horaria de Cost Explorer, filtrada a Fargate y Lambda, excluyendo Spot, sobre las últimas cuatro semanas. El perfil de MercadoFresco tras las optimizaciones de 11-03:

Tres cifras y tres conclusiones:

• El mínimo sostenido es 0,214 USD/hora. Es lo que está encendido siempre, sin excepción, incluida la madrugada del domingo.
• La media es 0,328 USD/hora, un 53 % por encima del mínimo. Comprometerse por la media significaría desperdiciar compromiso todas las noches y todos los fines de semana.
• El pico es 0,690, más del triple del mínimo. Comprometerse por el pico sería un desastre.

La regla práctica: comprometerse entre el 70 % y el 85 % del mínimo sostenido en el primer plan. MercadoFresco elige 0,17 USD/hora, que es el 79 % del mínimo. Ese margen del 21 % cubre tres riesgos concretos:

1. Que se apague algo más de lo previsto en los próximos meses —hay optimizaciones pendientes—.
2. Que una parte del cómputo se mueva a Spot y deje de ser elegible.
3. Que un cambio de arquitectura reduzca el cómputo, como pasaría si alguna carga se pasa a un servicio no cubierto.

Cost Explorer ofrece recomendaciones de compra en Savings Plans → Recommendations, configurables por plazo, forma de pago y periodo de análisis (7, 30 o 60 días).

Para MercadoFresco, con 30 días y 1 año sin pago inicial, la recomendación es:

Y MercadoFresco no la sigue. Compra 0,17, no 0,29. Las razones son instructivas y valen para cualquier caso:

1. La recomendación asume que el futuro será igual que el pasado. Los 30 días analizados incluyen las dos primeras semanas anteriores al apagado nocturno de 11-03. La recomendación está calculada sobre un consumo que ya no existe.
2. Optimiza el ahorro esperado, no el riesgo. El algoritmo busca el punto que maximiza el ahorro medio; no sabe que en tres meses hay una migración planificada, ni que el equipo quiere probar a mover una carga a Lambda.
3. La utilización estimada del 98 % es una media mensual, no una garantía horaria. Con las noches apagadas, la utilización real de un compromiso de 0,29 sería mucho peor de lo que sugiere ese número.
4. Nadie de AWS pierde dinero si te pasas. La recomendación es honesta y está bien calculada, pero el incentivo no está alineado con el tuyo.

La forma correcta de usarlas: como punto de partida y como techo, nunca como decisión. Si la recomendación dice 0,29, se sabe que 0,29 es demasiado y que la respuesta está por debajo. Y siempre se contrasta con la vista horaria propia, que es el dato que la recomendación no puede tener en cuenta: tu conocimiento de lo que va a pasar.

Después del análisis, Marta lleva a gerencia una propuesta de dos líneas:

La justificación de cada decisión, escrita en el ADR-024:

• Compute y no EC2 Instance, porque el cómputo de MercadoFresco es Fargate y Lambda, que el EC2 Instance no cubre en absoluto.
• 0,17 USD/hora y no los 0,29 recomendados, porque es el 79 % del mínimo sostenido real posterior a las optimizaciones.
• Un año y no tres, porque en 10-03 se escribieron seis criterios objetivos que llevarían a MercadoFresco a migrar a EKS, y dos de ellos podrían cumplirse en dieciocho meses. Comprometerse tres años con una migración plausible en el horizonte es exactamente el error que esta lección enseña a evitar. Con el matiz de que un Compute Savings Plan sobreviviría a esa migración —EKS sobre Fargate sigue siendo Fargate—, pero no sobreviviría a un cambio de estrategia mayor.
• Sin pago inicial, porque los 4 puntos de descuento adicionales del pago total suponen unos 5 USD al mes a cambio de inmovilizar 1.489 USD durante un año. Para una empresa de este tamaño, el efectivo vale más.
• La compra se hace desde la cuenta de gestión para que el descuento se reparta automáticamente por toda la organización mediante la facturación consolidada.
• Los nodos de ElastiCache sí con pago parcial, porque el importe es pequeño y la certeza es total: llevan diez meses encendidos y no hay ningún plan de tocarlos.

El comando de compra —que en la práctica se ejecuta desde la consola después de revisar el resumen dos veces, porque no hay deshacer:

Tres notas sobre estos comandos:

• --commitment es USD por hora, no mensual ni anual. Escribir 170 en lugar de 0.17 compraría un compromiso mil veces mayor, y no hay forma de deshacerlo. Es el error más caro que se puede cometer en toda esta lección.
• --duration 31536000 son los segundos de un año. Tres años son 94608000.
• Etiquetar la compra permite verla en los informes con las mismas dimensiones que todo lo demás. Sí: hasta un compromiso financiero se etiqueta.

Y el balance completo del módulo, que es la cifra que se lleva a gerencia:

Conviene señalar la proporción, porque es la lección que más se repite en la práctica y la que menos se cuenta: de los 556 USD de ahorro, 488 vienen de apagar y limpiar, y solo 68 de comprometer. Es decir, el 88 % del ahorro se consiguió sin firmar nada. En una arquitectura mayoritariamente sin servidor, los compromisos son la guinda, no el plato principal.

Se confunden constantemente y miden cosas opuestas:

La clave está en que una utilización del 100 % es obligatoria y una cobertura del 100 % es un error:

• Utilización por debajo del 100 % significa que estás pagando compromiso que no usas. Cada punto perdido es dinero tirado. Si baja del 95 %, hay que investigar.
• Cobertura del 100 % significaría que todo tu consumo, incluido el pico del viernes, está comprometido. Como el pico no es sostenido, para llegar ahí habrías tenido que comprometer muchísimo más de la base, y estarías perdiendo dinero todas las noches.

Para MercadoFresco, con un compromiso de 0,17 sobre una media de 0,328:

Una cobertura del 65 % con utilización del 100 % es exactamente el punto correcto: se aprovecha todo lo comprometido y queda la parte variable pagándose bajo demanda, que es donde debe estar.

Un compromiso comprado y no vigilado es una fuga silenciosa. Tres mecanismos, en orden de importancia:

1. Presupuesto de utilización de Savings Plans (11-04), que es la forma más directa:

Con una notificación de tipo ACTUAL, operador LESS_THAN y umbral 95: avisa cuando la utilización baja de ese porcentaje. Es uno de los pocos usos legítimos de LESS_THAN en un presupuesto, y aquí es imprescindible.

2. Informes de utilización y cobertura en Cost Explorer, revisados en la reunión mensual junto al resto. Dos gráficos que se miran en diez segundos y que cuentan toda la historia.

3. Un aviso de vencimiento noventa días antes de que expire el plan. Los Savings Plans no se renuevan solos: el día que vence, todo el consumo vuelve a precio bajo demanda de golpe y la factura sube sin que nadie haya hecho nada. Una regla de EventBridge sobre la fecha de expiración, o simplemente una entrada en el calendario, evita esa sorpresa. La renovación es además el momento ideal para replantear el compromiso con un año de datos reales encima de la mesa.

El escenario que hay que anticipar antes de firmar. Supongamos que MercadoFresco hubiera comprado en 2024 un EC2 Instance Savings Plan a 3 años sobre la familia m5 en eu-west-1, dimensionado para su ASG de entonces. Y que en 2026, siguiendo el módulo 10, migra toda la tienda a Fargate con arm64.

El resultado: el compromiso deja de aplicarse por completo. No cubre Fargate, no cubre Graviton fuera de su familia, y quedaría un año pagando por capacidad que no se usa. Sobre un compromiso de unos 150 USD al mes, serían 1.800 USD tirados y, peor aún, un incentivo perverso a retrasar la migración para no desperdiciar el plan. Ese es el daño real de un compromiso mal elegido: no solo cuesta dinero, sino que condiciona decisiones técnicas.

De ahí las tres reglas de MercadoFresco:

1. Compute Savings Plan por defecto, aunque dé algo menos de descuento. Sobrevive a la mayoría de los cambios: EC2 a Fargate, x86 a arm64, cambio de región, parte a Lambda.
2. Un año mientras haya cualquier cambio plausible en el horizonte. Tres años solo para la parte de la arquitectura que lleve años sin moverse y no tenga alternativa a la vista.
3. Antes de comprometer, revisar el registro de decisiones de arquitectura (11-01). Si hay un ADR que contempla un cambio en los próximos dos años, ese cambio afecta a la decisión de compra.

Y si aun así el plan se queda sin uso, las opciones son escasas y conviene conocerlas de antemano: un Compute Savings Plan no se cancela, no se reduce y no se vende. Lo único que se puede hacer es darle uso: mover cargas a servicios cubiertos, adelantar migraciones que estaban previstas, o dejar encendido algo que se iba a apagar —lo cual es absurdo, pero es exactamente lo que acaba haciendo la gente—.

Con facturación consolidada (09-04), un Savings Plan comprado en cualquier cuenta se aplica al uso de todas las cuentas de la organización, empezando por la que lo compró y siguiendo por el resto en orden de mayor descuento.

Este comportamiento se controla con el ajuste de compartición de descuentos (Discount sharing), que se configura en las preferencias de facturación de la cuenta de gestión:

MercadoFresco la deja activada, que es lo correcto en su caso: hay un solo presupuesto y el objetivo es que el compromiso se aproveche al máximo, venga de donde venga el consumo. Con dos consecuencias que conviene tener presentes:

• El descuento aparece en la cuenta que consume, no en la que compró. El coste amortizado de 11-03 es la métrica que refleja bien esto; el no combinado, no.
• Comprar desde la cuenta de gestión es la práctica recomendada precisamente por eso: la gestión no consume casi nada, así que el compromiso se reparte por donde de verdad hay uso, y la propiedad del contrato queda donde está el control financiero.

Los tres que arruinan una compra, en orden de frecuencia:

1. Comprometer antes de optimizar. Es el error de orden y el más caro de todos. Si MercadoFresco hubiera comprado un Savings Plan en agosto, sobre un consumo de cómputo de 262,40 USD, y en septiembre hubiera ejecutado las diez optimizaciones de 11-03 —que bajan ese consumo un 24 %—, el compromiso sobrante se pagaría durante todo el plazo. El orden correcto no admite excepciones: primero apagar lo que sobra, después dimensionar lo que queda, y solo entonces comprometer.

2. Comprometer demasiado. Nace de dimensionar sobre la media o sobre la recomendación automática en lugar de sobre el mínimo sostenido. El síntoma es una utilización por debajo del 100 % desde el primer mes, y no tiene arreglo hasta el vencimiento.

3. Confundir cobertura con utilización. Alguien ve una cobertura del 65 % y concluye que hay que comprar más. Es exactamente al revés: una cobertura del 65 % con utilización del 100 % está bien; subir la cobertura al 90 % obligaría a comprometer por encima del mínimo sostenido y haría bajar la utilización. La pregunta correcta nunca es «¿cuánta cobertura tengo?» sino «¿estoy aprovechando todo lo que pago?».

Error: comprar un EC2 Instance Savings Plan teniendo la carga en contenedores. Da más descuento sobre el papel y cubre exactamente cero de tu consumo. Consejo: comprueba la tabla de cobertura antes de mirar los porcentajes. Fargate y Lambda solo los cubre el Compute.

Error: escribir el compromiso en unidades equivocadas. --commitment es USD por hora. Poner el importe mensual multiplica el compromiso por 730 y no hay deshacer. Consejo: revisa el resumen de la compra dos veces y compáralo con tu vista horaria antes de confirmar.

Error: dimensionar por la media. La media de MercadoFresco es 0,328 y su mínimo sostenido 0,214. Comprometer por la media significa desperdiciar todas las noches y todos los fines de semana. Consejo: el compromiso se fija entre el 70 y el 85 % del mínimo sostenido.

Error: comprar a tres años en la primera compra. El descuento seduce y el plazo supera la vida media de una decisión de arquitectura. Consejo: primer plan a un año; a la renovación, con datos reales, se plantea el plazo largo sobre la parte demostradamente estable.

Error: incluir el consumo Spot en el cálculo de la base. Spot ya tiene su descuento y no consume compromiso, así que comprometer sobre él es comprometer sobre nada. Consejo: excluye Spot del filtro de la vista horaria antes de calcular el mínimo.

Error: esperar que el plan cubra RDS, ElastiCache o Redshift. No los cubre ninguno de los tres tipos. Consejo: para eso están las instancias reservadas, y solo si el recurso es provisionado: Serverless no admite reservas.

Error: olvidar la fecha de vencimiento. El plan expira, todo vuelve a precio bajo demanda y la factura sube sin que nadie haya tocado nada. Consejo: aviso 90 días antes y renovación tratada como una decisión nueva, no como un trámite.

Error: dejar que el compromiso condicione la arquitectura. «No migramos todavía porque desaprovecharíamos el plan» es una frase que se oye demasiado. Consejo: si un compromiso mal elegido está frenando una decisión técnica correcta, asume la pérdida y sigue adelante. El coste de una arquitectura peor durante dos años supera con creces al del plan desperdiciado.

Consejo: compra desde la cuenta de gestión y deja la compartición activada. Es lo que hace que el compromiso se aproveche donde de verdad hay consumo.

Consejo: escribe un ADR para la compra. Un compromiso de uno o tres años es una decisión de arquitectura con consecuencias financieras: merece el mismo tratamiento que cualquier otra, con sus alternativas descartadas y su fecha de revisión.

Una empresa ficticia, TallerNube, tiene este perfil de cómputo elegible (EC2 y Fargate, sin Spot) medido durante cuatro semanas:

1. Calcula la media horaria del mes y compárala con el mínimo.
2. Propón un compromiso y justifica el porcentaje elegido.
3. Con un descuento del 22 %, calcula el ahorro mensual y anual.
4. La recomendación automática de AWS propone 1,95 USD/hora. ¿La seguirías? ¿Por qué?

Para cada una de estas cargas, indica qué modelo de compra usarías y por qué:

1. Un clúster de Aurora provisionado db.r6g.large Multi-AZ, encendido 24/7 desde hace dos años.
2. Un servicio de Fargate que escala entre 2 y 20 tareas según la hora.
3. Un proceso nocturno de transformación de datos que tarda 3 horas y se puede reintentar.
4. Un clúster de Redshift Serverless que se usa 2 horas al día.
5. Una flota de 40 instancias m6i.xlarge que llevan tres años sin cambiar y no se prevé migrar.
6. Una función Lambda invocada 4 millones de veces al mes con duración media de 200 ms.

Tres meses después de comprar un Compute Savings Plan de 0,30 USD/hora a un año, los informes muestran:

1. ¿Cuál es el problema y cuál no lo es?
2. Enumera tres causas posibles, ordenadas por probabilidad.
3. ¿Qué opciones hay para arreglarlo y cuál recomendarías?

Solución al ejercicio 1

(1) Media horaria. Sobre una semana tipo de 168 horas, con el pico repartido (17 horas al mes ≈ 4 horas semanales, que salen del horario laboral):

La media (1,471) está un 34 % por encima del mínimo sostenido (1,10). Comprometerse por la media supondría desperdiciar 0,371 USD/hora durante las 96 horas semanales de valle: unas 39,7 USD semanales tiradas, más de 170 USD al mes.

(2) Compromiso propuesto: 0,88 USD/hora, que es el 80 % del mínimo sostenido. El margen del 20 % cubre lo previsible: que alguna carga se mueva a Spot, que se apague algún entorno, o que una optimización pendiente reduzca el consumo base. Si TallerNube tiene ya hechas todas sus optimizaciones y una previsión de crecimiento firme, se podría subir a 0,93 (85 %), pero no más en una primera compra.

(3) Ahorro con un descuento del 22 %:

(4) La recomendación de 1,95 USD/hora no se sigue. Está por encima incluso de la media horaria (1,471) y casi duplica el mínimo sostenido (1,10). Con ese compromiso, TallerNube pagaría 0,85 USD/hora de compromiso no utilizado durante las 96 horas semanales de valle —unas 353 USD al mes tiradas—, que superarían con creces el ahorro obtenido en las horas de actividad. Es un ejemplo perfecto de por qué la recomendación es un punto de partida y no una decisión: probablemente esté calculada sobre un periodo con un pico atípico, o esté optimizando el ahorro esperado sin ponderar el riesgo de las horas valle.

Solución al ejercicio 2

La observación transversal del ejercicio: de seis cargas, cuatro modelos distintos. No existe «el mejor modelo de compra», existe el adecuado para cada perfil de consumo.

Solución al ejercicio 3

(1) Cuál es el problema. El problema es la utilización del 78 %: se está pagando el 22 % del compromiso sin recibir nada a cambio, unos 48,20 USD al mes, que son 578 USD si sigue así todo el año. La cobertura del 71 % no es un problema en absoluto; de hecho está en la banda razonable. Quien mire solo la cobertura concluirá que todo va bien, y es justo la confusión que esta lección advierte.

(2) Tres causas posibles, por probabilidad:

1. Se comprometió por encima del mínimo sostenido, probablemente dimensionando sobre la media o siguiendo la recomendación automática. Es la causa más frecuente con diferencia, y el síntoma característico es que la utilización sea mala desde el primer mes.
2. Algo se apagó o se optimizó después de comprar: un entorno con apagado nocturno, una migración a arm64, una carga movida a Spot o a un servicio no cubierto. El síntoma sería una utilización buena al principio que empeora en un momento identificable.
3. Una parte del cómputo dejó de ser elegible: se movió a Spot —que no consume compromiso— o a un servicio que el plan no cubre, como pasar un trabajo por lotes de Fargate a AWS Batch sobre capacidad Spot.

Para distinguirlas basta con mirar la serie temporal de utilización desde la compra: plana y baja apunta a la causa 1; con un escalón, a la 2 o a la 3, y la fecha del escalón señala qué ocurrió.

(3) Opciones y recomendación. Las opciones reales son pocas, porque un Savings Plan no se cancela, no se reduce y no se vende:

Recomendación: una combinación de la segunda y la cuarta. Primero, revisar si hay migraciones ya planificadas hacia servicios cubiertos que puedan adelantarse; eso convierte compromiso desperdiciado en descuento real sin distorsionar ninguna decisión. Lo que quede, se asume. Y sobre todo, se documenta el porqué para que la renovación no repita el error: compromiso al 75-80 % del mínimo sostenido, calculado sobre datos posteriores a las optimizaciones y excluyendo Spot.

Lo que no se debe hacer bajo ningún concepto es dejar de optimizar para «rentabilizar» el plan. Sería exactamente el incentivo perverso que esta lección advierte: el compromiso pasaría de ser una herramienta de ahorro a ser un freno para la arquitectura.

MercadoFresco ha cerrado el ciclo de optimización con la única palanca que reduce la factura sin tocar una línea de la arquitectura.

Sabes por qué existe el descuento por compromiso —AWS construye centros de datos por adelantado y paga por la previsión de demanda— y las cuatro consecuencias que se deducen solas de esa lógica: más plazo, más pago inicial y menos flexibilidad dan más descuento, y el riesgo se traslada íntegro al cliente. Con los cuatro modelos de compra y el árbol de decisión que los ordena: Spot si la carga tolera interrupciones, bajo demanda si el consumo es impredecible, Savings Plans para EC2, Fargate y Lambda, e instancias reservadas para todo lo demás que sea provisionado.

Tienes los tres tipos de Savings Plans con la comparación que de verdad importa: el EC2 Instance da 6-8 puntos más y te ata a una familia y una región; el Compute da algo menos y sobrevive a cambios de instancia, de región, de arquitectura de CPU y de servicio. Y sabes por qué para MercadoFresco no hay debate: su cómputo es Fargate y Lambda, que el EC2 Instance no cubre en absoluto.

Tienes el mecanismo del compromiso por dólar-hora entendido de verdad, con las tres horas del ejemplo: la hora que consume exactamente lo comprometido y ahorra un 20 %, la hora de pico donde el excedente no se penaliza y simplemente se paga a precio normal, y la hora de madrugada donde el compromiso no utilizado se paga igual y hace que esa hora cueste un 70 % más de lo que habría costado sin el plan. De ahí la regla que gobierna todo: se dimensiona por el mínimo sostenido de la hora más floja de la semana, nunca por la media y muchísimo menos por el pico.

Tienes la tabla de cobertura y la conclusión incómoda que se deriva de ella para una arquitectura como esta: los 342,60 USD de Aurora Serverless v2 y los 104,50 de Redshift Serverless no se pueden comprometer de ninguna forma. Y su interpretación correcta, que no es una queja: serverless ya cobró ese ahorro por adelantado, escalando a cero cuando no hay carga, y no se puede cobrar dos veces el mismo ahorro.

Tienes las instancias reservadas para lo que los planes no alcanzan, con sus decisiones —estándar frente a convertible, alcance regional frente a zonal, capacidad reservada, mercado de reventa solo para RI estándar de EC2— y Spot revisado desde el coste, con el criterio que decide dónde entra y el detalle que se olvida: el consumo Spot no consume compromiso, así que se resta al calcular la base.

Tienes el análisis completo: el perfil horario de MercadoFresco con su mínimo sostenido de 0,214 USD/hora, su media de 0,328 y su pico de 0,690; la regla del 70-85 % del mínimo; y la razón por la que se compran 0,17 y no los 0,29 recomendados por AWS, con las cuatro razones que hacen que una recomendación automática sea un punto de partida y nunca una decisión, empezando por la más determinante: asume que el futuro será igual que el pasado, y ese pasado incluía un consumo que las optimizaciones de 11-03 acababan de eliminar.

Tienes el plan de compra con su ADR: Compute Savings Plan de 0,17 USD/hora a un año sin pago inicial desde la cuenta de gestión, más dos nodos reservados de ElastiCache a un año con pago parcial. Y el resultado: 68,00 USD al mes, 816 USD al año, que dejan la factura en 1.681,60 USD y el coste por pedido en 0,00934 USD. Con el balance completo del módulo —de 2.237,60 a 1.681,60 USD, un 24,8 % menos y 6.672 USD anuales— y la proporción que conviene no olvidar nunca: el 88 % del ahorro vino de apagar y limpiar, y solo el 12 % de comprometer.

Y tienes el seguimiento: cobertura y utilización como métricas opuestas, con la regla que las ordena —la utilización debe ser del 100 % y la cobertura no debe serlo—, el presupuesto de tipo SAVINGS_PLANS_UTILIZATION con operador LESS_THAN al 95 %, el aviso de vencimiento noventa días antes porque los planes no se renuevan solos, el reparto entre cuentas con la compartición de descuentos activada, y los tres errores caros: comprometer antes de optimizar, comprometer demasiado, y confundir cobertura con utilización. Más el daño menos evidente y más grave de un compromiso mal elegido: que condicione decisiones técnicas, convirtiendo «no migramos para no desperdiciar el plan» en una frase que alguien dice en serio.

Con esto, el pilar de optimización de costes que abría el plan de mejora de 11-01 queda cerrado: hay visibilidad, hay asignación, hay análisis, hay límites y hay compromisos. La factura es legible, está controlada y cuesta un 24,8 % menos que hace dos meses, con el mismo servicio y las mismas garantías.

Y con eso, MercadoFresco tiene la arquitectura completa y gobernada: elástica, segura, observable, desplegable, descrita en código, repartida en cinco cuentas, auditada con método y ahora también medida y presupuestada. Once módulos de decisiones, cada una con su porqué.

Queda una última cosa por hacer, y no es aprender un servicio nuevo. En 11-06, el proyecto final, se recorre la arquitectura entera de MercadoFresco asociando cada pieza al módulo donde se aprendió, se cierra el balance de los cinco problemas que abrieron el curso con su métrica, y se plantea el reto que lo integra todo: MercadoFresco abre en Portugal y Francia y lanza una aplicación móvil con seguimiento del reparto en tiempo real. Con su enunciado, su rúbrica, una solución de referencia comentada, los caminos de certificación, lo que este curso no ha tocado, y la limpieza final de todo lo creado.