CloudFormation for multiple parameter files and a single template

0
votes

I am currently storing all my parameters in Systems Manager Parameter Store and referencing them in CloudFormation stack.

I am now stuck in a scenario where the parameters vary for the same Cloudformation template.

For instance server A, has parameters m5.large instance type, subnet 1, host name 1 and likewise server B can have m5.xlarge, subnet 2, host name 2 and so on. These 2 parameters are for the same CFN template.

How can I handle this situation in a CI/CD manner?

My current setup involves SSM Parameter store -> CloudWatch Events -> CodePipeline -> Cloudformation.

1
amazon-cloudformation

1 Answers

1
votes

I am Assuming you use AWS CodePipeline. Each CodePipeline stage consists of multiple stage actions. On of the action configuration properties is the CloudFormation template, but also the The action can be configured to include the CloudFormation template, but also a template configuration can be provided. If you define the server name as a parameter in the CloudFormation stack then you can provide a different configuration for each CloudFormation parameter.

Assuming you define only one server in the CloudFormation stack and use the template twice in your codepipeline, then you can provide a different configuration to both stage actions . Based on this configuration you can decide which parameter in the parameter store you want to retrieve. Of course this implies that your parameter store should be parameterized as well e.g. instead of parameter instancetype you might have parameter servera/instancetype and serverb/instancetype

However I think it is best if you just define the parameter in the Template Configuration file provided to the action declaration. So for example define the parameter instancetype in your CloudFormation template and use two different configuration files ( one for each stack) where the first Template Configuration file might say instancetype: m5.large and the second configuration file instancetype: m5.xlarge. This makes your CloudFormation stack history more explicit, easier to read, and makes the use of the parameter store for non-secrets no longer necessary.