AWS Transform convertit le code Azure en SDK AWS, de Functions à Cosmos DB
Le 16 octobre 2026, AWS rend disponible la conversion automatique de code .NET d’Azure SDK vers AWS SDK dans AWS Transform : Azure Functions devient Lambda, Blob Storage devient S3, et Cosmos DB devient DynamoDB en préversion. Pour une équipe .NET qui évalue une sortie d’Azure, c’est un point de départ sérieux — mais pas une migration en un clic.
16 octobre 2026. AWS annonce la disponibilité générale de la conversion de code applicatif d’Azure SDK vers AWS SDK dans AWS Transform. Quatre services. Azure Functions devient AWS Lambda, Blob Storage devient Amazon S3, Queue Storage devient Amazon SQS, et Cosmos DB devient DynamoDB en préversion. Huit régions. De la Virginie du Nord à Sydney, en passant par Francfort et Londres. Pourquoi c’est important : pour la première fois, la guerre de la migration entre les deux grands clouds descend à la couche du code source — et elle change ce que « quitter Azure » veut dire pour une équipe .NET.
La migration descend à la couche du code
Jusqu’ici, les outils de migration cloud opéraient surtout à la couche de l’infrastructure — réhébergement de machines virtuelles, reconfiguration de réseaux, réplication de stockage. AWS Transform ajoute une couche plus profonde : l’agent de modernisation .NET lit le code source soumis, repère les appels à l’Azure SDK, et les convertit en appels équivalents vers l’AWS SDK. L’exemple donné par AWS est concret : une fonction serverless Azure Functions qui utilise Cosmos DB devient une fonction AWS Lambda qui utilise DynamoDB.
Le flux est pensé pour rester sous contrôle humain. AWS Transform découvre l’Azure SDK dans le code, puis présente les options de conversion dans un rapport d’évaluation et un plan de modernisation. L’équipe peut accepter ces options ou les ajuster avant d’exécuter la modernisation. Une fois la conversion lancée, l’outil transforme le code identifié et vérifie que les changements sont bien intégrés au résultat. C’est une assistance à la décision avant d’être un transformateur aveugle.
La cible est explicite et limitée aux applications cloud-native .NET — pas l’intégralité du catalogue Azure, pas les charges IaaS héritées. Le périmètre est celui des services managés modernes où l’effort de réécriture était jusqu’ici le plus manuel et le plus coûteux.
Ce qui est converti, et ce qui ne l’est pas encore
Le périmètre fonctionnel tient en quatre correspondances, toutes dans le sens Azure → AWS : Azure Functions → AWS Lambda, Azure Blob Storage → Amazon S3, Azure Queue Storage → Amazon SQS, et Azure Cosmos DB → Amazon DynamoDB en préversion. Les trois premières sont en disponibilité générale, la dernière encore en préversion — un choix prudent, car c’est de loin la plus risquée.
La prudence sur Cosmos DB → DynamoDB se justifie. Les deux bases sont des stores NoSQL managés, mais leurs modèles de cohérence, leurs modes de facturation et leurs limites opérationnelles diffèrent profondément. Cosmos DB propose plusieurs niveaux de cohérence configurables et un modèle d’unités de requête (RU) ; DynamoDB impose une cohérence forte ou éventuelle par lecture et facture en unités de capacité. Convertir les appels SDK ne convertit ni le schéma de données ni les choix de capacité. C’est exactement la partie que l’outil laisse — à juste titre — au jugement de l’équipe.
La disponibilité régionale est volontairement large mais pas universelle : US East (Virginie du Nord), Asie-Pacifique (Mumbai, Tokyo, Séoul, Sydney), Canada (Centre) et Europe (Francfort, Londres). Une équipe dont les données doivent rester dans une région non couverte devra attendre, ou exécuter l’évaluation depuis une région autorisée puis déployer ailleurs.
L’évaluation d’abord, pas le « lift » automatique
L’intérêt stratégique de l’annonce dépasse l’outil lui-même. En automatisant la conversion de code d’Azure vers AWS, AWS abaisse le coût d’entrée d’une évaluation de migration — le moment le plus coûteux d’une sortie de cloud, où une équipe doit chiffrer l’effort de réécriture avant même de savoir si le jeu en vaut la chandelle. C’est le même mouvement que l’on observe en sens inverse dans l’écosystème : la migration multi-cloud devient un marché d’outillage, pas seulement de services professionnels.
Le risque à ne pas sous-estimer est la confiance excessive dans le résultat. Un convertisseur de SDK produit un code syntaxiquement correct et sémantiquement « équivalent », mais il ne connaît pas les comportements de production : la latence différente de SQS face à Queue Storage, les limites de débit de DynamoDB, le modèle de cold start de Lambda. La vérification automatisée d’AWS Transform confirme que les changements sont incorporés, pas qu’ils se comportent identiquement sous charge. La revue humaine et les tests de charge restent le vrai chantier.
La lecture tactique est simple. Pour une équipe .NET qui porte déjà des applications Azure Functions et cherche une porte de sortie — contrat, coût, stratégie multi-cloud ou rapatriement — AWS Transform transforme la première étape d’un projet de plusieurs semaines en une journée d’évaluation. Pour une équipe qui n’a aucune intention de migrer, l’annonce reste un signal : AWS investit dans la capture des charges .NET d’Azure, et ce type d’outil finit par peser dans les négociations de contrat.
L’outillage de migration devient un champ de bataille
L’annonce s’inscrit dans une séquence plus large. AWS Transform existe déjà pour d’autres cibles — la modernisation de mainframes et la conversion de code COBOL ou Visual Basic vers des services managés AWS. Ajouter la conversion Azure SDK → AWS SDK étend ce catalogue au cas d’usage le plus courant : une entreprise déjà engagée chez Microsoft, qui veut chiffrer le coût d’un départ sans engager un cabinet de conseil.
Le mouvement est symétrique et concurrentiel. Microsoft pousse Azure Migrate dans l’autre sens, et les deux hyperscalers financent les bascules à coups de crédits et de programmes de services. Ce qui distingue l’outil d’AWS, c’est qu’il descend sous la couche des machines virtuelles : il touche le code applicatif, la partie la plus chère à réécrire et la plus difficile à estimer. Un rapport d’évaluation automatique produit donc une valeur que ni un rehost ni un replatform ne fournissent — une estimation chiffrée de l’effort de réécriture, avant toute décision budgétaire.
Reste une limite assumée : l’outil convertit des appels de SDK, pas des architectures. Une application conçue autour des propriétés d’Azure — Durable Functions, Event Grid, la grille de cohérence de Cosmos DB — exigera toujours une refonte que la conversion ne couvre pas. L’outil réduit le coût de la question « combien », pas celui de la réponse « comment ».
Verdict
Si vous évaluez une sortie d’Azure pour des applications .NET cloud-native, lancez AWS Transform sur votre code avant toute estimation manuelle : le rapport d’évaluation chiffre l’ampleur de la conversion — et donc le coût réel du projet — à un prix proche de zéro. Acceptez ou ajustez les options, puis traitez le code converti comme un brouillon de qualité, pas comme un livrable.
Si votre périmètre inclut Cosmos DB, traitez la conversion DynamoDB avec une prudence particulière : elle est en préversion, et la vraie difficulté n’est pas l’appel SDK, mais le modèle de données et les choix de capacité. Revaliderez le schéma, le modèle de cohérence et le dimensionnement avant tout basculement. Si vos données doivent rester dans une région non couverte, planifiez l’évaluation depuis une région autorisée et le déploiement séparément.
La conclusion tient en une phrase : l’outil abaisse le coût de la décision, pas celui de la migration — le travail d’ingénierie qui reste est précisément celui qu’aucun convertisseur ne peut faire à votre place.