La semaine du 5 octobre 2026 avait deux fils dignes de l'attention d'une équipe plateforme : AWS Transform a appris à inventorier des parcs Microsoft Hyper-V sans rien installer sur les hôtes, et une série de lancements plus modestes a poussé les contrôles d'identité et de certificats vers des couches qui faisaient jusqu'ici confiance au réseau sur lequel elles reposaient. Les event source mappings Kafka de Lambda acceptent OAuth, l'annuaire d'IAM Identity Center peut refuser les requêtes qui contournent vos VPC endpoints, l'émission ACME publique passe par PrivateLink, et GuardDuty lit les requêtes PostgreSQL plutôt que seulement les logins. Aucune de ces annonces n'est un gros titre. Ensemble, elles font la semaine.

Le bureau des migrations : Hyper-V obtient la découverte sans agent

Le 7 octobre, AWS a publié Discover and migrate Microsoft Hyper-V workloads with AWS Transform, classé comme annonce. L'outil de découverte de Transform enregistre désormais chaque hôte Hyper-V comme source, se connecte via WinRM et lit pour chaque VM les vCPU, la mémoire, les disques, les adaptateurs réseau, l'état d'alimentation et l'appartenance à un failover cluster. La collecte se répète toutes les heures, les VM en cluster sont dédupliquées, et System Center Virtual Machine Manager n'est pas requis. L'outil est livré comme appliance VHD qui collecte aussi depuis vCenter et depuis du bare metal importé en CSV, donc un parc mixte obtient un seul inventaire. Avec des identifiants invité, il ajoute des échantillons de performance toutes les 10 minutes, les connexions réseau pour la cartographie des dépendances, et les détails SQL Server et Oracle, alimentant la chaîne habituelle : dossier TCO avec dimensionnement EC2 d'après l'utilisation mesurée, plan de vagues, landing zone.

Le déplacement lui-même reste AWS Transform MGN au niveau de l'OS invité, ce qui signifie un agent de réplication sur chaque serveur source. La découverte est sans agent ; la migration ne l'est pas, et les approbations de changement pour le déploiement des agents sont la partie qui consomme du calendrier.

Deux billets compagnons sont sortis la même semaine. When to use what: A guide to AWS Transform interfaces (9 octobre) est la première carte claire de la console, de Kiro et des autres IDE IA, de la CLI atx avec ses flags non interactifs -x -t pour les pipelines, et du serveur MCP. Lisez-le avant de choisir un point d'entrée : la CLI ne couvre que les transformations custom. Et Run least-privilege AWS DMS CDC migration from SQL Server (6 octobre) est le document sur les permissions par lequel chaque projet DMS aurait dû commencer.

OAuth atteint les consumers Kafka de Lambda

Le 9 octobre, AWS Lambda a ajouté l'authentification OAuth pour les event source mappings Apache Kafka autogérés. Jusqu'ici, un ESM Kafka pouvait s'authentifier en SASL/PLAIN, SASL/SCRAM ou mTLS, rien d'autre. Les équipes dont les clusters étaient verrouillés sur un IdP OAuth uniquement (Okta, Cognito) ne pouvaient pas utiliser l'ESM du tout, donc elles faisaient tourner leur propre flotte de consumers et perdaient le scaling, le batching, le filtrage et la gestion d'erreurs que l'ESM donne gratuitement. Cela fonctionne pour les clusters auto-hébergés et pour Confluent Cloud, Aiven et Redpanda.

Le compromis : votre identité de consumer est désormais un token avec une durée de vie, donc une panne de l'IdP se manifeste comme un event source mapping bloqué au lieu d'une erreur de login que quelqu'un surveille. Mettez la métrique OffsetLag de l'ESM sous alarme avant de basculer la méthode d'authentification, pas après.

Le plan identité et certificats passe en privé

Trois lancements des 5 et 6 octobre partagent une même forme. IAM Identity Center prend désormais en charge les contrôles d'accès réseau pour Identity Store : vous pouvez exiger que les appels à l'API Identity Store n'arrivent que par des VPC endpoints autorisés dans votre compte ou votre organisation, et restreindre l'API SCIM que votre IdP externe utilise pour synchroniser utilisateurs et groupes. L'annuaire qui définit qui est votre personnel devient joignable uniquement depuis l'endroit que vous désignez.

ACM prend désormais en charge l'émission ACME via AWS PrivateLink. Créez un VPC interface endpoint vers le service ACM ACME et le DNS privé résout votre URL de répertoire ACME existante vers lui, donc tout client ACMEv2 renouvelle des certificats publics sans chemin internet et sans modification du client. Pour les hôtes en sous-réseau privé qui gardent une route NAT uniquement pour renouveler des certificats, c'est toute une exception d'egress qui disparaît.

AWS Private CA émet désormais des journaux détaillés d'émission de certificats : un événement de service CloudTrail, IssueCertificateDetails, avec le contenu complet du certificat, la CA émettrice, l'identité du demandeur et le statut de signature pour chaque émission, y compris celles qui ont échoué avant signature. L'ancien management event vous donnait un ARN. Si vous suivez une migration d'algorithme ou avez besoin d'un inventaire de certificats qui ne soit pas un tableur, voilà la source de vérité qui vous manquait.

Traitez ces trois lancements comme un seul change set : Identity Store et SCIM derrière des VPC endpoints, ACME via PrivateLink, journaux d'émission vers le compte d'audit. Le mode de défaillance à anticiper est le chemin de break-glass. Quand la policy de l'endpoint est fausse, la synchronisation SCIM s'arrête silencieusement et l'erreur apparaît comme « utilisateur introuvable » dans une application sans rapport, deux jours plus tard.

GuardDuty lit les requêtes, pas seulement les logins

Le 8 octobre, GuardDuty RDS Protection s'est étendu à la détection d'exfiltration et de destruction de données sur Aurora PostgreSQL et RDS for PostgreSQL. Il regardait jusqu'ici les anomalies de login. Il établit désormais une base de référence de l'activité sur les données et signale les accès inhabituels par détection d'anomalies plus renseignement sur les menaces, sans agent et sans modification de la base. L'écart qu'il comble est celui que chaque rapport post-incident mentionne : une fois qu'un attaquant détient des identifiants valides, ses requêtes ressemblent exactement à celles de l'application. La surveillance des logins ne voit rien. La surveillance de la forme des requêtes a au moins une chance.

Également cette semaine

Le fil conducteur

Pendant des années, le schéma était : authentifier l'utilisateur à la bordure, puis faire confiance au réseau derrière. Cette semaine, AWS a continué à déplacer la vérification vers l'intérieur. L'API de l'annuaire veut savoir par quel VPC endpoint vous êtes passé. Le renouvellement de certificat ne quitte jamais le VPC. Le consumer Kafka porte un token d'IdP. Le modèle de menace de la base de données suppose que l'identifiant est déjà volé et regarde ce que font les requêtes. Côté migration, Transform lit les hôtes Hyper-V via WinRM plutôt que d'y planter des agents, le même réflexe appliqué au parc que vous quittez. Le nombre d'endroits où « c'est à l'intérieur du réseau » compte comme réponse a encore diminué.

À lire ensuite

Pour la lecture modèles et agents de la même semaine, les notes de terrain IA vivent sur ercan.ai. Le hub, y compris le conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore, se trouve sur ercanermis.com.

Références