AWS CloudFormation best practices

At the beginning when AWS CloudFormation is being looked into first time it might be overwhelming on the sheer amount of options and how a successfully working deployment might be put together.

However, all-in-all, once acclimated it becomes a very useful, very powerful and rather handy to use toolset which is highly recommended to use for workload deployments into AWS. Specifically at the beginning of utilizing AWS CloudFormation it might be faster to just get some deployment done quickly through the AWS Console, the AWS CLI or AWS relevant API.

Certainly the initial invest in time and get to known with CloudFormation to follow a pattern of Infrastructure as Code deployment methodologies might feel to be a burden and would initially take time versus a traditional klick and hack through a Console, CLI etc… However it is worth to do the initial invest to become familiar with CloudFormation usage.

Keep it all clean

Utilizing workload deployments via CloudFormation will help to keep deployments clean. Naming conventions can be taken forward through various accounts and VPCs and will help to avoid to a variety to naming. Furthermore it’ll help to get everything removed alongside a turn down/removal of stack deployment. For example parameters written into AWS SSM Parameter Store, Security Groups, Subnets, VPCs etc – everything which literally would be generated and deployed as part of a stack deployment – can be removed whenever a stack is turned down.

This will not just keep a given AWS account clean but also will help to keep things consistent up to a point where audits would be done much easier, quicker.

Reusable code and templates

While a deployment which would be done through the AWS Console, CLI, API directly would not be able to be just re-used in a different account, VPC or deployment in general taken benefit of AWS CloudFormation templates will tremendously simplify reusability of Infrastructure as Code concepts.
Example: a deployment of a number of EC2 instances into a VPC, with Security Groups, Subnets, EBS volumes and so on defined and described within the CloudFormation template can be just re-used in a different account, VPC and so on – of dependent to the fact that a template would have to be described independently enough by utilizing pseudo parameters and such.

Agnostic to account and regions

AWS CloudFormation provides so called pseudo parameters. Those would not have to be described as they are predefined by AWS already. Parameters such like AWS::Region, AWS::AccountId are just available in any AWS region. Those predefined parameters help to write templates which are agnostic to accounts and regions and help to be able just get focused on the Infrastructure as Code description itself.

Ideally templates should be written in a way that they are agnostic to an AWS account and a region so that a CloudFormation template can be used in various accounts (such like testing, development, production)

Infrastructure as Code

Utilizing AWS CloudFormation literally means to describe the to be deployed AWS infrastructure for a given or to be created VPC in a given region and so on.

Infrastructure as Code (or IaC) basically is a procedure and methodology to create a definition (such like written in JSON, YAML) which simply describes what and how a workload should be deployed.

AWS obviously provides CloudFormation as a framework and toolset help to automate IaC defined deployments.

In the on-premise world tools such like Chef, Puppet, Terraform and many more help to declare and describe a deployment.

Custom resources

AWS improves the tool sets continuously. Therefore frameworks such like CloudFormation get enriched with more and more features which help to describe a to be deployed infrastructure. However, not everything can be described and sometimes so called custom resources would have to be added. An example would be to attach a given ENI or EBS to a certain EC2 instance which would need to be done uniquely where a custom resource based on a Lambda function will help to do what would be desired.

Basically a custom resource would be added when a required resource would not exist otherwise but would need to be created during stack deployment

Export Values

Values generated throughout a stack deployment can be referenced by other resources where they belong to that given stack. However, it’ll become a need quickly to be able to use values outside a given stack deployment. Luckily values can be exported for further usage by other AWS CloudFormation stack deployments.

A very useful and powerful service is the AWS SSM Parameter Store which belongs to AWS SSM (AWS Systems Manager). Values generated throughout a deployment can be written and stored into the AWS SSM Parameter Store easily where they then can be used by applications, via the API, CLI and various software SDKs.

Last but not least

  • Take good usage of the Description field. The description field in the various CloudFormation resource types is not just helpful to read through the IaC description much easier more importantly these description will be seen again alongside the various resource deployments. As mentioned above in this post ‘keep things clean’ – in this case a description field helps to maintain deployments much easier and time to search and audit will be able to be reduced
  • tag, tag, tag … For a number of reasons tagging resources is a key need and not just a best practice but rather something that should be considered as must have. The better tagging is done the better cost assignments, security audits and so one will be able to be done
  • AWS resource and property types reference … super useful and a reference to be able to write templates

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: