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.