Comparing SAM and Terraform is like comparing apples and oranges. Comparing Terraform to CloudFormation is more appropriate, and Terraform wins in terms of verbosity there every time.

SAM generates CloudFormation templates/stacks, which create your AWS resources. Serverless generates CloudFormation templates/stacks, which create your AWS resources.

Related: I wouldn't recommend deploying raw lambda's without a framework. The development workflow really sucks without one. Use SAM or Serverless.

> Comparing Terraform to CloudFormation is more appropriate, and Terraform wins in terms of verbosity there every time.

Nope.

Is SAM itself the end game or does it create some other code (like Cloudformation)?

The reason I'd be reluctant to use it without thoroughly being it is that I don't like using any 3rd party monster suite of modules. I've been bitten by that a few times. You're at the mercy of the 3rd party to continue updating and supporting the modules. On top of that, it may not support a particular user case you want to implement. And it's almost worse if it does, because that likely means that it's no longer a simple wrapper around raw terraform resources, but a huge complex beast.

In this case, I don't think the author necessarily expects the user to directly user his code. It is a set of examples. The modules themselves are very simple (really just one or two raw resources with vars and outputs)

SAM is a tool created by AWS.

It's a set of custom resources plus some CloudFormation macros that expand to CloudFormation templates.

It's also a bunch of scripts and utilities that help with the packaging and deployment.

At the end of the day you can use it to generate the final CloudFormation template and run that manually, if you want.

Problem with SAM is having to deal with one more tool.

But also, maybe even important, it makes things less transparent. I want to be able to refer to the original CloudFormation docs (even when using Terraform) without "translating" every time.

I agree that using SAM can be convenient for standalone lambda functions. However, in the context of a larger AWS configuration, where your integration points are already in defined in terraform, the cost of using SAM for these is breaking the invariant that "all our AWS resources are defined in _TOOL_ (in this case, _TOOL_ is terraform).

The verbosity is frustrating, but largely ignorable. Having to go back to string references of AWS references defined in different sources of truth is a maintenance nightmare, IMO