AWS: o agente novo não deveria esconder a migração com prazo marcado

A AWS destacou a prévia pública do Amazon Bedrock Managed Agents powered by OpenAI, com uma versão personalizada da Agents API integrada a recursos e controles AWS.[14] O mesmo panorama reúne marcos de manutenção e fim de suporte de serviços.[14] Para quem mantém aplicações, há duas decisões diferentes: experimentar uma capacidade nova e evitar que uma dependência existente vire uma urgência de migração.

O que muda para quem desenvolve

O ambiente de execução dos agentes pode ser autogerenciado ou usar Bedrock AgentCore Runtime, com sessões gerenciadas e armazenamento configurável na conta do cliente.[14] A oferta continua em prévia, sem confirmação de que toda integração ou região esteja pronta para qualquer implantação.[14]

Minha leitura é avaliar essa escolha pelo contrato operacional: permissões, persistência, recuperação, custo e saída para outra solução. Um runtime gerenciado pode ser uma opção, mas a decisão deveria explicitar o que permanece responsabilidade da aplicação.

Para serviços existentes, o panorama informa que Amazon Chime SDK SIP Media Application e Amazon WorkSpaces Secure Browser entram em manutenção e deixam de aceitar novos clientes em 29/10/2026.[14] Isso não significa desligamento de todos os usuários existentes nessa data.[14]

Os marcos de fim de suporte citados são 29/09/2027 para Amazon Managed Blockchain e AWS Backint Agent for SAP ASE, e 30/09/2027 para Amazon DevOps Guru.[14] No AWS Infrastructure Composer, o marco de 07/12/2026 refere-se ao console independente; Amazon Mechanical Turk aparece como tendo alcançado fim de suporte em 29/09/2026.[14] Preserve o escopo de cada anúncio antes de abrir uma tarefa de substituição.

Como aplicar

Faça primeiro um inventário de dependências por aplicação. Para cada serviço citado, registre se há uso efetivo, qual função ele cumpre, qual marco se aplica e como a continuidade será testada. Diferencie serviço central, ferramenta de desenvolvimento e integração periférica.

Para uma migração necessária, escolha um fluxo representativo e exercite a alternativa em homologação. Verifique dados, autenticação, permissões e comportamento de falha. Inclua exportação e possibilidade de retorno no planejamento, sem assumir que uma troca de nome no código resolve a dependência.

Em uma avaliação de agentes, use uma tarefa pequena com dados sintéticos e operações restritas. Compare o runtime próprio com AgentCore pelo mesmo resultado exigido: estado preservado, recuperação após interrupção e acesso negado fora do escopo. Registre o custo total e a disponibilidade na região pretendida.

Não misture a prova de conceito do agente com a migração de um serviço que já tem prazo. Uma pode continuar experimental; a outra precisa de responsável e critério de continuidade. Essa separação ajuda a não gastar o tempo disponível apenas com a novidade mais interessante.

Cuidados e limites

O panorama apresenta comparações de modelos como alegações dos fornecedores, sem um teste independente comum nem garantia dos mesmos custos em todas as cargas.[14] Elas não substituem uma medição da sua tarefa.

Manutenção, bloqueio de novos clientes e fim de suporte são estados distintos. A AWS remete à documentação de cada serviço e ao suporte para alternativas e migração.[14] Trate os marcos como gatilhos de investigação e decisão, não como prova de retirada imediata de toda funcionalidade que compartilha o nome do produto.

Fonte

[14] Fonte: AWS News Blog