Please AWS, Allow Me to Enforce the Decommission of Deprecated Lambda Runtimes
Gert Leenders@glnds
Please AWS, Allow Me to Enforce the Decommission of Deprecated Lambda Runtimes
As an AWS user responsible for managing serverless workloads, there’s a recurring headache that I can’t shake: deprecated Lambda runtimes. I know that deprecated runtimes entail a significant security risk. AWS does a fantastic job of releasing new versions, supporting multiple runtimes, and even providing ample notice when runtimes will be deprecated. But one thing is sorely missing from my toolbox —a way to enforce the decommission of deprecated Lambda runtimes.
If you’ve ever managed an environment with dozens, if not hundreds, of Lambdas, you probably know the drill. AWS announces that a runtime version is reaching end-of-life, and the countdown begins. You send out alerts, open tickets, and maybe even automate notifications. But there’s always that one runtime —tucked away in some obscure corner of the stack- that remains untouched, having that lambda with its deprecated runtime running forever.
“You can continue to invoke your functions indefinitely after the runtime is deprecated. However, AWS strongly recommends that you migrate functions to a supported runtime so that your functions continue to receive security patches and remain eligible for technical support.”
In reality, I assume AWS is unlikely to pull the plug on deprecated runtimes because they don’t want to break backward compatibility, and I understand that point of view. Instead, what AWS is more likely to do —similar to other technologies— is incentivize migration by making deprecated Lambda runtimes more expensive compared to supported ones. This way, they nudge customers in the right direction without breaking anything. From a labor perspective, this is probably easy for AWS to implement since it only requires a change in price calculation under the hood, without any significant technical modifications.
A Win-Win for Everyone
If i think about it, getting rid of deprecated Lambda runtimes is a win-win situation. It’s beneficial for me as a customer, mitigating security risks. But it’s also advantageous for AWS —improving overall security while being more cost-efficient by allowing AWS to fully decommission old runtimes instead of keeping everything in place for a handful of customers indefinitely.
A Plea for Enforceable Controls
What I’m hoping for is an AWS-native way to enforce runtime version policies. Specifically, I want the ability to set a grace period at the account or organization level for deprecated Lambda runtimes to stay alive —for example, 180 days. This grace period would give everyone within the company time to migrate away from deprecated runtimes. After that time, I should be able to configure if the functions should either automatically update (yes, with the risk of breaking) or just stop working entirely. Ideally, there would also be a notification feature at the account level in the web console, indicating which Lambdas are still within the grace period for deprecated runtimes. This would ensure that teams are aware and can take appropriate action before the grace period ends.
Adding such a capability would not only give us peace of mind but also align with the broader industry trend of “shift-left” approaches—automating policy enforcement as early in the development process as possible. And let’s be honest, automation is what the cloud is all about.
AWS, Help Us Out
AWS, you’ve empowered us with so many tools to build and innovate faster. But we need better guardrails when it comes to the lifecycle of Lambda runtimes. An option to enforce the decommissioning of deprecated runtimes wouldn’t just help us—it would help AWS reduce the support burden and ensure a more seamless user experience across the board. Let’s make the serverless future a little safer and more predictable for everyone.