Have you ever felt defeated by the AWS Console? Ever spend your day clicking through 20 screens in the AWS Console just to create one EC2 instance? And then you get frustrated when you input the user data incorrectly and so you click through another 20 screens to fix it? If this sounds like you, then you deserve to be compensated. 

Sadly, I can’t compensate you but I can recommend you use AWS CloudFormation. 

That’s because creating resources manually is time-consuming and often error-prone - and so you’d want to automate this process as much as possible. You may be thinking “Well, I can just use the CLI to do this” and while you can automate the creation of AWS resources with CLI or API calls, updating those resources would still be mostly manual.

By using CloudFormation, you can automate the creation, the updating, and the deletion of your infrastructure and its configurations all in one place. So instead of writing shell scripts and writing your own logic with AWS API calls, you can write your infrastructure as code declaratively using CloudFormation. 

So if you’re sold on using CloudFormation at this point, you’ll first begin by defining your infrastructure in a CloudFormation template. A template is written in either JSON or YAML format and uses a specific structure to document all of your AWS resources and their configurations. 

The cool thing about defining your infrastructure as code, is that you can apply the same best practices you use for your software development process to the development and deployment of your cloud infrastructure. That means you can use code versioning tools like Git or SVN to keep track of modifications to your templates. You can use virtualized tests and apply continuous monitoring. And you can even deploy your CloudFormation templates through a CI/CD pipeline. 

The benefit of this is that you reduce the number of errors in your templates and can easily redeploy templates to create multiple instances of your infrastructure.  This is helpful when you have multiple environments, such as dev, test, staging, and prod and you need to quickly stand up identical versions of these environments. 

After you’ve finished creating your template, the cloudformation engine will act as a function, take your template as an input, and spit out what is called a stack as the output. A stack is a collection of AWS resources that you can manage as a single unit. 

Each CloudFormation stack has a unique name and a linked template. When you create a new stack, you can then check the live status of your infrastructure deployment and view your newly created resources, or even delete the stack if your resources are no longer needed. 

It's important to keep in mind that CloudFormation checks if each stack resource is properly created and configured. If any one resource in the template cannot be created, CloudFormation rolls back and destroys all created resources by default. This default behavior ensures that stacks are “all or nothing” - meaning stacks are either created fully, or destroyed fully, so that you don’t have to worry about tracking down any stray resources CloudFormation created and deleting them yourself. 

While CloudFormation is available for most AWS services, it does not support all of them. However, Amazon is constantly updating their list of AWS supported resources and operations monthly. If there’s a service CloudFormation doesn’t support that you need coverage for, you can check out the CloudFormation Public Coverage Roadmap github, which is as the name suggests, a public roadmap focused on upcoming additions to the CloudFormation service. 

In summary, write your infrastructure as code in a template using YAML or JSON, upload the files to CloudFormation using the console, API, or SDKs, and CloudFormation will create your resources. No more point-and-clicking through the console.