[Beginner’s guide] Amazon AWS CloudFormation

Deploying on cloud is very very different as compared to traditional IT infrastructures. In cloud, your deployments no longer remain hardware devices, but rather become programmable services.

This provides you with a lot of flexibility and fault tolerance. But has it ever occurred to you what if you wanted to have an infrastructure copied?

Yes, the entire infrastructure!

Or, you want to maintain a version control on your infrastructure. Obviously it’s possible as it has now become nothing more than a collection of various services.

Well, the above advantages and many more requirements are satisfied when you think of your hardware as services. And AWS provides you just the type of flexibility you want.

And it does this by the means of CloudFormation.

AWS cloudFormation is a managed AWS service that helps you to deploy your entire infrastructure as a code (IaaC).

Using this, you can set up your resources continuously and repeatedly without doing all the work again and again.

Now that we know slightly about CloudFormation let’s dive deep into it.

Components of cloudFormation

CloudFormation has two most important components, templates and stacks.

Let’s get on to them one by one starting with templates.

A template is like a JSON or YAML file that lays the blueprint of your entire architecture. This is the document, sort of, that you upload to AWS and it provisions resources.

A template has its own elements, namely:

• A list of AWS resources and their configuration values. Do remember this is the only part that is mandatory in the entire template
• Optional version number. Just as I mentioned earlier, you can apply version control to your architecture.
• Optional list of parameters. Consider them like some variable input values that you want to provide the template at the time of provisioning, eg. IP CIDR ranges.
• Optional list of output values
• Optional list of data tables to lookup static configuration values, like the AMIs as per the region you are provisioning

And once the resources that you’ve mentioned in the template are provisioned, they all form a stack. But do remember that only the resources that are deployed as a part of the same template can be classified as a single unit called stack.

Simply said, stack is nothing but a collection of resources provisioned as a part of the same cloudFormation template.

Change sets

Now comes a very important part of the CloudFormation service, change sets.

So basically when you have deployed an architecture and now you want to make changes to the architecture, change sets come into picture.

It includes an overview of the changes that you intend to make, thereby helping you to check how the proposed changes could potentially affect the already running resources.

And once you execute the change set, only then will the changes be actually made to the resources. However, know that change set in no way tell you whether the stack will be successfully updated or not.

Permissions and security

Permissions and security, again, being the topmost priority of AWS, find their place in CloudFormation as well.

Beginning with IAM, you must have IAM permissions assigned to you to enable you to create, provision, modify, edit or delete resources. Whatever action your template intends to perform, you must have requisite permissions for it.

But AWS services have roles assigned to them, and you can use them too. A Service role is assigned to the template that enables cloudFormation to make API calls to required services on your behalf.

If you have a service role, CloudFormation will no longer need you to have permissions, it will simply execute as per the permissions of the service role.

But, how does it work? Like how do they grant permissions?

When using a user’s IAM permissions, a temporary token is created on the basis of the user’s credentials while in the case of service role, the token is created from the role’s credentials.

Cloudformation template attributes

A cloudFormation template have many attributes. Some of the most used attributes are:-

CreationPolicy

Creation policy makes sure that no resource sends a create complete signal until and unless it has sent a specified number of success signals to the CloudFormation.

DeletionPolicy

It specifies what to do when the stack is being deleted, as to whether to retain a resource or maintain it’s backup

For example you can specify to take snapshots of an RDS instance at the time of deletion.

DependsOn

This attribute tells the CloudFormation that the resource A is dependent on resource B and that you need to have B created before you can go on and create A.

Like in the case of an EC2 instance, you first need to have your custom VPC created only then can you proceed with the EC2 instance.