The most consequential launch of the week of 17 August is one most teams will not notice until a notification arrives: Amazon EKS now manages certificate authority rotation, and it exists because the first EKS clusters, created in 2018 with ten-year CAs, are approaching the end of them. Alongside it, Direct Connect raised the inbound prefix ceiling from 100 to 1,000, Europe (London) got a fourth Availability Zone, and IAM Policy Autopilot learned to read Terraform plan files. No AWS Transform or DMS launch this week, so the migration angle is the networking one: the prefix limit was a real blocker for large hybrid cutovers.

EKS CA rotation: the deadline nobody put in a ticket

Every EKS cluster has a CA that signs the API server certificate, and every cluster created since launch carries one valid for ten years. The first ones date from mid-2018. If that CA expires, nothing that trusts it can talk to the control plane: kubelets, kubectl, CI runners, the operators you forgot about. The new managed rotation gives you a lifecycle with safeguards: EKS appends a successor CA, updates the AWS-managed components to trust it, automatically handles EKS Auto Mode instances and Fargate nodes, sends advance expiration notifications, activates the successor on its own schedule if you never do, and keeps a rollback to the previous CA. No extra cost, all commercial Regions, drivable from the CLI, the EKS APIs, CloudFormation or the console.

Read the list for what AWS does not do. You still have to replace your own worker nodes so they trust the successor, and you still have to update every external client, which means every kubeconfig baked into a CI system, every bastion, every third-party tool that pinned certificate-authority-data. The automatic activation is the part to respect: it is a safety net against expiry, but if it fires before you have rotated your clients, those clients break at a time AWS chose. The right move is to inventory who talks to each cluster now, roll self-managed node groups as a normal refresh, and activate the successor yourself inside a change window. Start with the oldest cluster in the account; aws eks describe-cluster and the cluster's createdAt tell you which one that is.

Direct Connect: 1,000 prefixes and a capacity pool

A private or transit VIF used to accept at most 100 route prefixes advertised from on-premises. For a data centre with a decade of subnet sprawl that meant summarising aggressively or splitting across VIFs, and during a migration it meant the "temporary" summary routes that outlive the migration. Inbound prefix controls let you allocate up to 1,000 IPv4 and 1,000 IPv6 prefixes per VIF on dedicated and hosted connections, drawn from new capacity pools at the dedicated-connection and Direct Connect gateway level. Connection pools scale with link speed and LAG pools with member count. No additional cost; commercial Regions, GovCloud (US) and both China Regions.

The pool model is the part to understand before you touch it. Capacity is a shared budget, so a team that allocates 900 prefixes to one VIF has spent the pool for everyone else on that connection. Treat allocations as IaC, not console clicks, and decide the split before the first team asks.

Regions: eu-west-2d and a Las Vegas Local Zone

Europe (London) added eu-west-2d on 19 August, with Trn3 and P6 accelerated capacity plus general-purpose compute. New AZs are easy to ignore and expensive to ignore: if your VPC was built with three subnets per tier and hard-coded AZ names, the fourth zone is invisible to your Auto Scaling groups and your EKS node groups until someone adds the subnets. The day after, a Local Zone in Las Vegas (us-west-2-las-2a) went GA with C7i, M7i, R7i and C8gn instances, the gp3/gp2/io1/sc1/st1 EBS types, ECS, EKS, ALB and Direct Connect.

IAM: Policy Autopilot for Terraform, and a quota you stopped hitting

IAM Policy Autopilot, the open-source tool from re:Invent 2025 that derives scoped-down policies from application code, now takes a Terraform plan file and produces a baseline policy limited to create, read, update and delete on the resources in that plan, with specific ARNs where it can. It runs locally and lives at awslabs/iam-policy-autopilot. The gap it closes is real: the deploy role for a Terraform pipeline is usually the broadest role in the account precisely because nobody could enumerate what it needs. A plan-derived baseline is a defensible starting point, with the caveat that a baseline from one plan does not cover the destroy of a resource that is not in the next plan. Separately, the default managed-policy limit per role doubled from 10 to 20, with 25 available on request, which retires a class of "policy too large, attach another" workarounds.

Also this week

The throughline

Three of this week's launches are about limits that were set when the platform was small: a ten-year CA that seemed like forever in 2018, a 100-prefix VIF from when hybrid meant one data centre, a 10-policy role from before anyone attached managed policies by the dozen. AWS is raising or automating each of them, which is welcome, but the burden does not disappear, it moves. The CA rotation leaves you the clients, the prefix pool leaves you the allocation policy, the Autopilot baseline leaves you the destroy path. Automation at the platform layer converts a hard limit into a design decision, and design decisions need an owner.

Read this next

For the AI and agent reading of the same week, the field notes live at ercan.ai. Consulting on AWS, cloud, CI/CD pipelines, Linux, GitHub/GitLab and more runs through ercanermis.com.

References