AWS Health Adds a Version Catalog for Tracking End-of-Support Dates Across RDS, EKS and Lambda

On October 2, 2026, Amazon Web Services added a version catalog to AWS Health. It is a single place to look up which software versions AWS still supports across its managed services, and the dates on which each version loses support or stops working.

That may sound like housekeeping for engineers. For a business owner it addresses a familiar and expensive problem: the email from AWS saying that the database engine or language runtime under your application is about to be retired, arriving when nobody has budgeted time for the upgrade. Whether your product is built with Node.js development, PHP, Python or Java, the versions underneath it all have an expiry date.

This article covers what the catalog shows, who can use which part of it, and how a small or mid-sized team can turn it into a simple upgrade calendar.

What AWS announced on October 2, 2026

The AWS What's New post describes the version catalog as a centralized source of lifecycle information for software versions across AWS services. It is intended to help customers plan upgrades ahead of end-of-support dates instead of reacting to notices.

According to the post, the catalog is available now in the AWS Health Dashboard in all AWS commercial Regions, and at launch it covers Amazon RDS (managed databases), Amazon EKS (managed Kubernetes) and AWS Lambda (serverless functions), with more services planned. The post also says programmatic access through the AWS Health API is for customers on the Business Support Plus, Enterprise Support or Unified Operations plans. The announcement does not mention a separate charge for the catalog.

How it differs from the notices AWS already sends

AWS Health already warns customers about retirements. The AWS Health User Guide explains that those planned lifecycle events are specific to your account and your resources, and are sent ahead of major end-of-support milestones.

The catalog works the other way round. It is a service-wide view of supported versions and their timelines, whether or not you run them. The guide says the purpose is to let customers build upgrade schedules and governance controls, and move to newer versions before an account-specific notice ever arrives. Put simply, the old notices tell you that you have a problem; the catalog lets you see the whole timetable in advance.

What the catalog tells you about each version

The User Guide describes each entry as a service, a readable title, a version identifier and a chronological list of lifecycle events. Each event has a type, a date, a description and the Regions it applies to. The documentation's example is a Lambda Python runtime with three separate dates: when it stops receiving security patches, when you can no longer create new functions on it, and when you can no longer update existing ones.

Each event also carries one or more impact tags, which are the most useful part for non-technical readers:

• END_OF_SUPPORT: the version no longer receives security patches or updates.
• BILLING: staying on the version might cost more, for example through extended-support fees.
• AVAILABILITY: the resource becomes unavailable after the date. The guide calls this the most urgent impact.

These three tags map onto three different business conversations. The first is a security and compliance risk, the second is a line on next quarter's bill, and the third is an outage with a date attached.

Dashboard for everyone, API for supported accounts

There are two ways in. The Health Dashboard shows the catalog as a table of services and versions with a timeline for the selected version, and the announcement presents this as generally available. The second is an API operation named DescribeServiceLifecycle, which returns the same data in a consistent format so that tools and scripts can consume it.

The API is where the limit applies. The announcement restricts it to the support plans named above, and the User Guide says it is for customers on AWS Support. A business on the free Basic support tier should plan to use the dashboard and should confirm API eligibility with AWS before building anything that depends on it.

For teams that do have access, the User Guide suggests uses such as flagging unsupported database engines or runtimes in an inventory, alerting on versions close to end of support, and making a build pipeline warn or fail when a project depends on a version at or near end of life.

What this means for your business

This section is our interpretation, offered as guidance.

Version upgrades are among the least visible costs of owning software. Nothing is wrong until a date passes, and then the choice is between an urgent, unplanned project, paying extended-support fees where AWS offers them, or accepting unpatched software. The catalog does not remove the work, but it removes the surprise, and that is the part that makes upgrades expensive. An upgrade scheduled six months ahead can be combined with other development and properly tested. The same upgrade done in the last two weeks usually displaces something else.

It also gives owners and managers a way to ask better questions. You do not need to understand what a Kubernetes version is to ask your developers or agency for a one-page list of every managed version you run and the next date attached to each, grouped by those three impact tags.

Two limits are worth keeping in mind. The catalog covers versions of AWS-managed services, and the announcement names only three services at launch, so it is not yet a complete picture. It also says nothing about your application's own framework and libraries, or about operating systems on servers you manage yourself, which have separate lifecycles that still need tracking.

What to do next

Ask whoever manages your AWS account to open the version catalog in the Health Dashboard and compare it against what you actually run on RDS, EKS and Lambda. The output should be a short list: resource, current version, next lifecycle date, impact tag.

Deal with anything tagged AVAILABILITY first, then anything tagged BILLING where the date falls in the current budget year. Put the remaining END_OF_SUPPORT dates into the product roadmap as scheduled work with an owner, not as a note in an engineer's backlog.

If you have a qualifying support plan and an engineering team, consider a small automation that checks the API on a schedule and raises a ticket when a version you use comes within a set number of months of a lifecycle date. Keep it simple; a monthly reminder to check the dashboard achieves most of the benefit for a small application.

Conclusion

The AWS Health version catalog, launched on October 2, 2026, puts support timelines for Amazon RDS, Amazon EKS and AWS Lambda versions in one place, with more services planned. The dashboard view is available in all commercial Regions, while API access depends on your support plan. Its value for a smaller business is practical: retirement dates become something you plan for instead of something that interrupts you.

If you would like a second opinion on which parts of your application are approaching end of support and what the upgrades would involve, Entrant Technologies builds and maintains web applications, mobile apps and custom software, and you can contact us to discuss it.