A semana de 22 a 28 de junho de 2026 deu aos times de plataforma três primitivas de governança que eles vinham simulando com tags e páginas de wiki: watermarks de AMI que sobrevivem a cópias, Regiões e compartilhamentos entre contas; Lambda MicroVMs que colocam código não confiável na sua própria máquina virtual; e um default corrigido do Network Firewall que vinha descartando em silêncio pacotes legítimos de servidor para cliente. No lado da migração, o AWS Transform agora aterrissa cargas de trabalho em qualquer Região comercial, e OpenSearch e MSK lançaram caminhos de migração guiados por agente.

Sem Summit nesta semana, então os lançamentos são menores e mais úteis: cada item principal é algo sobre o qual você teria escrito um documento de política no ano passado, torcendo para que as pessoas o seguissem.

Migração: qualquer Região, e mais dois caminhos guiados por agente

AWS Transform for migrations agora suporta todas as Regiões comerciais da AWS como destino de migração, publicado em 22 de junho. A Região de destino é onde a landing zone, a rede e os servidores rehospedados são implantados, e o anúncio adiciona 16 delas: US West (N. California), Africa (Cape Town), Asia Pacific (Bangkok, Hong Kong, Hyderabad, Jakarta, Kuala Lumpur, Melbourne, New Zealand, Taipei), Canada (Calgary), Europe (Milan, Spain, Zurich), Mexico (Querétaro) e Middle East (Tel Aviv). Para leitores europeus, Zurich, Milan e Spain são as que transformam "o agente não consegue colocar isso onde o jurídico diz que precisa ficar" de bloqueio em um dropdown.

Dois lançamentos adjacentes a bancos de dados na mesma semana seguem o padrão do rename do MGN: a lógica de migração se move para algo que um agente conduz. O Amazon OpenSearch Service agora oferece migrações assistidas por IA (23 de junho): o Migration Assistant ganha um workflow guiado por agente, usável a partir do Kiro, do Claude Code e de outros, para planejar a mudança de Solr, Elasticsearch ou OpenSearch autogerenciados para OpenSearch Serverless ou Managed Clusters, implantar a infraestrutura e executar a migração histórica mais a de tráfego ao vivo, com capture-and-replay agora cobrindo Solr. Os Amazon MSK AI Agent Skills (22 de junho) dão ao Kiro, ao Claude Code e ao Cursor orientação especializada para dimensionar, diagnosticar, monitorar e migrar clusters Kafka externos para o MSK Express.

O trade-off de skills como mecanismo de distribuição é controle de versão: um runbook no seu repo tem histórico de commits, uma skill do fornecedor puxada em tempo de execução é um prompt que você não consegue diffar. Ótimo para uma migração pontual. Para quarenta clusters idênticos, exporte o que o agente fez da primeira vez para algo que seja seu.

Watermarks de AMI: linhagem que não se perde na cópia

O Amazon EC2 anunciou AMI Watermarks em 24 de junho. Você embute um identificador customizado em uma AMI privada, e ele se propaga para toda AMI derivada dela: cópias para outras Regiões, imagens criadas a partir de uma instância em execução e imagens compartilhadas com outras contas. Cada watermark carrega o ID da AMI original, o dono, a Região e os timestamps de criação. A metade de enforcement é o ponto: combine watermarks com Allowed AMIs para restringir lançamentos a imagens que carregam um watermark aprovado, e aplique isso em toda a organização com Declarative Policies. O EC2 Image Builder pode anexar um watermark no pipeline. Todas as Regiões, incluindo GovCloud e China, sem custo.

O buraco que isso fecha é específico. Programas de golden AMI impõem "lance apenas a partir da conta X" com Allowed AMIs. Na primeira vez em que um time copia a golden image para a própria conta para adicionar um pacote, a linhagem se perde, e a política ou bloqueia (então eles param de usar a golden image) ou permite a conta deles (então a política não significa nada). Um watermark que sobrevive à cópia permite dizer "lance qualquer coisa descendente da golden image" em vez disso.

Seja preciso sobre o que ele prova. Um watermark é proveniência, não integridade: diz que a imagem descende de um build que você aprovou, não que nada mudou na imagem derivada ou na instância depois. Ele substitui linhagem baseada em tags; não substitui o Inspector, o compliance do SSM ou a assinatura de imagens.

Lambda MicroVMs: uma VM por sessão não confiável

A AWS introduziu Lambda MicroVMs em 22 de junho: uma primitiva serverless que dá a cada usuário ou job sua própria VM isolada por Firecracker com kernel próprio, suspend e resume com estado de memória e disco intactos por até 8 horas de runtime total, e um endpoint HTTPS dedicado com suporte a HTTP/2, gRPC e WebSockets. Os limites por MicroVM são 16 vCPUs, 32 GB de memória, 32 GB de disco, apenas ARM64. Segundo o post de lançamento, você constrói uma imagem a partir de um Dockerfile com aws lambda-microvms create-microvm-image, lança com aws lambda-microvms run-microvm e uma política de idle, e paga computação baseline enquanto ela roda. Disponível em US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) e Asia Pacific (Tokyo).

Escrevi sobre isso em detalhe em AWS Lambda MicroVMs: o serverless ganha um sandbox isolado e com estado. A versão curta: a pergunta de design não é "funções ou MicroVMs" e sim "o que no meu sistema executa código que eu não escrevi". Notebooks, plugins de clientes e qualquer coisa que um LLM gera pertencem atrás de uma fronteira de VM com ciclo de vida, e até esta semana isso significava sua própria frota de Firecracker ou um container por tenant. O ângulo de agentes está em ercan.ai.

Network Firewall corrige um default que quebrava conexões

O AWS Network Firewall atualizou sua ação de drop padrão em 22 de junho. Novas políticas de firewall agora usam como ação stateful padrão "Application drop established (server-directed only)". O default anterior, "Application drop established (bidirectional)", podia descartar em silêncio pacotes TCP legítimos de servidor para cliente, como window updates, keep-alives e resets, o que aparecia como falhas de conexão intermitentes que ninguém conseguia reproduzir. Políticas existentes não são alteradas automaticamente; a AWS aponta para a documentação para atualizá-las, e observa que ambientes que precisam da ação bidirecional para handshakes TLS pós-quânticos fragmentados podem trocar ou adicionar uma flag to_server às suas regras de drop TCP.

Este é o item para agir hoje, porque é uma mudança de default, não um recurso. Toda aws_networkfirewall_firewall_policy no seu Terraform copiada de um exemplo antigo carrega o default antigo. Faça grep pelas ações stateful padrão, compare com a nova recomendação e aplique a mudança primeiro em staging. Se você tem um ticket aberto de timeout intermitente sem explicação contra algo atrás do Network Firewall, pode ter acabado de encontrar a causa.

Também nesta semana

  • Investigações com IA do GuardDuty entram em preview em 10 Regiões (23 de junho): cada finding recebe uma disposição com score de confiança, mapeamento MITRE ATT&CK, 90 dias de atividade relacionada e uma recomendação de supressão, contenção ou remediação, via console, CLI, API ou AWS MCP Server.
  • Ingestão gerenciada de syslog no CloudWatch Logs (23 de junho) aceita RFC 5424, RFC 3164 e Cisco FTD/ASA via TCP, TCP+TLS ou UDP para um VPC endpoint, sem agente, com facility, severity e hostname extraídos.
  • OTel Container Insights para EKS (23 de junho) coleta métricas de infraestrutura de 30 segundos via receivers cAdvisor, Kube State Metrics e NVIDIA DCGM com labels do Kubernetes e um endpoint PromQL, pelo add-on CloudWatch Observability v6.2.0 ou posterior.
  • Governança aberta para o MySQL: a Oracle anunciou um steering committee com quatro cadeiras fora da Oracle, uma delas da AWS. Dada a extensão do Extended Support na semana passada, a AWS planeja rodar MySQL por muito tempo.

O fio condutor

Três dos quatro itens principais desta semana tornam exigível uma propriedade que antes era aspiracional: de onde veio uma imagem, onde código não confiável roda, como um firewall trata a metade de retorno de uma conexão. O quarto, Transform em toda Região comercial, faz o mesmo para residência de dados. Nada disso é empolgante. Tudo isso é o tipo de controle que, uma vez que existe, faz o jeito anterior parecer negligente em uma revisão pós-incidente.

Leia isto a seguir

A leitura do lado de agentes sobre MicroVMs e as investigações do GuardDuty está em ercan.ai. Para consultoria em AWS, nuvem, pipelines de CI/CD, Linux, GitHub/GitLab e mais, o hub é ercanermis.com.

Referências