SAM vs CloudFormation

The processed template shows what SAM 24 wrote for you. Compare its size with the source, then delete the stack:

wc -l < template.yaml
aws cloudformation get-template --stack-name booknest-sam --template-stage Processed \
  --query TemplateBody --output yaml | wc -l
aws cloudformation get-template --stack-name booknest-sam --template-stage Processed \
  --output text --query 'TemplateBody.Resources.*.Type' | tr '\t' '\n' | sort | uniq -c
lstk --endpoint-url http://localhost:31566 sam delete --stack-name booknest-sam --no-prompts \
  | tail -n 1

32
162
      1 AWS::ApiGateway::Deployment
      1 AWS::ApiGateway::RestApi
      1 AWS::ApiGateway::Stage
      1 AWS::DynamoDB::Table
      1 AWS::IAM::Role
      1 AWS::Lambda::Function
      2 AWS::Lambda::Permission
   - Deleting S3 object with key b5b0ca70ea199b68fed38c3572e08193
   - Deleting S3 object with key 8f8aed38849d0af5775566064028ed40.template
Deleted successfully

Thirty-two lines became 162 and eight resources, including the role, the two invoke permissions and the API deployment whose ID must change whenever the API does. That is SAM's case: less to write and fewer ways to get permissions wrong, plus a local runner. Its limits are the other side: the expansion is SAM's, so a property it does not expose needs a raw resource beside it, and the ServerlessRestApi name and hashed IDs are chosen for you. Use SAM when a stack is mostly functions, APIs and tables, and plain CloudFormation 24 , or the CDK 24 of CDK and IaC Landscape, when it is mostly networks and data stores. sam delete also removed the artifacts it had uploaded, which a plain delete-stack would leave behind.