All Posts 
Blog Post
What are nested stacks in CloudFormation?
Nested stacks are stacks created as part of other stacks. You create a nested stack within another stack by using the AWS::CloudFormation::Stack resource. As your infrastructure grows, common patterns can emerge in which you declare the same components in multiple templates. Reusing common template patterns using nested stacks is efficient and considered a best practice in CloudFormation.
Tutorial on how to use CloudFormation with nested stacks
This blog will introduce how the nested stack works fundamentally and show you what the YAML coding looks like.
In this use case within CloudFormation, I created two instances in the Amazon Virtual Private Cloud (Amazon VPC), one with WordPress installed and the other with MySQL database. I launched the WordPress (WP) node through the AWS Auto Scaling group. It should be behind the AWS Application Load Balancer (AWS ALB). Both nodes should be in private subnets and AWS ALB within a public subnet. I also attached the scale-up/scale-down policy to the AWS Auto Scaling group. I didn’t provide a public subnet for these nodes.
Here are the nested stacks within the root stack:
- Amazon Virtual Private Cloud (Amazon VPC) stack
- Amazon VPC security group stack
- Amazon Elastic Compute Cloud (Amazon EC2) stack
- AWS ALB stack
- Auto Scaling group stack
To access WordPress from AWS ALB, you need to update your Domain Name System (DNS) settings by adding a record that points to the public DNS name of the load balancer. To do so, you will usually need to log in to your domain name provider’s management console and make the necessary changes. Also, use the Elastic Load Balancer’s DNS name (and not the IP address) in the record because Elastic Load Balancer IP addresses are dynamic and can change without warning. Then add the AWS Auto Scaling policies to the Auto Scaling group, and it will scale up and down according to the CPU usage.
In the root stack, I have stacks for the Amazon VPC security group, Amazon EC2, AWS ALB, and the Auto Scaling group. I have these five templates in the root stack.
In the Amazon VPC stack, I’m going to create a private VPC using the name “Saif.” This VPC stack has the following resources that need to be created:
- VPC (SaifPubPrivateVPC)
- Public Subnets (SaPubSubnet and SaPubSubnetb)
- Private Subnet (SaPvtSubnet)
- InternetGateway
- GatewayToInternet
- PublicRouteTable
- PublicRoute
- PublicSubnet1RouteTableAssociation
- NatGateway
- NatPublicIP
- PrivateRouteTable
- PrivateRoute
- PrivateSubnet1RouteTableAssociation
There are two public subnets, one private subnet, an internet gateway, a gateway to the internet public route table, a route table, and a public subnet associated with the route table. And there is a gateway for the private subnets, net public IP, and private route table.
The Amazon VPC security group stack has the following resources that need to be created:
- SaifWebSG This is the public security group. It will attach to the AWS ALB.
- SaifDBSG This is the private security group for the database node.
The Amazon EC2 stack will have only one database instance, with MySQL installed in the private subnet.
In the AWS ALB stack, we will have the following resources that need to be created:
- ApplicationLoadBalancer
- ALBListener
- Target Group (SAIFEC2TG)
In the Auto Scaling group stack, we will have the following resources that need to be created:
- WordPresslaunchTemplate (Launch template for WordPress instance)
- Auto Scaling group (SaifWPASG)
- ScaleUpPolicy
- ScaleUpAlarm
- ScaleDownPolicy
- ScaleDownAlarm
I created two security groups, one for web services and another for the database. The Amazon VPC security group database will be private. The security group used for the web will go into AWS ALB. Private subnets will attach to the instances, not to the AWS ALB. I’ll have a separate Amazon EC2 stack with only one instance for a database and install MySQL in a private subnet on that instance. I have an AWS ALB stack where I created the application load balancer and one target group in which the WordPress instance will be launched. In the Auto Scaling group, I will create the launch template for the WordPress instance. I will create an Auto Scaling group, scale-up policy, and scale-down policy with the scale up allowing them to scale down.
The following templates show the root stack. Here is my root stack route template, which I created with parameters that define the Amazon VPC block, the subnet blocks, and the private and public subnet blocks:
Here is the template for Amazon VPC spec, which I bind with the Amazon VPC stack. In the Amazon VPC stack, I have all the VPCs. For example, I created a VPC with a private subnet and a public subnet. Similarly, I created the internet gateway and NAT gateway for internet access through the private subnet and associated the public route with the public route table.
As a final step, I logged in to CloudFormation and created Amazon VPC, Amazon EC2, and AWS ALB nested stacks.
Need help with DevOps on AWS? The nClouds team is here to help with that and all your AWS infrastructure requirements.
Want more tips on using CloudFormation? Check out these related resources:
Read related blog posts:
What is AWS CDK, and why should your DevOps teams use it?
How to use AWS CDK for Terraform
Rapid data lake development with data lake as code using AWS CloudFormation.
View the related on-demand workshop:
Data Lake as Code on AWS Implementation Workshop (60 mins).
Read suggested case studies:
How nClouds manages DevOps services for Yewno so its team can focus on product innovation and accelerating time-to-market while optimizing costs.
How nClouds helped Efabless modernize its integrated circuit (IC) design platform to improve performance efficiency and scalability, enhance security, and optimize costs.
How nClouds helped Violet Grey enhance productivity, security, compliance, and scalability for their ecommerce beauty business.
