Duas coisas aconteceram na semana de 24 de agosto que ainda vão importar em 2028: a AWS concordou em adquirir a DuckLabs, a empresa de Amsterdã por trás do DuckDB, com o banco permanecendo sob licença MIT na sua fundação independente; e o Amazon ECS começou a detectar e reparar container instances cujo agente perdeu contato com o control plane. Em volta delas, o Lambda teve uma terça-feira de três lançamentos (runtimes em preview, resource-based policies completas, PrivateLink para MicroVMs), o EKS passou a aceitar até dez provedores OIDC por cluster, e no lado da migração o AWS Transform entrou no escopo FedRAMP Class C enquanto o Elastic Disaster Recovery ganhou Recovery Plans ordenados. O EC2 também fez vinte anos.

DuckLabs: a AWS compra a engine para dados que cabem em uma máquina

O anúncio é cuidadoso nos pontos que importam para quem tem DuckDB em produção: continua open source sob a licença MIT, continua sob a Foundation independente, e Hannes Mühleisen e Mark Raasveldt seguem liderando a direção técnica. A razão declarada pela AWS são os agentes, que exploram dados do jeito que analistas fazem, em pequenas consultas iterativas sobre um terabyte ou menos, e a evidência é da própria AWS: o Amazon Quick já roda DuckDB sobre S3 Tables e serviu mais de 2,5 bilhões de consultas com uma queda de 30% na latência média.

A leitura honesta para um time de plataforma tem duas partes. Primeiro, a engine in-process que o seu pessoal de dados já roda em notebooks agora vai aparecer dentro do Athena, Redshift, EMR, Glue e SageMaker de alguma forma, o que significa que o caminho de "small data" na AWS deixa de ser um cluster Spark esperando um arquivo Parquet de 2 GB. Isso é boa notícia para o custo. Segundo, toda aquisição de uma empresa open source carrega a mesma pergunta independentemente do press release, e a resposta aqui é a licença e a estrutura da fundação. MIT significa que forks são triviais se a governança algum dia derivar. Fique de olho em onde os novos recursos aparecem primeiro, no repositório aberto ou nos serviços da AWS, porque essa é a pista, não o texto da licença.

ECS: um evento de saúde para a falha que você não conseguia ver

Uma container instance do ECS cujo agente perdeu a conexão com o control plane é um tipo específico de quebrada: as tasks nela podem continuar rodando, a instância passa nos status checks do EC2, mas o ECS não consegue posicionar, parar nem observar nada ali. Degradação do EBS, um evento térmico ou uma falha de rede podem causar isso. O ECS agora monitora isso continuamente e emite um evento de mudança de saúde de container instance AGENT_CONNECTIVITY em Fargate, ECS Managed Instances e ECS on EC2, sem custo, em todas as Regiões comerciais e GovCloud (US).

A divisão é a parte importante. No Fargate e nas Managed Instances, o ECS faz a recuperação sozinho: drena as cargas, provisiona capacidade de substituição, remove a instância comprometida. No ECS on EC2 você recebe o evento e o trabalho. Esse é o design certo, porque no EC2 o capacity provider é seu e o ECS não tem como saber se terminar a instância é seguro, mas significa que o lançamento só te ajuda se você o conectar. Uma regra do EventBridge no evento que chama aws autoscaling set-instance-health --health-status Unhealthy é a versão mínima viável. Se você queria um motivo para mover os capacity providers EC2 remanescentes para Managed Instances, este é concreto: na mesma semana o AWS Batch ganhou Managed Instances como compute environment por meio de um bloco managedInstancesProvider em CreateComputeEnvironment.

A terça-feira do Lambda: runtimes, políticas, endpoints privados

Node.js 26 e Python 3.15 chegaram como runtimes em preview público com uma escolha de design útil: os identificadores são nodejs26.x e python3.15, os mesmos que o GA terá, então as funções passam para GA automaticamente. O custo dessa conveniência é a armadilha dentro dela. Um runtime em preview está excluído do SLA do Lambda e do AWS Support, e breaking changes são possíveis, então uma função definida como python3.15 em um template SAM compartilhado hoje é uma função de produção em um runtime sem suporte amanhã. Bloqueie isso no CI.

Resource-based policies completas do IAM substituem o modelo de permissão de um principal por vez por um único documento de política cobrindo múltiplos principals e ações, com o conjunto completo de condition keys do IAM. Quem já gerenciou uma função invocada por três serviços e uma conta externa sabe que o modelo antigo produzia uma resource policy que ninguém conseguia ler; isso torna a política revisável e, via CloudFormation e SAM, diffável. E as Lambda MicroVMs agora suportam PrivateLink, então recursos na VPC podem criar imagens, lançar MicroVMs e acessar o endpoint HTTP de cada MicroVM sem sair da rede da AWS, que era o bloqueio para times regulados que as usam como sandboxes de agentes.

Migração e DR: Transform no escopo FedRAMP, DRS ganha um runbook

O AWS Transform agora está no escopo do FedRAMP Class C (o antigo baseline Moderate) quando usado a partir de US East (N. Virginia), com destino US East ou US West; o componente MGN se qualifica separadamente para Class D. Para migrações do setor público que estavam travadas em compliance de ferramental, esse é o desbloqueio. Os Recovery Plans do DRS permitem agrupar servidores em passos sequenciais com tempos de espera, adicionar gates de aprovação, rodar tudo como um drill não disruptivo e acompanhar o progresso ao vivo. A ordem banco-antes-da-aplicação que vivia em uma página de wiki agora é um objeto que o serviço executa, o que também é o único jeito de um drill de DR ser rodado duas vezes.

Também nesta semana

O fio condutor

O lançamento do ECS e a aquisição do DuckDB são ambos a AWS admitindo que muito trabalho real acontece abaixo da escala para a qual seus serviços foram projetados. Uma container instance silenciando é pequena demais para um dashboard e comum demais para ignorar; um terabyte de Parquet é pequeno demais para o Spark e comum demais para fingir o contrário. As duas correções têm a mesma forma: perceber a falha pequena ou o dataset pequeno, tratar nativamente, e parar de fazer o cliente construir um cluster ou um cron job para lidar com isso. O preview de runtime do Lambda e as resource policies pertencem à mesma semana porque também são sobre a cauda longa: a função que ninguém é dono, invocada por quatro principals, em um runtime que alguém definiu em 2026. Plataformas ganham confiança na cauda longa, não no keynote.

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