Native support for Terraform in SAM CLI (now in Beta)

[praneetap]

Terraform Support

Recently we added native support for CDK applications in the SAM CLI - you can see our launch announcement blog post and download the beta version of the CLI.

We would like to collect the community’s feedback on whether we should add native support for Terraform in the SAM CLI. Terraform users would be able to use the SAM CLI’s build, package, local invoke, and start-api commands. The build and package commands make it easy to create deployment packages or OCI images that are ready to be used in AWS Lambda. The local invoke and start-api commands makes it easy to emulate AWS Lambda and API Gateway in local Docker container for testing purposes.

With this change, the SAM CLI would parse HCL definitions to understand functions and APIs that can be locally tested and built. The SAM CLI would not write HCL, translate to, or force the use of CloudFormation. Deployments should still be performed using the Terraform toolkit.

What feedback are we looking for?

1. Is this something the community is interested in? **Vote with 👍🏽 **.
2. The sam build, package, and local invoke commands rely on the CodeUri property of a function resource pointing to a local path where the source code for the Lambda function is stored. The SAM CLI automatically pulls dependencies, compiles if necessary, and prepares a deployment package for AWS Lambda. The package command today produces an output template that contains the S3 URL for the deployment package the SAM CLI prepared. How would you like this work with Terraform?

[Vlaaaaaaad]

The sam build, package, and local invoke commands rely on the CodeUri property of a function resource pointing to a local path where the source code for the Lambda function is stored. The SAM CLI automatically pulls dependencies, compiles if necessary, and prepares a deployment package for AWS Lambda. The package command today produces an output template that contains the S3 URL for the deployment package the SAM CLI prepared. How would you like this work with Terraform?

The "usual" way of doing Lambdas with Terraform is to use a module that abstracts the Lambda build and IaC boilerplate. A great module is serverless.tf's terraform-aws-lambda module. I'd love to see sam-beta-terraform integrate with that, maybe as an alternative to the current package.py script used to do builds? Would that make sense @antonbabenko?

I am imagining a repo like this:

.
├── template.yaml # the SAM config file for local work + Terraform integration
├── entrypoint.py 
├── functions     # the Lambda functions code
│   ├── one
│   │  ├── one.py
│   │  └── test_one.py
│   └── two
│      ├── two.py
│      └── test_two.py
├── deploy        # the Terraform IaC code
│   ├── dev
│   │  ├── lambda.tf
│   │  ├── dynamodb.tf
│   │  ├── alb.tf
│   │  └── main.tf
│   └── prod
│      ├── lambda.tf
│      ├── dynamodb.tf
│      ├── alb.tf
│      └── main.tf
├── requirements.txt
├── README.md
└── LICENSE

As a developer, I would clone the above repo, run sam local invoke and sam local start-api and I could instantly start working on the Lambda code! I would expect sam local start-api to support API Gateways defined both directly and through Terraform modules.

In the CI/CD pipeline, terraform plan and terraform apply would call out to sam build (and maybe also to sam deploy to upload the package to S3) and use the resulting package.

[antonbabenko]

@Vlaaaaaaad I like the idea of bringing an alternative approach to the package.py with the main goal to make the module independent from Python and cross-platform right away.

(When we were making the terraform-aws-lambda module module, sam build was far from feature-rich. Since there is support for running Lambda functions from a container image, I recommend using that instead of relying on package.py which is not perfect. See container-image example.)

Terraform has its own resource lifecycle management which is carefully implemented as a part of the terraform-aws-lambda module. For example, rebuild the package and redeploy it only if something in dependencies changed. This does not sound like an easy task for me to even describe how Terraform & SAM should share the lifecycle management since resources can be cross-linked between SAM template and Terraform code.

As a developer, I like to have a tool that does comprehensive infrastructure management and serverless application deployments. terraform apply is it.

Yes, there is more to be done to improve the developer experience but it is not related to SAM CLI or this issue.

[Vlaaaaaaad]

Terraform has its own resource lifecycle management which is carefully implemented as a part of the terraform-aws-lambda module. For example, rebuild the package and redeploy it only if something in dependencies changed. This does not sound like an easy task for me to even describe how Terraform & SAM should share the lifecycle management since resources can be cross-linked between SAM template and Terraform code.

Good point!
I was imagining sam build generating some kind of hashed artifact that can safely be used by Terraform. Having unnecessary deploys because of packaging would definitely ruin the dev experience. @praneetap any chance this would be an option?

[praneetap]

@Vlaaaaaaad @antonbabenko Thank you for the feedback - this is helpful. To help us prioritize and make the integration decision, do you know how many Lambda users rely on the terraform-aws-lambda module? Could we get their +1s here if you are connected to the community?

[antonbabenko]

@praneetap Let me share some statistics for the terraform-aws-lambda module.

1. Terraform Registry page says Total provisions: 11.5M on November 2022 (April 2022: 4.9M). This is more than all other Lambda modules published in the Registry combined.
2. GitHub insights for the repo says: 457,925 Clones, 86,982 Unique cloners during the last 14 days.
3. Some users use private forks of the module or don't use Terraform Registry (e.g., using terragrunt).

I will share this issue with the community if anyone wants to upvote it.

[debragail]

The only issue is that my projects use GraphQL, so sam local start-api isn't as helpful since i'm using AppSync and in some cases the serverless framework which hosts its own Apollo server.

[praneetap]

@debragail thanks for your input! We just published our open roadmap that proposes to address your issue in a couple ways - Cloud based development or building emulator plugins. Take a look and upvote the one that would work well for you.

[moelasmar]

Hello All,

I am trying to collect some data to know if the following pattern (defining multiple lambda functions and lambda layers using the count property, and t set the function.layers property to the corresponding layer using count.index) is commonly used pattern or not :

resource "aws_lambda_layer_version" "layer" {
  count = 2
  filename   = var.layers_source_code[count.index]
  ....
}

resource "aws_lambda_function" "get_country_languages" {
    count = 2
    filename = var.functions_source_code[count.index]
    ...
    layers = [aws_lambda_layer_version.layer[count.index].arn]
}

Also, if the following pattern (use conditional expression to set the Lambda function layers property) is commonly used

resource "aws_lambda_function" "get_country_languages" {
    count = 2
    filename = var.functions_source_code[count.index]
    ...
    layers = var.env == "prod" ? [aws_lambda_layer_version.prod_layer.arn] : [aws_lambda_layer_version.beta_layer.arn]
}

I appreciate if you can share with us form your experience with using terraform if you used any of these patterns in any of your terraform projects.

[antonbabenko]

@moelasmar Here are my 5 cents into this.

1. Using count is less flexible for cases where an order is not critical, so users should prefer to use for_each instead.
2. Using conditional expressions to set Lambda layers property is possible but I don't think many users would do it this way. An alternative solution would be to use try() like this - layers = try([aws_lambda_layer_version.prod_layer.arn], [aws_lambda_layer_version.beta_layer.arn], [])

"commonly used pattern" is a rather tricky thing to ask because if it is valid syntax, there are users who write it like this, and any tool/solution should support it.