As we mentioned previously, Lambda supports multiple runtimes and allows you to build functions using Node.js, Python, Java, Go, Ruby, and .NET (C# and PowerShell). AWS often adds support for more runtimes (check the latest here: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html), and recently released a feature that allows you to create your own custom runtime. This will allow you to bring your own language to Lambda using the Runtime API. We'll find out how this works in Chapter 6, Going Deeper with Lambda, so before we get ahead of ourselves, let's move on.

When creating a new Lambda function, you choose which runtime to use. You can't change the runtime once it is created – which isn't an issue – there are pretty much no use cases where you would need to change the runtime of a function after it's been created.

For runtimes that Lambda supports, there's a particular subset of versions that are supported. It's important that developers are using modern versions of runtimes that are current with the latest security and vulnerability updates. AWS has the same opinion and would rather not support an out-of-date runtime version along with its operating system and library dependencies. To make sure we are always developing against best practices, AWS deprecate versions of runtimes when they reach a certain stage in their life cycle.

Before starting deprecation, AWS will announce an end of life for a runtime. This is to notify you (via email) that it is about to be deprecated over two phases. The first phase is to remove the ability to create new functions using the deprecated runtime. You can still update deployed functions that use that runtime, but you can't create new ones.

The second phase removes the ability to update as well. There is a loosely defined third phase that Lambda may choose to use, and that is removing the ability to invoke the function altogether. There will be efforts to contact anyone in that situation prior to retiring the runtime.