La première semaine d'août, AWS Transform a livré trois lancements qui, ensemble, couvrent une migration depuis le schéma que vous n'avez pas encore converti jusqu'à la dette technique que vous trouverez un an après le cutover. Le 3 août, l'agent de modernisation Windows a gagné la transformation hors ligne de schéma SQL Server vers Aurora PostgreSQL et la modernisation continue est passée en disponibilité générale ; le 6 août, le workflow de migration a appris à exécuter des actions post-lancement via Systems Manager. Autour, Lambda a obtenu jusqu'à 3 000 Mbps de bande passante réseau, Aurora Serverless a appris à sauter à 12 ACU en une seconde, et les load balancers ont gagné des politiques TLS de niveau NSA.

La thèse de la semaine : AWS ne vend plus Transform comme un outil de rehost avec une étiquette IA. Il remplit les parties d'une migration qui étaient autrefois le tableur d'un partenaire, et cela change ce que vous devriez vous attendre à faire à la main.

AWS Transform : le schéma, le cutover et l'année d'après

Prenez les trois dans l'ordre d'une migration. La transformation hors ligne de schéma accepte des fichiers DDL SQL Server, donc vous n'avez pas besoin de connexion active à la source. Elle évalue la complexité de la base et des procédures stockées, vous laisse éditer le plan généré, puis convertit tables, schémas, procédures stockées et fonctions, valide l'équivalence fonctionnelle et déploie le résultat sur Aurora PostgreSQL. La conversion des objets de stockage s'appuie sur AWS DMS sous le capot. C'est limité à US East (N. Virginia) pour l'instant. La partie hors ligne compte plus qu'il n'y paraît : les équipes qui ne peuvent pas démarrer une migration de base de données sont en général celles dont les DBA refusent d'ouvrir un port à un outil de conversion. Un dump DDL est une conversation plus facile.

Les actions post-lancement comblent l'écart entre « le serveur a démarré dans AWS » et « le serveur est vraiment à nous ». Vous définissez les actions une fois au niveau du compte, et Transform les applique à chaque serveur source, à travers les comptes cibles dans une migration multi-comptes, en les exécutant via AWS Systems Manager juste après un lancement de test ou de cutover. Actions prédéfinies ou votre propre document SSM. Le fichier d'inventaire de migration gagne aussi une structure pour la revue par serveur. Si vous avez fait tourner MGN à grande échelle, vous connaissez le mode de défaillance que cela supprime : une vague de 80 serveurs atterrit et quelqu'un lance l'installation de l'agent CloudWatch à la main sur 79 d'entre eux.

La modernisation continue est la pièce qui vise ce qui se passe après. Elle se connecte aux organisations GitHub, aux groupes GitLab et aux workspaces Bitbucket, tourne à la demande ou sur planification, classe les constats par dette technique, sécurité, préparation agentique et préparation à la modernisation, et pour les constats qui ont un correctif, elle ouvre des pull ou merge requests avec des changements validés. L'analyse tourne dans votre propre compte sous vos identifiants, et vous pouvez la piloter depuis l'application web, la CLI, Kiro, ou comme plugin d'agent. Le compromis est celui que porte tout outil de PR automatisées : la capacité de revue. Un scanner planifié qui ouvre des PR plus vite que l'équipe ne peut les lire devient du bruit en un trimestre. Commencez avec un seul groupe de dépôts et un filtre de classement strict.

Bande passante Lambda : 3 000 Mbps, si vous n'êtes pas dans un VPC

La bande passante réseau de Lambda évolue désormais avec la mémoire pour les fonctions de 2 Go ou plus, de 625 Mbps à 2 Go jusqu'à 3 000 Mbps à 10 Go, en remplacement du plafond fixe de 625 Mbps. Sans coût supplémentaire, dans toutes les Régions commerciales. Deux réserves accompagnent le lancement. D'abord, c'est en opt-in via une demande Service Quotas sur le quota « Network bandwidth per execution environment », après quoi chaque fonction hors VPC du compte évolue automatiquement. Ensuite, et c'est plus important, cela ne s'applique qu'aux fonctions hors d'un VPC. La plupart des fonctions d'entreprise qui déplacent de gros objets sont dans un VPC, parce que c'est là que vivent l'instance RDS et l'endpoint S3 privé. Si vos lourdes transformations S3 vers S3 tournent dans un VPC, cette semaine n'a rien changé pour vous. Vérifiez avec aws lambda get-function-configuration --function-name X --query VpcConfig avant de déposer la demande de quota.

Aurora Serverless : 12 ACU en une seconde

Aurora Serverless atteint désormais jusqu'à 12 ACU en une seconde pendant la montée en charge, continue jusqu'à 256, et redescend toujours à zéro ensuite. C'est activé par défaut pour les clusters en version de plateforme 3 ou 4 ; les versions 1 et 2 peuvent monter directement en 4. Vérifiez la vôtre avec le champ ServerlessV2PlatformVersion de describe-db-clusters. AWS cadre cela autour des charges agentiques, ce qui est juste : un fan-out d'agents est exactement la rafale qui passait ses 30 premières secondes à attendre de la capacité. Le mode de défaillance, c'est le coût. Un cluster qui montait doucement avant frappe maintenant 12 ACU sur un pic qui aurait été absorbé à 2. Posez une alarme CloudWatch sur ServerlessDatabaseCapacity avant de monter la version de plateforme, pas après la première facture.

Aussi cette semaine

Le fil conducteur

Lisez les lancements Transform à côté de ceux de Lambda et d'Aurora et le motif porte sur l'endroit où le travail manuel se cachait. La conversion de schéma se cachait derrière une règle de firewall que personne n'approuverait. La configuration post-lancement se cachait dans un runbook. La dette technique se cachait dans le backlog. Le plafond de bande passante de Lambda se cachait derrière un quota, et la montée d'Aurora dans les 30 premières secondes de chaque pic. AWS a passé la semaine à retirer des cachettes. Le coût en est le même chaque fois : les défauts deviennent plus agressifs, et l'équipe plateforme doit décider, en amont, lesquels de ces défauts elle veut vraiment.

À lire ensuite

Pour la lecture IA et agents de la même semaine, 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