How To Create A Multi-tier Stack Using AWS CloudFormation?

AWS CloudFormation (CFN) makes it easy to deploy and manage your application infrastructure as an atomic unit using CloudFormation templates. In this article, we will cover how to use CFN to create a multi-tier stack. We will also see how to handle different deployment variations, such as a full-blown production stack with a load balancer, and a smaller footprint development stack using the same CFN template! Lastly, I will also highlight some important tips when designing the CFN templates for your applications.

Note: If you are new to CloudFormation, I highly recommend reading the AWS CloudFormation – An Architect’s Best Friend first to familiarize yourself with the basics.

Identify The Application Deployment Models

Before you start designing the CFN template, it is important to understand in which all possible ways the application can be deployed. At a minimum, identify the key deployment models. For example, what would a typical development deployment look like? Which resources would be needed and what are their configurations? Likewise, for production. Having these details upfront has several benefits.

• You will have a clear understanding of the legitimate combinations in which the application can be deployed.
• You can then delve into the resource configurations and addressing other key aspects like security.
• Lastly, you can ensure that the deployment models are as cost-optimal as possible. For example, the development stack may have the smallest footprint possible to keep cost low versus the production stack that may have a larger footprint.

Let’s take a look at our sample multi-tier stack.

• For the sake of discussion, we will cover 2 deployment models: Development and Production.
• The Production deployment will comprise of a public-facing load balancer, which will be backed by 2 web-tier EC2 instances running Apache. These instances will talk to the EC2 instance hosting the app-tier running tomcat.
• Security Groups will be used for access control. The PublicWebSecurityGroup will be assigned to the web-tier and the AppSecurityGroup will be assigned to the app-tier. Now, you may have noticed the PrivateWebSecurityGroup. Can you guess what’s that for? Perhaps you got it. It is the Security Group created for the Production stack to ensure that the web-tier EC2 instances are only accessible via the load balancer and not exposed publicly.
• The Development deployment of the stack will comprise of a single web-tier EC2 instance and a single app-tier EC2 instance.

So, as you can see, this seemingly simple stack deployment can also become complex considering the different deployment models. But, not to worry. CFN provides us several useful capabilities to make this work.

The Multi-Tier Stack CFN Template

Here is the CFN template.

Let’s break it down by section to understand it better.

Template Parameters

• The DeploymentType parameter is used to determine the deployment model. Such logical parameters are extremely useful as compared to exposing the individual resource properties as parameters. Why? Firstly, these enable the CFN template designer to ensure that the deployments meet only the prescribed models. Secondly, these hide unnecessary complexities from the template users. Also, tomorrow if you add more resources or change configurations, the template users do not have to be bothered about these.
• The next 3 parameters take the target VPC and subnet information. Note that because we are doing a Production deployment we do want to leverage from the high availability capabilities offered by AWS so that we can distribute our EC2 instances across multiple Availability Zones.
• The SSHSecurityGroup parameter is used to specify the Security Group that will be used to connect to the EC2 instances. Now, you could very well create a Security Group for SSH in this template itself. However, I wanted to demonstrate the use of a Security Group that has been created by the networking team for access control. For example, they may set up the SSH Security Group to only allow inbound traffic from the corporate network. So, as opposed to every application team coming up with their own SSH Security Group, here the organization has chosen to use the same SSH Security Group for consistency and ease of management. These considerations are quite important when you design CFN templates. You want to ensure you are not creating backdoors that could lead to a potential security breach.
• The KeyPair parameter specifies the SSH key pair name that will be used for connecting to the EC2 instances.

Mappings

• The Globals map defines constants to avoid hardcoding values all over the template. For example, instead of hardcoding the AMI ID everywhere, we can simply define it once here. Tomorrow, if we want to change it, we just have to update it in one place. Likewise, the other constants.
• The DeploymentTypes map specifies the resource properties for each deployment model. For example, a Development EC2 instance will use t2.small instance type. Whereas, a Production EC2 instance will use t2.medium.

Conditions

• The CreateMultipleInstances condition is set to true only if it is NOT a Development deployment. This will be used later in the template when creating the resources. If you are wondering why I didn’t call it IsProductionDeployment, there is a good reason. What if I add another deployment model tomorrow called QA, which also has multiple instances? By keeping the condition name more generic, we can use it for both these deployment models.

Resources

Notice the use of DependsOn to ensure the resources are created in the correct order.

• First, it creates a load balancer (LB) for the web-tier if the CreateMultipleInstances condition is true. This LB will have 2 EC2 instances attached – Web1EC2Instance and Web2EC2Instance. It will have access to the specified subnets and will be assigned the PublicWebSecurityGroup. The LB will listen on port 80 (HTTP) and will forward traffic to port 80 on the EC2 instances. As we know, LB works by checking the health of the underlying instances. In this case, it will access the base URL (/) every 10 seconds with a timeout value of 3 seconds. If the health check fails 5 consecutive times, the instance will be declared unhealthy. And, the check must succeed 3 consecutive times to declare the instance as healthy.
• Next, it creates the Web1EC2Instance. It uses the Globals map to find some property values like the AMI ID. The InstanceType is set based on the DeploymentType. If it is a Production EC2 instance, it will be assigned the PrivateWebSecurityGroup to avoid direct public access. For Development, it will be assigned the PublicWebSecurityGroup. Also, the SSH Security Group will be assigned. The instance will have a single EBS volume attached. Apart from KeyName and Tags, notice the use of UserData. This is used to install and configure the apache daemon when the instance first boots using the AWS CFN Helper Scripts. The Metadata section contains the information used by these scripts to do their work. The CreationPolicy is used to ensure that CFN waits till it receives a success or failure signal from the UserData script with a timeout of 5 minutes. Note that Web1EC2Instance is created regardless of the DeploymentType since the stack will have at least one web-tier instance.
• The Web2EC2Instance is created only if the CreateMultipleInstances condition is set to true. Its configuration is the same as the Web1EC2Instance.
• The AppEC2Instance is created similarly with the key difference being it will be assigned the AppSecurityGroup and tomcat will be installed on it. Note that just like the web-tier we could create multiple EC2 instances for the app-tier and put an LB in-front of these for high availability and load balancing purposes. But, I’ve skipped that part here for brevity purposes.
• Next, it creates the Security Groups for the respective tiers. Notice how the PrivateWebSecurityGroup sets its ingress rule to permit traffic only from the source resource that has the PublicWebSecurityGroup assigned. This will ensure that only the LB can talk to the web EC2 instances.

Outputs

• The template outputs the stack access URL. Again, it uses the CreateMultipleInstances condition to determine whether the output URL should be based on the load balancer or the Web1EC2Instance.

Metadata

This section contains data used by the CFN Designer tool.

Sample Deployment Commands

The following command shows a Production deployment.

And, here’s a command that shows a Development deployment.

Conclusion

Great job in reading along. As you might have already gathered, authoring a good CFN template is no different from writing good code. It needs to have considerations of what you are trying to accomplish, enterprise readiness aspects like security and be cost-efficient. By thinking about these points upfront you can not only design a better template but also avoid common issues and save time in the longer run.

Happy deploying!
– Nitin

 

---

Also published on Medium.