La semaine du 22 au 28 juin 2026 a donné aux équipes plateforme trois primitives de gouvernance qu'elles simulaient jusque-là avec des tags et des pages de wiki : des filigranes d'AMI qui survivent aux copies, aux Régions et aux partages entre comptes ; des Lambda MicroVMs qui placent le code non fiable dans sa propre machine virtuelle ; et un défaut corrigé de Network Firewall qui rejetait silencieusement des paquets légitimes du serveur vers le client. Côté migration, AWS Transform dépose désormais les workloads dans n'importe quelle Région commerciale, et OpenSearch comme MSK ont livré des parcours de migration guidés par agent.

Pas de Summit cette semaine, donc les lancements sont plus petits et plus utiles : chaque élément de tête est quelque chose sur quoi vous auriez écrit une politique l'an dernier en espérant que les gens la suivent.

Migration : toute Région, et deux parcours guidés par agent de plus

AWS Transform for migrations prend désormais en charge toutes les Régions commerciales AWS comme cibles de migration, publié le 22 juin. La Région cible est celle où sont déployés la landing zone, le réseau et les serveurs réhébergés, et l'annonce en ajoute 16 : US West (N. California), Africa (Cape Town), Asia Pacific (Bangkok, Hong Kong, Hyderabad, Jakarta, Kuala Lumpur, Melbourne, New Zealand, Taipei), Canada (Calgary), Europe (Milan, Spain, Zurich), Mexico (Querétaro) et Middle East (Tel Aviv). Pour les lecteurs européens, Zurich, Milan et l'Espagne sont celles qui transforment « l'agent ne peut pas le déposer là où le juridique exige qu'il vive » d'un blocage en un menu déroulant.

Deux lancements proches des bases de données la même semaine suivent le schéma du renommage de MGN : la logique de migration passe dans quelque chose qu'un agent pilote. Amazon OpenSearch Service propose désormais des migrations assistées par IA (23 juin) : Migration Assistant gagne un workflow guidé par agent, utilisable depuis Kiro, Claude Code et d'autres, pour planifier le passage de Solr, Elasticsearch ou OpenSearch autogérés vers OpenSearch Serverless ou Managed Clusters, déployer l'infrastructure et exécuter la migration de l'historique puis du trafic live, le capture-and-replay couvrant désormais Solr. Les Amazon MSK AI Agent Skills (22 juin) donnent à Kiro, Claude Code et Cursor des conseils d'expert pour dimensionner, dépanner, superviser et migrer des clusters Kafka externes vers MSK Express.

Le compromis des skills comme mécanisme de distribution, c'est le contrôle de version : un runbook dans votre dépôt a un historique de commits, une skill fournisseur tirée à l'exécution est un prompt que vous ne pouvez pas differ. Très bien pour une migration ponctuelle. Pour quarante clusters identiques, exportez ce que l'agent a fait la première fois dans quelque chose qui vous appartient.

Filigranes d'AMI : une lignée qui ne se perd pas à la copie

Amazon EC2 a annoncé les AMI Watermarks le 24 juin. Vous intégrez un identifiant personnalisé dans une AMI privée, et il se propage à chaque AMI qui en dérive : copies vers d'autres Régions, images créées depuis une instance en cours d'exécution, et images partagées avec d'autres comptes. Chaque filigrane porte l'ID de l'AMI d'origine, son propriétaire, sa Région et ses horodatages de création. La moitié « application » est le vrai sujet : combinez les filigranes avec Allowed AMIs pour restreindre les lancements aux images portant un filigrane approuvé, et appliquez cela à toute l'organisation avec les Declarative Policies. EC2 Image Builder peut attacher un filigrane dans le pipeline. Toutes les Régions, GovCloud et Chine comprises, sans frais.

Le trou que cela bouche est précis. Les programmes de golden AMI imposent « lancer uniquement depuis le compte X » avec Allowed AMIs. La première fois qu'une équipe copie l'image dorée dans son propre compte pour ajouter un paquet, la lignée disparaît, et la politique soit la bloque (donc l'équipe cesse d'utiliser l'image dorée), soit autorise son compte (donc la politique ne veut plus rien dire). Un filigrane qui survit à la copie vous permet de dire « lancer tout ce qui descend de l'image dorée » à la place.

Soyez précis sur ce que cela prouve. Un filigrane est de la provenance, pas de l'intégrité : il dit que l'image descend d'un build que vous avez approuvé, pas que rien n'a changé dans l'image dérivée ou sur l'instance ensuite. Il remplace la lignée par tags ; il ne remplace ni Inspector, ni la conformité SSM, ni la signature d'images.

Lambda MicroVMs : une VM par session non fiable

AWS a introduit Lambda MicroVMs le 22 juin : une primitive serverless qui donne à chaque utilisateur ou job sa propre VM isolée par Firecracker avec son propre noyau, la suspension et la reprise avec l'état mémoire et disque intact jusqu'à 8 heures de runtime au total, et un endpoint HTTPS dédié prenant en charge HTTP/2, gRPC et WebSockets. Les limites par MicroVM sont 16 vCPU, 32 Go de mémoire, 32 Go de disque, ARM64 uniquement. D'après le billet de lancement, vous construisez une image depuis un Dockerfile avec aws lambda-microvms create-microvm-image, vous lancez avec aws lambda-microvms run-microvm et une politique d'inactivité, et vous payez le compute de base pendant qu'elle tourne. Disponible en US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) et Asia Pacific (Tokyo).

J'en ai parlé longuement dans AWS Lambda MicroVMs : le serverless gagne un sandbox isolé et stateful. La version courte : la question de conception n'est pas « fonctions ou MicroVMs » mais « qu'est-ce qui, dans mon système, exécute du code que je n'ai pas écrit ». Les notebooks, les plugins clients et tout ce qu'un LLM génère ont leur place derrière une frontière de VM avec un cycle de vie, et jusqu'à cette semaine cela voulait dire votre propre flotte Firecracker ou un conteneur par tenant. L'angle agents est sur ercan.ai.

Network Firewall corrige un défaut qui cassait des connexions

AWS Network Firewall a mis à jour son action de rejet par défaut le 22 juin. Les nouvelles politiques de firewall prennent désormais par défaut l'action stateful « Application drop established (server-directed only) ». L'ancien défaut, « Application drop established (bidirectional) », pouvait rejeter silencieusement des paquets TCP légitimes du serveur vers le client, comme les window updates, les keep-alives et les resets, ce qui se manifestait par des échecs de connexion intermittents que personne ne parvenait à reproduire. Les politiques existantes ne sont pas modifiées automatiquement ; AWS renvoie à la documentation pour les mettre à jour, et précise que les environnements qui ont besoin de l'action bidirectionnelle pour les handshakes TLS post-quantiques fragmentés peuvent basculer ou ajouter un flag to_server à leurs règles de rejet TCP.

C'est celui à traiter aujourd'hui, parce que c'est un changement de défaut et pas une fonctionnalité. Chaque aws_networkfirewall_firewall_policy de votre Terraform copié depuis un vieil exemple porte l'ancien défaut. Grep les actions stateful par défaut, comparez avec la nouvelle recommandation, et déployez le changement en staging d'abord. Si vous avez un ticket de timeout intermittent inexpliqué ouvert sur quelque chose derrière Network Firewall, vous venez peut-être d'en trouver la cause.

Aussi cette semaine

  • Les investigations GuardDuty assistées par IA entrent en preview dans 10 Régions (23 juin) : chaque finding reçoit une disposition avec score de confiance, un mapping MITRE ATT&CK, 90 jours d'activité liée, et une recommandation de suppression, de confinement ou de remédiation, via la console, la CLI, l'API ou l'AWS MCP Server.
  • L'ingestion syslog managée de CloudWatch Logs (23 juin) accepte RFC 5424, RFC 3164 et Cisco FTD/ASA en TCP, TCP+TLS ou UDP vers un endpoint VPC, sans agent, avec facility, sévérité et hostname extraits.
  • OTel Container Insights pour EKS (23 juin) collecte des métriques d'infrastructure à 30 secondes via les receivers cAdvisor, Kube State Metrics et NVIDIA DCGM, avec les labels Kubernetes et un endpoint PromQL, par l'add-on CloudWatch Observability v6.2.0 ou ultérieur.
  • Gouvernance ouverte pour MySQL : Oracle a annoncé un comité de pilotage avec quatre sièges hors Oracle, dont un pour AWS. Vu l'extension de l'Extended Support la semaine dernière, AWS prévoit de faire tourner MySQL encore longtemps.

Le fil conducteur

Trois des quatre éléments de tête de la semaine rendent opposable une propriété qui n'était qu'un vœu : d'où vient une image, où tourne le code non fiable, comment un firewall traite la moitié retour d'une connexion. Le quatrième, Transform dans toute Région commerciale, fait la même chose pour la résidence des données. Rien de tout cela n'est excitant. Tout cela est le genre de contrôle qui, une fois qu'il existe, fait passer l'ancienne façon de faire pour de la négligence dans une revue post-incident.

À lire ensuite

La lecture côté agents des MicroVMs et des investigations GuardDuty est sur ercan.ai. Pour du conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore, le point de départ est ercanermis.com.

Références