The Anatomy of a CloudFormation Template


DVA-C02 Introduction
Amazon CloudWatch
Anomaly Detection
PREVIEW14m 35s
Options for Operating Programmatically with AWS
AWS AppConfig
AWS Cloud Development Kit (CDK)

The course is part of this learning path

Start course
3h 58m

This course provides detail on the AWS Management & Governance services relevant to the AWS Certified Developer - Associate 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 each of 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

The cornerstone of CloudFormation is the template file. Whether you’re using a JSON formatted or YAML formatted template, the anatomy of the template is the same. For every template, there are several main sections.

The format version and date, the document description, parameters, mappings, conditions, transform, resources and output information. Let’s go through these one by one. 

The AWS template format version is the version of the CloudFormation template. The latest template format version is 2010-09-09 and is also the only valid value at this point in time.

Description is an optional field that you can use to leave comments to describe your infrastructure. It's your template documentation.  That way, other collaborators will know exactly what’s happening in the template without having to look further.

Resources is the only required section of a CloudFormation template, meaning you have to declare at least one infrastructure resource. Each resource is broken up into three parts, a logical ID that is unique within the template, a resource type, and properties for that resource. 

The logical ID is used to describe the resources, and can be referenced in other parts of the template.

The resource type is a CloudFormation predefined code for the resource that you’re creating. You’ll need to look this up in the CloudFormation documentation. For example, the code for an EC2 instance is type of “AWS::EC2::Instance”. 

Resource properties are additional options that you can specify for a resource. For example, to create an EC2 instance, you can declare properties such as Instance Type, ImageID, user data and more. 

Now depending on the infrastructure you’re creating, you may have a situation where you need to avoid hard coding values and instead dynamically choose certain attributes of resources. For example, if you’re building a template to create an EC2 instance, you may need to choose what kind of EC2 instance should be used or how many instances should be created - and those values may change each time you run the template. 

You can do this using the parameter section of your template. With parameters, you can pass values to resources during the stack creation. You can also set parameters to have default values that can be overwritten when a user creates the stack. This means that at run time, a user can choose things like instance type, instance key pair name, and more - in order to customize the template to their own environment. 

There are also predefined parameters that you don’t have to declare called pseudo parameters. For example, you can use the predefined AWS account ID pseudo parameter to retrieve your account ID or the AWS region pseudo parameter to get the AWS region in which the resource has been created. You don't have to declare these yourself in the parameters section, you can simply reference them whenever you need them in your template. 

When you reference a parameter, a pseudo parameter, or even another resource, you can reference each of these using their logical IDs. For example, if you’re creating an EC2 Instance resource, and you have a parameter that enables a user to pass in their EC2 key pair name, in your EC2 instance resource block, you can use the “!Ref” keyword and specify the logical ID of the key pair parameter. 

This !Ref keyword is a CloudFormation-specific keyword that is a part of built-in functions called intrinsic functions. Other common intrinsic functions are: 

  • !GetAtt, which returns a value of from a resource attribute in your template 

  • !FindInMap, which finds a value in a map by using a key, and

  • Join, which joins two values using a delimiter, in this case the new line delimiter

As you create your template, you may need to look up certain values based on chosen parameters. For example, think about how to choose the right AMI for an EC2 instance type. This might be tough to hardcode since the same OS image usually has different IDs depending on the AWS region. So if you hard coded one AMI ID for our instance, you would need to make sure it launches in the same region every time. 

You can solve this problem using mappings. Mappings are very beneficial for cross-region usability, because I can then create a lookup table for AMI ID based on region and OS architecture and quickly find the right AMI ID for my instance. 

The conditions section is where you control what resources are created based on conditions that you define. You can think of this as an if/else statement. If my condition is true, create my resources. If it’s false, don’t create them or create different resources. For example, you could conditionally create a resource depending on whether the stack is for production or a test environment. To do this, you can create a parameter called the environment type parameter with allowed values of test and prod. 

From there, the isProduction condition will evaluate if the string the user passed in for the environment type parameter is equal to prod or not. 

If it’s equal to prod, the CloudFormation template will create the EC2 instance that specifies the isProduction condition. 

Then, there’s the transform section which enables you to specify macros that you can use in your template. Macros can be pretty advanced, so I won’t talk much about them in this introductory course, but they provide you more custom processing in your templates. 

And finally, you can use the template output section to return resource information once the stack has been created. For example, if you have a template creating an EC2 instance, you can use the outputs section to pass back the Public IP address of that instance or the instance ID. You can then see these values in the CloudFormation console, or import them to another stack if you’d like. 

About the Author
Learning Paths

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.