How do I safely update my AWS Lambda functions' runtime from Node.js 12 to Node.js 16?-CodePudding

I recently got an email from AWS detailing the deprecation of Node.js 12. So, I updated the runtime of my Lambda functions by, in the AWS Console, going to Lambda > Functions > [My Function]. In the Code tab, there's a section called Runtime settings. There, I changed Runtime from Node.js 12x to Node.js 16x.

This modification has not broken any of my Lambda functions. However, I'm not sure whether I should also change CloudFormation Templates, or if there's any other requirements for changing the runtime of a Lambda function.

Any help would be greatly appreciated. Thank you!

CodePudding user response：

Did you use CloudFormation to create the Lambda function, and if so, have you continued to use CloudFormation to manage the function over time? If so, you should update the template to use the new runtime.

The premise of CloudFormation is manage your infrastructure as code. Ideally, if you're using CloudFormation to manage you infrastructure, all changes should be done with CloudFormation. Setting aside some special exceptions, the best practice is to update your template, then update the CloudFormation stack and allow CloudFormation to make the appropriate changes to your infrastructure.

Manually updating infrastructure that was originally created by code creates drift: differences between the CloudFormation template the actual current state of infrastructure. Drift can be dangerous. Imagine that somebody makes an important change manually, either in the console or using the AWS CLI or otherwise. Now the infrastructure has a new configuration that you're depending on, but the CloudFormation template has not been updated. Later, you run a CloudFormation update. Now CloudFormation will see that the infrastructure does not match the code, and it will reverse the manual configuration!

So yes, you should update the runtime in your CloudFormation template. You can use the CloudFormation Drift Detection feature to automatically identify drift, which may be wise in your particular case.

CodePudding user response：

For AWS Amplify projects, look for the "Runtime": property in each amplify/backend/function/YOURLAMBDA/yourlambda-cloudformation-template.json file and update it.

It's probably nodejs14.x so you can search for that and just bump it to 16.

This snippet demonstrates settings for Node 16, uses the 'Graviton' processor (can be faster/cheaper), bumps the timeout a smidge, and increases memory:

"Runtime": "nodejs16.x",
"Architectures": [
  "arm64"
],
"Layers": [],
"MemorySize": 256,
"Timeout": 60

You only need to modify the Runtime line.

With respect to "safely", the above is the correct way to update the runtime, and the change will propagate to new 'environments' as you deploy them. If you edit the setting directly via the console, it will (probably) be overwritten the next time you deploy an updated lambda.

Be sure to test your changes in dev just as you would when updating to a new node package. I'm sure it's obvious that switching runtimes (and/or the architecture) can introduce subtle bugs if your code behaves slightly differently when running against Node 16.