Working with modules in Terraform is a better experience. First of all, a large number of publicly available modules can be used for implementing your infrastructure stacks. This reduces the development and maintenance effort and you can get started in no time. Secondly, the tooling is much better integrated with external modules as you can see all changes as part of the terraform plan command, which is similar to what a change set does.
To summarize, both tools have their unique strengths, which could be more or less important for your specific use case. However, if you are just getting started with hosting your workloads on AWS, and foresee large -scale deployments becoming a reality in the near future, I would recommend going ahead with AWS CloudFormation. Vendor lock-in is commonly discussed as a drawback with this service, but I’d say that applies equally to using a third- party tool from another company. It is beneficial to use the right tool for solving the right problem, even if it comes down to using different IaC frameworks for efficiently managing resources across different cloud providers. Later in this book, we will cover some enterprise-grade CloudFormation deployment frameworks that have been used by many companies already.
So far, we have covered a lot of theoretical details and I am sure it would be a great experience for you to see the CloudFormation service in action. We will use a full-fledged infrastructure rollout to host an application in the AWS account. Let’s get our hands dirty.
Hands-on deployment with CloudFormation
In the previous chapter, we deployed an AMI with Hashicorp’s Packer, followed by EC2 instance creation. We didn’t have to worry about provisioning networks, public interfaces, internet gateways, and so on. This was possible because of the default VPC resources that were made available by AWS as part of the newly vended account. In real-life implementations, this is rarely the case. You design and implement the entire infrastructure stack from scratch, and automate its management with tools. This level of customization and automation of infrastructure provisioning is going to be our focus in this section. By quickly recapping the concepts we’ve discussed so far, we can get our hands dirty with actual code deployment activities. I will also walk you through some networking components along the way.
We will deploy our application as part of two CloudFormation stacks:
- Network stack: This will include all the networking components required to host a public internet-facing application in your AWS account. We will not use any default resources, which means everything, including VPCs, subnets, route tables, internet gateways, NAT gateways, and so on, will be managed through the CloudFormation template that we develop.
- Application stack: Once the networking foundations are ready, we will host our application in multiple availability zones to adhere to high-availability design principles. It is a good practice to abstract the underlying compute with a load balancer at the network edge. To achieve this, we will deploy an HTTP application load balancer (ALB) in the public subnets that can then respond to incoming requests from the users.