O lançamento mais consequente da semana de 17 de agosto é um que a maioria dos times não vai notar até uma notificação chegar: o Amazon EKS agora gerencia a rotação de autoridades certificadoras, e ele existe porque os primeiros clusters EKS, criados em 2018 com CAs de dez anos, estão se aproximando do fim delas. Junto com ele, o Direct Connect elevou o teto de prefixos de entrada de 100 para 1.000, Europe (London) ganhou uma quarta Availability Zone, e o IAM Policy Autopilot aprendeu a ler arquivos de plan do Terraform. Nenhum lançamento do AWS Transform ou do DMS nesta semana, então o ângulo de migração é o de rede: o limite de prefixos era um bloqueio real para grandes cutovers híbridos.

Rotação de CA no EKS: o prazo que ninguém colocou em um ticket

Todo cluster EKS tem uma CA que assina o certificado do API server, e todo cluster criado desde o lançamento carrega uma válida por dez anos. Os primeiros datam de meados de 2018. Se essa CA expira, nada que confia nela consegue falar com o control plane: kubelets, kubectl, runners de CI, os operators que você esqueceu. A nova rotação gerenciada dá a você um ciclo de vida com salvaguardas: o EKS anexa uma CA sucessora, atualiza os componentes gerenciados pela AWS para confiar nela, cuida automaticamente de instâncias do EKS Auto Mode e nós Fargate, envia notificações antecipadas de expiração, ativa a sucessora no próprio cronograma se você nunca o fizer, e mantém um rollback para a CA anterior. Sem custo extra, todas as Regiões comerciais, operável pela CLI, pelas APIs do EKS, pelo CloudFormation ou pelo console.

Leia a lista pelo que a AWS não faz. Você ainda precisa substituir seus próprios worker nodes para que confiem na sucessora, e ainda precisa atualizar todo cliente externo, o que significa todo kubeconfig embutido em um sistema de CI, todo bastion, toda ferramenta de terceiros que fixou certificate-authority-data. A ativação automática é a parte a respeitar: é uma rede de segurança contra a expiração, mas se ela disparar antes de você ter rotacionado seus clientes, esses clientes quebram em um momento que a AWS escolheu. O movimento certo é inventariar quem fala com cada cluster agora, trocar node groups autogerenciados como um refresh normal, e ativar a sucessora você mesmo dentro de uma janela de mudança. Comece pelo cluster mais antigo da conta; aws eks describe-cluster e o createdAt do cluster dizem qual é.

Direct Connect: 1.000 prefixos e um pool de capacidade

Uma VIF privada ou de trânsito costumava aceitar no máximo 100 prefixos de rota anunciados do on-premises. Para um data center com uma década de proliferação de subnets isso significava sumarizar agressivamente ou dividir entre VIFs, e durante uma migração significava as rotas sumarizadas "temporárias" que sobrevivem à migração. Os controles de prefixos de entrada permitem alocar até 1.000 prefixos IPv4 e 1.000 IPv6 por VIF em conexões dedicadas e hospedadas, retirados de novos pools de capacidade no nível da conexão dedicada e do Direct Connect gateway. Pools de conexão escalam com a velocidade do link e pools de LAG com o número de membros. Sem custo adicional; Regiões comerciais, GovCloud (US) e as duas Regiões da China.

O modelo de pool é a parte a entender antes de tocar nele. A capacidade é um orçamento compartilhado, então um time que aloca 900 prefixos a uma VIF gastou o pool de todos os outros naquela conexão. Trate as alocações como IaC, não como cliques no console, e decida a divisão antes de o primeiro time pedir.

Regiões: eu-west-2d e uma Local Zone em Las Vegas

Europe (London) adicionou a eu-west-2d em 19 de agosto, com capacidade acelerada Trn3 e P6 mais computação de uso geral. AZs novas são fáceis de ignorar e caras de ignorar: se a sua VPC foi construída com três subnets por camada e nomes de AZ hard-coded, a quarta zona é invisível para os seus Auto Scaling groups e seus node groups do EKS até alguém adicionar as subnets. No dia seguinte, uma Local Zone em Las Vegas (us-west-2-las-2a) entrou em GA com instâncias C7i, M7i, R7i e C8gn, os tipos de EBS gp3/gp2/io1/sc1/st1, ECS, EKS, ALB e Direct Connect.

IAM: Policy Autopilot para Terraform, e uma quota que você parou de bater

O IAM Policy Autopilot, a ferramenta open source do re:Invent 2025 que deriva políticas com escopo reduzido a partir do código da aplicação, agora recebe um arquivo de plan do Terraform e produz uma política baseline limitada a create, read, update e delete nos recursos daquele plan, com ARNs específicos onde consegue. Roda localmente e vive em awslabs/iam-policy-autopilot. A lacuna que fecha é real: o papel de deploy de um pipeline Terraform costuma ser o papel mais amplo da conta precisamente porque ninguém conseguia enumerar o que ele precisa. Um baseline derivado de plan é um ponto de partida defensável, com a ressalva de que um baseline de um plan não cobre o destroy de um recurso que não está no plan seguinte. Separadamente, o limite padrão de managed policies por papel dobrou de 10 para 20, com 25 disponíveis sob solicitação, o que aposenta uma classe de contornos do tipo "política grande demais, anexe outra".

Também nesta semana

O fio condutor

Três dos lançamentos desta semana são sobre limites definidos quando a plataforma era pequena: uma CA de dez anos que parecia eterna em 2018, uma VIF de 100 prefixos de quando híbrido significava um data center, um papel de 10 políticas de antes de alguém anexar managed policies por dúzia. A AWS está elevando ou automatizando cada um deles, o que é bem-vindo, mas o fardo não desaparece, ele se move. A rotação de CA deixa os clientes com você, o pool de prefixos deixa a política de alocação com você, o baseline do Autopilot deixa o caminho de destroy com você. Automação na camada da plataforma converte um limite rígido em uma decisão de design, e decisões de design precisam de um dono.

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