AWS e a diferença entre poder pagar e conseguir capacidade para escalar
Grandes compromissos futuros não equivalem a indisponibilidade geral, mas exigem tratar capacidade como dependência da arquitetura.
Andy Jassy afirmou que os grandes compromissos de capacidade da AWS estão amplamente vendidos até 2027 e que uma parcela relevante de 2028 já foi alocada.[5] A empresa também diz manter margem para consumo sob demanda, EC2 e Bedrock.[5] Portanto, a notícia não significa que toda a AWS deixou de aceitar novas instâncias. Significa que planejamento de capacidade merece mais do que uma linha sobre orçamento.
O que muda para quem desenvolve
A InfoQ apresenta relatos de profissionais com dificuldade para obter até instâncias EC2 comuns, mas esses depoimentos não formam uma medição abrangente por região ou família.[5] A AWS oferece On-Demand Capacity Reservations e Capacity Blocks for ML, associados a zonas de disponibilidade; os blocos também podem reservar uma janela futura.[5]
Minha análise é que o desenho de escala precisa declarar suas condições. Uma promessa como “o cluster cresce quando necessário” deveria identificar qual recurso será solicitado, onde, em quanto tempo e qual alternativa existe se a solicitação não for atendida. Sem isso, o autoscaling vira uma expectativa sem plano de contingência.
Para cargas de IA, recomendo distinguir inferência interativa, processamento em lote e treinamento. Não há motivo para atribuir a todas o mesmo prazo de execução ou a mesma política de reserva.
Como aplicar
Escolha um fluxo crítico e descreva um cenário de crescimento com recursos, zona, prazo e limite de custo. Liste substituições aceitáveis e as que exigem nova validação: família de instância, tamanho, região e janela de execução. Registre também restrições de localização dos dados antes de considerar outra região.
Em homologação, simule a indisponibilidade do provisionamento sem criar recursos pagos adicionais. Interrompa o adaptador de criação ou devolva uma falha controlada e observe o comportamento: existe fila limitada? O usuário recebe uma resposta clara? O sistema preserva trabalho aceito? A recuperação cria tarefas duplicadas? Esses resultados ajudam a avaliar resiliência sem depender de uma escassez real.
Para o planejamento financeiro, compare reserva com atraso tolerável e impacto de não executar. Documente em quais condições a flexibilidade é mais valiosa do que garantir antecipadamente uma configuração específica.
Cuidados e limites
A matéria cita aumento aproximado de 15% nas tarifas dos Capacity Blocks em janeiro.[5] Esse dado não deve ser aplicado indiscriminadamente a toda instância EC2 ou a qualquer contrato.
Também não recomendo multicloud como resposta automática. Antes, estime o custo de portar dados, observar dois ambientes e manter caminhos de execução equivalentes. A decisão útil não é escolher a arquitetura mais abrangente, mas estabelecer uma alternativa praticável para a dependência que realmente ameaça o prazo.
Fonte
[5] Fonte: InfoQ