Soixante-dix-neuf annonces sont tombées la semaine du 28 septembre, dont cinq modèles frontière, et celle avec la plus longue traîne était un avis de cycle de vie : Amazon DevOps Guru, Amazon Managed Blockchain et le Backint Agent for SAP ASE sont entrés en sunset, la console autonome d'Infrastructure Composer disparaît en décembre, et Mechanical Turk a atteint sa fin de support. Deux jours plus tard, AWS Health a livré un catalogue de versions pour que ce genre de nouvelle cesse d'arriver par surprise. Sur le front des migrations, AWS Transform a ajouté des évaluations agentiques Kafka vers MSK. EKS Auto Mode a ouvert le tuning kubelet, sysctl et hugepages, Kubernetes 1.37 est arrivé, et Aurora PostgreSQL a commencé à interroger Iceberg et Parquet dans S3 via un DuckDB embarqué.

La liste des sunsets, et le catalogue qui devrait la remplacer

Les AWS Service Availability Updates du 29 septembre font passer Amazon Chime SDK SIP Media Application et Amazon WorkSpaces Secure Browser en maintenance (fermés aux nouveaux clients à partir du 29 octobre 2026, les clients existants continuent). Entrent en sunset : Amazon Managed Blockchain (fin de support le 29 septembre 2027), Amazon DevOps Guru (30 septembre 2027), AWS Backint Agent for SAP ASE (29 septembre 2027) et la console autonome d'AWS Infrastructure Composer (7 décembre 2026). Amazon Mechanical Turk a atteint sa fin de support le 29 septembre 2026.

DevOps Guru est celui que la plupart des équipes infra vont sentir. Beaucoup l'ont activé en 2021 et l'ont oublié, donc il est encore dans des templates CloudFormation et encore câblé à des topics SNS qui pagent quelqu'un. AWS ne nomme aucun successeur ; vu que CloudWatch Omni et le DevOps Agent ont été livrés une semaine plus tôt, la piste de l'investigation agentique est la lecture évidente. Auditez dès maintenant les ressources AWS::DevOpsGuru::ResourceCollection et NotificationChannel et décidez de ce qui remplace les alertes, parce que douze mois passent vite quand le retrait exige un ticket de changement dans quarante comptes.

Puis, le 2 octobre, AWS Health a introduit le catalogue de versions : une vue à l'échelle du service des versions logicielles prises en charge et de leurs échéances de cycle de vie, dans le Health Dashboard pour tout le monde et via la Health API pour les clients Business Support Plus, Enterprise Support et Unified Operations. Au lancement, il couvre RDS, EKS et Lambda, d'autres services suivront. Branchez l'API sur ce qui suit votre backlog de mises à niveau ; une version EKS à qui il reste quatre mois devrait être un ticket, pas un e-mail.

AWS Transform évalue Kafka vers MSK

Le 29 septembre, AWS Transform a ajouté des évaluations de migration agentiques d'Apache Kafka on-premises vers Amazon MSK. Vous téléversez un fichier d'inventaire de clusters ou décrivez les clusters dans le chat, et l'agent vérifie la compatibilité MSK de chaque cluster sur la topologie, la version, la configuration, l'authentification et les quotas, dimensionne les brokers MSK Express et produit un business case TCO avec options tarifaires et prochaines étapes.

La partie lente d'une migration Kafka n'est pas la copie des données, ce sont les semaines de tableur pour savoir si ça rentre et ce que ça coûte. Compresser cela en minutes change qui a le droit de poser la question.

Lisez le mot « évaluation » littéralement. Elle produit un dossier, pas une migration. Les offsets de consumer groups, le schema registry, la topologie MirrorMaker, les changements d'authentification côté client et les décisions de nombre de partitions qu'imposent les brokers Express restent tous à votre charge. Traitez le TCO comme un chiffre d'ouverture et vérifiez le dimensionnement des brokers Express contre vos pics de rétention et de débit.

EKS Auto Mode perd sa dernière excuse

Le 1er octobre, EKS Auto Mode a ajouté la configuration de calcul avancée : un nouveau champ advancedCompute dans la ressource NodeClass permet de définir déclarativement les options kubelet, les sysctls Linux et les hugepages : user namespaces pour les builds d'images rootless, seuils d'éviction, limites du cache ARP, hugepages de 2Mi ou 1Gi pour les bases de données et le HPC. EKS valide les réglages, les applique au boot et les conserve à travers le scaling et les mises à niveau, sans launch templates, AMI custom ni DaemonSets privilégiés.

« Il nous faut une AMI custom pour le tuning sysctl » était la raison honnête la plus courante de rester sur des node groups autogérés. Cette raison a disparu, de la bonne manière : le tuning vit dans un objet Kubernetes versionné, pas dans un pipeline d'images que personne ne veut posséder. Le mode de défaillance est le même que pour tout réglage au niveau nœud : un mauvais sysctl dans une NodeClass se déploie sur chaque nœud que cette classe provisionne. Donnez à la NodeClass ajustée son propre node pool et testez-la en canary avec une seule charge.

Le 2 octobre, EKS et EKS Distro ont ajouté Kubernetes 1.37 : la Metrics API est GA en metrics.k8s.io/v1, les taints et tolerations de device DRA sont GA, et le scale-to-zero de l'HPA est en beta et activé par défaut. Le même jour, ECS a ajouté les déploiements blue/green, linéaires et canary pour les services derrière VPC Lattice.

Aurora PostgreSQL lit le data lake sur place

Le 30 septembre, Aurora PostgreSQL a gagné l'interrogation directe de données Apache Iceberg et Parquet. Vous créez des foreign tables PostgreSQL sur des données dans S3, S3 Tables ou le Glue Data Catalog (y compris des catalogues Iceberg REST externes fédérés via Glue), et Aurora exécute ces requêtes avec DuckDB embarqué dans le moteur. Les applications et outils BI existants continuent de parler du PostgreSQL ordinaire ; pour les chemins sensibles à la latence, vous pouvez matérialiser localement les données du lake.

Cela tue toute une classe de jobs nocturnes « copier les tables de dimension dans Postgres », et DuckDB est un moteur raisonnable pour scanner des fichiers colonnes. Le compromis, c'est que le scan tourne désormais sur votre instance OLTP. Une requête de reporting sur un an de Parquet, c'est beaucoup de CPU et de mémoire sur la machine qui sert aussi les paiements ; placez la charge tournée vers le lake sur un reader, et surveillez la connexion que vous donnez à l'outil BI aussi étroitement qu'un cron job.

Également cette semaine

Le fil conducteur

Le vrai thème de la semaine est le cycle de vie. Un service que vous avez adopté en 2021 s'en va. Le catalogue de versions existe pour que le prochain ne vous prenne pas de court. AWS Transform écrit désormais le business case pour quitter Kafka on-prem. EKS Auto Mode a supprimé l'écart de configuration qui maintenait les node groups en vie au-delà de leur temps, et Aurora a supprimé le job de copie qui maintenait une douzaine de pipelines ETL en vie au-delà du leur. Le travail de plateforme consiste surtout à décider ce qu'on arrête de faire tourner, et cette semaine AWS a livré des outils pour les deux moitiés : découvrir ce qui se termine, et rendre le remplacement assez bon marché pour le faire vraiment.

À lire ensuite

Pour la lecture IA et agents de la même semaine, voir ercan.ai. Si votre équipe a besoin d'aide concrète sur AWS, l'architecture cloud, les pipelines CI/CD, Linux, GitHub ou GitLab et le travail de plateforme qui les entoure, le volet conseil se trouve sur ercanermis.com.

Références