La semaine du 27 juillet, AWS Transform a abandonné l'hypothèse qu'une migration commence dans vSphere. L'entrée du 29 juillet dans le change log renomme le workflow « Migrations (including VMware) » et ouvre la découverte, la planification des vagues, la landing zone, la migration réseau et le rehost de serveurs à Hyper-V, au bare metal et à d'autres plateformes. La même semaine, AWS Interconnect vers Oracle Cloud Infrastructure est passé GA, le policy-based routing de Transit Gateway a permis aux décisions de forwarding d'utiliser la source, le port et le protocole, IAM Identity Center a étendu la réplication multi-Région à son annuaire intégré, et CloudWatch a commencé à faire tourner des collecteurs Prometheus pour vous.

AWS Transform for migrations : l'hyperviseur cesse de compter

La documentation migrer des serveurs le dit désormais clairement : vous pouvez migrer depuis des data centers on-premises, d'autres fournisseurs cloud ou d'autres Régions AWS, physiques ou virtuels, sur VMware, Hyper-V, KVM ou n'importe quoi d'autre, et l'hyperviseur est sans importance tant que l'OS invité figure sur la liste des systèmes pris en charge par AWS Transform MGN. Le moteur de réplication a toujours été MGN, qui ne s'est jamais soucié de la source ; ce qui a changé, c'est que le workflow agentique autour de lui, découverte, recommandations 7R, planification des vagues, conversion réseau, accepte maintenant ces sources aussi. La même entrée ajoute des actions post-lancement au rehost : des documents SSM, prédéfinis ou personnalisés, que l'agent recommande et exécute sur chaque serveur quand il démarre comme instance de test ou de cutover, définis au niveau du compte ou par serveur dans le fichier d'inventaire sous mgn:launch:post-actions:<ACTION_NAME>:<FIELD_NAME>.

Pour quiconque dimensionne un parc Hyper-V ou bare metal pour AWS, c'est la semaine où l'outillage a rattrapé le discours commercial. Deux précautions. D'abord, le changement est une entrée de doc, pas un billet What's New, donc il n'y a ni liste de Régions ni note de tarif à citer ; vérifiez dans la Région de votre workspace avant de planifier autour. Ensuite, la réplication sans agent reste non prise en charge, donc chaque serveur source a besoin d'un agent, et sur du bare metal il n'y a pas de chemin vCenter pour masquer les machines sur lesquelles vous ne pouvez pas vous connecter. Confirmez les identifiants par serveur à la validation de l'inventaire, pas quand le connecteur MGN expire. Les actions post-lancement sont la victoire discrète : la checklist « installer l'agent CloudWatch, joindre le domaine, lancer le scan de conformité » qui était un runbook fait désormais partie de la vague, et mustSucceedForCutover vous laisse en faire une porte.

Interconnect vers OCI, et un routage qui lit plus que la destination

AWS Interconnect - multicloud a atteint la GA le 29 juillet pour Oracle Cloud Infrastructure, provisionné depuis la console, la CLI ou l'API, avec Google Cloud aussi pris en charge à la GA et Microsoft Azure attendu plus tard en 2026. OCI a construit son côté sur une spécification ouverte publiée par AWS sur GitHub. La disponibilité est us-east-1 pour OCI, et l'annonce ne donne ni paliers de bande passante ni tarif, donc la documentation est la prochaine étape.

La comparaison se fait avec ce que font les équipes aujourd'hui : un Direct Connect vers une installation de colocation, un cross-connect vers l'autre fournisseur, deux sessions BGP, et une page de wiki sur qui appeler quand ça casse. Interconnect remplace cela par un objet géré, et concentre le risque dans un seul produit, dans une seule Région au lancement. Le motif base de données dans OCI, application dans AWS que le licensing Oracle continue de produire est le client évident. Pour tout le reste, attendez que la liste des Régions s'allonge.

Le policy-based routing sur Transit Gateway, GA le 30 juillet sans coût supplémentaire, est la pièce qui permet à un réseau hub-and-spoke de dire « cette source, sur ce port, passe par le firewall ; tout le reste va en direct ». Vous attachez une policy table à un attachment, écrivez un jeu de règles ordonné qui matche sur IP source et destination, port et protocole, et chaque règle envoie les paquets correspondants vers une table de routage nommée, première correspondance gagnante. Le mode de défaillance est celui que le PBR a toujours eu : une policy table est un second endroit où le routage se décide, et « chercher la destination dans la table de routage » cesse d'être un modèle mental suffisant. Documentez les règles à côté des tables de routage, et résistez à l'envie d'utiliser le PBR pour tout ce qu'une table de routage peut exprimer.

Direct Connect a gagné la visibilité des routes BGP le même jour : routes acceptées et annoncées sur les VIF privées, transit et publiques, avec préfixe, AS path, communities et famille d'adresses, via la console ou ListVirtualInterfaceRoutes. Quiconque a débogué un chemin asymétrique en demandant à l'équipe réseau de lancer show ip bgp de son côté sait pourquoi ça compte.

Identity Center réplique son propre annuaire

Le support multi-Région dans IAM Identity Center exigeait auparavant un fournisseur d'identité externe. Depuis le 29 juillet, une instance d'organisation qui utilise l'annuaire Identity Center intégré peut répliquer identités et droits depuis sa Région primaire vers des Régions supplémentaires de votre choix, parmi les 17 Régions commerciales activées par défaut. Si la Région primaire est perturbée, les utilisateurs gardent l'accès à leurs comptes via les droits déjà provisionnés ailleurs. L'administration reste dans la Région primaire, l'instance doit utiliser une clé KMS multi-Région gérée par le client, et le seul coût est KMS.

Identity Center est le composant dont la défaillance empêche chaque humain de réparer quoi que ce soit d'autre, et sans IdP externe il a été une dépendance mono-Région depuis son lancement. Le prérequis est le piège : une CMK multi-Région doit exister avant d'activer la réplication, et une instance créée avec la clé par défaut détenue par AWS a d'abord besoin d'un changement de clé. Planifiez cela comme un changement à part, avec un rollback.

CloudWatch fait tourner le collecteur Prometheus

Les collecteurs gérés CloudWatch, GA le 31 juillet, scrapent des métriques Prometheus depuis EKS (service discovery Kubernetes), ECS (DNS Cloud Map), EC2 (direct), ainsi que MSK et OpenSearch Service (endpoints d'open monitoring) sans OpenTelemetry Collector à faire tourner vous-même. Vous fournissez une config de scrape et une connexion ; CloudWatch provisionne et dimensionne le collecteur, livre les métriques au format OpenTelemetry, et vous laisse les interroger en PromQL à côté des métriques fournies par les services. Les collecteurs sont facturés à l'heure en plus de l'ingestion standard de métriques OpenTelemetry, et la fonctionnalité est disponible partout où se trouve l'endpoint OTLP de CloudWatch, sauf en Asie-Pacifique (Nouvelle-Zélande).

Le collecteur autogéré était la partie de la pile d'observabilité la plus susceptible d'être en panne quand vous aviez besoin des métriques, en général parce que son nœud était celui en difficulté. Le sortir du cluster est correct. La question, c'est le coût à la cardinalité : les frais horaires sont prévisibles, l'ingestion ne l'est pas, et une config de scrape récupérée d'un serveur Prometheus qui gardait tout ingérera tout. Gardez vos règles de drop dans metric_relabel_configs, et lisez la ligne d'ingestion sur la première facture avant d'ajouter le second cluster.

Aussi cette semaine

Le fil conducteur

Chaque titre de la semaine élargit une entrée qu'AWS contraignait auparavant. Transform accepte n'importe quel hyperviseur. Interconnect accepte un autre cloud. Transit Gateway accepte des correspondances à cinq tuples au lieu d'une destination. Identity Center emmène son propre annuaire dans plus de Régions. Les collecteurs gérés acceptent la config de scrape que vous avez déjà. Le coût se paie chaque fois dans la même monnaie : plus d'entrées, c'est plus d'endroits où la configuration peut être fausse, et moins d'entre eux visibles dans une table de routage. Le lancement de la visibilité BGP est le signe révélateur : AWS a ajouté de l'observabilité à Direct Connect le jour même où il ajoutait le policy routing à Transit Gateway, parce qu'il sait ce que le second fait au débogage.

À lire ensuite

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

Références