What I'm currently missing is a way to support having the Terraform configuration files in a subdirectory, e.g.:

/project
  /infrastructure
    main.tf
    providers.tf
  /src
    ... (lambda code) ...

When using e.g. sam build --beta-features --hook-name terraform everything from the working directory seems to be copied to a temporary scratch folder, but it is also expected to run this command with your Terraform configuration root (here infrastructure) being the working directory. This way, in the above example, I'm unable to write Terraform configuration that depends on files from src as it is not copied to this scratch folder, e.g., the actual build process.

I saw this parameter but not sure if it's configurable with CLI parameters?

__

Btw: Link to launch announcement should rather be this one, right?

I've had a hard time wrapping my head around what it means for "Native Support for Terraform in SAM CLI" I realize what I think of / what we need is very different than what this change does.

I now think that "Native Support for Terraform in SAM CLI" means that SAM uses Terraform to at least update the Lambda Function code. Not clear if it also means it would deploy the Lambda infrastructure by triggering Terraform.

But in ether case, that's not really what we need / want.

We use Terraform as our IaC but we do not use Terraform to normally deploy the Lambda image (code) to the Lambda function from our dev environment.

Instead we run Terraform only to build out or update infrastructure and all the terraform code is in a directory tree distinct from our Lambda function code.

We currently deploy our Lambda function code as zip images or docker images via our CI/CD pipeline or via some internal tooling. Both deal with the build process (Python, Node or Ruby, but mostly Python), packaging into zip or docker images, and then uploading to the lambda function using AWS CLI/SDK.

So I am wondering if SAM in general or Sam for Terraform can be of use for us? We would love to use SAM in our environment in lieu of our internally built tools for doing the dev cycles of development and testing. Would also love to be able to take advantage of the ecosystem of SAM tooling primarily for the development and testing side of SAM, not the deployment so much. Unless we had a way to connect SAM's intentions of deployment to our mechanisms of deployment.

I love that AWS SAM is heading in this direction. My company requires that we use Terraform for our IaC as they are using Hashicorp's Sentinel for governance. I just found this page after doing a comparison between AWS CDK / SAM and Terraform / SAM, hoping that we could use Terraform / SAM, but it just doesn't feel like its there yet.

Couple of issues that I have run into.

1. There aren't a lot of great examples out there
   I wanted to create an echo endpoint using API Gateway and Lambda that would return the path that a user calls. This requires using the AWS_PROXY integration, which is difficult to navigate by itself, much less in terraform with SAM. These are the resources I had to cobble together to get it working:

• Using AWS SAM with Terraform
  Better together: AWS SAM CLI and HashiCorp Terraform
  Using the AWS SAM CLI with Terraform for local debugging and testing

2. SAM for terraform doesn't seem to support sam local start-api, which seems like a huge miss. Half the reason I used SAM in the past is because of this feature to test my api end to end.

❯ sam local start-api
Error: Template does not have any APIs connected to Lambda functions

When I look at .aws-sam/build/template.yaml, only the CF for the Lambda is there, nothing for the API Gateway.

I really like the idea that Terraform could the common Infrastructure as Code layer with CDK as an option for cloud-native style applications. To that end it would be really nice if CDK supported CDK for Terraform (CDKTF). Perhaps activated with a flag like --beta-features --hook-name cdktf. This would move nicely in the direction of an ideal solution for us. Developers can write simpler modern, cloud-native apps (event-driven architectures, Lambda, API Gateway, Event Bridge, et. al.) in their language of choice and use CDKTF to "synthesize" the CDK to Terraform. Build/CI/CD process would use existing institutional Terraform knowledge, output, security/IAM, etc. i.e. CDK to those that want it, Terraform for all.

I think that the direction is very right. There are probably a few companies that are using TF + AWS in order to be a bit less vendor locked-in.
I did some tests back in April. Looks very promising and it has a potential. One thing is still a blocker for us -> lack of support for Terraform Enterprise and their remote executions and variables.

Even if we switch the execution mode temporarily to Local, then we are missing all the variables’ values that we maintain on TFE.
I tried to export those values and failed to inject them on the execution.
TFE has a good API, so I don’t think it should be a big challenge to integrate with it and start supporting TFE as such. Happy to help if needed, just let me know.

We release the Terraform support in sam local start-api for V1 API Gateway resources in release V1.90.0. Now you can test your V1 API Gateway services that integrate to lambda functions locally. Please let us know if you have any feedback.

Hi @moelasmar,
congrats on reaching GA with TF support.
I tried to validate if you managed to tame the Remote executions (Terraform Enterprise support) but unfortunately sam build command still fails with "Error: Saving a generated plan in currently not supported" .
That is a TF restriction done to keep the potential sensitive details of terraform plan output on the server, not local machine.
https://discuss.hashicorp.com/t/saving-a-generated-plan-is-currently-not-supported/2116/4

Getting the same (as suggested above) via API was also not possible as it requires admin access on the workspace, which is not the common case in bigger organisations.
https://developer.hashicorp.com/terraform/enterprise/v202309-1/api-docs/plans#retrieve-the-json-execution-plan

I have also tried the -skip-prepare-infra command but it does not seem to have any effect.

One thing also struck me - terraform plan is just the delta between code and infra state. What in the case when there are no changes and you just want to attach SAM to an existing TF project. Plan would be empty then. Wouldn't it make more sense to base everything on a state version?
Just ask user for: TF URL, Token, Workspace name/id and simply fetch the content of current-state-version via API? You can even download it without much hassle.