image
Nested Stacks
Start course
Difficulty
Beginner
Duration
1h 49m
Students
824
Ratings
4.2/5
Description

This section of the SysOps Administrator - Associate learning path introduces you to automation and optimization services relevant to the SOA-C02 exam. We will understand the service options available and learn how to apply these designs and solutions to meet specific design scenarios relevant to the exam. 

Learning Objectives

  • Understand how to decouple architecture using Amazon Simple Notification Service and the Simple Queue Service
  • Learn how AWS CloudFormation can be used to optimize and speed up your deployments using infrastructure as Code (IaC)
Transcript

Welcome back to CloudAcademy's Advanced Amazon Web Services CloudFormation course. Today we'll be talking about nested stacks, a technique that you can use to make increasingly complex modeled systems without having to increase the complexity of doing the deployment.

This slide should look really familiar to anybody that's been following along in the course. We used it earlier in the course to explain what exactly CloudFormation is. We discovered that it's actually a state management machine defined by CloudFormation itself as the transition function for stacks. And then we found out that resources are very similar where resources have resource provider logic that is delegated to by CloudFormation itself.

Now realizing that the patterns are so similar, it seems only natural that we should be able to feed CloudFormation into a resource. That is, we can use a CloudFormation stack within another CloudFormation stack as a resource and define the resource provider logic as CloudFormation itself.

This is a conceptual diagram for how CloudFormation nested stacks work. Some of these concepts should look pretty familiar now that we've talked about how the state machines work for both resources and stacks, but we should go over exactly what nested stacks do so it makes sense.

On the left-hand side here, the user develops multiple stacks, or multiple templates rather. The Master Stack is the stack or master template that references a child template and then creates as a sub-resource. So the master stack here treats the child stack as a resource. This stack action with parameters is just a request that we will make to CloudFormation that points to the master stack.

It's important to know that the stack action with params does not reference the child stack directly, but rather only references the master stack. The child stack is referenced by the master stack inside of the stack template definition.

Once we've initialized the master creation with CloudFormation, we should see that the CloudFormation stack actually goes and looks for the template from an S3 bucket. Note that here we did not submit the stack template from the user directly to CloudFormation, but just gave it the action with parameters, having stored the master stack inside of the S3 bucket. We do this because it's easier for us to provide a pointer to CloudFormation to the template whenever we're working with a nested stack. And this is actually the pattern that we must use because child stacks are referenced by their S3 key and bucket inside of the master template.

Once CloudFormation has finished receiving the template for the master stack from the bucket that you defined, the master stack instance initializes itself. We can see that everything in this box is a master stack resource. I've only defined four here, where I've said that the CloudFormation stack type is depended on by the database in Elastic Load Balancer in some EC2 instances because, in my example, the AWS CloudFormation stack resource is a sub-stack that defines all of the network components of a VPC that the database load balancer instances will live inside of.

It should make sense that we might want to group something like a VPC or a networking stack together, and then just have other resources join into that stack because we may find that we want to reuse a network architecture without reusing the three components that are depending on the sub-stack.

Looking at how this works in runtime, the key takeaway is that the master stack just sees the child stack as another resource. That is, we can see that the depends on already works. It follows the same pattern and namespacing as other resources, and it has a service call just like a normal resource as saw in the resource life cycle diagram. That is, this master stack instance just submits this stack or nested stack resource to CloudFormation for creation and waits for it to tell it that it's finished just like a normal resource.

Once we've entered the service call back with CloudFormation, the child stack command and status events looks exactly like a normal stack creation. That is, resources are created and then an event is admitted at the end, in this case, back to CloudFormation, which tells it rather than dumping this into the UI only, we should also tell CloudFormation that the stack is finished creating.

Once a master stack sees that the stack is done, the other resources inside of the master stack can use the CloudFormation stack itself, just like a normal resource. The nested stack's child stack is very similar to a normal resource in that you just provided a properties hash, which can include in this case, the parameters to pass into the stack.

You also provide the S3 bucket and key for the child stack template like we uploaded over here. That is the pointer that is used to define the template that should be used. The input parameters inside the master stack define on the properties object for the CloudFormation stack define the stack parameters that are passed in. And then the outputs of the stack are represented as fn.getAttribute-able properties. The ref value when we run a ref on this CloudFormation stack will simply be the Amazon resource name.

This was a fairly short lecture so we can get into a hands-on demonstration in the next video. In the next video, I'll show you an example of a nested stack.

About the Author
Students
236921
Labs
1
Courses
232
Learning Paths
187

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.