Support zipfiles in addition to single-file templates

[benbridts]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request

Allowing a stack to be created from a zipfile, which can contain additional template snippets (normally used by Includes or Nested Stacks), would allow developers to deploy CloudFormation stacks without needing to orchestrate deployments or build multi-step ci/cd pipelines for resources that are always deployed together.

Tell us about the problem you are trying to solve. What are you trying to do, and why is it hard?

Currently there is a very steep cliff between working with one template (you only need a text editor) and combining multiple templates in one stack (you need to upload things to S3, pass them as parameters, make sure updates to the snippet trigger a stack update, handle race conditions, ...).

Are you currently working around this issue?

Currently this is always a multistep process:

1. Upload a thing to S3
2. Have a way to pass the s3 URI (eg with a parameter or resolve)
3. Update the template and hope everything is in sync

What is the expect behavior with this new feature

It would be nice if there was a way to upload a template and its related resources in one zip file, and use something like local://path/to/file.yaml instead of s3://bucket/object.yaml.

Additional context

This would be useful for:

• Fn::Include: This is probably the best example, as everything stays within the same Stack Update anyway
• AWS::CloudFormation::Stack: for the TemplateURL
• AWS::CloudFormation::StackSet: for the TemplateURL

There are some future expansions to this, like allowing to "inline" modules. I wouldn't want this for ResourceTypes or Hooks (as they have more dynamic output). There might also be a use case to support any resource that takes an S3 URI (similar to how SAM CLI supports this).

[benbridts]

Some extra notes:

• It might make sense to only accept one or only a few "root" template(s) in a zip file (eg. only template.yaml and template.json, and throwing an error if both exist)
• We don't want to confuse SAM, so it's probably better to use local:// or file:// instead of assuming that something is a path if it does not start with s3://.
• While technically it could be possible to have parameters (!Sub "local://configuration/${Environment}.yaml") or conditions (!If [UseLocalFile, 'local://...', 's3://']), I think it might make sense to not support that (or not support that in the initial version)

[benbridts]

More background: With the current version of Include, there are some limitations (twitter thread)

Maybe there should also be something like or !IncludeSub [filename, ...] which behaves like !Sub, but gets the String from a file instead of being defined inline

[benkehoe]

I think the longer term answer is here is convergence with CDK's cloud assembly format.