What to do about the Lambda Node.js 20 end-of-life email
The "[Action Required] AWS Lambda Node.js 20.x end-of-life" email in plain terms - what ends on 30 April, why the September deadline is the one that bites, and how to find and upgrade every affected function.
Another entry for the inbox of worrying AWS emails:
[Action Required] AWS Lambda Node.js 20.x end-of-life
The short version: your functions will keep running, on 30 April and after it. What ends is the care - AWS stops patching the Node.js 20 runtime and stops supporting functions that use it, because the Node.js community itself retires version 20 the same day. The fix is usually the smallest job in this genre of email: point each function at a newer runtime, test, and redeploy. For most Lambda functions the code needs no changes at all. The part that deserves the attention is finding every affected function before the later deadlines arrive, because this email has three dates in it and the last one has teeth.
What the email actually means
Support ends in stages. From 30 April, no more security patches or technical support, and the runtime disappears from the console's menus. From 31 August, no new functions on Node.js 20. From 30 September, no updates to existing Node.js 20 functions - and that's the deadline that matters, because it means the day a bug needs fixing in production, you can't deploy the fix without doing the runtime upgrade at the same time, unplanned, mid-incident. An unsupported runtime that hums along quietly is a manageable risk; being unable to ship a one-line fix to your own function until you've done an upgrade you didn't schedule is how a small problem becomes a long afternoon.
Finding every affected function
The upgrade is rarely the hard part - the inventory is. Lambda functions accumulate: across accounts, across regions, behind API Gateways, glued to S3 buckets and cron schedules, written by someone three years ago and not touched since. The email only counts functions where the latest version uses Node.js 20, so published versions can hide affected code too. AWS gives you a one-liner to list them, run per region:
aws lambda list-functions --region us-east-1 --output text --query "Functions[?Runtime=='nodejs20.x'].FunctionArn"Trusted Advisor will also flag deprecated runtimes across an account, and the 'Affected resources' tab of the AWS Health Dashboard lists what AWS emailed you about. Between the three you can build the full list, including the functions nobody remembers deploying.
The upgrade itself
For a typical function this is the gentlest upgrade AWS asks for: run the code and its tests on the new Node version locally, change one line in the infrastructure config (or the console setting, for functions managed by hand), and deploy through your environments in the usual order. Dependencies occasionally need a bump, but Node's own compatibility between recent versions is good and most functions go through untouched. Go to the newest runtime Lambda offers rather than the next one along - each Node version gets this same email roughly two years after the last, and the bigger jump costs nothing extra while buying the longest quiet spell before the next round.
If the list from the inventory step is long, or nobody's sure what some of the functions do any more, that's the actual project - and it's a familiar one. If you'd like a hand working through it, get in touch.
Also in this series: the RDS MySQL 8.0 end of standard support email and the Elastic Beanstalk PHP 8.2 platform retirement email.