La semaine du 1er au 7 juin 2026 a supprimé deux raisons de longue date de laisser une charge de travail là où elle se trouve : la licence SQL Server qui clouait les bases de données sur EC2, et le user pool Cognito qui clouait une application à une seule Région. Aucun des deux lancements n'est spectaculaire. Les deux changent une conversation de migration qui se terminait jusqu'ici par « on ne peut pas, parce que ».

En dessous, Kubernetes 1.36 est arrivé sur Amazon EKS avec les user namespaces en disponibilité générale, Fargate est monté à des tâches de 32 vCPU, et le Cost and Usage Report arrive enfin dans Athena et Redshift sans pipeline construit à la main. Lus ensemble, c'était une semaine de plomberie, et les semaines de plomberie sont celles où les équipes plateforme économisent de l'argent réel.

RDS for SQL Server : apportez la licence que vous avez déjà payée

Amazon RDS for SQL Server prend désormais en charge Bring Your Own Media, publié le 2 juin. Les clients qui viennent d'on-premises, d'un autre cloud ou d'un SQL Server auto-géré sur EC2 peuvent tourner sur RDS en réutilisant leurs licences SQL Server existantes, Software Assurance comprise, via le programme License Mobility de Microsoft. L'usage des licences est suivi par AWS License Manager.

Jusqu'ici, l'option RDS était License Included, ce qui revenait à payer Microsoft deux fois si vous étiez en cours de contrat entreprise. C'est la raison la plus fréquente que j'ai entendue pour qu'un parc SQL Server atterrisse sur EC2 plutôt que sur RDS : pas une contrainte technique, une contrainte d'achats. BYOM retire l'argument, et il arrive une semaine avant qu'AWS Transform n'ajoute une évaluation de coût qui modélise BYOM face à License Included (celle-là est datée du 8 juin, elle appartient donc au billet de la semaine prochaine).

Le compromis est celui que License Mobility a toujours porté : il dépend d'une Software Assurance active, et la position de conformité est maintenant à vous de la prouver sur un service managé. License Manager aide à compter ; il n'aide pas lors de l'audit. Décidez qui en est responsable avant la première instance.

Cognito gagne une seconde Région, sous conditions

La réplication multi-Région d'Amazon Cognito maintient une copie synchronisée des profils utilisateurs, des identifiants et de la configuration du pool dans une Région secondaire. Le billet de lancement en détaille la forme : la réplication est unidirectionnelle, la secondaire est en lecture seule et sert l'authentification, les tokens émis par l'une ou l'autre Région sont reconnus par les deux, et la fédération (sociale, SAML, OIDC) fonctionne depuis le réplica. C'est un complément pour les pools de niveau Essentials et Plus dans 16 Régions, facturé 0,0045 $ par utilisateur actif mensuel et par Région de réplica sur Essentials, 0,006 $ sur Plus, avec un supplément de 30 % sur les tokens machine-to-machine.

Cognito était le composant qui faisait de « multi-Région » un mensonge dans beaucoup d'architectures : la base de données était répliquée, le compute était stateless, et le fournisseur d'identité vivait à un seul endroit. Ceci corrige cela, mais lisez les étapes de mise en place avant de fêter. Il vous faut une clé KMS multi-Région, et vous devez basculer le type d'émetteur OIDC vers les nouveaux endpoints multi-Région, ce qui signifie redéployer chaque client côté serveur et livrer des mises à jour d'applications mobiles. Les triggers Lambda, la configuration SMS et email, le streaming de logs et les règles WAF ne sont pas répliqués ; vous les reconstruisez à la main dans la Région cible. Pendant le failover, la connexion continue, mais les nouvelles inscriptions et les mises à jour de profil sont suspendues.

Le failover lui-même vous appartient : des mises à jour DNS pilotées par des health checks que vous concevez. Pour le managed login avec un domaine personnalisé, il existe un routage intégré sur un health check Route 53. Le conseil du billet, router une petite part du trafic hors pointe vers la secondaire avant d'en avoir besoin, c'est tout l'enjeu. Un standby non testé est une hypothèse.

Kubernetes 1.36 sur EKS : moins de webhooks, moins de root

Amazon EKS et EKS Distro prennent en charge Kubernetes 1.36 dans toutes les Régions où EKS tourne, GovCloud compris. Quatre fonctionnalités comptent pour les opérateurs de plateforme : les User Namespaces sont en disponibilité générale, et mappent le root du conteneur sur un utilisateur hôte non privilégié, de sorte qu'une évasion de conteneur ne rapporte aucun privilège sur le nœud ; les Mutating Admission Policies permettent d'exprimer des mutations en CEL dans l'API server sans faire tourner d'infrastructure de webhooks ; le redimensionnement vertical in-place au niveau du Pod ajuste le budget CPU et mémoire partagé d'un Pod sans redémarrage ; et Resource Health Status fait remonter la santé des périphériques dans le statut du Pod.

Celle sur laquelle agir, ce sont les Mutating Admission Policies. Chaque webhook mutant que vous faites tourner est un composant sur le chemin critique de chaque kubectl apply, avec son propre TLS, sa propre disponibilité et son propre timeout. Déplacer l'injection de sidecars, les labels par défaut et les réécritures d'images dans des politiques CEL supprime une classe de pannes. Les User Namespaces sont le gain de sécurité, mais ils ont besoin du support du runtime et du nœud, donc traitez-les comme une migration de node group plutôt que comme un flag.

CUR 2.0 dans Athena et Redshift, sans la glu

Le Cost and Usage Report 2.0 s'intègre désormais à Athena et Redshift. Choisissez le moteur, et l'export arrive au bon format (Parquet ou GZIP) avec des modèles, des définitions de tables et des instructions de chargement ; les tables se mettent à jour au rythme des données. Quiconque a maintenu un crawler Glue plus une stack CloudFormation juste pour rendre les données de facturation interrogeables sait ce que cela remplace. C'est disponible dans toutes les Régions commerciales, pas dans GovCloud ni en Chine. Associez-le à la nouvelle fenêtre d'analyse de 32 jours de Compute Optimizer pour le rightsizing EBS et ECS, qui couvre enfin un cycle mensuel complet.

Également cette semaine

Le fil conducteur

Aucun des lancements de cette semaine n'ajoute une capacité que vous ne pouviez pas construire avant. Vous pouviez faire tourner SQL Server sur EC2 avec votre propre licence. Vous pouviez écrire un job d'export Cognito et prier. Vous pouviez faire tourner des webhooks. Ce qui a changé, c'est que le chemin managé couvre désormais le cas qui forçait auparavant le chemin non managé, et que l'écart entre « ce que nous voudrions faire tourner » et « ce que la licence ou l'architecture permet » s'est un peu refermé. Ce sont ces semaines-là qui font avancer les migrations, pas les semaines de keynote.

À lire ensuite

La lecture IA et agents de la semaine vit sur ercan.ai. Pour du conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore, le point d'entrée est ercanermis.com.

Références