AWS Lambda is great. The minimal management overhead of the official runtimes means I spend so much less time worrying about OS-level patching and updates. Exploits like Heartbleed were fixed before I even knew they existed.
"Minimal management" is not "no management" though, and part of creating a lambda function is choosing a rutime for your function. AWS continually and gradually updates these runtimes as the various supported languages. Unfortunately, this also means they sometimes get rid of runtimes (RIP the Go runtime). A function will continue to allow invocations even after it has officially been deprecated
, but 60 days after deprecation you lose the ability to update or deploy them. This quickly becomes a security issue since your runtime and code longer gets security patches, or is eligible for technical support.
The best strategy is to keep your runtimes updated, and don't let them get too far out of date; Easier said than done, especially in large environments where just keeping track of all your lambda functions can be a challenge.
Which functions?
This little script I wrote uses the AWS CLI to check all the deployed functions in your environment and make a TSV (Tab Separated Values) of all the functions running unsupported runtimes. The output gives you the function name, the runtime, when the function was last modified, and it's ARN to uniquely identify it:
You can then use this as a "hitlist" you can easily open it in your spreadsheet tool of choice (like Excel or Mac Numbers) for functions that you need to upgrade or decommission, since you can no longer update them running a deprecated runtime.
Keep in mind that new AWS regions may not even support runtimes that are going to be deprecated in the next 6 months after their launch, which is more reason to keep your runtimes up to date.