Introducción
La disponibilidad de recursos en la nube ha dejado de ser un supuesto abstracto para convertirse en una restricción física y contractual tangible. Andy Jassy, CEO de Amazon, confirmó que la capacidad comprometida a gran escala de AWS está mayormente vendida hasta 2027, con una parte significativa de 2028 ya asignada. Esta realidad no implica que sea imposible desplegar instancias hoy, pero sí altera drásticamente la planificación estratégica para equipos de infraestructura y SRE.
El problema concreto es la fragmentación entre la capacidad «hiperescale» reservada por grandes proveedores de modelos de IA y los recursos On-Demand necesarios para cargas de trabajo empresariales estándar. Los equipos que dependen exclusivamente de instancias Spot o On-Demand sin reservas adecuadas están experimentando ya errores de capacidad (InsufficientInstanceCapacity) en clústeres Kubernetes de producción y pipelines de CI. Esta guía detalla cómo navegar este escenario, distinguiendo entre la escasez de bloques pre-reservados y la disponibilidad diaria, y presenta herramientas para auditar tu eficiencia de reserva actual.
Qué es y para qué sirve
AWS maneja dos mecanismos principales para asegurar capacidad: On-Demand Capacity Reservations (ODCR) y Capacity Blocks for ML. Los primeros garantizan que las instancias EC2 estén disponibles en una zona de disponibilidad específica, independientemente de la demanda global del momento. Los segundos son bloques de tiempo fijo para instancias GPU especializadas (como P5en o Trn2), esenciales para entrenamiento e inferencia masiva. La declaración de Jassy se refiere a que los grandes contratos de estos bloques han absorbido el margen de crecimiento previsto en los centros de datos actuales.
Para un arquitecto de soluciones, esto significa que la estrategia de «solo pagar por lo que usas» tiene un límite operativo cuando la física del data center impone restricciones. No basta con tener presupuesto; se necesita garantía de acceso. Mientras que las instancias estándar (m5.large, c5.xlarge) suelen seguir disponibles para uso diario, los picos de demanda y las zonas geográficas específicas pueden generar fricción. El objetivo de esta guía es evitar la parálisis operativa mediante una combinación correcta de reservas comprometidas, monitoreo activo y arquitectura tolerante a fallos de capacidad.
Prerequisitos
Antes de ajustar tu estrategia de capacidad, asegurate de tener el entorno técnico listo para auditar y gestionar recursos:
- AWS CLI v2.x: Instalado y configurado con credenciales que tengan permisos
ec2:DescribeReservedInstances,ec2:GetCapacityReservationUsageycloudwatch:GetMetricData. - kubectl: Versión 1.27 o superior, conectado a tu clúster EKS o autoscalador de instancias EC2.
- Prometheus: Instancia activa recolectando métricas de nodos (node-exporter) y estado de pods.
- Python 3.9+ o Rust: Para scripts de automatización si necesitas consultar API en tiempo real fuera del CLI estándar.
Guía paso a paso
1. Auditar la eficiencia de las reservas actuales
No asumas que tus reservas están cubriendo la demanda real. El primer paso es verificar la tasa de uso de las instancias reservadas frente a las on-demand. AWS ofrece EC2 Capacity Manager para ver esto, pero podemos extraer datos clave vía CLI.
Ejecutá el siguiente comando para listar los tipos de instancia que estás usando y su estado de reserva:
aws ec2 describe-reserved-instances \
--state active \
--query 'ReservedInstances[].{Type:InstanceType, Count:InstanceCount, AZ:AvailabilityZone}' \
--output tableResultado esperado: Una tabla con tus reservas activas. Si ves reservas en zonas donde no tienes instancias corriendo, estás pagando por capacidad ociosa. Si no hay reservas y tus logs muestran InsufficientCapacity, tenés un riesgo inminente.
2. Monitorear la presión sobre el autoscaler de Kubernetes
En entornos EKS o K8s en EC2, la escasez de capacidad se manifiesta como pods en estado Pending que no escalan. Prometheus es crucial aquí para detectar tendencias antes de que ocurra un fallo total.
Consultá las métricas de nodos pendientes y errores del autoscaler:
# Consulta en Prometheus usando curl o API
curl -G http://<PROMETHEUS_URL>/api/v1/query \
--data-urlencode 'query=sum(kube_node_status_condition{condition="Ready",status="false"})'
# Revisar logs del cluster autoscaler para errores de capacidad
kubectl logs -n kube-system deployment/cluster-autoscaler | grep "NoCapacity"Resultado esperado: Deberías ver cero nodos NotReady por falta de recursos. Si el log muestra repetidamente mensajes como «Instance capacity exhausted», necesitás aumentar las reservas o cambiar de tipo de instancia.
3. Implementar una estrategia híbrida de capacidad
La recomendación de expertos como David Linthicum es no confundir la escasez de bloques masivos con la imposibilidad de desplegar hoy. La estrategia óptima combina tres niveles:
- Reservas base (60-70%): Cubrís el tráfico sostenido con ODCR para instancias estándar (m5/c5). Esto evita errores de capacidad y ofrece descuento de precio.
- On-Demand flexible: Para picos impredecibles o cargas nuevas que aún no están optimizadas.
- Capacity Blocks (solo ML/GPU): Reservados con anticipación para reentrenamientos programados.
Para automatizar la alerta cuando el uso de On-Demand supera un umbral crítico, podés usar una función simple en Python con boto3:
import boto3
def check_on_demand_headroom(region='us-east-1'):
ec2 = boto3.client('ec2', region_name=region)
# Ejemplo conceptual: consultar métricas de CloudWatch para uso de CPU promedio
# En producción, cruzar con datos de Cost Explorer o API GetCapacityReservationUsage
# Simulación de lógica de alerta
print(f"Verificando margen On-Demand en {region}...")
return True
check_on_demand_headroom()4. Evitar el «anti-patrón de reserva excesiva»
Un riesgo destacado en la comunidad es reservar capacidad que no se usa por miedo a quedarse sin recursos (fear-based provisioning). Esto infla los costos fijos y desperdicia capital operativo. AWS permite modificar o vender reservas en el marketplace, pero tiene fricción.
Revisá mensualmente si tenés instancias on-demand corriendo en zonas donde tenés reservas disponibles. Si la diferencia de costo entre la reserva no utilizada y la instancia on-demand es mínima, priorizá la flexibilidad. Si la discrepancia es alta por más de 2 meses, ajustá el volumen de reserva.
Consideraciones y buenas prácticas
La distinción clave que los equipos deben internalizar es la diferencia entre capacidad comprometida (contratos a largo plazo para grandes bloques) y disponibilidad operativa (lo que podés lanzar console en 5 minutos). La declaración de Jassy afecta a la primera, pero los usuarios reportan problemas con la segunda en zonas específicas o durante picos globales.
Además, no todas las regiones están igualadas. Azure East US ha mostrado restricciones similares según comentarios de operadores técnicos. Si tu arquitectura es multi-cloud (AWS y Azure), considerá que ambos proveedores pueden enfrentar cuellos de botella simultáneos por la demanda de IA generativa. No asumas que «migrar a otro proveedor» resolverá el problema instantáneamente; las curvas de aprendizaje y las restricciones de capacidad son sistémicas en 2026-2027.
Otra consideración técnica es el impacto en los spot instances. Con la capacidad on-demand bajo presión, la probabilidad de que AWS revoque instancias spot aumenta, ya que necesita liberar recursos para clientes on-demand comprometidos o con mayor margen de beneficio. Para cargas de trabajo stateless, esto es aceptable; para bases de datos sin réplicas adecuadas, es un riesgo crítico.
Finalmente, recordá que las cifras de 2027-2028 mencionadas se refieren a contratos grandes (hyperscale). Las empresas medianas y pequeñas siguen teniendo acceso al mercado spot y on-demand estándar, pero con menos margen para sorpresas arquitectónicas. La planificación debe ser incremental: no reserves capacidad para cargas que aún no mediste, pero sí reserva lo suficiente para tu núcleo estable.
Conclusión
La saturación de la capacidad AWS hasta 2027 obliga a los equipos DevOps y SRE a pasar de una mentalidad de «abundancia infinita» a una de «gestión activa de inventario». El éxito no depende de evitar el uso de On-Demand, sino de equilibrarlo con reservas estratégicas para cargas sostenidas.
Al implementar monitoreo preciso con Prometheus en Kubernetes y auditar regularmente tus ODCR mediante CLI o EC2 Capacity Manager, podés prevenir interrupciones en producción sin inflar costos innecesariamente. La clave es la visibilidad: sabés exactamente qué capacidad tenés contratada, cuál estás usando y dónde están los riesgos de escasez inminente.
Fuentes
https://www.infoq.com/news/2026/11/aws-capacity-sold-out/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global