Ir para o conteúdo principal
Voltar aos artigos

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.

·3 min de leitura·6 visualizações

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

Continue lendo