If you’re using AWS CloudFormation you might have come across clouds-aws. If not you might want to have a look at it on GitHub.

It makes managing CloudFormation stacks from the shell fairly easy. It keeps a local representation of the stack as a Template (JSON or YAML) and a YAML-file holding the parameter values for the stack.

Until now an update to an existing stack had to be performed in the dark, meaning that there was no possibility to dry-run or predict a stack update before going for it without a safety net other than the built-in rollback capability.

The new feature introduced in 0.3.8 brings now change sets to the game allowing to stage a stack update and inspect the changes in detail before actually executing the change.

To get clouds simply run pip install clouds-aws. You can then dump an existing stack with clouds dump <stack name>, then edit the stack and create a new change set with clouds change create <stack name> <change name> which will print out an overview of the changes.

If you need more detail you can inspect the full detail AWS API returns for the change you can describe the change in either YAML or JSON format: clouds change describe --yaml <stack name> <change name>.

When everything is to your liking you execute the change with clouds change execute --events <stack name> <change name>. The –events in this example will poll for stack events until the stack reaches a stable state.

Adding a subscription to an SNS topic in CloudFormation is easily done with a few lines:

But that’s actually not enough. While creating a subscription in the AWS Console is a single step it implicitly creates a Lambda permission for SNS to invoke the function. This needs to be added as a separate resource in CloudFormation:

This will allow SNS to successfully invoke the function.

If you send a JSON message to your SNS topic that will be encapsulated in the event sent to Lambda (as JSON) and you will have to unpack it in your function like in this example for node.js runtime:

Wanna know whether your ELB has at least one instance in service or not?

Just add a CloudWatch Alarm to your ELB and have it send status changes to SNS (from where you can route it to whatever notification system you’re using).

The following template will create a CloudFormation distribution with an AliasRecord pointing at it. It assumes your origin is already up and running. You don’t want to have the origin and CloudFront in the same stack anyways.

In order to be able to properly diff and read your CloudFormation templates you want them to be in a harmonised shape:

  1. Validity check and indentation
  2. Apply some regex search/replace transformations to improve human readability

This can be done on the shell: nice-cf.py < template.json > beautified.json

Or in vim using a keybinding:

This is the nice-cf.py Python script used to apply the transformations to the template: