Dans la semaine du 8 au 14 juin 2026, AWS a renommé son moteur de rehost en AWS Transform MGN, ce qui vous dit où va la gamme de produits de migration : l'agent est le produit, et le service de réplication est une pièce qu'il appelle. La même semaine a livré une grappe d'outils de coût qui lisent votre facture à votre place (le FinOps Agent en preview, des investigations d'anomalies assistées par IA et des explications de coût intelligentes), les premières instances Graviton5 pour l'usage général, et un avis de maintenance pour l'AWS CLI v1 que quiconque possède dix ans de scripts shell devrait lire deux fois.

Également cette semaine : Claude Fable 5 d'Anthropic a été lancé sur Bedrock le 9 juin et son accès a été révoqué le 12 juin en vertu d'une directive américaine sur les exportations. Cette histoire est racontée sur ercan.ai ; la leçon d'infrastructure est la leçon habituelle : ne clouez pas la production à un seul fournisseur amont que vous ne contrôlez pas.

AWS Transform MGN : le changement de nom qui est une roadmap

AWS Application Migration Service devient AWS Transform MGN, daté du 8 juin. L'annonce dit explicitement qu'il s'agit d'un changement de nom reflétant le rôle de MGN comme « le moteur de réplication éprouvé qui propulse AWS Transform », ne liste aucun changement d'API, de tarification ou de fonctionnalité, et conserve les certifications de conformité (FedRAMP High, HIPAA, PCI DSS, ISO, SOC 1, 2, 3). Il est disponible dans toutes les Régions commerciales et dans les deux Régions GovCloud.

Vous disposez désormais de deux expériences de rehosting. La console AWS Transform MGN donne un contrôle direct sur la réplication et le cutover, comme MGN l'a toujours fait. Le workflow agentique d'AWS Transform confie à un agent la découverte, la planification des vagues, la mise en place de la landing zone, la création du réseau et le rehost ou la conteneurisation elle-même, en appelant MGN en dessous. Lisez-le comme une déclaration d'intention : le chemin console est pour ceux qui savent ce qu'ils font et veulent les réglages ; le chemin agent est là où AWS s'attend à voir partir le volume.

Le même jour, AWS Transform a ajouté une évaluation du coût de migration pour RDS for SQL Server. Donnez-lui des exports RVTools, des données de CMDB ou la sortie de l'outil de découverte de Transform, et il recommande des configurations d'instances, modélise Bring Your Own Media face à License Included (BYOM est arrivé sur RDS la semaine dernière), intègre les Database Savings Plans dans le prix (jusqu'à 20 % de moins que l'On-Demand) et signale l'éligibilité MAP. Des scénarios what-if permettent de faire varier la Région, l'utilisation et la durée. Le compromis de tout outil de TCO : la sortie est aussi honnête que les données d'utilisation que vous lui avez fournies. Les chiffres de pic de RVTools donnent une facture prudente ; les chiffres au 95e percentile donnent celle que la finance vous opposera.

Note pratique : l'annonce ne dit rien des préfixes d'actions IAM, des namespaces de SDK ou des types de ressources Terraform, donc supposez que mgn reste en place jusqu'à ce qu'un changelog dise le contraire.

Trois agents pour une seule facture

La gestion des coûts a reçu plus d'attention agentique en une semaine qu'au cours de l'année précédente. AWS FinOps Agent est entré en preview le 9 juin dans US East (N. Virginia), sans frais pendant la preview. Il répond aux questions de coût, fait remonter les recommandations de rightsizing, de ressources inactives et de Savings Plans depuis Cost Optimization Hub et Compute Optimizer, enquête sur les anomalies, exécute des workflows FinOps planifiés, ouvre des tickets Jira et publie ses constats dans Slack. Ses données couvrent toutes les Régions sauf GovCloud et la Chine.

Les investigations de coût assistées par IA (8 juin) vivent dans Cost Anomaly Detection : choisissez « Investigate with Amazon Q » sur une anomalie détectée, et il détermine si le changement vient de l'usage ou du tarif, nomme les services, comptes et Régions contributeurs, et pour les changements d'usage, croise avec CloudTrail pour attribuer le pic à des appels d'API et des principals IAM précis. Avec un organization trail, il couvre les comptes membres. Sans frais supplémentaires, sauf que le chemin cross-account lit un organization trail livré dans CloudWatch Logs, donc les frais de scan de Logs Insights s'appliquent. Les explications de coût intelligentes de Cost Explorer (9 juin) et l'analyse de couverture cible dans le Savings Plans Purchase Analyzer (8 juin) complètent le tableau.

Si vous allez laisser un agent s'approcher de la production, le coût est le bon premier domaine : les données sont en lecture seule, le rayon d'impact d'une mauvaise réponse est un mauvais ticket Jira, et l'alternative est un humain qui fait la même corrélation CloudTrail à 23 h après une alerte d'anomalie. Le mode de défaillance, c'est le bruit. Un agent qui ouvre un ticket pour chaque anomalie entraîne l'équipe à fermer les tickets sans les lire en moins d'un mois. Cadrez les plannings et les seuils avant d'activer les intégrations, de la même façon que vous cadreriez une alerte de budget.

Graviton5 arrive en usage général

Les instances M9g et M9gd sont passées en disponibilité générale le 10 juin. AWS revendique jusqu'à 25 % de performance compute en plus par rapport à Graviton4 en général, jusqu'à 35 % pour les applications web et l'inférence ML, jusqu'à 30 % pour les bases de données, et un cache L3 cinq fois plus grand. Les plus grandes tailles atteignent 192 vCPU et 768 GiB ; M9gd embarque jusqu'à 11,4 To de NVMe local. Disponibles dans US East (N. Virginia), US East (Ohio), US West (Oregon) et Europe (Frankfurt).

Quatre Régions, voilà la contrainte. Si vos Savings Plans sont des EC2 Instance plans verrouillés sur M8g dans une Région absente de cette liste, il n'y a rien à faire pour l'instant. Si ce sont des Compute Savings Plans, M9g est une expérience à coût nul : mêmes binaires ARM64, un changement de launch template, et une semaine de CloudWatch pour voir si les 25 % apparaissent pour votre charge ou seulement pour le benchmark.

L'AWS CLI v1 passe en maintenance le 15 juillet

L'équipe AWS CLI a annoncé le 10 juin que la CLI v1 entre en mode maintenance le 15 juillet 2026. À partir de là, v1 embarque ses propres copies de botocore et s3transfer au lieu de dépendre des paquets autonomes ; mettre à jour la CLI ne les met plus à jour, et les installer ne change plus ce que la CLI utilise. Les nouvelles versions de v1 se limitent aux corrections de bugs critiques et aux problèmes de sécurité.

La casse subtile concerne les environnements où la CLI v1 et boto3 partagent une installation Python. Après le changement, il y a deux copies de botocore dans cet environnement, et tout script qui supposait que « pip install awscli » maintenait à jour les dépendances de boto3 se trompe. Épinglez explicitement les dépendances de boto3, puis planifiez le passage à v2. Les différences entre v1 et v2 sont surtout des valeurs par défaut de sortie et de pagination, exactement le genre de chose qui casse un cron job en silence.

Également cette semaine

Le fil conducteur

Chaque titre de cette semaine, c'est AWS qui déplace une tâche humaine dans un service : la planification des vagues dans un agent, l'investigation d'anomalies dans Q, la modélisation du TCO dans Transform. Les moteurs n'ont pas changé ; ce qui a changé, c'est qui lit la sortie. Décidez délibérément auxquels de ces lecteurs vous faites confiance, et gardez le chemin console au chaud pour le jour où l'agent se trompe sur votre parc.

À lire ensuite

Pour le volet modèles et agents de la même semaine, y compris l'interruption de Fable 5, lisez ercan.ai. Pour du conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore, le point d'entrée est ercanermis.com.

Références