La semaine du 10 août a vu AWS reprendre à son compte des décisions que les équipes plateforme prenaient jusqu'ici à la main, et deux d'entre elles méritent un second regard avant d'accepter le défaut. Les application status checks d'EC2 permettent à EC2 lui-même de sonder un endpoint HTTP sur votre instance et de transmettre le résultat à Auto Scaling, et IAM role manager est passé en GA : il crée les rôles IAM dont un service a besoin pendant que vous cliquez dans sa console. Également cette semaine : ACM a daté la fin de la validation par e-mail, et MSK a appris à migrer un cluster de ZooKeeper vers KRaft en place. Aucun lancement AWS Transform cette semaine ; côté modernisation, il y a eu le sujet MSK et un correctif plus discret dans Elastic Disaster Recovery.

Application status checks EC2 : la santé sans load balancer

Jusqu'ici, EC2 avait deux status checks : system (l'hôte) et instance (l'OS invité). Le nouvel application status check ajoute une troisième couche. Vous définissez un protocole, un port et un chemin, plus les codes de réponse qui comptent comme sains, vous associez le check à des instances par ID ou par tag, et EC2 envoie une requête HTTP ou HTTPS toutes les 60 secondes et rapporte le résultat à côté des deux autres. Les Auto Scaling groups peuvent remplacer les instances qui échouent. Toutes les Régions commerciales et GovCloud (US).

La question évidente est de savoir pourquoi vous en voudriez alors que le target group de l'ALB sonde déjà le même chemin. La réponse, ce sont toutes les instances qui ne sont pas derrière un load balancer : des workers qui consomment SQS, des schedulers, un hôte Docker dont le daemon est mort pendant que l'instance continuait à répondre à l'ICMP. Ces machines sont aujourd'hui « saines » selon tous les signaux dont EC2 dispose, et l'astreinte apprend le contraire par un client. Le mode de défaillance à prévoir est l'inverse : un endpoint de santé qui dépend d'un composant aval (une base de données, un cache) mettra toute la flotte à terre quand l'aval aura un hoquet, parce que l'ASG remplacera des instances qui allaient très bien. Gardez le chemin sondé superficiel, et comme l'association par tag signifie qu'une faute de frappe dans un tag peut laisser la moitié de la flotte sans contrôle en silence, auditez avec aws ec2 describe-instance-status après le rollout.

IAM role manager : pratique, et le défaut Lambda est large

Role manager observe ce que vous configurez dans une console prise en charge (six au lancement, dont Lambda et EventBridge) et crée un rôle par défaut ou réutilise un rôle existant du compte qui convient déjà, via la nouvelle API AcquireRole rapprochée des modèles de rôles managés par AWS. Les rôles sont des rôles IAM ordinaires que vous contrôlez entièrement, il s'agit d'un seul réglage au niveau du compte dans la console IAM, et il est activé par défaut dans les comptes créés avec la nouvelle expérience AWS. Indisponible dans GovCloud (US) et en Chine.

Le détail qui devrait guider votre décision se trouve dans le billet du blog sécurité : parce que les permissions d'une fonction Lambda ne peuvent pas être connues avant que le code existe, le rôle qu'elle reçoit porte PowerUserAccess, qui exclut IAM, Organizations et les paramètres du compte mais inclut tout le reste. La réponse d'AWS consiste à lancer IAM Access Analyzer plus tard et à resserrer. C'est une histoire raisonnable pour un sandbox de développeur et une mauvaise pour la production, parce que « plus tard » est l'étape qui n'arrive jamais. Si vos comptes provisionnent déjà les rôles via Terraform ou CDK, désactivez-le, et utilisez une SCP pour empêcher les comptes membres de le réactiver ; le billet confirme que les SCP peuvent le verrouiller. Si vous le voulez actif pour les sandboxes, associez-le à l'account access manager de la même semaine, qui attribue les rôles IAM d'un compte à des utilisateurs et groupes Identity Center, pour qu'au moins les humains qui détiennent ces rôles larges soient fédérés.

La validation par e-mail d'ACM s'arrête en 2027, et les dates sont échelonnées

À la suite de la décision du CA/Browser Forum de novembre 2025, ACM cessera de prendre en charge les certificats publics validés par e-mail en trois étapes : plus de validation par e-mail dans les nouvelles Régions après le 1er janvier 2027, plus aucune nouvelle demande validée par e-mail où que ce soit après le 31 mars 2027, et plus de renouvellement des certificats existants validés par e-mail après le 30 septembre 2027. Les certificats émis avant l'échéance de l'industrie restent valides jusqu'à leur expiration, donc rien ne casse le jour J ; ce qui casse, c'est le renouvellement un an plus tard, sur un certificat dont personne ne se souvient avoir fait la demande.

La migration coûte peu si vous la faites maintenant. Filtrez la console ACM sur la méthode de validation Email et le type Amazon Issued, ou scriptez-le, puis basculez chaque certificat en place avec aws acm update-certificate-options, qui conserve l'ARN pour qu'aucun listener ni aucune distribution n'ait à être modifié. Ajoutez le CNAME dans la fenêtre de 72 heures et ACM renouvelle avec la nouvelle méthode. La validation HTTP existe aussi, mais uniquement pour CloudFront. Traitez cela comme un ticket du T3, pas comme un ticket de 2027.

MSK : de ZooKeeper à KRaft sans nouveau cluster

Kafka 3.9.x est la dernière lignée qui prend en charge ZooKeeper et Kafka 4.x est KRaft uniquement, donc tout cluster MSK provisionné encore sur ZooKeeper a une migration devant lui. MSK la fait désormais en place : pas de nouvelle infrastructure, pas de copie de données, pas de reconfiguration des clients, et le cluster reste disponible pendant toute l'opération selon AWS. Il faut d'abord être en 3.9.x. Disponible partout où tourne MSK provisionné, sauf dans l'European Sovereign Cloud. C'est le genre de modernisation qui n'est jamais priorisée parce qu'aucune fonctionnalité n'y est attachée, et c'est exactement pour cela qu'un chemin en un bouton compte : il transforme un projet d'un trimestre en une fenêtre de changement.

Également cette semaine

Le fil conducteur

Les application status checks et role manager sont le même mouvement dans deux directions. L'un laisse EC2 observer votre application pour qu'il puisse agir à votre place ; l'autre laisse IAM agir à votre place avant que vous ayez observé quoi que ce soit. Le premier est un bon échange parce que le rayon d'impact d'un mauvais health check se limite à une flotte et qu'il est bruyant. Le second est un moins bon échange parce que le rayon d'impact d'un rôle large est le compte et qu'il est silencieux. L'échéance ACM et la migration MSK rappellent que la moitié ingrate du travail de plateforme, les renouvellements et les planchers de version, est là où vivent les vraies pannes. Mettez les trois éléments datés au calendrier cette semaine et débattez de role manager à loisir.

À 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