1 2 3 Lambda (with Terraform)

Ta-da!

Those of you who work with AWS all the time have surely faced the dilemma of managing Lambdas.

What are Lambdas?

Lambdas are "containers" that Amazon manages for you on its own. Depending on the number of invocations, it spins up one or more containers so that requests always get a fast response. What you pay for is the total execution time in milliseconds.

With that quick introduction out of the way, here's Amazon's page that explains better what Lambdas are https://aws.amazon.com/it/lambda/features/ .

Terraform with Lambdas

There are various ways to package and upload Lambdas to AWS, the first of which is creating the zip by hand and then invoking the aws cli to upload the code to the lambda.

This method, though, isn't very reproducible and relies mostly on a manual operation. On top of that you have to manually create all the surrounding resources on Amazon, like the execution policies, the role, the permissions, any environment variables etc.

But I can do that with Jenkins too!

Yes, if you want you can create CI jobs that handle the lambdas by automating all these steps. The problem with managing lambdas this way is that you don't have a single place holding the current state of all the "deployed" lambdas, and it's also not easy to delete and recreate them when needed.

I created a project on GitHub that serves as a base for deploying any lambda, here's the link: https://github.com/nutellinoit/terraform-aws-lambda-skeleton

The process used by this terraform module is the following:

1. You update the lambda_version variable
2. this variable is used as a trigger in a null_resource that takes care of creating the zip of the code, with a file name that depends on the value of the lambda_version variable;
3. this change makes the aws_lambda_function resource get modified through the file name
4. Terraform will then upload the code to AWS again

To do subsequent deploys of the code, you only ever have to touch the value of the lambda_version variable.

Why this workaround?

All the examples you find online, and even the official terraform documentation, use the archive_file resource. The problem is that this resource runs on every terraform run, since it's of type data, and so it creates a new zip. This new zip means the aws_lambda_function resource is always modified.

Why is that a problem?

Because if our lambda is made up of a large number of libraries that are usually ignored with a .gitignore file, we can end up with a partial upload of the code and therefore a "broken" lambda. (I learned this the hard way, and it's not fun).

So by avoiding something that runs on every terraform apply, we get more granular control over updating a lambda.

Example of how to use the module (you'll also find it in the project's README.md):

module "lambda-skeleton"{
  source = "git::https://github.com/nutellinoit/terraform-aws-lambda-skeleton.git?ref=master"
  lambda_version = "1" # change this value to trigger another deploy
  name = "CoolLambda"
  environment_1 = "1"
  environment_2 = "2"
  environment_3 = "3"
}