AWS::CloudFormation::Stack parameter type, and/or AWS::SSM::Parameter::Value<"arbitraryString"> #141
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Community Note
Tell us about your request
What do you want us to build?
A way to have a CloudFormation parameter type that represents an existing, deployed CloudFormation stack. Possibly have contracts/interfaces so that a template can reference an existing stack that has a set of agreed-upon Outputs/Exports that it can reference via ImportValue.
The main idea is: right now with NestedStacks you can have a single template that deploys many stacks. What we most often find ourselves doing the opposite: having many stacks that reference a single stack that has no beforehand knowledge of whatever templates will reference it in the future.
Example: you deploy a VPC stack, then can deploy multiple different stacks (ALBs for example) that reference that VPC stack without the VPC stack knowing anything about them. You deploy multiple ASG stacks that reference a single ALB stack and a single VPC stack. You deploy multiple ECS service stacks that references a single VPC, ASG/Cluster and ALB stack.
This helps with reusability across different workloads within the same customer, and reusability between different customers by keeping the templates loosely-coupled, and each "parent" stack loosely-coupled to whatever stacks end up attaching to it that it knows nothing about in advance.
Tell us about the problem you are trying to solve. What are you trying to do, and why is it hard?
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now?
What is the impact of not having this problem solved? The more details you can provide, the better we will be able to understand and solve the problem.
Using the Import/Export feature we often find ourselves referencing values exported from existing stacks in our templates. We export the values as {stackName}- and ask the user for {stackName} as an input parameter in the stack that needs to import. Example: template that creates an ECS cluster and exports the name of the cluster as ${AWS::StackName}-clusterName, template that takes the name of the ECS cluster stack as a {pClusterStackName} parameter and imports the name of the cluster as {pClusterStackName}-clusterName.
In our most common example, we have a VPC template, an ALB template, an ASG/Cluster template and a "Workload" template which is either an application deployed on EC2 (includes Target Group that attaches to the ALB via a Custom Resource Lambda retrieving a unique Priority value for the Listener Rule, a CI/CD pipeline using CodePipeline + CodeBuild + CodeDeploy, installs the application on the EC2 via CodeDeploy) or an ECS Service (creates the CI/CD pipeline using CodePipeline + CodeBuild + ECS standard deployments, attaches to the Load Balancer and ECS cluster).
We use the exact same templates to deploy the same infrastructure to hundreds of different customers for an arbitrary number of different workloads per customer, allowing the customer to re-use the same VPC stack for multiple ALB stacks, the same ALB stack for multiple ASGs / ECS clusters, the same workload stack to deploy several applications on a single ASG or multiple ECS services on a single ECS cluster, and allowing customers to basically deploy multiple workloads on their accounts independently by simply copy-pasting the same templates and filling in the required parameters, attaching to pre-existing resources without the complexity of nested stacks / modifying the nested stack template / copy-pasting resources across template files.
Are you currently working around this issue?
How are you currently solving this problem?
Right now we type all these parameters as String.
What is the expected behavior with this new feature
Please include some code examples showing how this feature can be used.
It would be great though if there was a way (or a workaround) to have these as a AWS::CloudFormation::Stack parameter type to show users a dropdown list of deployed stacks in the region.
We tried working around this using SSM parameter types, although you can do ssmParameterValueAWS::VPC::Id you unfortunately can't do something based on completely arbitrary SSM Parameter values like AWS::SSM::Parameter::Value<"customDataType.CloudFormationStack"> (which would take as input the name of any parameter whose string value is "customDataType.CloudFormationStack"). This would be great because a stack called "my-ecs-cluster" could create a parameter whose name is "my-ecs-cluster" whose value is "customDataType.CloudFormationStack" and in the template where I need to reference it, I would reference it as AWS::SSM::Parameter::Value<"customDataType.CloudFormationStack"> and CloudFormation could validate it. Plus, deleting the first stack ("my-ecs-cluster") would also delete the parameter.
Additional context
Anything else we should know?
Having a meaningful dropdown implemented at the CloudFormation web interface level is nice but not super important to us: having the ability to use the types within CloudFormation without getting a
Parameter validation failed: parameter type <x> does not existwould be great as we could leverage it within external scripts / automation / re-implementation of the CloudFormation web interface to deploy / update stacks that does our custom validation / enrichment.Right now we are thinking about highjacking the ConstraintDescription property to do our custom types.
If there is any other approach that you suggest we could use to achieve the same result, we are happy to hear any suggestions!
Attachments
If you think you might have additional information that you would like to include via an attachment,
please do - we will take a look. (Remember to remove any personally-identifiable information.)
AWS::NoValue
The text was updated successfully, but these errors were encountered: