Capacidade da AWS está praticamente esgotada até 2027, confirma Andy Jassy

# Capacidade da AWS está praticamente esgotada até 2027, confirma Andy Jassy

Jassy diz à a16z que grandes blocos de capacidade reservada estão vendidos até 2027; Linthicum rebate, mas relatos de campo mostram fila também em instâncias comuns

Em podcast com a Andreessen Horowitz, o CEO da Amazon disse que os grandes blocos de capacidade reservada da AWS estão praticamente esgotados até 2027, com parte de 2028 já comprometida. Para quem decide orçamento de nuvem, a mensagem é clara: quem não planejar a compra de instâncias com meses de antecedência vai sentir a fila.

O que Jassy disse, e quando

Em entrevista em vídeo ao cofundador da Andreessen Horowitz, Ben Horowitz, e ao general partner Erik Torenberg, o CEO da Amazon, Andy Jassy, afirmou que os grandes blocos de capacidade comprometida da AWS estão praticamente esgotados até 2027, com uma parte relevante de 2028 já alocada. A fala foi reportada pela Reuters em 23 de outubro de 2026. Jassy disse ainda que a empresa poderia investir bem além dos cerca de US$ 220 bilhões de capex planejados para este ano sem que isso fosse mau uso de capital.

A citação direta, no podcast:

2027 está praticamente esgotado. Sempre deixamos uma parte para on demand e para o nosso serviço de inferência, o Bedrock, ou para o EC2, mas as grandes fatias já estão praticamente todas vendidas. Uma boa parte de 2028 também já foi vendida.

2027 is largely sold out. We always leave a certain amount for on demand and our inference service bedrock, or EC2, but largely sold out all the big chunks. A good chunk of 2028 is sold out.Andy Jassy, CEO da Amazon

Segundo Jassy, a capacidade para 2026 já não existe mais. Segundo a reportagem da InfoQ, a AWS vende garantia de capacidade por dois mecanismos, On-Demand Capacity Reservations (reserva de instância numa Availability Zone nomeada) e Capacity Blocks for ML (reserva por janela fixa a partir de uma data futura, usada para treinamento de modelo). Em janeiro de 2026, a AWS já havia reajustado as tarifas dos Capacity Blocks for ML em cerca de 15% de forma uniforme em todas as regiões, cobrindo as instâncias P5en, P5e, P5 e P4d, além de Trn2 e Trn1.

A réplica: "sold out" é exagero de manchete

O analista de cloud David Linthicum contestou a leitura de que a AWS estaria "esgotada" no sentido operacional do dia a dia. Para ele, existe diferença entre os blocos pré-reservados em escala de hyperscaler que Jassy descreveu e o que uma empresa comum consegue alocar agindo pelo console:

Claro, suspeito que ainda consigo entrar no console da AWS hoje e alocar capacidade de GPU para cargas de trabalho de IA. Talvez não o bloco de capacidade massivo, pré-reservado e em escala de hyperscaler que algum grande provedor de modelos quer para os próximos três anos, mas isso não é exatamente a mesma coisa que "a AWS está esgotada".

Of course, I suspect I can still go into the AWS console today and allocate GPU capacity for AI workloads. Maybe not the exact massive, pre-reserved, hyperscale capacity block some large model provider wants for the next three years, but that's not exactly the same thing as "AWS is sold out."David Linthicum, analista de cloud

Linthicum argumenta que o mercado já carrega confusão suficiente sobre instância reservada, serviço on demand e capacidade comprometida, e que manchetes desse tipo levam a premissas erradas e estratégia ruim. É um ponto relevante para quem assina orçamento: a frase de Jassy fala de alocação estratégica de longo prazo da AWS como negócio, não necessariamente da fila que seu time vai encontrar amanhã ao subir uma instância.

O que já aparece no campo, independente da manchete

Ao mesmo tempo, relatos recentes de quem opera carga real sugerem que a restrição já chegou a tipos de instância comuns, não só GPU. Um desenvolvedor identificado como cbigsby descreveu, em comentário no Reddit, dificuldade crescente nas últimas semanas:

Temos visto um aumento grande nos problemas de capacidade de computação no último mês ou mais, no trabalho, só para instâncias EC2 comuns. Esquece instância Spot, estamos com dificuldade até para conseguir on demand suficiente. Por sorte, é principalmente ligado à integração contínua, mas já tivemos alguns dias em que os clusters Kubernetes de produção ficaram preocupantemente limitados.

We've been seen a big rise in compute capacity issues the past month or so at work, just for regular ec2 instances. Forget spot instances we have trouble getting enough on demand. Luckily mostly tied to CI but there have been a few days where the production k8s clusters have been concerningly constrained.cbigsby, desenvolvedor, em comentário no Reddit

Richard T., gerente de operações técnicas, comentou em resposta ao post de Linthicum que a Microsoft divulgou informação limitada sobre restrições de capacidade na região Azure East US, e que o time dele adotou instâncias reservadas para garantir capacidade diante de crescimento projetado. Outro comentarista, em discussão paralela, relatou dificuldade para obter capacidade suficiente nos três grandes provedores de nuvem, não restrita a GPU.

O risco arquitetural de reservar por medo

Ian Rae, também em resposta a Linthicum, nomeou a consequência arquitetural desse cenário:

No fim das contas, as pessoas acabam reservando recursos de nuvem com medo de precisar deles, o que é um padrão anti-nuvem.

next thing you know, folks reserve cloud resources they are worried they might need, which is an anti-cloud patternIan Rae, em resposta a David Linthicum

O ponto de Rae importa para o pilar de otimização de custo do Well-Architected: reservar capacidade "por via das dúvidas" devolve à nuvem o mesmo problema que ela resolveu no data center próprio, capacidade ociosa paga antecipadamente. Segundo reportagem da InfoQ de outubro de 2025, a AWS oferece uma ferramenta para esse problema: o EC2 Capacity Manager agregaria dados de capacidade num painel entre contas e regiões e calcularia a razão entre capacidade reservada usada e não usada, como medida de eficiência da reserva.

Nota da redação: a afirmação sobre como o EC2 Capacity Manager funciona (agregação de dados entre contas e regiões e cálculo da razão de uso de capacidade reservada) se baseia apenas na reportagem da InfoQ, sem confirmação na documentação oficial da AWS entre as fontes consultadas. Trate esse detalhe específico de funcionamento do produto com reserva até verificar diretamente na documentação da AWS.

O que decidir neste trimestre

Para quem responde pela fatura, a decisão não é escolher entre reservar tudo ou não reservar nada: é escolher o mecanismo certo para cada carga, e isso envolve tanto o pilar de confiabilidade (garantir capacidade quando ela importa) quanto o de otimização de custo (não pagar por capacidade parada).

A cobertura da InfoQ cita dois mecanismos de garantia de capacidade: On-Demand Capacity Reservations, que reserva instâncias numa Availability Zone nomeada, e Capacity Blocks for ML, reserva por janela fixa a partir de uma data futura, voltada a treinamento de modelo em GPU e Trainium. A AWS também oferece outros instrumentos de compra comprometida e de capacidade sob demanda com desconto, mas os termos exatos de flexibilidade, troca e janela de aviso de interrupção de cada um variam e devem ser conferidos diretamente na documentação oficial da AWS antes de qualquer decisão de orçamento, já que esse nível de detalhe não constava das fontes consultadas nesta reportagem.

O ângulo prático do anúncio de Jassy é este: se a AWS está reservando propositalmente menos headroom de On-Demand para dar prioridade a compromissos de longo prazo, cargas que hoje rodam em On-Demand "porque sempre coube" são as primeiras a sentir fila em momento de pico regional. Isso vale sobretudo para ambiente de teste e integração contínua, que historicamente consome capacidade On-Demand sem reserva alguma e que o relato de cbigsby mostra ser onde a restrição já apareceu primeiro.

Em resumo: antes de aprovar mais um trimestre de capacidade On-Demand sem reserva, vale checar na documentação oficial da AWS qual mecanismo de garantia de capacidade se encaixa em cada carga, em vez de reservar tudo por precaução ou arriscar tudo em fila.

Fonte: InfoQ — Architecture & Design