Setenta e nove anúncios caíram na semana de 28 de setembro, cinco deles modelos de fronteira, e o de cauda mais longa foi um aviso de ciclo de vida: Amazon DevOps Guru, Amazon Managed Blockchain e o Backint Agent para SAP ASE entraram em sunset, o console independente do Infrastructure Composer sai em dezembro, e o Mechanical Turk chegou ao fim do suporte. Dois dias depois o AWS Health lançou um catálogo de versões para que esse tipo de notícia pare de chegar como surpresa. Na frente de migração, o AWS Transform adicionou avaliações agênticas de Kafka para MSK. O EKS Auto Mode abriu o ajuste de kubelet, sysctl e hugepages, o Kubernetes 1.37 chegou, e o Aurora PostgreSQL começou a consultar Iceberg e Parquet no S3 por meio de um DuckDB embutido.

A lista de sunset, e o catálogo que deveria substituí-la

Os AWS Service Availability Updates de 29 de setembro movem Amazon Chime SDK SIP Media Application e Amazon WorkSpaces Secure Browser para manutenção (fechados a novos clientes a partir de 29 de outubro de 2026, clientes existentes continuam). Entrando em sunset: Amazon Managed Blockchain (fim do suporte em 29 de setembro de 2027), Amazon DevOps Guru (30 de setembro de 2027), AWS Backint Agent para SAP ASE (29 de setembro de 2027) e o console independente do AWS Infrastructure Composer (7 de dezembro de 2026). O Amazon Mechanical Turk chegou ao fim do suporte em 29 de setembro de 2026.

O DevOps Guru é o que a maioria dos times de infra vai sentir. Muitos o ligaram em 2021 e esqueceram, então ele ainda está em templates do CloudFormation e ainda conectado a tópicos SNS que acionam alguém. A AWS não nomeia sucessor; dado que o CloudWatch Omni e o DevOps Agent saíram uma semana antes, o caminho de investigação agêntica é a leitura óbvia. Audite agora por recursos AWS::DevOpsGuru::ResourceCollection e NotificationChannel e decida o que substitui os alertas, porque doze meses passam rápido quando a remoção precisa de um ticket de mudança em quarenta contas.

Então, em 2 de outubro, o AWS Health introduziu o catálogo de versões: uma visão por serviço das versões de software suportadas e suas linhas do tempo de ciclo de vida, no Health Dashboard para todos e pela Health API para clientes de Business Support Plus, Enterprise Support e Unified Operations. No lançamento cobre RDS, EKS e Lambda, com mais serviços a seguir. Conecte a API ao que quer que acompanhe o seu backlog de upgrades; uma versão de EKS com quatro meses restantes deveria ser um ticket, não um e-mail.

AWS Transform avalia Kafka para MSK

Em 29 de setembro o AWS Transform adicionou avaliações agênticas de migração de Apache Kafka on-premises para Amazon MSK. Você sobe um arquivo de inventário de clusters ou descreve os clusters no chat, e o agente verifica cada cluster quanto à compatibilidade com o MSK em topologia, versão, configuração, autenticação e quotas, dimensiona brokers MSK Express e produz um business case de TCO com opções de preço e próximos passos.

A parte lenta de uma migração de Kafka não é a cópia dos dados, são as semanas de trabalho em planilha para descobrir se cabe e quanto custa. Comprimir isso para minutos muda quem pode fazer a pergunta.

Leia a palavra "avaliação" literalmente. Ela produz um case, não uma migração. Offsets de consumer groups, schema registry, topologia do MirrorMaker, mudanças de autenticação no cliente e as decisões de contagem de partições que os brokers Express impõem continuam sendo suas. Trate o TCO como número de abertura e verifique o dimensionamento dos brokers Express contra seus picos de retenção e throughput.

O EKS Auto Mode perde a última desculpa

Em 1 de outubro o EKS Auto Mode adicionou configuração avançada de computação: um novo campo advancedCompute no recurso NodeClass permite definir opções do kubelet, sysctls do Linux e hugepages de forma declarativa: user namespaces para builds de imagem rootless, limiares de eviction, limites de cache ARP, hugepages de 2Mi ou 1Gi para bancos de dados e HPC. O EKS valida as configurações, aplica no boot e as mantém por scaling e upgrades, sem launch templates, AMIs customizadas ou DaemonSets privilegiados.

"Precisamos de uma AMI customizada para ajuste de sysctl" era o motivo honesto mais comum para ficar em node groups autogerenciados. Esse motivo se foi, do jeito certo: o ajuste vive em um objeto Kubernetes versionado, não em um pipeline de imagem que ninguém quer ser dono. O modo de falha é o mesmo de qualquer botão no nível do nó: um sysctl ruim em uma NodeClass se propaga para todo nó que essa classe provisiona. Dê à NodeClass ajustada o seu próprio node pool e faça canary com uma única carga.

Em 2 de outubro o EKS e o EKS Distro adicionaram o Kubernetes 1.37: a Metrics API está em GA como metrics.k8s.io/v1, taints e tolerations de dispositivos DRA estão em GA, e o scale-to-zero do HPA está em beta e ligado por padrão. No mesmo dia o ECS adicionou deploys blue/green, linear e canary para serviços atrás do VPC Lattice.

O Aurora PostgreSQL lê o data lake no lugar

Em 30 de setembro o Aurora PostgreSQL ganhou consulta direta a dados Apache Iceberg e Parquet. Você cria foreign tables do PostgreSQL sobre dados no S3, no S3 Tables ou no Glue Data Catalog (incluindo catálogos Iceberg REST externos federados pelo Glue), e o Aurora executa essas consultas com DuckDB embutido na engine. Aplicações e ferramentas de BI existentes continuam falando PostgreSQL puro; para caminhos sensíveis a latência você pode materializar os dados do lake localmente.

Isso mata uma classe de jobs noturnos de "copiar as tabelas de dimensão para o Postgres", e o DuckDB é uma engine sensata para varrer arquivos colunares. O trade-off é que o scan agora roda na sua instância OLTP. Uma consulta de relatório sobre um ano de Parquet é muita CPU e memória na máquina que também atende checkouts; coloque a carga voltada ao lake em um reader, e observe a conexão que você dá à ferramenta de BI tão de perto quanto observaria um cron job.

Também nesta semana

O fio condutor

O tema real da semana é ciclo de vida. Um serviço que você adotou em 2021 está indo embora. O catálogo de versões existe para que o próximo não te pegue de surpresa. O AWS Transform agora escreve o business case para sair do Kafka on-prem. O EKS Auto Mode removeu a lacuna de configuração que mantinha node groups vivos além do tempo, e o Aurora removeu o job de cópia que mantinha uma dúzia de pipelines de ETL vivos além do deles. Trabalho de plataforma é em grande parte decidir o que parar de rodar, e esta semana a AWS entregou ferramentas para as duas metades disso: descobrir o que está acabando, e tornar a substituição barata o bastante para de fato acontecer.

Leia isto a seguir

Para a leitura de IA e agentes da mesma semana, veja ercan.ai. Se o seu time precisa de ajuda prática com AWS, arquitetura de nuvem, pipelines de CI/CD, Linux, GitHub ou GitLab e o trabalho de plataforma em volta deles, o lado de consultoria vive em ercanermis.com.

Referências