[Exploration] Next steps for the SAM transform

[praneetap]

As we think about where to take SAM Transform next, we are seeking community feedback on what would be the most useful feature. Please tell us via comments, what is your main challenge with SAM? Which of these options would benefit you the most, and in what order of priority?

Feel free to comment on this issue with your ideas/use-cases.

1. Making “AWS::Serverless::*” resources available via the CloudFormation registry (or the Cloud Control API)
2. Support for “AWS::Serverless::*” resources beyond CloudFormation (e.g. Terraform)
3. Support for “AWS::Serverless:*” resources covering more resource types
4. Support for “AWS::Serverless:*” resources that encapsulate higher-level patterns and best practices

[PatMyron]

Number 1 would start with #1133

[Jacco]

I vote 3/4.

One of the most promising projects I have seen recently is https://github.com/awslabs/aws-solutions-constructs which builds on CDK. I think SAM can benefit from a lot of the relations they make between service resources.

Other ideas I have:

• support deploying stacks in/as stacksets (for example for landing zones)
• support deploying as a service catalog product (with version management)
• go one step further than Solution Constructs: add some logic, standardized configurable lambda actions

A lambda implementation essentially always follows the same structure:

• receive some json
• use this json to send some json to some service(s)
• if required return some transformation of these jsons as a response

In a large cloud setup you often need a lot of lambda doing simple tasks:

• custom config -> lambda -> securityhub
• securityhub -> lambda -> JIRA
• rule -> lambda -> report something to s3
• queue -> lambda -> http request
• dynamodb -> lambda -> queue

It would be great to make these steps easier :-) The code would not be code of this actual application business logic but only the code you want to be immutable. The glue between the different services.

[hoffa]

Number 1 would start with #1133

FWIW we've started work on it, see #1133 (comment).

[jplock]

What about extending AWS::Serverless::* beyond the traditional Lambda-based EDA patterns?

Examples:

• CloudFront + S3 for static content hosting (I've been maintaining a ServerlessRepo project called cloudfront-cdn as an example that sets up IPv4/IPv6, optional www redirect support, multiple origins [APIGW and/or AppSync])
• Containers (either AppRunner or ECS/Fargate)