Deux choses se sont produites la semaine du 24 août qui compteront encore en 2028 : AWS a conclu un accord pour racheter DuckLabs, la société d'Amsterdam derrière DuckDB, la base restant sous licence MIT au sein de sa fondation indépendante ; et Amazon ECS a commencé à détecter et réparer les container instances dont l'agent a perdu le contact avec le control plane. Autour, Lambda a eu un mardi à trois lancements (runtimes en preview, politiques basées sur les ressources complètes, PrivateLink pour les MicroVMs), EKS a accepté jusqu'à dix fournisseurs OIDC par cluster, et côté migration AWS Transform est entré dans le périmètre FedRAMP Class C tandis qu'Elastic Disaster Recovery gagnait des Recovery Plans ordonnés. EC2 a aussi fêté ses vingt ans.

DuckLabs : AWS achète le moteur pour les données qui tiennent sur une machine

L'annonce est prudente sur les points qui comptent pour quiconque a DuckDB en production : il reste open source sous licence MIT, il reste sous la Foundation indépendante, et Hannes Mühleisen et Mark Raasveldt continuent de diriger la direction technique. La raison déclarée d'AWS, ce sont les agents, qui explorent les données comme le font les analystes, par petites requêtes itératives sur un téraoctet ou moins, et sa preuve est la sienne : Amazon Quick fait déjà tourner DuckDB sur S3 Tables et a servi plus de 2,5 milliards de requêtes avec une baisse de 30% de la latence moyenne.

La lecture honnête pour une équipe plateforme est double. D'abord, le moteur in-process que vos data people font déjà tourner dans des notebooks va désormais apparaître sous une forme ou une autre dans Athena, Redshift, EMR, Glue et SageMaker, ce qui veut dire que le chemin « small data » sur AWS cesse d'être un cluster Spark qui attend un fichier Parquet de 2 Go. C'est une bonne nouvelle pour le coût. Ensuite, chaque acquisition d'une société open source soulève la même question quel que soit le communiqué, et la réponse ici tient dans la licence et la structure de fondation. MIT veut dire que les forks sont triviaux si la gouvernance dérive un jour. Surveillez où les nouvelles fonctionnalités arrivent en premier, le dépôt ouvert ou les services AWS, parce que c'est là le signe révélateur, pas le texte de la licence.

ECS : un événement de santé pour la panne que vous ne pouviez pas voir

Une container instance ECS dont l'agent a perdu sa connexion au control plane est cassée d'une manière bien précise : les tâches qu'elle porte tournent peut-être encore, l'instance passe les status checks EC2, mais ECS ne peut plus rien placer, arrêter ni observer dessus. Une dégradation EBS, un événement thermique ou une panne réseau peuvent tous en être la cause. ECS surveille désormais cela en continu et émet un événement de changement de santé de container instance AGENT_CONNECTIVITY sur Fargate, ECS Managed Instances et ECS sur EC2, sans frais dans toutes les Régions commerciales et GovCloud (US).

La séparation est la partie importante. Sur Fargate et Managed Instances, ECS fait la reprise lui-même : il draine les charges, provisionne de la capacité de remplacement, retire l'instance dégradée. Sur ECS sur EC2, vous recevez l'événement et le travail. C'est la bonne conception, parce que sur EC2 le capacity provider est à vous et qu'ECS ne peut pas savoir si terminer l'instance est sans danger, mais cela veut dire que le lancement ne vous aide que si vous le câblez. Une règle EventBridge sur l'événement qui appelle aws autoscaling set-instance-health --health-status Unhealthy est la version minimale viable. Si vous cherchiez une raison de déplacer les capacity providers EC2 restants vers Managed Instances, en voici une concrète : la même semaine, AWS Batch a gagné Managed Instances comme environnement de calcul via un bloc managedInstancesProvider dans CreateComputeEnvironment.

Le mardi de Lambda : runtimes, politiques, endpoints privés

Node.js 26 et Python 3.15 sont arrivés comme runtimes en public preview avec un choix de conception utile : les identifiants sont nodejs26.x et python3.15, les mêmes qu'en GA, donc les fonctions passent en GA automatiquement. Le prix de cette commodité, c'est le piège qu'elle contient. Un runtime en preview est exclu du SLA Lambda et d'AWS Support, et des changements cassants sont possibles, donc une fonction réglée sur python3.15 dans un template SAM partagé aujourd'hui est demain une fonction de production sur un runtime non supporté. Verrouillez-le en CI.

Les politiques IAM basées sur les ressources complètes remplacent le modèle de permission un principal à la fois par un seul document de politique couvrant plusieurs principals et actions, avec l'ensemble complet des clés de condition IAM. Quiconque a géré une fonction invoquée par trois services et un compte externe sait que l'ancien modèle produisait une resource policy que personne ne pouvait lire ; ceci rend la politique relisible et, via CloudFormation et SAM, diffable. Et les Lambda MicroVMs prennent désormais en charge PrivateLink, donc les ressources d'un VPC peuvent créer des images, lancer des MicroVMs et atteindre l'endpoint HTTP de chaque MicroVM sans quitter le réseau AWS, ce qui était le bloqueur pour les équipes régulées qui les utilisent comme sandboxes d'agents.

Migration et DR : Transform dans le périmètre FedRAMP, DRS reçoit un runbook

AWS Transform est désormais dans le périmètre FedRAMP Class C (l'ancienne baseline Moderate) lorsqu'il est utilisé depuis US East (N. Virginia) et cible US East ou US West ; le composant MGN est séparément qualifié pour Class D. Pour les migrations du secteur public bloquées sur la conformité de l'outillage, c'est le déblocage. Les Recovery Plans de DRS vous permettent de grouper des serveurs en étapes séquentielles avec des temps d'attente, d'ajouter des portes d'approbation, d'exécuter le tout comme un exercice non perturbateur, et de suivre la progression en direct. L'ordre « base de données avant application » qui vivait dans une page de wiki est maintenant un objet que le service exécute, ce qui est aussi la seule façon pour qu'un exercice de DR soit jamais lancé deux fois.

Également cette semaine

Le fil conducteur

Le lancement ECS et l'acquisition de DuckDB sont tous deux AWS admettant qu'une grande partie du vrai travail se fait en dessous de l'échelle pour laquelle ses services ont été conçus. Une container instance qui se tait est trop petite pour un dashboard et trop fréquente pour être ignorée ; un téraoctet de Parquet est trop petit pour Spark et trop fréquent pour faire semblant du contraire. Les deux correctifs ont la même forme : remarquer la petite panne ou le petit jeu de données, le gérer nativement, et cesser de faire construire au client un cluster ou un cron pour s'en sortir. La preview de runtime Lambda et les resource policies appartiennent à la même semaine parce qu'elles parlent aussi de la longue traîne : la fonction que personne ne possède, invoquée par quatre principals, sur un runtime que quelqu'un a fixé en 2026. Les plateformes gagnent la confiance dans la longue traîne, pas dans la keynote.

À lire ensuite

Pour la lecture IA et agents de la même semaine, les notes de terrain sont sur ercan.ai. Le conseil en AWS, cloud, pipelines CI/CD, Linux, GitHub/GitLab et plus encore passe par ercanermis.com.

Références