El problema
La capacidad para familias de instancias GPU de EC2 como P5, P4d, G7, G6 y G5 puede escasear, sobre todo en periodos de alta demanda. Cuando detienes una instancia, esta vuelve al pool compartido y no hay garantía de que esté disponible cuando quieras volver a iniciarla.
Esto convierte el mantenimiento rutinario en una apuesta. Apenas detienes una instancia GPU para parchar un driver, rotar una AMI, redimensionar el volumen root o aplicar una actualización del sistema operativo, esa capacidad queda a disposición de cualquier otro cliente de AWS.
Si la demanda es alta, puedes toparte con un error InsufficientInstanceCapacity al intentar iniciarla de nuevo, y tu "ventana de mantenimiento de 10 minutos" se transforma en horas de reintentos o, peor aún, en una caída mientras esperas a que se libere capacidad.
Qué hace realmente una On-Demand Capacity Reservation
Una On-Demand Capacity Reservation (ODCR) de EC2 reserva capacidad de cómputo para un tipo de instancia específico, en una Availability Zone específica, mientras mantengas la reserva activa. Lo clave es que la capacidad queda apartada para ti, esté o no corriendo una instancia en ese momento.
Ese último punto es lo que convierte a las ODCR en la herramienta indicada para el mantenimiento. Cuando detienes una instancia que está usando una reserva, el cómputo reservado sigue disponible para ti. AWS mantiene esa capacidad asignada exclusivamente a tu cuenta. Cuando vuelvas a iniciar la instancia, AWS te garantiza que la capacidad reservada estará disponible.
Algunas características importantes
A diferencia de lo que sugiere el nombre, una Capacity Reservation inmediata no es un compromiso a largo plazo. Simplemente garantiza que la capacidad de EC2 que necesitas esté disponible en el momento que la necesites. Si tus planes cambian o ya no necesitas esa capacidad reservada, puedes cancelar la reserva cuando quieras. No hay comisiones por cancelación ni periodos mínimos de compromiso.
El costo de una Capacity Reservation es el mismo que el de correr una instancia On-Demand de EC2. Si tienes un Savings Plan aplicable o Reserved Instances, el precio con descuento también aplica a la Capacity Reservation. La única diferencia es que sigues pagando por la capacidad reservada incluso mientras la instancia está detenida, hasta que canceles la Capacity Reservation o inicies la instancia.
Por qué esto importa justamente en tareas de mantenimiento
Paradójicamente, el mantenimiento suele ser el momento en que estás más expuesto. Apenas detienes tu instancia, su capacidad regresa al pool compartido de AWS. Si otro cliente de AWS lanza una instancia equivalente en la misma Availability Zone antes de que reinicies la tuya, puede quedarse con la capacidad que antes respaldaba tu instancia, y una ventana de mantenimiento planeada termina convertida en una caída inesperada.
Operaciones de stop/start
Muchas tareas de mantenimiento requieren un stop/start completo en lugar de un reboot:
- Migrar a una nueva AMI
- Modificar ciertos atributos de la instancia
Cada una de estas acciones devuelve la instancia al pool de capacidad compartida.
Mantenimiento progresivo en una flota
Si estás parchando una flota nodo por nodo, normalmente drenas y detienes una instancia a la vez. Sin capacidad reservada, cada nodo que apagues podría no volver a levantarse, y puedes terminar con una flota permanentemente más pequeña que la inicial.
Eventos de hardware programados
De vez en cuando, AWS programa mantenimiento en el host subyacente (por ejemplo, por hardware degradado o retiro del host). Contar con una Capacity Reservation te garantiza el cómputo cuando detienes e inicias la instancia para migrarla fuera del host afectado.
Cómo usarla en la práctica
En la Consola de EC2, crea una On-Demand Capacity Reservation abierta que coincida con:
- El tipo de instancia
- La Availability Zone
- El sistema operativo (Platform)
Dimensiona la Capacity Reservation para que coincida con el número total de instancias del mismo tipo (por ejemplo, g7.xlarge) que tengas en esa Availability Zone durante la operación de mantenimiento progresivo.
Confirma que tus instancias estén consumiendo la reserva. Por defecto, las instancias EC2 usan automáticamente una Capacity Reservation abierta cuando hay una reserva coincidente disponible. Verifica que las Capacity Reservations que creaste realmente estén siendo aprovechadas por tus instancias.
Las Capacity Reservations también soportan casos de uso más avanzados, como Capacity Reservations dirigidas a workloads específicos. Esos escenarios quedan fuera del alcance de este artículo.
Haz tu mantenimiento como de costumbre:
- Detén la instancia.
- Aplica los cambios necesarios.
- Vuelve a iniciar la instancia.
Como la capacidad sigue reservada, la instancia arranca sin competir por la capacidad de GPU disponible.
Una vez terminado el mantenimiento, cancela la Capacity Reservation si ya no la necesitas. Tus instancias seguirán corriendo con normalidad.
¿Cuánto costó?
Para ver exactamente cuánto pagaste por la capacidad reservada mientras tus instancias estuvieron detenidas, espera unas 48 horas después de terminar el mantenimiento. Los datos de AWS Billing no son en tiempo real y estos cargos pueden tardar hasta dos días en aparecer.
Una vez actualizados los datos de facturación:
- Abre AWS Billing → Bills.
- Busca "Unused Reservation".
Verás una línea que muestra:
- El tipo de instancia
- El monto que se te cobró por la Capacity Reservation mientras no estaba siendo usada por una instancia en ejecución
Esta es una forma sencilla de medir el costo de garantizar la capacidad durante tu ventana de mantenimiento.
En mi caso, el mantenimiento tomó menos de 30 minutos. Sin una Capacity Reservation, podría haber estado esperando horas a que se liberara capacidad de GPU.
En resumen
La escasez de capacidad es parte inevitable de operar workloads en un entorno cloud compartido. Por suerte, AWS ofrece una manera sencilla de eliminar esa incertidumbre justo cuando más importa.
Si vas a hacer mantenimiento en instancias GPU, o en cualquier tipo de instancia EC2 con capacidad escasa, una Capacity Reservation temporal puede marcar la diferencia entre una ventana de mantenimiento rutinaria y horas de downtime inesperado.