8 Best Reasons to Use AWS Cloud-Formation for Provisioning Your Architecture

Managing your infrastructure as code is one of the key DevOps practices, AWS CloudFormation is your service on AWS to realize it.

I have wide experience using AWS CloudFormation for many cloud migration projects from various services, I need to manage my time efficiently and should not repeat myself. By applying automation in infrastructure provisioning and keeping my architecture as a code, I can save, test, and re-use my work later.

1.It is free and a managed service

You do not pay for using AWS CloudFormation. You pay for the resources you provision as you do when you provision them manually. So, the cost is not a parameter in this comparison.

AWS CloudFormation is a managed AWS service. You do not need to maintain the architecture behind it. This allows you to focus on only provisioning new resources by saving time from maintaining a centralized system for automated provisioning.

2 - You can avoid human errors

I remember my OS classes at the university. At those times, we configured everything manually in Linux, and we often forgot to apply a command when we repeated the same thing. It was a nightmare. You always forget some steps when you do things manually, even if you document them well.

It was not a big issue at my university years as I could retake the class if I had failed (glad that I did not). However, when you have a workload in production, it can become a disaster because you can lose customers, business, or reputation that is far more crucial than the preceding two.

Now you have AWS CloudFormation. You prepare your templates, validate, try, fail, correct in a repeating process until you succeed in your development/test environment. Then you can apply the same template in your staging environment for the last time, and after being sure that it will work, you can apply it to your production environment.

3 - You can keep your architecture as code in your repository

When you use AWS CloudFormation, your infrastructure becomes a template or a collection of templates that can be kept in your code repository.

I sometimes use a dedicated repository for my templates in AWS CodeCommit, but you can keep them alongside with your project in the same repository as a best practice. When you need to remember, review, or revert to your previous architecture for some reason, you can locate it in your repository history.

You can even create a CI/CD pipeline for your architecture using AWS CodePipeline and deploy changes to your AWS environment by Git pushes. Recently, we did this for one of my clients as he needed to update AppSync resolvers and schema more efficiently.

4 - Re-use your templates later to replicate the same environment

I hate repeating myself. Using AWS CloudFormation can avoid this, and you can become more efficient by reusing the work you did before.

Let’s say that you are a startup and need an AWS environment for the development of your new project. You can do it yourself or hire an AWS specialist like me to do the provisioning, or your developer can tell you that she knew AWS and does it herself. But whoever does this, let’s assume that he/she provisions all AWS resources manually using the AWS Management Console. You become happy at that time because your development process goes well. Then, three months pass, and now you need a staging environment. Guess what? You have to repeat every work done before in the new environment as well. Besides, it is a high probability that the errors encountered will be repeated, too. They often come as a package when you do things manually.

Alternatively, whoever provisions your development environment, can prepare an AWS CloudFormation template and use it to create a new stack for your new environment within minutes. You do not repeat or pay for the work done before. Maybe you still pay but not as much as before!

5 - Save costs by deleting unused stacks and re-create them later

Our next benefit is also related to previous ones. Let’s say that you made progress in the development of your application but need to give a break due to some reason. If you use CloudFormation, you can easily take backups, delete your stack and recreate it later when you decide to continue. It saves you money because you will not pay for your resources when they are idle. As it is simple, you will not hesitate to tear them down.

Similarly, you might have a project in production provisioning AWS environments for your clients and need to tear them down after they no longer need them. You can use AWS CloudFormation templates for automating this process, too.

6- Easy to learn if you can read/write YAML or JSON

You might find using the AWS Management Console handy, and I really understand that. When you are trying a new service, AWS often provides a Get Started feature for it, and it is a viable option at the beginning. However, after deciding to use the service, you should switch to AWS CloudFormation templates because of the reasons I listed here, and CloudFormation is very easy to learn.

If you know YAML or JSON, you can start writing your templates right away. Even if you do not, especially YAML is easy to learn. It mainly consists of key-value pairs with some indentation rules.

I started preparing templates in JSON because I was familiar with it as a full-stack developer programming Javascript applications. Later, I found YAML more readable, and today, I mostly use YAML.

7 - Your templates are self-explanatory

While working with a new client for the first time, if the provisioning was made using AWS CloudFormation before, all I need is the template or templates to understand what they have on AWS because templates are self-explanatory.

Also, when I research for some service and if the AWS team provided a reference architecture template, it helps me a lot. I can use it to start trying and can read the contents to understand what they did. A CloudFormation template is a blueprint for your architecture and self-explanatory to everyone knowing how to read it.

8 - It is integrated with nearly all AWS services

When AWS launches a new service, they often provide AWS CloudFormation integration, or they do this soon enough. Besides, AWS has good documentation for supported services.

For example, AWS Serverless Application Model (SAM) is an extension of AWS CloudFormation that simplifies the creation of serverless resources. You can use SAM to define your serverless resources like AWS Lambda functions easily with AWS CloudFormation. CloudFormation has many integrations like this.

#happylearning