AI & Infra6 min readUpdated November 7, 2026

Who Tracks End-of-Life Versions in Your Cloud? (Nobody, and It Costs)

Every environment has something approaching end of life: Kubernetes versions, Lambda runtimes, database engines, certificates, even AI model versions on Bedrock and Azure OpenAI. Each cloud provider announces deprecations differently. Nobody's job is to watch all of them.

EOL tracking fails because it is everyone's job, so it is nobody's. The fix is a single inventory with expiry dates, checked monthly: one script that lists your runtime versions, engine versions, certificates and reserved instances, compared against a published EOL list. An hour a month prevents the forced upgrade at the worst possible time, which is the only kind of forced upgrade there is.

Ask five infrastructure engineers what in their cloud expires this quarter. Most cannot answer. The inventory is scattered: Kubernetes versions live in the cluster, runtimes in function configs, engine versions in Terraform, certificates in ACM, model IDs in application code. No single view exists, so no single owner can exist.

The expiry inventory nobody keeps

Ask five infrastructure engineers what in their cloud expires this quarter. Most cannot answer. The inventory is scattered: Kubernetes versions live in the cluster, runtimes in function configs, engine versions in Terraform, certificates in ACM, model IDs in application code. No single view exists, so no single owner can exist.
Ask five infrastructure engineers what in their cloud expires this quarter. Most cannot answer. The inventory is scattered: Kubernetes versions live in the cluster, runtimes in function configs, engine versions in Terraform, certificates in ACM, model IDs in application code. No single view exists, so no single owner can exist. Creating that view is the whole project, and it is one script.

The monthly 30-minute ritual

Run the inventory script, diff against last month, check the diff against each provider's EOL list, and file tickets for anything inside 90 days. That is it. The ritual works because it is small enough to survive busy quarters, and because the script does the work: the humans only judge priorities.
Run the inventory script, diff against last month, check the diff against each provider's EOL list, and file tickets for anything inside 90 days. That is it. The ritual works because it is small enough to survive busy quarters, and because the script does the work: the humans only judge priorities.

Why this matters more in the AI era

AI model versions added a whole new expiry class that did not exist five years ago, and they deprecate faster than any database engine ever did. A startup that pinned to a model ID in January can get a deprecation notice with a deadline inside its biggest quarter.
AI model versions added a whole new expiry class that did not exist five years ago, and they deprecate faster than any database engine ever did. A startup that pinned to a model ID in January can get a deprecation notice with a deadline inside its biggest quarter. The companies that treat model versions like runtime dependencies, with the same tracking, are the ones that do not find out from a broken production call.

4 Tips to Get Started

1

Build one script that lists: EKS/GKE/AKS node versions, Lambda and Cloud Functions runtimes, RDS engine versions, ACM certificate expiries, and container image base tags. Run it monthly, diff against last month.

2

Subscribe to the deprecation RSS/emails of each provider you use. AWS, GCP and Azure all publish them; the problem is they land in inboxes nobody reads. Route them to one Slack channel.

3

Treat AI model versions as runtime dependencies too. Bedrock and Azure OpenAI deprecate models with dates, and a pinned model ID that dies breaks production as surely as an expired certificate.

4

Set expiry alerts at 90, 60 and 30 days for anything dated: certificates, reserved instances, support contracts. The 30-day alert is the one that saves you.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Sources & References

roqy.io cites authoritative sources including engineering blogs, vendor documentation, industry surveys, and academic research to ensure accuracy.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data and cited sources above.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

What happens if we miss a cloud EOL date?

The provider upgrades or deprecates for you, on their schedule. Lambda runtimes get frozen (no new deployments until you upgrade), EKS nodes get force-upgraded, database engines lose security patches, and AI model IDs start failing. The upgrade happens anyway. You just lose the ability to choose when, and it always lands during a launch or an on-call week.

Is there a tool that tracks this automatically?

Cloud providers surface some of it (AWS Compute Optimizer, GCP recommendations, Azure Advisor), and third-party tools cover pieces. But no tool knows your full inventory across providers plus your own dependencies. A simple monthly script plus a deprecation channel covers 90% of the risk for zero cost.

How often should we review versions?

Monthly, as a 30-minute agenda item in your ops review. Quarterly is too slow: Kubernetes releases every few months and AI model deprecations move faster than that. Monthly with automated listing means the review is reading a diff, not doing an audit.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.