image
Nested Stacks

Contents

DOP-C02 Introduction
Amazon CloudWatch
3
4
Anomaly Detection
PREVIEW14m 35s
Advanced CloudFormation Skills
14
State Machines
PREVIEW8m 54s
15
Data Flow
19m 36s
AWS OpsWorks
21
Parameter Store vs. Secrets Manager
40
AWS Service Catalog
41
AWS Service Catalog
PREVIEW10m 34s
AWS Control Tower
47
AWS Control Tower
PREVIEW19m 56s
Managing Product Licenses
Amazon Managed Grafana
Amazon Managed Service for Prometheus
AWS Proton
57
AWS Resilience Hub

The course is part of this learning path

Start course
Difficulty
Intermediate
Duration
7h 24m
Students
80
Ratings
4.3/5
starstarstarstarstar-half
Description

This course provides detail on the AWS Management & Governance services relevant to the AWS Certified DevOps Engineer - Professional exam.

Want more? Try a lab playground or do a Lab Challenge!

Learning Objectives

  • Learn how AWS AppConfig can reduce errors in configuration changes and prevent application downtime
  • Understand how the AWS Cloud Development Kit (CDK) can be used to model and provision application resources using common programming languages
  • Get a high-level understanding of Amazon CloudWatch
  • Learn about the features and use cases of the service
  • Create your own CloudWatch dashboard to monitor the items that are important to you
  • Understand how CloudWatch dashboards can be shared across accounts
  • Understand the cost structure of CloudWatch dashboards and the limitations of the service
  • Review how monitored metrics go into an ALARM state
  • Learn about the challenges of creating CloudWatch Alarms and the benefits of using machine learning in alarm management
  • Know how to create a CloudWatch Alarm using Anomaly Detection
  • Learn what types of metrics are suitable for use with Anomaly Detection
  • Create your own CloudWatch log subscription
  • Learn how AWS CloudTrail enables auditing and governance of your AWS account
  • Understand how Amazon CloudWatch Logs enables you to monitor and store your system, application, and custom log files
  • Explain what AWS CloudFormation is and what it’s used for
  • Determine the benefits of AWS CloudFormation
  • Understand what the core components are and what they are used for
  • Create a CloudFormation Stack using an existing AWS template
  • Learn what VPC flow logs are and what they are used for
  • Determine options for operating programmatically with AWS, including the AWS CLI, APIs, and SDKs
  • Learn about the capabilities of AWS Systems Manager for managing applications and infrastructure
  • Understand how AWS Secrets Manager can be used to securely encrypt application secrets
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
229443
Labs
1
Courses
216
Learning Paths
173

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.