How to implement region specific configuration for AWS CloudFormation stack and resources

0
votes

Scenario:

  1. We need to create CloudFormation stack with certain set of resources like Lambda, API Gateway, DynamoDB, ElasticSearch etc.
  2. These stacks needs to be deployed in multiple regions, to be more specific 5 different regions like Oregon, Sydney etc.
  3. Each stack has different configuration based on a region e.g. DynamoDB auto-scaling values are different for each region and Lambda concurrency or Instance types for ElasticSearch etc. are region specific.

What we currently doing:

Currently we have a single CloudFormation template with Mappings defined for region specific values. i.e. we are using condition functions like if-else to check current AWS region and based on that we select the mapping for that region.

Problem:

  • As the need grows to support more and more regions the size of mappings also increasing
  • For each new resource getting added we need to update mapping to add the configuration for new resource
  • Supporting multiple regions and resource configurations along with conditions becoming unmanageable

Expectation:

We are looking for a comprehensive solution to support multiple regions using the same CloudFormation template and need to get rid of mappings and find more manageable way to handle region specific configurations.

Any help is highly appreciated.

1
javascriptamazon-web-servicesaws-lambdaamazon-cloudformationdevops
Have you considered using CDK to generate region-specific templates? You might find that the net result is cleaner, more maintainable than one complex template with many conditionals. – jarmod
Thanks. Using CDK is a good option but it will require us to rewrite entire infrastructure which is currently in CloudFormation. For a long term goal we can consider using CDK, but can you suggest something to reduce current plain. – Darshan Ambhaikar
Mappings, while prone to bloat, are fine by themselves. If you don't want to use CDK, take a look at stacksets in combination with AWS Organizations: aws.amazon.com/blogs/aws/… – Oleksii Donoha
If the mappings are a problem, then a non-CDK option might be to decompose the templates just a little and use a template engine such as jinja2 to re-compose the templates with conditional inserts. That might sound complex at first, but it's actually quite straightforward. You'd have one main template then a number of smaller ones and you'd programmatically inject them into the relevant place in the main template, with the relevant values, using normal template features such as {% include %} and passing runtime values in. This way your existing templates would remain largely intact. – jarmod

1 Answers

1
votes

You can use SSM parameters to solve your issue. If you don't know, SSM allows you to store parameters in your AWS environment. The parameters are scoped to each region. The procedure would be:

  1. Create a CloudFormation template with all parameters. Create the stack in each region using the defined values for that region;
  2. Change you current template to read the parameters from Parameter Store instead of the parameter map;
  3. Create your main stack.

You can find more information regarding this feature here.