AWS centralises RDS, EKS and Lambda end-of-support dates in a version catalog
On 2 October 2026 AWS Health launched a version catalog that gives a centralised view of the software-version lifecycles across AWS services, starting with RDS, EKS and Lambda. Teams on Business Support Plus, Enterprise Support or Unified Operations can query it through an API to build upgrade plans before end of support, instead of absorbing lifecycle events one by one.
Thursday, 2 October 2026. AWS introduced the version catalog in AWS Health: a centralised source of lifecycle information for software versions across AWS services. Three services at launch. The catalog covers Amazon RDS, Amazon EKS and AWS Lambda, with more services to come. API access is gated. You can read it in the AWS Health Dashboard, but API integration is reserved for Business Support Plus, Enterprise Support and Unified Operations customers.
What the catalog changes versus existing events
AWS Health already sent Planned Lifecycle Events: account- and resource-specific notifications, announced in advance for major end-of-support milestones — for example the end of an RDS engine version or a Kubernetes version on EKS. Those events are useful, but they arrive resource by resource, and only as a deadline approaches.
The version catalog inverts that logic. It provides a service-wide view of supported versions and their timelines, independent of exactly what you run. The result: a team can build an upgrade schedule and governance rules before it ever receives an account-specific Planned Lifecycle Event. The AWS announcement sums up the positioning in one line: move from reactive to proactive management of end-of-support risk.
Why RDS, EKS and Lambda first
The three services chosen for launch share one trait: they are where an obsolete version costs the most, and usually too late.
- Amazon RDS manages engines — PostgreSQL, MySQL, MariaDB, Oracle, SQL Server — each major version carrying its own support window. A database left on an end-of-support version stops receiving security patches, and the upgrade must be planned months ahead.
- Amazon EKS enforces a strict schedule: each minor Kubernetes version is supported for about fourteen months. Version 1.34, for example, reaches end of life on 27 October 2026; a cluster not upgraded before then stops being patched.
- AWS Lambda keeps evolving its runtimes — Node.js, Python, Java — and regularly deprecates the old ones, forcing teams to revalidate functions and dependencies.
All three cases show the same mechanism: the deadline is known in advance, but scattered across fragmented documentation. The version catalog gathers it into one place, with a chronological view of supported versions and their timelines.
How to use it: dashboard or API
Two access levels exist. Reading the catalog happens in the AWS Health Dashboard, across all AWS Commercial Regions. For integration, Business Support Plus, Enterprise Support and Unified Operations customers can query the AWS Health API and inject lifecycle data into their own operational flows: internal dashboards, ticketing systems, or automated remediation pipelines.
The point of the API is not to read a date but to cross it with your inventory. Once deadlines are queryable, a team can match its EKS clusters, RDS instances and Lambda runtimes against the catalog and automatically produce a list of components to migrate before a given date — without waiting for the individual notification.
The deeper issue: version debt is security debt
Behind the product announcement, the real subject is version debt as a risk vector. An engine or runtime version at end of support no longer receives security patches; it becomes a documented entry point, since the flaws that affect it are public and unfixed. The cost of the upgrade, meanwhile, grows with the wait: the longer a version ages, the wider the distance to cover and the more incompatibilities pile up.
The version catalog does not solve the migration, but it removes the excuse of ignorance. The most common reason for a late upgrade is not technical complexity but the absence of simple, centralised visibility over deadlines. By providing that visibility, AWS shifts the burden: it is no longer up to each team to compile dates from release notes, but up to the organisation to use data that already exists.
Verdict
If you are on Business Support Plus, Enterprise Support or Unified Operations, wire the AWS Health API into your inventory now: the immediate payoff is an automatic list of the RDS, EKS and Lambda components to migrate before end of support, starting with your Kubernetes 1.34 clusters due on 27 October. If you are on a lower support tier, read the dashboard at each monthly review and feed the deadlines into your backlog manually: the information is available, only the automation is billed. Whatever your tier, treat the catalog as a starting point, not a substitute: it lists service deadlines, but it knows neither your architecture nor your application dependencies — crossing that data with what you actually deploy is your job. End of support for RDS, EKS and Lambda has always been predictable; on 2 October, AWS simply decided to make it legible.