Na primeira semana de agosto, o AWS Transform entregou três lançamentos que juntos cobrem uma migração desde o schema que você ainda não converteu até a dívida técnica que você vai encontrar um ano depois do cutover. Em 3 de agosto o agente de modernização Windows ganhou transformação offline de schema de SQL Server para Aurora PostgreSQL e a modernização contínua entrou em disponibilidade geral; em 6 de agosto o workflow de migração aprendeu a executar ações pós-lançamento pelo Systems Manager. Em volta disso, o Lambda ganhou até 3.000 Mbps de banda de rede, o Aurora Serverless aprendeu a saltar para 12 ACUs em um segundo, e os load balancers ganharam políticas TLS de nível NSA.

A tese da semana: a AWS não vende mais o Transform como uma ferramenta de rehost com rótulo de IA. Ela está preenchendo as partes de uma migração que costumavam ser a planilha de um parceiro, e isso muda o que você deveria esperar fazer à mão.

AWS Transform: schema, cutover e o ano seguinte

Tome os três em ordem de migração. A transformação offline de schema aceita arquivos DDL de SQL Server, então você não precisa de uma conexão ao vivo com a origem. Ela avalia a complexidade do banco e das stored procedures, permite editar o plano gerado, depois converte tabelas, schemas, stored procedures e funções, valida equivalência funcional e implanta o resultado no Aurora PostgreSQL. A conversão de objetos de armazenamento é movida pelo AWS DMS por baixo. Por enquanto é apenas US East (N. Virginia). A parte offline importa mais do que parece: os times que não conseguem começar uma migração de banco geralmente são aqueles cujos DBAs não abrem uma porta para uma ferramenta de conversão. Um dump de DDL é uma conversa mais fácil.

As ações pós-lançamento fecham a lacuna entre "o servidor subiu na AWS" e "o servidor é de fato nosso". Você define as ações uma vez no nível da conta, e o Transform as aplica a todo servidor de origem, entre contas de destino em uma migração multi-conta, executando-as pelo AWS Systems Manager logo depois de um lançamento de teste ou de cutover. Ações predefinidas ou o seu próprio documento SSM. O arquivo de inventário da migração também ganha uma estrutura para revisão por servidor. Se você já rodou MGN em escala, conhece o modo de falha que isso remove: uma wave de 80 servidores aterrissa e alguém roda a instalação do agente do CloudWatch à mão em 79 deles.

A modernização contínua é a peça voltada para o que acontece depois. Ela se conecta a organizações do GitHub, grupos do GitLab e workspaces do Bitbucket, roda sob demanda ou em um cronograma, classifica os achados por dívida técnica, segurança, prontidão agêntica e prontidão para modernização, e para achados com correção abre pull ou merge requests com mudanças validadas. A análise roda na sua própria conta sob as suas credenciais, e você pode operá-la pelo web app, pela CLI, pelo Kiro ou como plugin de agente. O trade-off é o mesmo que toda ferramenta de PR automatizado carrega: capacidade de revisão. Um scanner agendado que abre PRs mais rápido do que o time consegue ler vira ruído em um trimestre. Comece com um grupo de repositórios e um filtro de ranking rigoroso.

Banda do Lambda: 3.000 Mbps, se você não está em uma VPC

A banda de rede do Lambda agora escala com a memória para funções com 2 GB ou mais, de 625 Mbps em 2 GB a 3.000 Mbps em 10 GB, substituindo o teto fixo de 625 Mbps. Sem custo extra, todas as Regiões comerciais. Duas ressalvas acompanham o lançamento. Primeiro, é opt-in via uma solicitação no Service Quotas na quota "Network bandwidth per execution environment", depois da qual toda função fora de VPC na conta escala automaticamente. Segundo, e mais importante, aplica-se apenas a funções fora de uma VPC. A maioria das funções corporativas que movem objetos grandes está dentro de uma, porque é lá que vivem a instância RDS e o endpoint privado do S3. Se as suas transformações pesadas S3-para-S3 rodam em uma VPC, esta semana não mudou nada para você. Verifique com aws lambda get-function-configuration --function-name X --query VpcConfig antes de abrir a solicitação de quota.

Aurora Serverless: 12 ACUs em um segundo

O Aurora Serverless agora alcança até 12 ACUs em um segundo durante o scale-up, continua até 256 e ainda escala para zero depois. Vem ligado por padrão para clusters na platform version 3 ou 4; as versões 1 e 2 podem fazer upgrade direto para a 4. Verifique a sua com o campo ServerlessV2PlatformVersion de describe-db-clusters. A AWS enquadra isso em torno de cargas agênticas, o que é justo: um fan-out de agentes é exatamente o burst que costumava gastar os primeiros 30 segundos esperando capacidade. O modo de falha é custo. Um cluster que antes subia suavemente agora bate 12 ACUs em um pico que teria sido absorvido em 2. Coloque um alarme do CloudWatch em ServerlessDatabaseCapacity antes de atualizar a platform version, não depois da primeira fatura.

Também nesta semana

O fio condutor

Leia os lançamentos do Transform ao lado dos do Lambda e do Aurora e o padrão é sobre onde o trabalho manual estava escondido. A conversão de schema se escondia atrás de uma regra de firewall que ninguém aprovaria. A configuração pós-lançamento se escondia em um runbook. A dívida técnica se escondia no backlog. O teto de banda do Lambda se escondia atrás de uma quota, e a rampa do Aurora se escondia nos primeiros 30 segundos de cada pico. A AWS passou a semana removendo esconderijos. O custo disso é o mesmo toda vez: os defaults ficam mais agressivos, e o time de plataforma precisa decidir, de antemão, quais desses defaults ele realmente quer.

Leia isto a seguir

Para a leitura de IA e agentes da mesma semana, as notas de campo vivem em ercan.ai. Consultoria em AWS, nuvem, pipelines de CI/CD, Linux, GitHub/GitLab e mais passa por ercanermis.com.

Referências