AWS Lambda Node 8.10 End of Life

{{text-cta}}

AWS Lambda will end support for Node 8.10

If you’re using AWS Lambda functions, there’s a chance that you recently got an email about Node 8.10 reaching the end of its life. It’s clear and concise, but a little short.

In this article, we’ll elaborate on a few of the main points, and then suggest some coping strategies that go beyond sticking the email in Trash and hoping that nothing breaks.

First, the email:

Hello,

We are contacting you as we have identified that your AWS Account currently has one or more Lambda functions using Node.js 8.10, which will reach its EOL at the end of 2019.‍

> What’s happening?

The Node community has decided to end support for Node.js 8.x on December 31, 2019 [1]. From this date forward, Node.js 8.x will stop receiving bug fixes, security updates, and/or performance improvements. To ensure that your new and existing functions run on a supported and secure runtime, language runtimes that have reached their EOL are deprecated in AWS [2].

For Node.js 8.x, there will be 2 stages to the runtime deprecation process:

1. Disable Function Create – Beginning January 6, 2020, customers will no longer be able to create functions using Node.js 8.10

2. Disable Function Update – Bginning February 3, 2020, customers will no longer be able to update functions using Node.js 8.10After this period, both function creation and updates will be disabled permanently.

However, existing Node 8.x functions will still be available to process invocation events.

> What do I need to do?

We encourage you to update all of your Node.js 8.10 functions to the newer available runtime version, Node.js 10.x[3].

You should test your functions for compatibility with the Node.js 10.x language version before applying changes to your production functions.

> What if I have issues/What if I need help?

Please contact us through AWS Support [4] or the AWS Developer Forums [5] should you have any questions or concerns.

What does this email mean, and why did I get it?

The TL;DR is that the Node community decided to collectively stop supporting Node 8.10 on December 31st, 2019, so AWS is disabling the creation of Lambda functions that rely on it. This is to ensure that it services are stable and secure, and that all of its users take advantage of the latest Node features.

This means that you got this email because somewhere you’re using a Lambda function that depends on Node 8.10.

I use Lambda with Node 8 - what do I do now?

‍

You’ll need to check your Lambda function creation scripts (or definitions, if you’re using a platform such as Terraform or Serverless) to find all Node runtime declarations that use Node 8.

You have a couple of options for finding all of the problematic declarations here, depending on the size of your codebase and how many different repositories you have.

‍

1 - Search manually

If you only have one or two small repositories and just a handful of Lambda functions, it would probably be most efficient for you to search your codebase manually. GitHub’s search repository feature is great for this, and so is VS Code’s project-wide search function.

However, if your codebase is larger and contains many functions within different repositories or even different organizations, you’ll run into two issues with the manual approach: finding all of the function runtimes may prove laborious, and you’re also prone to missing some of them here and there (which then leads to the aforementioned security vulnerabilities, bugs, etc.).

In this case, the best way to go about it is to use tools that allow you to find all of the problematic declarations. Tools like Datree.

‍

2 - Search using Datree

Datree has a powerful feature that you can tailor to find Node 8.10 declarations with just a couple of clicks - it's called the Properties Explorer. I'm not going into details on how to use it - it's quite simple to use and more importantly, scalable.

{{text-cta}}

How to migrate

Of course, once you find the culprit(s) it’s an easy enough matter to increment the Node runtime version. And luckily, there aren’t any real breaking changes or gotchas with this upgrade that have been widely noted, unlike the upgrade from Node 6 to Node 8.

Two things I can recommend you do to be extra cautious whenever you’re performing a dependency upgrade to Lambda functions (these steps are generally applicable to dependency upgrades in other situations as well):

First, read up on the changes that the dependency’s new version introduces; for your reading convenience, I’ll link you to an article on the changes from Node 8 to Node 10 here.

The other thing you should do is manually deploy a completely new, non-production version of your function with the new dependency enabled and test it before you cut everything over.

This is especially important to do after you’ve passed cutoff dates for creating or upgrading functions with a specific runtime, because if you update everything in one go and discover that the new runtime’s version breaks your functions, you’ll have no way to revert back to the working runtime.

‍

How long can I procrastinate?

‍

As the email mentioned, the two key dates to keep in mind are:

• January 6th, 2020: you can’t create new Node 8.10 function
• February 3rd, 2020: you can no longer upgrade Node 8.10 functions.

So technically, you can procrastinate indefinitely, because existing functions will continue to work going forward.

‍

Keep your code secure

However, in practice, it’s really best to update as quickly as possible. As with most end-of-life procedures, the Node 8.10 EOL means that this version of Node will completely cease to be updated.

Security vulnerabilities in Node 8.10 that may be exposed after December 31st will not be addressed, and bugs that are found will not be dealt with. Instead, fixes and updates will be implemented in later Node versions, if and where necessary.

‍

Using Datree to migrate

‍

As mentioned earlier in this article, it’s possible to use Datree to find deprecated Node 8.x runtime environment in your code base. Not only is it possible to find a specific version of a Node runtime within Lambda function declaration files, but you can also define your own custom rules or choose from a variety of other predefined ones to gain visibility into your code in a huge range of scenarios.

This is how it works:

‍

Give it a try here. Datree is free for up to 5 developers and indie open source projects. Good luck!