e-Zest members share technology ideas to foster digital transformation.

AWS CloudFormation Use Case

Written by Aniruddha Jawanjal | Mar 4, 2014 5:24:54 PM

What is AWS CloudFormation?

AWS CloudFormation gives developers and system administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion.

You can use AWS CloudFormation’s sample templates or create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. You don’t need to figure out the order for provisioning AWS services or the subtleties of making those dependencies work. CloudFormation takes care of this for you. After the AWS resources are deployed, you can modify and update them in a controlled and predictable way, in effect applying version control to your AWS infrastructure the same way you do with your software.

You can deploy and update a template and its associated collection of resources (called a stack) by using the AWS Management Console, AWS Command Line Interface, or APIs. CloudFormation is available at no additional charge, and you pay only for the AWS resources needed to run your applications.

So in short, AWS CloudFormation is Infrastructure as Code – Readable, Reusable and Reviewable.

How does it work?

AWS CloudFormation works on the concept of stack which enables you to create and delete related AWS resources together as a unit. You define the characteristics of stack parameters, mappings, resource properties, and output values using a template (a JSON-compliant text file). You can write your template from scratch, or start with one of the example templates provided by AWS. You can use a number of AWS products with AWS CloudFormation, such as Amazon EC2, AWS Elastic Beanstalk, and Amazon RDS.

[one_third last="no"][/one_third]

[two_third last="yes"]

Why do we need it?

We need same architecture for Acceptance, Production and Test Environments. To create that, we need to carry out following and many more activities:

  • Launch Instance
  • Create LoadBalancers
  • Attach Instance to those LB’s
  • Make Required Installations
  • Create and Configure Security Groups
  • Create RDS and configure it’s EC2 Security Group, DBParameter Group, DBSubnet Group, DBSecurity Group
  • Create AutoScaling Group

[/two_third]

And believe me; we haven’t really talked about creating S3 buckets, setting permissions for them, configuring LB Listeners and Healthchecks, attaching Tags to all these resources. We also haven’t given a thought to bunch of other services and configurations that we need to use in architecture and it is very hectic indeed. So, it’s a very complex phenomenon and chances for errors are very high. What if you miss something?

Complexity only increases as,

  • You need to manually check every resource used in that architecture
  • Take the shell login to every server used in that architecture

Still, there could be loopholes in the created infrastructure, as AWS doesn’t provide anything like Centralized Management of Application specific architecture.

AWS CloudFormation Template is a Simple JSON file which works as a powerful tool to make all these things manageable. Template (JSON) specifies what resources you need; AWS CloudFormation powers you with provisioning of the resources in an orderly and predictable fashion.

How would you fortify it further?

Further, this can be made even better by integrating AWS CloudFormation with Puppet, an efficient system administration tool which works as a great solution to manage the dynamic infrastructure in AWS Cloud. You can automate the provisioning and orchestration using puppet and few more proven tools such as Nagios, Tomcat, Subversion and CloudInit. You can bootstrap the instance by configuring and managing the installation of Nagios, Tomcat, subversion, puppet-client and everything else that you need without taking the shell session at boot time.

Reduce the Rework:

Once the CloudFormation script is ready for one application we can then reuse the part of JSON code we’ve designed for prior applications as they follow the same three tier redundant architecture. Due to this we can reduce the time required to create our favorite architecture.

Follow the best practices

It is recommended to use security group ID instead of IP to define the security group of every application. In manual way, it was kind of difficult to implement it, but in CloudFormation we have defined all these changes in “Mappings” section of template which has made it very easy to implement. We cannot define database username and password in a Template for security purpose; so, we can declare reference to such data in “Parameters” section and can pass the required arguments using CLI or AWS CloudFormer tool.

Something is still missing

In one of our projects, we automated most of the tasks while creating instances but CloudFormation is not a perfect way yet. One notable drawback is that we cannot give reference to security groups which are created in same template. AWS Developers are already working on this problem and hopefully we’ll have the solution for this problem too. There was another problem of loading events while creation of CloudFormation stack but it’s now solved in new AWS CloudFormation console.