AWS centralise les dates de fin de support de RDS, EKS et Lambda dans un catalogue de versions
Le 2 octobre 2026, AWS Health a lancé un catalogue de versions qui donne une vue centralisée des cycles de vie des versions logicielles des services AWS, à commencer par RDS, EKS et Lambda. Les équipes sur Business Support Plus, Enterprise Support ou Unified Operations peuvent l’interroger par API pour bâtir des plans de montée de version avant la fin de support, au lieu de subir les événements de cycle de vie au cas par cas.
Jeudi 2 octobre 2026. AWS a présenté le catalogue de versions d’AWS Health : une source centralisée d’informations de cycle de vie pour les versions logicielles des services AWS. Trois services au lancement. Le catalogue couvre Amazon RDS, Amazon EKS et AWS Lambda, avec d’autres services à venir. Par API, sous condition. La consultation se fait dans le tableau de bord AWS Health, mais l’intégration par API est réservée aux clients Business Support Plus, Enterprise Support et Unified Operations.
Ce que le catalogue change par rapport aux événements existants
AWS Health envoyait déjà des Planned Lifecycle Events : des notifications spécifiques à un compte et à une ressource, annoncées à l’avance pour les jalons majeurs de fin de support — par exemple la fin d’une version de moteur RDS ou d’une version Kubernetes sur EKS. Ces événements sont utiles, mais ils arrivent ressource par ressource, et seulement quand une échéance approche.
Le catalogue de versions inverse la logique. Il fournit une vue à l’échelle du service des versions supportées et de leurs échéances, indépendamment de ce que vous utilisez précisément. Résultat : une équipe peut construire un calendrier de montées de version et des règles de gouvernance avant même de recevoir un Planned Lifecycle Event propre à son compte. L’annonce d’AWS résume le positionnement en une phrase : passer d’une gestion réactive à une gestion proactive du risque de fin de support.
Pourquoi RDS, EKS et Lambda en premier
Les trois services choisis pour le lancement partagent un point commun : ce sont ceux où une version obsolète se paie le plus cher, et souvent trop tard.
- Amazon RDS gère des moteurs — PostgreSQL, MySQL, MariaDB, Oracle, SQL Server — dont chaque version majeure a une fenêtre de support propre. Une base restée sur une version en fin de support ne reçoit plus de correctifs de sécurité, et la montée de version se planifie des mois à l’avance.
- Amazon EKS impose un calendrier strict : chaque version mineure de Kubernetes est supportée environ quatorze mois. La version 1.34, par exemple, atteint sa fin de vie le 27 octobre 2026 ; un cluster qui n’est pas monté avant cette date cesse d’être patché.
- AWS Lambda fait évoluer ses runtimes — Node.js, Python, Java — et déprécie régulièrement les anciens, ce qui oblige les équipes à revalider fonctions et dépendances.
Ces trois cas illustrent la même mécanique : l’échéance est connue à l’avance, mais dispersée dans une documentation éparpillée. Le catalogue de versions la rassemble en un seul endroit, avec une vue chronologique des versions supportées et de leurs échéances.
Comment s’en servir : tableau de bord ou API
Deux niveaux d’accès existent. La consultation du catalogue se fait depuis le tableau de bord AWS Health, dans toutes les régions commerciales AWS. Pour l’intégration, les clients Business Support Plus, Enterprise Support et Unified Operations peuvent interroger l’API AWS Health et injecter les données de cycle de vie dans leurs propres flux opérationnels : tableaux de bord internes, systèmes de tickets, ou chaînes de remédiation automatique.
L’intérêt de l’API n’est pas de lire une date, mais de la croiser avec votre inventaire. Une fois les échéances accessibles par requête, une équipe peut rapprocher ses clusters EKS, ses instances RDS et ses runtimes Lambda du catalogue, et produire automatiquement une liste des composants à migrer avant une date donnée — sans attendre la notification individuelle.
Le fond du problème : la dette de version est une dette de sécurité
Derrière l’annonce produit, le sujet réel est la dette de version comme vecteur de risque. Une version de moteur ou de runtime en fin de support ne reçoit plus de correctifs de sécurité ; elle devient un point d’entrée documenté, puisque les failles qui la touchent sont publiques et non corrigées. Le coût de la montée de version, lui, augmente avec l’attente : plus on laisse une version vieillir, plus la distance à parcourir est grande, plus les incompatibilités s’accumulent.
Le catalogue de versions ne résout pas la migration, mais il supprime l’excuse de l’ignorance. La raison la plus fréquente d’une montée de version tardive n’est pas la complexité technique, mais l’absence d’une visibilité simple et centralisée sur les échéances. En fournissant cette visibilité, AWS déplace la charge : ce n’est plus à chaque équipe de compiler les dates dans les notes de version, c’est à l’organisation d’utiliser une donnée déjà disponible.
Verdict
Si vous êtes sur Business Support Plus, Enterprise Support ou Unified Operations, branchez l’API AWS Health sur votre inventaire dès maintenant : le retour sur investissement immédiat est la liste automatique des composants RDS, EKS et Lambda à migrer avant leur fin de support, en commençant par vos clusters Kubernetes 1.34 qui arrivent à échéance le 27 octobre. Si vous êtes sur un palier de support inférieur, consultez le tableau de bord à chaque revue mensuelle et intégrez manuellement les échéances dans votre backlog : l’information est disponible, seule l’automatisation est facturée. Quel que soit votre palier, traitez le catalogue comme un point de départ, pas comme un substitut : il liste les échéances de service, mais il ne connaît ni votre architecture, ni vos dépendances applicatives — c’est à vous de croiser la donnée avec ce que vous déployez réellement. La fin de support de RDS, d’EKS et de Lambda était prévisible depuis toujours ; le 2 octobre, AWS a simplement décidé de la rendre lisible.