El rightsizing (subcapítulo 25.3) ahorra ajustando el tamaño de los recursos. Ahora veremos otra palanca de ahorro muy potente, pero por un camino distinto: conseguir descuentos importantes (de hasta el 70 %) a cambio de comprometerte a usar AWS durante un tiempo. Las dos formas de hacerlo son los Savings Plans y las Reserved Instances. Entender la diferencia te puede ahorrar muchísimo dinero.

Por defecto, en AWS pagas bajo demanda (on-demand): usas un recurso una hora, pagas esa hora, sin ataduras. Es flexible, pero es la opción más cara. AWS te ofrece un trato: si te comprometes a usar cierta cantidad de recursos durante 1 o 3 años, te hacen un gran descuento (puede llegar al 70 %).

Analogía: es como el abono del transporte público frente al billete suelto. El billete suelto (bajo demanda) lo compras cuando quieres, sin compromiso, pero sale caro si viajas mucho. El abono mensual o anual (el compromiso) requiere que pagues por adelantado un periodo, pero el precio por viaje es mucho más barato. Si sabes que vas a usar el transporte de forma constante, el abono te ahorra mucho. AWS funciona igual: si sabes que vas a usar recursos de forma continua, comprometerte sale muy a cuenta.

Esto tiene sentido para AWS (les garantizas uso estable, pueden planificar) y para ti (pagas mucho menos por lo que ibas a usar igualmente).

La clave es la previsibilidad. El compromiso conviene para la parte de tu uso que es estable y constante, esa «base» que sabes que vas a necesitar sí o sí durante meses o años:

La estrategia inteligente: cubre tu uso base (lo que siempre necesitas) con compromisos (descuento), y deja los picos variables bajo demanda (flexibilidad). Así combinas ahorro y flexibilidad.

⚠️ El riesgo del compromiso: si te comprometes a usar cierta cantidad y luego no la usas (porque tu proyecto se redujo o cambió), pagas igual (ya te comprometiste). Por eso solo debes comprometer la parte que estés seguro de que usarás. Para lo incierto, mejor bajo demanda.

Las Reserved Instances (RI) son la forma clásica de comprometerse, y son específicas: reservas un tipo concreto de recurso (por ejemplo, «un servidor de tipo X en la región Y») durante 1 o 3 años, a cambio del descuento. Como son específicas, son algo rígidas: el descuento se aplica a ese tipo concreto.

Los Savings Plans son la opción más moderna y flexible. En vez de comprometerte a un tipo concreto de recurso, te comprometes a gastar cierta cantidad de dinero por hora (por ejemplo, «me comprometo a gastar al menos 10 € por hora en cómputo») durante 1 o 3 años, y obtienes el descuento. La gran ventaja: ese compromiso se aplica flexiblemente a lo que uses (distintos tipos de servidor, distintas regiones, incluso Lambda o Fargate, según el plan).

Analogía: una Reserved Instance es como un abono para una línea de metro concreta (solo te sirve para esa línea). Un Savings Plan es como un abono de transporte que vale para metro, bus y tren indistintamente: te comprometes a un gasto, pero lo aprovechas en lo que necesites. Mucho más flexible si tus necesidades cambian.

Recomendación general: para la mayoría de los casos, los Savings Plans son la opción preferida hoy por su flexibilidad (consigues un descuento similar pero te adaptas mejor a los cambios). Las Reserved Instances siguen teniendo sentido en casos muy específicos y estables.

Ejemplo del mundo real: una empresa lleva tiempo en AWS y ve, con Cost Explorer, que tiene un uso base muy estable de cómputo (sus aplicaciones de producción funcionan 24/7 todo el año). Hasta ahora pagaban todo bajo demanda. Contratan un Savings Plan a 1 año que cubre ese uso base, comprometiéndose a un gasto por hora que saben que van a tener igualmente. Resultado: un 55 % de descuento sobre esa parte de su factura, sin cambiar nada en su infraestructura. Y como eligieron un Savings Plan (no RI), cuando luego migraron algunos servidores a otros tipos, el descuento se siguió aplicando automáticamente. Dejaron los picos puntuales bajo demanda para mantener flexibilidad.

💡 Orden importante: haz primero el rightsizing y luego compra Savings Plans. Si te comprometes a recursos sobredimensionados, estarías «atando» un desperdicio durante años. Ajusta el tamaño primero, y compromete solo lo que de verdad necesitas.

• Por defecto pagas bajo demanda (flexible pero más caro). AWS ofrece grandes descuentos (hasta ~70 %) a cambio de comprometerte a usar recursos 1 o 3 años. Como el abono de transporte frente al billete suelto.
• Conviene para tu uso base estable y previsible; deja los picos variables bajo demanda. ⚠️ Si te comprometes y no lo usas, pagas igual: compromete solo lo seguro.
• Reserved Instances (RI): forma clásica, comprometes un tipo concreto de recurso. Más rígidas.
• Savings Plans: forma moderna y flexible, comprometes una cantidad de gasto por hora que se aplica automáticamente a lo que uses (distintos tipos, regiones, Fargate/Lambda). Recomendados en general por su flexibilidad.
• 💡 Haz primero el rightsizing y luego compra compromisos, para no «atar» recursos sobredimensionados.

En el último subcapítulo del capítulo veremos la disciplina que engloba toda esta gestión de costes como práctica de equipo: FinOps.