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.
In This Guide
The expiry inventory nobody keeps
The monthly 30-minute ritual
Why this matters more in the AI era
4 Tips to Get Started
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.
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.
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.
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.
Related Guides
Who Owns Vibe-Coded Internal Apps When the Builder Leaves?
Marketing built a dashboard on a personal Vercel account with a service key. The builder left. Who owns it, who fixes it, and how to prevent the next orphaned app.
What Do You Do When Your DevOps Team Shrinks but Your Infrastructure Triples?
Microservices tripled in 8 months, the DevOps team stayed the same size, then got smaller. The realistic options: platform guardrails, deletion, and buying back hours.
Why Do Internal Dashboards Become a Maintenance Nightmare, and How to Fix It?
Tens of internal tools, each breaking when the data model changes. Why internal dashboards rot, which ones to keep, and the pattern that makes the rest maintainable.
Why Do AI-Generated PRs Break Your Infrastructure, and What Guardrails Work?
AI pull requests change pipelines and add services that need config outside the codebase. Why code review cannot catch it, and the four guardrails that do.
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.