Le lancement le plus lourd de conséquences de la semaine du 17 août est celui que la plupart des équipes ne remarqueront qu'à l'arrivée d'une notification : Amazon EKS gère désormais la rotation des autorités de certification, et il existe parce que les premiers clusters EKS, créés en 2018 avec des CA valables dix ans, approchent de leur fin. À ses côtés, Direct Connect a relevé le plafond de préfixes entrants de 100 à 1 000, Europe (London) a reçu une quatrième Availability Zone, et IAM Policy Autopilot a appris à lire les fichiers de plan Terraform. Aucun lancement AWS Transform ou DMS cette semaine, donc l'angle migration est celui du réseau : la limite de préfixes était un vrai bloqueur pour les grandes bascules hybrides.

Rotation des CA EKS : l'échéance que personne n'a mise dans un ticket

Chaque cluster EKS a une CA qui signe le certificat de l'API server, et chaque cluster créé depuis le lancement en porte une valable dix ans. Les premiers datent de la mi-2018. Si cette CA expire, rien de ce qui lui fait confiance ne peut plus parler au control plane : les kubelets, kubectl, les runners CI, les operators que vous avez oubliés. La nouvelle rotation managée vous donne un cycle de vie avec des garde-fous : EKS ajoute une CA successeur, met à jour les composants managés par AWS pour qu'ils lui fassent confiance, gère automatiquement les instances EKS Auto Mode et les nœuds Fargate, envoie des notifications d'expiration à l'avance, active le successeur selon son propre calendrier si vous ne le faites jamais, et conserve un rollback vers la CA précédente. Sans surcoût, dans toutes les Régions commerciales, pilotable depuis la CLI, les API EKS, CloudFormation ou la console.

Lisez la liste pour ce qu'AWS ne fait pas. Vous devez toujours remplacer vos propres nœuds workers pour qu'ils fassent confiance au successeur, et vous devez toujours mettre à jour chaque client externe, c'est-à-dire chaque kubeconfig embarqué dans un système CI, chaque bastion, chaque outil tiers qui a épinglé certificate-authority-data. L'activation automatique est la partie à respecter : c'est un filet de sécurité contre l'expiration, mais si elle se déclenche avant que vous ayez fait tourner vos clients, ces clients cassent à un moment choisi par AWS. La bonne approche est d'inventorier dès maintenant qui parle à chaque cluster, de renouveler les node groups autogérés comme un refresh ordinaire, et d'activer le successeur vous-même dans une fenêtre de changement. Commencez par le cluster le plus ancien du compte ; aws eks describe-cluster et le createdAt du cluster vous disent lequel c'est.

Direct Connect : 1 000 préfixes et un pool de capacité

Une VIF privée ou de transit acceptait jusqu'ici au plus 100 préfixes de routes annoncés depuis le on-premises. Pour un data center avec dix ans d'étalement de sous-réseaux, cela voulait dire résumer agressivement ou répartir sur plusieurs VIF, et pendant une migration cela voulait dire les routes résumées « temporaires » qui survivent à la migration. Les contrôles de préfixes entrants vous permettent d'allouer jusqu'à 1 000 préfixes IPv4 et 1 000 préfixes IPv6 par VIF sur les connexions dédiées et hébergées, puisés dans de nouveaux pools de capacité au niveau de la connexion dédiée et de la Direct Connect gateway. Les pools de connexion évoluent avec la vitesse du lien et les pools de LAG avec le nombre de membres. Sans coût supplémentaire ; Régions commerciales, GovCloud (US) et les deux Régions de Chine.

Le modèle de pool est la partie à comprendre avant d'y toucher. La capacité est un budget partagé, donc une équipe qui alloue 900 préfixes à une seule VIF a dépensé le pool pour tous les autres sur cette connexion. Traitez les allocations comme de l'IaC, pas comme des clics dans la console, et décidez de la répartition avant que la première équipe ne demande.

Régions : eu-west-2d et une Local Zone à Las Vegas

Europe (London) a ajouté eu-west-2d le 19 août, avec de la capacité accélérée Trn3 et P6 plus du compute généraliste. Les nouvelles AZ sont faciles à ignorer et coûteuses à ignorer : si votre VPC a été construit avec trois sous-réseaux par tier et des noms d'AZ codés en dur, la quatrième zone est invisible pour vos Auto Scaling groups et vos node groups EKS jusqu'à ce que quelqu'un ajoute les sous-réseaux. Le lendemain, une Local Zone à Las Vegas (us-west-2-las-2a) est passée en GA avec les instances C7i, M7i, R7i et C8gn, les types EBS gp3/gp2/io1/sc1/st1, ECS, EKS, ALB et Direct Connect.

IAM : Policy Autopilot pour Terraform, et un quota que vous ne heurtez plus

IAM Policy Autopilot, l'outil open source de re:Invent 2025 qui dérive des politiques restreintes à partir du code applicatif, prend désormais un fichier de plan Terraform et produit une politique de base limitée à create, read, update et delete sur les ressources de ce plan, avec des ARN précis quand il le peut. Il tourne en local et vit dans awslabs/iam-policy-autopilot. Le vide qu'il comble est réel : le rôle de déploiement d'un pipeline Terraform est en général le rôle le plus large du compte précisément parce que personne ne pouvait énumérer ce dont il a besoin. Une base dérivée d'un plan est un point de départ défendable, avec la réserve qu'une base issue d'un plan ne couvre pas le destroy d'une ressource absente du plan suivant. Par ailleurs, la limite par défaut de politiques managées par rôle a doublé, de 10 à 20, avec 25 disponibles sur demande, ce qui retire du service toute une catégorie de contournements du type « politique trop grosse, on en attache une autre ».

Également cette semaine

Le fil conducteur

Trois des lancements de la semaine portent sur des limites fixées quand la plateforme était petite : une CA de dix ans qui semblait une éternité en 2018, une VIF à 100 préfixes datant de l'époque où hybride voulait dire un seul data center, un rôle à 10 politiques d'avant que quiconque n'attache des politiques managées par douzaines. AWS relève ou automatise chacune d'elles, ce qui est bienvenu, mais la charge ne disparaît pas, elle se déplace. La rotation des CA vous laisse les clients, le pool de préfixes vous laisse la politique d'allocation, la base Autopilot vous laisse le chemin de destroy. L'automatisation au niveau de la plateforme convertit une limite dure en décision de conception, et les décisions de conception ont besoin d'un propriétaire.

À lire ensuite

Pour la lecture IA et agents de la même semaine, les notes de terrain sont sur ercan.ai. Le conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore passe par ercanermis.com.

Références