Logotipo de YuSMP Group
Redacción de YuSMP Group Equipo editorial, YuSMP Group
Ilustración isométrica de una sala de centro de datos con filas de racks de servidores iluminados y totalmente ocupados, y una fila con luz ámbar en primer plano

La versión corta

El 23 de octubre de 2026, el consejero delegado de Amazon, Andy Jassy, afirmó que la capacidad de AWS está agotada para 2026, «en gran parte agotada» para 2027 y que también hay reservada una buena parte de 2028, pese a una inversión de capital prevista de unos $220 mil millones en 2026. AWS sigue reservando algo de capacidad para EC2 bajo demanda y Bedrock, pero los grandes bloques ya están comprometidos. Si su producto necesita GPU o mucho cómputo en los próximos 12–24 meses, trate la capacidad como un punto de planificación de su hoja de ruta de cloud y DevOps. Resérvela pronto, úsela de forma eficiente y conserve la opción de cambiar.

¿Qué dijo Andy Jassy sobre la capacidad de AWS?

Jassy habló en The a16z Show, el pódcast de Andreessen Horowitz, con el cofundador Ben Horowitz y el socio general Erik Torenberg, en un episodio publicado el viernes 23 de octubre. Dijo que AWS ya ha vendido su capacidad de este año y que 2027 también está «en gran parte agotado». Añadió que AWS siempre deja algo de capacidad para el uso bajo demanda y para su servicio de inferencia Bedrock o EC2, pero que «vende en gran parte todos los grandes bloques». También afirmó que «una buena parte del ’28 está vendida». Reuters y The Information informaron de sus declaraciones ese mismo día.

Todo ello ocurre mientras Amazon invierte más que nunca. En julio, la compañía elevó su plan de inversión de capital para 2026 a unos $220 mil millones, en parte porque la memoria se ha encarecido. Jassy dijo en el pódcast que Amazon «podría invertir mucho más y no sería un mal uso del capital». La demanda procede de los laboratorios de IA y de las empresas que integran la IA en sus productos. Ni Amazon ni las informaciones citaron clientes, regiones o tipos de chip concretos detrás de las reservas.

¿Por qué se está agotando la capacidad de cloud?

Aquí el cuello de botella no es el dinero, sino la oferta física. Jassy señaló tres límites: el espacio en centros de datos, la energía y la memoria. Ninguno se puede ampliar en un trimestre. Los nuevos emplazamientos tardan años en obtener permisos y construirse, las conexiones a la red eléctrica escasean en muchas regiones y la memoria de alto ancho de banda para aceleradores de IA tiene la oferta limitada en todo el sector. Si el mayor proveedor de cloud dice que tiene reservas hasta 2028 incluso con este nivel de inversión, es casi seguro que sus competidores trabajan bajo una presión similar.

Para los compradores, el detalle clave es cómo reparte AWS lo que tiene. La mayor parte va a compromisos plurianuales de grandes clientes, sobre todo laboratorios de IA y empresas que reservaron capacidad pronto. Lo que queda se guarda para el uso bajo demanda y la inferencia gestionada. En la práctica, un equipo de tamaño medio todavía puede lanzar instancias y llamar a modelos hoy, pero la capacidad grande o especializada, como grandes clústeres de GPU para entrenamiento o ajuste fino, es lo más difícil de conseguir con poca antelación, y puede costar más cuando se consigue.

Qué significa para los equipos de software de EE. UU. y la UE

Primero, la planificación de capacidad forma ya parte de la planificación del producto. Si su hoja de ruta incluye entrenar o ajustar modelos, inferencia de gran volumen o una migración importante en 2027, el momento de asegurar el cómputo es antes de que empiece el trabajo, no cuando el backlog llegue a él. AWS ya ofrece formas de hacerlo, como las reservas de capacidad, los precios con compromiso de uso y los bloques de GPU programados para ML. La contrapartida es que se compromete a gastar antes de que la demanda esté demostrada, así que dimensione las reservas según previsiones que pueda defender. Reservar de más solo traslada el riesgo de la disponibilidad al coste.

Segundo, los servicios gestionados se convierten en la opción por defecto más segura. Jassy dijo que AWS aparta capacidad para la inferencia a través de Bedrock y EC2. Los equipos que llaman a modelos fundacionales mediante un servicio gestionado como Amazon Bedrock tiran de esa reserva y no necesitan asegurar su propia flota de GPU. Para la mayoría de los equipos de producto, es un motivo para preferir la inferencia gestionada frente a clústeres de modelos autoalojados, salvo que las normas sobre datos, el coste a escala o el control del modelo justifiquen claramente operarlos por cuenta propia.

Tercero, la eficiencia afecta ahora a la disponibilidad además de al coste. Cuando el cómputo escasea, el equipo que necesita menos entrega antes. Los modelos más pequeños o destilados, la caché de respuestas, el procesamiento por lotes y las instancias bien dimensionadas reducen la factura y también la cantidad de capacidad escasa de la que depende. Con la portabilidad ocurre lo mismo. Las cargas de trabajo definidas como infraestructura como código y contenedorizadas en Kubernetes pueden trasladarse a otra región o proveedor cuando uno se queda corto. Para los equipos de la UE, compruebe que cualquier región de respaldo sigue cumpliendo sus obligaciones del RGPD y de residencia de datos antes de depender de ella.

¿Cómo deberían planificar ahora la capacidad los equipos?

  1. Prevea 12–24 meses de cómputo. Desglóselo por carga de trabajo: entrenamiento, inferencia, lotes, carga estable. Lo que más GPU consume va primero en la cola.
  2. Reserve lo que pueda justificar. Use reservas de capacidad o compromisos para la carga base predecible y deje bajo demanda la carga variable o experimental.
  3. Prefiera la inferencia gestionada. Llame a los modelos mediante servicios gestionados siempre que pueda, en lugar de montar sus propios clústeres de GPU.
  4. Haga de la eficiencia un criterio de lanzamiento. Mida el cómputo por solicitud o por usuario y use caché, procesamiento por lotes y modelos más pequeños antes de escalar el hardware.
  5. Mantenga las cargas de trabajo portables. Use infraestructura como código y contenedores para que la falta de capacidad en una región o una nube no bloquee un lanzamiento.
  6. Compruebe el cumplimiento de las regiones de respaldo. Confirme que cualquier región alternativa cumple sus requisitos de residencia de datos y regulatorios antes de que un incidente le obligue a moverse.
  7. Revise sus supuestos de precios. La capacidad escasa puede significar menos descuentos. Téngalo en cuenta en los presupuestos de cloud de 2027.

Preguntas frecuentes

¿De verdad se ha agotado la capacidad de AWS?

No del todo. El 23 de octubre de 2026, el consejero delegado de Amazon, Andy Jassy, afirmó que la capacidad de AWS para 2026 está vendida, que 2027 está «en gran parte agotado» y que también está vendida una buena parte de 2028. Dijo que AWS siempre reserva algo de capacidad para el uso bajo demanda y para la inferencia a través de Bedrock y EC2. Lo que está agotado son los grandes bloques comprometidos que han reservado los grandes clientes. Los equipos todavía pueden lanzar instancias y llamar a modelos, pero la capacidad grande o especializada, sobre todo de GPU, es más difícil de conseguir con poca antelación.

¿Por qué Amazon no construye simplemente más centros de datos?

Amazon ya prevé una inversión de capital de unos $220 mil millones en 2026, y Jassy dijo que podría invertir más. Los límites son físicos. Los centros de datos tardan años en construirse, la energía y las conexiones a la red escasean y la memoria para hardware de IA está en falta en todo el sector. Jassy citó los centros de datos, la energía y la memoria como los cuellos de botella.

¿Cómo puede un equipo de software asegurarse capacidad en la nube?

Prevea sus necesidades de cómputo con 12 a 24 meses de antelación por carga de trabajo y reserve capacidad para la base predecible con las opciones de reserva o compromiso del proveedor. Mantenga bajo demanda la carga experimental y variable. Prefiera los servicios gestionados para la inferencia de modelos, ya que AWS dice que aparta capacidad para ellos. Reduzca el cómputo que necesita con caché, procesamiento por lotes y modelos más pequeños, y mantenga las cargas de trabajo portables con infraestructura como código y contenedores para poder cambiar de región o de proveedor si uno se queda corto.

¿Afecta de forma distinta la escasez de capacidad de AWS a los equipos de la UE?

Las informaciones no desglosaron la capacidad por región, así que no hay una cifra publicada para las regiones de la UE en concreto. La diferencia práctica para los equipos de la UE es el cumplimiento normativo. Si piensa conmutar o ampliarse a otra región porque la suya se queda corta, esa región debe seguir cumpliendo sus obligaciones del RGPD y de residencia de datos. Compruébelo con antelación e incluya regiones de respaldo conformes en su plan de capacidad, en lugar de elegir una en mitad de un incidente.

Fuentes

The a16z Show — Amazon CEO Andy Jassy on the $220 Billion AI Buildout (fuente primaria, 23 de octubre de 2026) (en inglés)
Reuters (via U.S. News) — Amazon cloud capacity sold out through 2027, CEO Jassy says (23 de octubre de 2026) (en inglés)
The Information — AWS largely sold out of capacity into 2028, Jassy says (23 de octubre de 2026) (en inglés)
CNBC — Amazon hikes 2026 capex to $220 billion due to higher memory costs (30 de julio de 2026) (en inglés)