AWS aposenta sete serviços entre 2026 e 2027: prazos e como migrar sem parar produção

Em setembro de 2026 a AWS publicou um lote de mudanças de disponibilidade que afeta sete serviços: alguns já saíram de linha, outros estão fechados para novos clientes e outros têm data marcada para 2027. Quem acompanha o AWS Builder Center de perto chamou atenção para o padrão, mas quem só lê anúncio de lançamento corre o risco de descobrir a aposentadoria tarde demais. É o caso descrito pelo autor Muhammad Faseeh em artigo publicado no AWS Builder Center em 3 de novembro de 2026.

Para quem desenha e opera ambiente AWS, a questão não é saudosismo. É inventário: quais desses serviços estão hoje em alguma conta da organização, em qual template de CloudFormation, CDK ou Terraform, e quem é o dono de cada migração.

As sete baixas, com data e status

A tabela abaixo resume o que a fonte traz, por ordem de proximidade do prazo.

"Manutenção" não é sinônimo de quebrado: quem já usa Chime SDK SIP Media Application ou WorkSpaces Secure Browser continua operando normalmente, só não pode mais iniciar projeto novo nesses serviços. O prazo mais próximo da lista é o do console standalone do Infrastructure Composer, em 7 de dezembro de 2026: vale checar agora se algum runbook ou bookmark do time ainda aponta para ele.

Por que o DevOps Guru é o caso que exige plano

DevOps Guru é, de longe, o serviço mais adotado entre os sete, e por isso a fonte dedica a ele um roteiro de saída inteiro. A AWS já fechou o serviço para novos clientes em 29 de outubro de 2026, mesma data do Chime SDK e do WorkSpaces Secure Browser, embora o sunset completo só aconteça em 30 de setembro de 2027.

Até lá, quem já usa o serviço mantém patches de segurança e correção de bugs críticos, mas sem novas funcionalidades. Depois do sunset:

• Console e API deixam de responder.
• Os tipos de recurso AWS::DevOpsGuru::* são retirados do CloudFormation, o que quebra qualquer template, stack do CDK ou módulo Terraform que ainda os referencie.
• Os insights já gerados deixam de poder ser recuperados pela API.

Em resumo: DevOps Guru é um serviço de observabilidade, então a aposentadoria tira visibilidade operacional, não disponibilidade de workload. Ninguém perde uptime por causa disso, mas pode perder a detecção de anomalia que hoje avisa antes do incidente virar pós-mortem.

O plano de cinco passos

A fonte descreve um roteiro direto para quem precisa sair do DevOps Guru antes do prazo:

1. Mapear toda dependência, buscando nos repositórios por AWS::DevOpsGuru e por chamadas à API do serviço.
2. Capturar os novos insights criando um canal de notificação via Amazon SNS, para manter histórico enquanto o suporte durar.
3. Exportar o histórico acumulado usando a própria API do DevOps Guru antes do desligamento.
4. Reconstruir o alerta que importa como alarme de detecção de anomalia no Amazon CloudWatch.
5. Limpar a infraestrutura como código, removendo os recursos do DevOps Guru dos templates antes que uma implantação quebre por referência a um tipo de recurso que não existe mais.

A AWS nomeia dois destinos de migração: Amazon CloudWatch para detecção de anomalia em métrica e alarme tradicional, e Amazon DevOps Agent para investigação assistida por IA de problema operacional. São caminhos diferentes: o primeiro é a rota conservadora, que qualquer time já conhece; o segundo pressupõe adotar um agente que investiga e sugere causa raiz, não só dispara alarme.

De console operado à mão para agente que age por você

A fonte aponta um padrão por trás da lista inteira. Entre os lançamentos recentes da própria AWS, aparecem o Amazon Bedrock AgentCore harness (disponível desde junho de 2026, com cobrança por uso e suporte a múltiplos provedores de modelo), o Amazon Bedrock Managed Agents com OpenAI (em preview público, rodando dentro da conta do cliente sob as identidades e permissões existentes), os workflows multiagente do Kiro e o AWS Well-Architected Agent, também em preview, que analisa o ambiente e devolve recomendação nos pilares de custo, segurança, desempenho e resiliência.

Na minha visão, e esta é apenas minha interpretação pessoal e não uma posição oficial da AWS, o padrão é claro. Muitas das ferramentas aposentadas eram consoles operados manualmente, enquanto muitos dos lançamentos recentes são agentes que atuam em seu nome.

In my view, and this is my own interpretation rather than an AWS statement, the pattern is clear. Many retired tools were consoles that people operate by hand, while many new launches are agents that operate on your behalf.Muhammad Faseeh, autor no AWS Builder Center

O próprio fato de a AWS indicar o Amazon DevOps Agent como destino de migração do DevOps Guru reforça essa leitura. Vale tratar como hipótese plausível, não como roteiro confirmado: nenhum dos dois produtos de agente citados acima está em disponibilidade geral completa, e adotar um serviço em preview como substituto definitivo de produção merece a mesma cautela que qualquer dependência nova em ambiente crítico.

O que isso muda no pilar de excelência operacional

Para quem segue o Well-Architected Framework, a lição não é sobre estes sete serviços específicos: é sobre o hábito de tratar ciclo de vida de serviço como parte do inventário de risco, no mesmo nível que capacidade ou custo. Managed Blockchain e Backint Agent for SAP ASE afetam pouca gente, mas DevOps Guru e, em menor medida, Infrastructure Composer, aparecem em pipeline de observabilidade e em fluxo de design de arquitetura de times comuns.

A fonte resume a prática recomendada em cinco pontos que cabem em qualquer revisão de arquitetura:

• Assinar as atualizações de disponibilidade de serviço da AWS, para que a aposentadoria nunca chegue como surpresa.
• Fazer inventário de quais serviços em fim de vida estão em uso, com um dono designado para cada migração.
• Manter tudo em infraestrutura como código: uma stack legível em Terraform ou CDK migra muito mais rápido que uma construída clicando no console.
• Preferir primitivas duráveis como Amazon S3, AWS Lambda e Amazon CloudWatch para workload que precisa durar anos.
• Fazer a pergunta de saída antes de adotar qualquer serviço novo: qual é o plano se ele mudar.

Nenhum desses sete desligamentos derruba produção por conta própria. O risco real é descobrir a data errada, num template de CloudFormation que falha no meio de um deploy porque referencia um tipo de recurso que a AWS já retirou. Revisar hoje qual desses sete serviços está em alguma conta da organização custa bem menos do que corrigir isso sob pressão em 2027.

Fonte: AWS Builder Center