Le 16 octobre 2026, AWS Transform a rendu la conversion de code Azure vers AWS généralement disponible : l'agent de modernisation .NET repère désormais les appels Azure SDK dans vos sources et les réécrit en appels AWS SDK, ce qui fait passer la conversation sur la migration Azure de « déplacer les VM » à « changer le code ». La même semaine, Lambda a gagné un second format, Lambda Web Functions, facturé sur le CPU actif plutôt que sur le temps écoulé ; ECS a livré une métrique de compte de tâches qui inclut les tâches en cours de drain ; et ARC Region switch a appris à vérifier les quotas de la Région de secours avant que vous en ayez besoin.

Transform convertit le code Azure SDK, pas seulement les VM Azure

L'annonce du 16 octobre est précise sur le périmètre. Transform détecte l'Azure SDK dans les sources .NET soumises, présente des options de conversion dans le rapport d'évaluation, vous laisse les accepter ou les ajuster, puis convertit les appels et valide le résultat. Généralement disponible : Azure Functions vers AWS Lambda, Azure Blob Storage vers Amazon S3, Azure Queue Storage vers Amazon SQS. Azure Cosmos DB vers Amazon DynamoDB est en preview. AWS Transform tourne dans huit Régions : Virginie du Nord, Mumbai, Tokyo, Séoul, Sydney, Canada Centre, Francfort et Londres.

Pourquoi cela compte plus qu'une nouvelle histoire VMware : jusqu'ici, le chemin agentique depuis Azure était de l'infrastructure. Vous pouviez répliquer des VM Azure, mais une app Functions qui parle à Blob Storage restait une réécriture que quelqu'un devait planifier. Les paires GA sont les trois services qui composent l'essentiel d'un back-end .NET cloud-native : un déclencheur, un stockage objet, une file. La paire en preview est la plus honnête. Cosmos DB vers DynamoDB est une conversion de modèle de données, pas un échange de SDK ; les clés de partition, les niveaux de cohérence et les formes de requête ne se traduisent pas par regex, donc attendez-vous à ce que le code DynamoDB généré compile avant d'être correct. Lancez l'évaluation même si vous ne migrez pas ce trimestre : la part du parc qui tombe dans les paires GA plutôt que dans Cosmos, Service Bus ou Key Vault est le chiffre que chaque business case de migration devine depuis le début.

Trois autres nouvelles Transform : Transform for migrations est arrivé en Asie-Pacifique (Singapour) (15 octobre). La modernisation Windows full-stack déploie désormais les clusters Aurora PostgreSQL convertis dans une autre Région et est disponible dans sept Régions de plus (15 octobre) : vous téléversez le DDL SQL Server, choisissez une Région cible, et le code .NET dépendant est rendu compatible PostgreSQL dans la même passe. Côté mainframe, un billet commun avec Cognition (12 octobre) montre Transform qui extrait les règles métier du COBOL, du PL/I et du JCL avec traçabilité jusqu'à la ligne source, et Devin qui transforme les exigences approuvées en specs, backlog, code et tests, chacun sous forme de pull request qu'un humain fusionne. Aucun pourcentage d'automatisation, aucune promesse de temps gagné. Cette retenue est ce qu'il y a de plus crédible dans l'annonce.

Lambda Web Functions : un port, pas un handler

Le 12 octobre, AWS a annoncé Lambda Web Functions. Votre code écoute sur l'hôte et le port indiqués dans AWS_LAMBDA_HTTP_ENDPOINT et traite le HTTP comme n'importe quel serveur ; Express, Hono, Fastify et Next.js tournent sans adaptateur, et les fonctions existantes sont renommées Lambda Event Functions. Un environnement chaud sert jusqu'à 128 requêtes concurrentes (64 par défaut, via maxConcurrencyPerEnvironment) ; au-delà de la limite, les requêtes reçoivent un 429, pas une place dans une file. Chaque environnement dispose de 2 vCPU et 2 Go, le runtime est Node.js 24 sur Arm64, et le service est ouvert en Virginie du Nord, Ohio, Oregon, Tokyo et Irlande. aws lambda-web deploy --name app --code ./dist --regions us-east-1,eu-west-1 renvoie l'URL. Le même jour, CloudFront a ajouté les Web Functions comme origine avec Origin Access Control, ce qui est la façon d'obtenir un domaine personnalisé et un WAF devant l'une d'elles.

Le modèle de facturation est la vraie annonce. La page de tarification Lambda affiche les Web Functions en Virginie du Nord sur Arm à 0,0000276944 $ par vCPU-seconde active, 0,0000036667 $ par Go-seconde de mémoire retenue, et 0,30 $ par million de requêtes, contre 0,20 $ par million pour les Event Functions et 0,0000166667 $ par Go-seconde au tarif x86 des Event Functions. Prenez les deux extrêmes. Un environnement de 2 vCPU et 2 Go à pleine charge CPU coûte environ 0,000063 $ par seconde ; une Event Function de 2 Go environ 0,000033 $. Un environnement qui attend surtout une base de données coûte environ 0,0000073 $ par seconde en mémoire et presque rien en CPU. Le modèle gagne quand le CPU est inactif, le cas normal d'une couche web, et perd quand il est occupé, traitement d'images et SSR lourd. Mesurez votre part de CPU au p95 avant de déplacer une charge ; la page de tarification n'affiche aucun free tier pour les Web Functions.

Un mode de défaillance à nommer : 128 requêtes concurrentes dans un seul processus Node.js partagent une seule event loop, donc un chemin synchrone lent dégrade 127 voisins. Et puisque les requêtes excédentaires reçoivent un 429, la politique de retry de vos clients fait partie de l'architecture.

ECS compte enfin les tâches qui tournent encore

Le 13 octobre, Amazon ECS a ajouté LiveTaskCount et supprimé la facturation de RunningTaskCount. LiveTaskCount compte les tâches dans les états ACTIVATING, RUNNING et DEACTIVATING, y compris celles qui servent encore du trafic pendant leur drain lors d'un scale-in. Cette clause est le bug qu'il corrige : l'ancien compte sous-estimait pendant le scale-in, donc un service en train de drainer 20 tâches paraissait plus petit qu'il ne l'était et la politique pouvait sur-corriger. Si vous scalez sur le nombre de tâches, changez de métrique et réajustez la cible. RunningTaskCount dans Container Insights est désormais gratuit.

Region switch vérifie les quotas avant le failover

Le 14 octobre, ARC Region switch a ajouté quatre capacités : des blocs d'exécution Systems Manager Run Command et Lambda avec payload, des vérifications de parité des service quotas, et une attente de la santé du target group sur les actions de scaling compute. La vérification des quotas est celle à adopter cette semaine. Les plans de failover échouent de la manière la plus terne qui soit : la Région de secours a une limite par défaut de 32 vCPU là où la production en a 2 000, découverte au moment du scale-out pendant l'incident. La parité des quotas évaluée à l'avance transforme cela en ticket un mardi tranquille. L'attente du target group ferme l'autre trou classique, celui où le runbook déclare la Région opérationnelle quand l'ASG atteint la capacité désirée alors que l'ALB échoue encore ses health checks.

Aussi cette semaine

Le fil conducteur

Chaque titre de la semaine remplace quelque chose que vous estimiez par quelque chose que vous pouvez mesurer. L'évaluation de Transform dit quelle part d'une base de code Azure est convertible au lieu de laisser un comité de pilotage deviner. Les Web Functions facturent le CPU que vous consommez, et la grille tarifaire vous donne le seuil de rentabilité avant de bouger. LiveTaskCount compte les tâches qui servent vraiment. Region switch vérifie les quotas de secours avant le jour où ils comptent. Moins excitant qu'une keynote, plus utile un mardi.

À lire ensuite

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

Références