AWS tem capacidade reservada esgotada até 2027, mas reserva fatia para uso sob demanda

AWS tem capacidade reservada esgotada até 2027, mas reserva fatia para uso sob demanda

Andy Jassy confirma que blocos grandes de capacidade da AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → estão praticamente esgotados até 2027, com parte de 2028 já alocada. A empresa diz guardar espaço para EC2 e Bedrock sob demanda, mas devs já relatam fila para instâncias comuns.

Nota da redação: a descrição do funcionamento do EC2 Capacity Manager neste artigo (agregação cross-account/cross-region e cálculo de proporção de uso de capacidade reservada) se baseia apenas em reportagem secundária da InfoQ, sem confirmação em documentação oficial da AWS consultada por esta redação. O leitor deve considerar essa seção como informação de segunda mão sobre o comportamento exato da ferramenta, não verificada na fonte primária.

O que Jassy disse

Em um podcast em vídeo com o cofundador da Andreessen Horowitz, Ben Horowitz, e o sócio-geral Erik Torenberg, o CEO da Amazon, Andy Jassy, afirmou que os grandes blocos de capacidade reservada da AWS estão praticamente esgotados até 2027, com uma parte relevante de 2028 já comprometida. A declaração foi reportada pela Reuters em 23 de outubro e repercutida pela InfoQ.

Segundo Jassy, a capacidade de 2026 já se esgotou por completo, e a AWS poderia investir bem mais do que os cerca de 220 bilhões de dólares de despesas de capital (capex) planejados para este ano sem que isso fosse um mau uso de capital.

2027 está praticamente esgotado. Sempre deixamos uma quantidade reservada para demanda sob consumo e para nosso serviço de inferência, o Bedrock, ou para o EC2, mas os grandes blocos estão praticamente esgotados. Uma boa parte de 2028 também já foi vendida.

Andy Jassy, CEO da Amazonfoto: Lisi Mezistrano Wolf · CC BY-SA 4.02027 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.

Como funciona a reserva de capacidade na AWS

Segundo reportagem da InfoQ, a AWS vende garantia de capacidade por dois mecanismos: On-Demand Capacity Reservations, em que o cliente reserva instâncias numa Availability Zone nomeada, e Capacity Blocks for ML↳Machine learning39 conteúdosClassificador de Sentimentos – Azure MLData · abr 2019Inteligência Artificial e Machine Learning: O que você precisa saberAI · fev 2024Inteligência Artificial: seminário online da USP debate o futuro do aprendizado de máquinaGestão Dev & TI · jun 2021Ver tudo em AI →, voltado a cargas de machine learning, em que a reserva vale para uma janela fixa a partir de uma data futura. Em janeiro, a AWS já havia reajustado em cerca de 15% os preços dos Capacity Blocks for ML de forma uniforme em todas as regiões, cobrindo as instâncias de GPU P5en, P5e, P5 e P4d, além das instâncias Trn2 e Trn1, conforme a própria InfoQ já havia noticiado.

É esse modelo de pré-reserva, voltado a grandes provedores de modelos e empresas com planejamento de capacidade de longo prazo, que está "esgotado" segundo Jassy. O conceito é diferente de simplesmente não conseguir subir uma instância no console hoje.

A reação cética: "sold out" não é bem isso

O analista de cloud David Linthicum contestou a leitura mais alarmista da notícia, separando os blocos pré-reservados descritos por Jassy do que uma empresa consegue alocar no dia a dia.

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

David Linthicum, analista de cloudOf 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."

Para Linthicum, o mercado já carrega confusão suficiente entre instâncias reservadas, serviços sob demanda e capacidade comprometida, e manchetes desse tipo levam a suposições erradas e a estratégias ruins de planejamento.

O que devs estão vendo na prática

Enquanto Jassy falava de contratos até 2027 e 2028, a discussão em fóruns de desenvolvedores girou em torno de um problema mais imediato: disponibilidade agora, em instâncias comuns do EC2. O comentário mais votado numa thread no Reddit, assinado por um desenvolvedor identificado como cbigsby, descreve o cenário.

Temos visto um aumento grande nos problemas de capacidade de computação no último mês ou mais no trabalho, só para instâncias comuns do EC2. Esqueça instâncias spot, já temos dificuldade de conseguir sob demanda em quantidade suficiente. Por sorte isso está majoritariamente ligado a CI, mas teve alguns dias em que os clusters de Kubernetes em produção ficaram preocupantemente restritos.

cbigsby, desenvolvedor, em comentário no RedditWe'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.

Relatos parecidos apareceram em outros lugares. Richard T., gerente de operações técnicas, comentou no post de Linthicum que a Microsoft divulgou informações limitadas sobre restrições de capacidade na região Azure East US, e que o time dele passou a adotar instâncias reservadas para garantir capacidade diante do crescimento projetado. Em uma thread paralela, outro comentarista relatou dificuldade para obter computação suficiente das três grandes provedoras de nuvem, e disse que a restrição não se limita a GPUs.

O padrão anti-cloud que isso pode gerar

A consequência arquitetural desse cenário foi apontada por Ian Rae, em resposta a Linthicum.

No momento seguinte, você percebe que o pessoal está reservando recursos de nuvem com medo de precisar deles, o que é um padrão anti-cloud.

Ian Raenext thing you know, folks reserve cloud resources they are worried they might need, which is an anti-cloud pattern

O ponto de Rae é direto: reservar capacidade "por precaução" reintroduz o mesmo problema que a nuvem elástica prometia resolver, só que em formato contratual em vez de hardware físico comprado. Quem reserva demais paga por ociosidade; quem reserva de menos entra na fila que cbigsby descreveu.

A ferramenta que a própria AWS já oferece

Como a InfoQ já havia noticiado em outubro do ano anterior, o EC2 Capacity Manager agrega dados de capacidade num painel cross-account e cross-region, e reporta a proporção entre capacidade reservada usada e não usada como medida de eficiência da reserva.

Na prática, para quem já opera com Capacity Reservations ou Capacity Blocks, esse painel funciona como um primeiro lugar natural para checar antes de decidir reservar mais, já que mostra se a capacidade contratada está sendo de fato consumida ou se está ociosa.

O que muda para quem desenvolve no Brasil

O recado prático do episódio é separar dois horizontes de tempo. Os contratos de longo prazo para blocos massivos de GPU (os destinados a treinar modelos grandes) são negociação entre a AWS e poucos clientes muito grandes; isso não afeta diretamente quem sobe uma instância t3.medium ou um cluster de EKS pequeno em sa-east-1.

O que afeta o time de infraestrutura no dia a dia é o segundo horizonte, o que os relatos no Reddit descrevem: picos de contenção em instâncias on-demand comuns, especialmente quando a esteira de CI depende de escalar rápido. Em resumo: se o seu time já viu falha de InsufficientInstanceCapacity ao escalar um cluster de Kubernetes ou um runner de CI, não é imaginação, e o fenômeno tende a se repetir enquanto a demanda por capacidade de IA segue pressionando as mesmas regiões.

Alguns pontos valem revisão antes do fim do ano:

• Verificar, no console ou via EC2 Capacity Manager, a taxa de uso das reservas existentes antes de comprar mais capacidade reservada.
• Para workloads de IA (treino ou inferência via Bedrock), considerar reservar Capacity Blocks com antecedência maior do que o habitual, já que 2026 está esgotado e 2027 está indo pelo mesmo caminho.
• Para CI/CD e cargas elásticas comuns, testar múltiplos tipos de instância e múltiplas zonas de disponibilidade na mesma região como mitigação, em vez de depender de um único tipo de instância sob demanda.
• Acompanhar o relatório trimestral da Amazon (os resultados do terceiro trimestre saíram em 29 de outubro) para entender quanto da capacidade comprometida já virou receita contratada via o indicador de remaining performance obligations (RPO).

O episódio também é um lembrete de que "nuvem elástica" sempre teve limite físico por trás do discurso de capacidade infinita. A diferença agora é que esse limite ficou visível tanto para quem compra blocos de GPU para 2028 quanto para quem só queria subir um m5.large a mais num dia de pico.

Fonte: InfoQ