This is the post on AWS Lambda Layers I wish I had been able to read at the start.
AWS Lambda Layers are actually extremely simple. A Layer is a zip file, whose contents will be unzipped into /opt/ when the Lambda executes. That’s it.
That can be files, libraries, executables, etc…. My most recent project has one layer providing a Perl runtime and libraries, and one custom layer providing the exiftool perl program. This was on top of a NodeJS 12.x runtime environment. So you get NodeJS and Perl, and of course the exiftool. The perl executable from the layer is at /opt/bin/perl, and the exiftool is at /opt/exiftool, for example.
You can use up to five layers which are applied in order: 1 then 2 then 3, etc…. So overrides go further down in the order.
AWS Lambda Layers do not make your Lambda run, or cold start, any faster. They only make the packaging and management of your Lambda function simpler.
Layers can be versioned and published as new versions. Lambda functions don’t automatically pick up new versions, you have to update the AWS Lambda Layer’s configuration to point to the new version of the Layer. You can do this via the API or the Console.
AWS Lambdas are a powerful tool for Serverless computing. Auto-scaling, stateless, and powerful, there is a lot you can do with a Lambda. Especially now that Lambdas have more compute, memory, and time resources available to them, AND now you can mount an EFS volume from your VPC to your Lambda environment.
If you’d like to talk about ways you might be able leverage AWS Lambda functions in your own application, reach out to us at [email protected]!
