Resumen

  • Savings Plans ofrece precios menores a cambio de comprometer una cantidad monetaria de uso por hora durante uno o tres años. AWS dice expresamente que no reserva capacidad y que no puede cancelarse durante el plazo.
  • Una On-Demand Capacity Reservation sí mantiene capacidad EC2 compatible en una zona de disponibilidad, pero cobra el equivalente On-Demand tanto si la plaza se ocupa como si queda vacía.
  • La rebaja y la capacidad pueden combinarse. Savings Plans o el descuento de una Reserved Instance regional pueden aplicarse a la Capacity Reservation, sin convertirla en garantía de que la aplicación estará sana.
  • Utilización, cobertura, ocupación, lanzamiento y disponibilidad del servicio son cinco registros distintos.

Tres recibos detrás de una palabra

El primer recibo es financiero. Savings Plans exige un compromiso de uso de cómputo medido en dinero por hora durante uno o tres años. El pago puede ser total al inicio, parcial o sin anticipo. La última modalidad no elimina la obligación: sólo distribuye el desembolso.

Compute Savings Plans busca flexibilidad. Su tarifa puede seguir uso elegible de EC2 entre familias, tamaños, sistemas operativos, tenancies y regiones, además de Fargate y Lambda. EC2 Instance Savings Plans reduce el campo a una familia dentro de una región. AWS anuncia descuentos máximos de 66% y 72%, respectivamente. El ahorro real depende de plazo, pago, uso elegible y asignación; el máximo no es una rentabilidad garantizada.

El contrato no se convierte en capacidad cuando no se usa. AWS explica que Savings Plans no reserva capacidad y no admite cancelación durante el plazo. Si una migración, una adquisición o una caída de demanda reduce el consumo, el reloj monetario continúa.

AWS ofrece un indicador adecuado para ese riesgo. La utilización compara el compromiso con el uso que recibió las tarifas del plan. US$9,80 de consumo con un compromiso de US$10 por hora equivalen a 98%. El número demuestra que la promesa de gasto encontró trabajo elegible. No indica si una instancia específica podrá arrancar mañana.

El segundo recibo es de colocación. Una On-Demand Capacity Reservation mantiene un número de instancias con tipo, plataforma, zona y tenancy determinados. La capacidad activa aunque vacía cuenta además dentro de los límites On-Demand de la cuenta.

Su factura se parece a la de una opción ejercida o no. AWS cobra el equivalente de la tarifa On-Demand mientras la reserva esté aprovisionada. Con veinte plazas y quince instancias compatibles en ejecución, el cliente paga quince instancias activas y cinco plazas sin usar. No hay un recargo adicional para las ocupadas, pero las vacías no son gratuitas.

El tercer recibo es operativo. Incluso con capacidad pagada, el lanzamiento debe coincidir con los atributos y dirigirse correctamente a una reserva activa que conserve cantidad disponible. Después del arranque, todavía faltan salud de la aplicación, datos, red, dependencias y recuperación. Ningún producto de compra puede certificar por sí solo esa cadena.

La rebaja puede cubrir la plaza

AWS permite que una Savings Plan o una Reserved Instance regional aplique su descuento a una Capacity Reservation. La combinación no es redundante. La reserva mantiene la posibilidad de colocar instancias compatibles; el plan reduce el precio aplicable al uso o a la capacidad facturable.

Esto permite cuatro situaciones. Un cliente puede tener descuento sin reserva de capacidad. Puede tener capacidad reservada a precio On-Demand sin descuento. Puede superponer ambos. También puede pagar ambos y no ejecutar un servicio útil porque el lanzamiento o la aplicación estén mal configurados.

La evaluación económica debe respetar las cuatro. Una plaza vacía durante una ventana de recuperación no es automáticamente un error: puede ser el coste de una opción necesaria. Pero una reserva que nunca se prueba, no coincide con las plantillas actuales o protege una arquitectura abandonada necesita una justificación nueva. Del mismo modo, un plan utilizado al 100% puede ser una buena compra financiera y dejar sin protección un pico zonal.

El lanzamiento tiene una llave exacta

Las reglas de lanzamiento obligan a hacer coincidir tipo de instancia, plataforma, zona y tenancy. La reserva debe estar activa y disponer de cantidad libre.

En una reserva abierta, una instancia compatible puede ocuparla automáticamente. Si no hay coincidencia, ciertas preferencias permiten usar capacidad On-Demand ordinaria. Una reserva dirigida cambia el comportamiento: si la identificación seleccionada no tiene capacidad adecuada, el lanzamiento puede fallar. Por eso una plantilla en otra zona o con otra plataforma puede dejar ocioso el activo contratado mientras una solicitud busca capacidad fuera de él.

Sin reserva, el descuento no mejora la prioridad de lanzamiento. AWS documenta InsufficientInstanceCapacity cuando no hay capacidad On-Demand suficiente para una solicitud. Savings Plans pudo haber reducido cada factura anterior correctamente. Nunca prometió resolver esa escasez.

Una instancia que ocupa la reserva tampoco demuestra continuidad. Puede arrancar sin pasar los controles de salud, sin alcanzar la base de datos o sin poseer una réplica actualizada. La disponibilidad del recurso es una condición; el servicio al usuario es un resultado posterior.

Dos Reserved Instances con el mismo precio

La división entre Reserved Instances regionales y zonales elimina cualquier confianza en el nombre. La RI regional no reserva capacidad. Su descuento puede moverse entre zonas de la región y, en casos compatibles, entre tamaños. La RI zonal reserva capacidad en una zona concreta, pero pierde flexibilidad entre zonas y tamaños.

AWS indica que el alcance no altera el precio de la RI. Dos contratos con coste equivalente y nombre común entregan derechos operativos diferentes. Para comparar ofertas hay que registrar alcance, no sólo porcentaje de descuento.

La lección para compras es incómoda pero útil. La flexibilidad tiene valor cuando la arquitectura cambia; la precisión tiene valor cuando un lanzamiento debe ocurrir en un lugar concreto. Un contrato más rígido puede sostener continuidad o atrapar una configuración obsoleta. Un contrato flexible puede conservar la economía y dejar el riesgo de capacidad intacto.

AWS decide dónde cae el descuento

La asignación de Savings Plans no queda fijada a un proyecto. AWS aplica primero las Reserved Instances, después EC2 Instance Savings Plans y luego Compute Savings Plans. Dentro del uso elegible, dirige el compromiso hacia los porcentajes de ahorro más altos hasta agotarlo. Lo restante paga tarifa On-Demand.

Con facturación consolidada, el uso de la cuenta propietaria entra primero y otras cuentas pueden recibir el beneficio si compartir está activado. Así, una organización puede mostrar utilización plena mientras el servicio que justificó la compra desaparece y otro consumo absorbe el plan. La cartera está usando bien el descuento; la tesis original no queda probada.

La cobertura añade la vista inversa: qué proporción del uso aplicable fue cubierta por Savings Plans. Cobertura y utilización son porcentajes con denominadores distintos. Ninguno cuenta plazas disponibles ni lanzamientos exitosos.

Fuentes