This is a post where I would like to share about the things which I picked up over the course of time which has come really enjoyable writing an AWS CloudFormation template.

Editor : Sublime Text Editor with Neon Theme

I use Sublime Text Editor with Neon Theme to save time and not going mad over the missing { or } during the development phase. Sublime editor highlights the closing or opening of the braces which aids not having to run the counting of [Push & Pop] Compliers’ Stack program for the braces. It is not that other IDEs like Visual Studio or Eclipse or PyCharm are not useful; well actually they all have in fact inbuilt plugins with CloudFormation to deploy directly; but Sublime is light weight and simple. The intellisense like code suggestion in Sublime would really help not having to ignore the long naming styling for easy readability; example : ADInstanceEIP, ADInstanceEIPAttachment wouldn’t be a problem as the Sublime editor would automatically prompt that for you.

To summarize, Sublime editor helps highlighting Opening and Closing { } and has a very good code suggestion and nice color.

Use the File format as JSON

The .json file extension for the CloudFormation template just works fine and we don’t have a hard and fast rule to use the .template all the time. Actually using the .json activates the IDEs to treat the code base with intelligence, syntax coloring and code suggestion prompts.

Prefer Mappings over Parameters

When I started writing the CloudFormation template, I used Parameters where ever possible and when ever possible; there by having the possibility of dynamism in the CloudFormation template. Essentially, that may not be true all the cases. It was more like a thumb-rule to use AMI mappings in MAPPINGS block and rest of them in Parameters.

When I realized there was a very very handful number of times, I actually had used the parameters. When I moved the entities from Parameters to Mappings; I actually started building the Class like structure for the entire stack. It is not hard coding at the same time easy to have all the things that would change in exactly one place and aid rapid copy pasting functionality.

Region Mapping with AZ Dropdown

All the sample templates from CloudFomation library has the region mapping; so template becomes region independent with no additional effort except that you need to ensure the AMI are created (or copied) to the designated regions and those AMIs are placed in Mappings block.

I use the AWS::EC2::AvailabilityZone::Name which is extremely handy during my AWS DR Scenario or DR-like Scenario or DR Drills [ Yes I just coined the term DR-like Scenario 🙂 ] where it prompts the available AZ.

Splitting CloudFormation Templates – Networks Separately, Instance Separately [Nested Stack]

Nested Stacks would be in the must use case where the environment involves several Route Table Routes and/or ACL rules as every single rule is resource in the terminology of the CloudFormation where it is currently maxed at 200 resources. The solution is to separate the Route Table rules in a separated nested template and ACL rules in a different one.

A Resource can wait for dependency of completion after multiple other Resources

There are few cases where you might need to wait for multiple resources to be completed before initiating the new resources creation; this is not required most of the time but during the demo :).

Also the DependsOn doesn’t require usage of Ref i.e. DependsOn : {Ref : “Resource”} but DependsOn : “Resource” or DependsOn : [“Resource”]

Don’t use IDE’s Default format code

I prefer to not use any of the IDE’s default formatting options as IMHO make the code look long if there is anything it make the JSON / JS code look lengthier.