UNIT 4
AWS Cloud Formation
AWS CloudFormation is a service that helps you create and manage AWS
resources easily.
You use a template to describe the resources you need (like EC2 or RDS).
CloudFormation then automatically creates and configures those
resources for you.
You don’t need to set up each resource one by one or worry about their
dependencies.
This saves time so you can focus more on your applications instead of
managing infrastructure.
Simplify infrastructure management
For a web app with a backend database, you may need an Auto Scaling
group, a Load Balancer, and an RDS database.
Normally, you would create and connect each service one by one, which
takes time and adds complexity.
With CloudFormation, you just write or use a template that describes all
these resources.
CloudFormation then creates and connects everything for you as a stack.
When the stack is ready, your app is up and running.
If you delete the stack, all resources are deleted together.
This makes it easy to manage everything as one unit.
Quickly replicate your infrastructure
If you want your app to be highly available, you can run it in multiple
regions.
The problem is, you would need to create and set up the same resources
in each region, which is time-consuming.
With CloudFormation, you only write the template once.
You can then reuse the same template to create the same resources in
multiple regions.
This makes the process consistent, fast, and repeatable.
Easily control and track changes to your infrastructure
Sometimes you may want to upgrade resources step by step (for
example, use a faster instance type in Auto Scaling).
If problems happen, you may need to go back to the old settings.
Doing this manually is hard because you must remember what was
changed and what the old values were.
With CloudFormation, your template stores all resources and their
settings.
Since the template is just a text file, you can use version control (like
developers do for code).
This lets you track what changed, who changed it, and when.
If needed, you can easily roll back by using an earlier version of the
template.
Key concepts
When you use CloudFormation, you work with templates and stacks.
You create templates to describe your AWS resources and their
properties.
Whenever you create a stack, CloudFormation provisions the resources
that are described in your template
Template
A CloudFormation template is a YAML or JSON formatted text file.
You can save these files with any extension, such as .yaml, .json,
.template, or .txt.
CloudFormation uses these templates as blueprints for building your
AWS resources.
For example, in a template, you can describe an Amazon EC2 instance,
such as the instance type, the AMI ID, block device mappings, and its
Amazon EC2 key pair name.
Whenever you create a stack, you also specify a template that
CloudFormation uses to create whatever you described in the template.
For example, if you created a stack with the following template,
CloudFormation provisions an instance with an ami-0ff8a91507f77f867
AMI ID, [Link] instance type, testkey key pair name, and an Amazon EBS
volume
You can also specify multiple resources in a single template and
configure these resources to work together.
For example, you can modify the previous template to include an Elastic
IP address (EIP) and associate it with the Amazon EC2 instance
CloudFormation templates have additional capabilities that you can use
to build complex sets of resources and reuse those templates in multiple
contexts.
For example, you can add input parameters whose values are specified
when you create a CloudFormation stack.
In other words, you can specify a value like the instance type when you
create a stack instead of when you create the template, making the
template easier to reuse in different situations
Stacks
When you use CloudFormation, you manage related resources as a single
unit called a stack.
You create, update, and delete a collection of resources by creating,
updating, and deleting stacks.
All the resources in a stack are defined by the stack's CloudFormation
template.
Suppose you created a template that includes an Auto Scaling group,
Elastic Load Balancing load balancer, and an Amazon Relational Database
Service (Amazon RDS) database instance.
To create those resources, you create a stack by submitting the template
that you created, and CloudFormation provisions all those resources for
you.
Change sets
If you need to make changes to the running resources in a stack, you
update the stack.
Before making changes to your resources, you can generate a change set,
which is a summary of your proposed changes.
Change sets allow you to see how your changes might impact your
running resources, especially for critical resources, before implementing
them.
For example, if you change the name of an Amazon RDS database
instance, CloudFormation will create a new database and delete the old
one.
You will lose the data in the old database unless you've already backed
it up.
If you generate a change set, you will see that your change will cause
your database to be replaced, and you will be able to plan accordingly
before you update your stack
Working of Cloud Formation
When you use CloudFormation to create your stack, CloudFormation
makes underlying service calls to AWS to provision and configure the
resources described in your template.
You need permission to create these resources.
For example, to create EC2 instances by using CloudFormation, you need
permissions to create instances.
You manage these permissions with AWS Identity and Access
Management (IAM). The calls that CloudFormation makes are all declared
by your template.
For example, suppose you have a template that describes an EC2 instance
with a [Link] instance type. When you use that template to create a
stack, CloudFormation calls the Amazon EC2 create instance API and
specifies the instance type as [Link].
The following diagram summarizes the CloudFormation workflow for
creating stacks
To create a stack
1. Use a text editor to create a CloudFormation template in YAML or JSON
format.
The CloudFormation template describes the resources you want and their
settings. Use Infrastructure Composer to visualize and validate your template.
This helps you make sure that your template is properly structured and free of
syntax errors. For more information, see Working with CloudFormation
templates.
2. Save the template locally or in an Amazon S3 bucket.
3. Create a CloudFormation stack by specifying the location of your template
file, such as a path on your local computer or an Amazon S3 URL.
If the template contains parameters, you can specify input values when you
create the stack.
Parameters allow you to pass in values to your template so that you can
customize your resources each time you create a stack
After all the resources have been created, CloudFormation reports that your
stack has been created. You can then start using the resources in your stack. If
stack creation fails, CloudFormation rolls back your changes by deleting the
resources that it created.
Updating a stack with a change set
When you need to update your stack's resources, you can modify the
stack's template.
You don't need to create a new stack and delete the old one.
To update a stack, create a change set by submitting a modified version
of the original stack template, different input parameter values, or both.
CloudFormation compares the modified template with the original
template and generates a change set.
The change set lists the proposed changes.
After reviewing the changes, you can start the change set to update your
stack or you can create a new change set.
The following diagram summarizes the workflow for updating a stack
To update a stack with a change set
1. You can modify a CloudFormation stack template by using editor. For more
information, see Infrastructure Composer or a text Update your stack template.
As you update your template, keep in mind that updates can cause
interruptions. Depending on the resource and properties that you are updating,
an update might interrupt or even replace an existing resource. For more
information, see Understand update behaviors of stack resources.
2. Save the CloudFormation template locally or in an S3 bucket
3. Create a change set by specifying the stack that you want to update and the
location of the modified template, such as a path on your local computer or an
Amazon S3 URL.
4. View the change set to check that CloudFormation will perform the changes
that you expect. For example, check whether CloudFormation will replace any
critical stack resources. You can create as many change sets as you need until
you have included the changes that you want.
5. Initiate the change set that you want to apply to your stack. CloudFormation
updates your stack by updating only the resources that you modified and signals
that your stack has been successfully updated. If the stack updates fails,
CloudFormation rolls back changes to restore the stack to the last known
working state
CloudFormation templates
An AWS CloudFormation template defines the AWS resources you want to
create, update, or delete as part of a stack.
It consists of several sections, but the only required section is the Resources
section, which must declare at least one resource.
You can create templates using the following methods:
• AWS Infrastructure Composer – A visual interface for designing templates.
• Text Editor – Write templates directly in JSON or YAML syntax.
• IaC generator – Generate templates from resources provisioned in your
account that are not currently managed by CloudFormation.
The IaC generator works with a wide range of resource types that are supported
by the Cloud Control API in your Region
Where the templates are getting stored
Amazon S3 bucket
You can store CloudFormation templates in an Amazon S3 bucket.
When creating or updating a stack, you can specify the S3 URL of the
template instead of uploading it directly.
If you upload templates directly through the AWS Management Console
or AWS CLI, an S3 bucket is automatically created for you.
Git repository
With Create a stack from the CloudFormation Git sync, you can store
templates in a Git repository.
When creating or updating a stack, you can specify the Git repository
location and branch containing the template instead of uploading it
directly or referencing an S3 URL.
CloudFormation automatically monitors the specified repository and
branch for template changes.
Steps to Create CloudFormation templates
To get started with creating a CloudFormation template, follow these steps:
1. Choose resources – Identify the AWS resources you want to include in your
stack, such as EC2 instances, VPCs, security groups, and more.
2. Write the template – Write the template in JSON or YAML format, defining
the resources and their properties.
3. Save the template – Save the template locally with a file extension like: .json,
.yaml, or .txt.
4. Validate the template – Validate the template using the methods described
in the templates section.
5. Create a stack – Create a stack using the validated template
CloudFormation template format
You can author CloudFormation templates in JSON or YAML formats. Both
formats serve the same purpose but offer distinct advantages in terms of
readability and complexity.
• JSON – JSON is a lightweight data interchange format that's easy for
machines to parse and generate. However, it can become cumbersome for
humans to read and write, especially for complex configurations.
In JSON, the template is structured using nested braces {} and brackets [] to
define resources, parameters, and other components.
Its syntax requires explicit declaration of every element, which can make the
template verbose but ensures strict adherence to a structured format.
• YAML - YAML is designed to be more human-readable and less verbose than
JSON.
It uses indentation rather than braces and brackets to denote nesting, which
can make it easier to visualize the hierarchy of resources and parameters.
YAML is often preferred for its clarity and ease of use, especially when dealing
with more complex templates.
However, YAML's reliance on indentation can lead to errors if the spacing is not
consistent, which requires careful attention to maintain accuracy
Note from AWS Documentation resources
The structure of a JSON-formatted template with all available sections
The structure of a YAML-formatted template with all available sections.
Comments
In JSON-formatted templates, comments are not supported.
JSON, by design, doesn't include a syntax for comments, which means you
can't add comments directly within the JSON structure.
However, if you need to include explanatory notes or documentation, you
can consider adding metadata.
In YAML-formatted templates, you can include inline comments by using
the # symbol
JSON CloudFormation follows the ECMA-404 JSON standard.
YAML CloudFormation supports the YAML Version 1.1 specification with
a few exceptions.
CloudFormation doesn't support the following features:
o The binary, omap, pairs, set, and timestamp tags
o Aliases
o Hash merges
AWS Code Development Kit (AWS -CDK)
The AWS Cloud Development Kit (AWS CDK) is an open-source software
development framework for defining cloud infrastructure in code and
provisioning it through AWS CloudFormation.
The AWS CDK consists of two primary parts:
• AWS CDK Construct Library – A collection of pre-written modular and
reusable pieces of code, called constructs, that you can use, modify, and
integrate to develop your infrastructure quickly.
The goal of the AWS CDK Construct Library is to reduce the complexity required
to define and integrate AWS services together when building applications on
AWS.
• AWS CDK Toolkit - Tools that you can use to manage and interact with your
CDK apps, such as performing synthesis or deployment. The CDK Toolkit
consists of a command line tool and a programmatic library
The AWS CDK supports TypeScript, JavaScript, Python, Java, C#/.Net, and
Go.
You can use any of these supported programming languages to define
reusable cloud components known as constructs.
You compose these together into stacks and apps.
Then, you deploy your CDK applications through AWS CloudFormation to
provision or update your resources
Benefits of the AWS CDK
Use the AWS CDK to develop reliable, scalable, cost-effective applications in the
cloud with the considerable expressive power of a programming language
Develop and manage your infrastructure as code (IaC)
Practice infrastructure as code to create, deploy, and maintain
infrastructure in a programmatic, descriptive, and declarative way. With
IaC, you treat infrastructure the same way developers treat code. This
results in a scalable and structured approach to managing infrastructure.
With the AWS CDK, you can put your infrastructure, application code,
and configuration all in one place, ensuring that you have a complete,
cloud-deployable system at every milestone.
Employ software engineering best practices such as code reviews, unit
tests, and source control to make your infrastructure more robust
Define your cloud infrastructure using general-purpose programming
languages
With the AWS CDK, you can use any of the following programming
languages to define your cloud infrastructure: TypeScript, JavaScript,
Python, Java, C#/.Net, and Go.
Choose your preferred language and use programming elements like
parameters, conditionals, loops, composition, and inheritance to define
the desired outcome of your infrastructure.
Use the same programming language to define your infrastructure and
your application logic.
Receive the benefits of developing infrastructure in your preferred IDE
(Integrated Development Environment), such as syntax highlighting and
intelligent code completion
Deploy infrastructure through AWS CloudFormation
AWS CDK integrates with AWS CloudFormation to deploy and provision
your infrastructure on AWS.
AWS CloudFormation is a managed AWS service that offers extensive
support of resource and property configurations for provisioning services
on AWS.
With AWS CloudFormation, you can perform infrastructure
deployments predictably and repeatedly, with rollback on error.
If you are already familiar with AWS CloudFormation, you don’t have to
learn a new IaC management service when getting started with the AWS
CDK
Get started developing your application quickly with constructs
Develop faster by using and sharing reusable components called
constructs.
Use low-level constructs to define individual AWS CloudFormation
resources and their properties.
Use high level constructs to quickly define larger components of your
application, with sensible, secure defaults for your AWS resources,
defining more infrastructure with less code.
Create your own constructs that are customized for your unique use
cases and share them across your organization or even with the public
AWS CDK features
The AWS CDK GitHub repository
For the official AWS CDK GitHub repository, see aws-cdk.
Here, you can submit issues, view our license, track releases, and more.
Because the AWS CDK is open-source, the team encourages you to
contribute to make it an even better tool.
The AWS CDK API reference
The AWS CDK Construct Library provides APIs to define your CDK
application and add CDK constructs to the application.
The Construct Programming Model
The Construct Programming Model (CPM) extends the concepts behind
the AWS CDK into additional domains.
Other tools using the CPM include:
o CDK for Terraform (CDKtf)
o CDK for Kubernetes (CDK8s)
o Projen, for building project configurations
The Construct Hub
The Construct Hub is an online registry where you can find, publish, and share
open-source AWS CDK libraries.
AWS CDK core concepts
AWS CDK and IaC
The AWS CDK is an open-source framework that you can use to manage
your AWS infrastructure using code.
This approach is known as infrastructure as code (IaC).
By managing and provisioning your infrastructure as code, you treat your
infrastructure in the same way that developers treat code.
This provides many benefits, such as version control and scalability.
AWS CDK and AWS CloudFormation
Infrastructure created with the AWS CDK is eventually translated, or
synthesized in to AWS CloudFormation templates and deployed using
the AWS CloudFormation service.
So while the AWS CDK offers a different approach to creating your
infrastructure, you still receive the benefits of AWS CloudFormation, such
as extensive AWS resource configuration support and robust deployment
processes.
AWS CDK with abstractions
With AWS CloudFormation, you must define every detail of how your
resources are configured.
This provides the benefit of having complete control over your
infrastructure.
However, this requires you to learn, understand, and create robust
templates that contain resource configuration details and relationships
between resources, such as permissions and event-driven interactions.
With the AWS CDK, you can have the same control over your resource
configurations.
However, the AWS CDK also offers powerful abstractions, which can
speed up and simplify the infrastructure development process.
For example, the AWS CDK includes constructs that provide sensible
default configurations and helper methods that generate boilerplate code
for you.
The AWS CDK also offers tools, such as the AWS CDK Command Line
Interface (AWS CDK CLI), that perform infrastructure management actions
for you.
AWS CDK stacks
An AWS CDK stack is the smallest single unit of deployment.
It represents a collection of AWS resources that you define using CDK
constructs.
When you deploy CDK apps, the resources within a CDK stack are
deployed together as an AWS CloudFormation stack.
AWS CDK stages
An AWS Cloud Development Kit (AWS CDK) stage represents a group of
one or more CDK stacks that are configured to deploy together.
Use stages to deploy the same grouping of stacks to multiple
environments, such as development, testing, and production
AWS CDK Constructs
Constructs are the basic building blocks of AWS Cloud Development Kit
(AWS CDK) applications.
A construct is a component within your application that represents one
or more AWS CloudFormation resources and their configuration.
You build your application, piece by piece, by importing and configuring
constructs.
Import and use constructs
Constructs are classes that you import into your CDK applications from
the AWS Construct Library.
You can also create and distribute your own constructs, or use constructs
created by third-party developers.
Constructs are part of the Construct Programming Model (CPM).
They are available to use with other tools such as CDK for Terraform
(CDKtf), CDK for Kubernetes (CDK8s), and Projen.
Numerous third parties have also published constructs compatible with
the AWS CDK.
Construct levels
Constructs from the AWS Construct Library are categorized into three
levels.
Each level offers an increasing level of abstraction.
The higher the abstraction, the easier to configure, requiring less
expertise.
The lower the abstraction, the more customization available, requiring
more expertise.
Level 1 (L1) constructs
L1 constructs, also known as CFN resources,
These are the lowest-level construct and offer no abstraction.
Each L1 construct maps directly to a single AWS CloudFormation
resource.
With L1 constructs, you import a construct that represents a specific AWS
CloudFormation resource.
You then define the resource’s properties within your construct instance.
L1 constructs are great to use when you are familiar with AWS
CloudFormation and need complete control over defining your AWS
resource properties.
In the AWS Construct Library, L1 constructs are named starting with Cfn,
followed by an identifier for the AWS CloudFormation resource that it
represents.
Level 2 (L2) constructs
L2 constructs, also known as curated constructs, are thoughtfully
developed by the CDK team and are usually the most widely used
construct type.
L2 constructs map directly to single AWS CloudFormation resources,
similar to L1 constructs.
Compared to L1 constructs, L2 constructs provide a higher-level
abstraction through an intuitive intent-based API.
L2 constructs include sensible default property configurations, best
practice security policies, and generate a lot of the boilerplate code and
glue logic for you.
L2 constructs also provide helper methods for most resources that make
it simpler and quicker to define properties, permissions, event-based
interactions between resources, and more.
Level 3 (L3) constructs
L3 constructs, also known as patterns, are the highest-level of
abstraction.
Each L3 construct can contain a collection of resources that are
configured to work together to accomplish a specific task or service
within your application.
L3 constructs are used to create entire AWS architectures for particular
use cases in your application.
To provide complete system designs, or substantial parts of a larger
system, L3 constructs offer opinionated default property configurations.
They are built around a particular approach toward solving a problem and
providing a solution.
With L3 constructs, you can create and configure multiple resources
quickly, with the fewest amount of input and code.
The app and stack construct
The App and Stack classes from the AWS Construct Library are unique
constructs.
Compared to other constructs, they don’t configure AWS resources on
their own.
Instead, they are used to provide context for your other constructs.
All constructs that represent AWS resources must be defined, directly or
indirectly, within the scope of a Stack construct.
Stack constructs are defined within the scope of an App construct.
AWS CDK bootstrapping
Bootstrapping is the process of preparing your AWS environment for
usage with the AWS Cloud Development Kit (AWS CDK). Before you
deploy a CDK stack into an AWS environment, the environment must first
be bootstrapped
Bootstrapping prepares your AWS environment by provisioning specific
AWS resources in your environment that are used by the AWS CDK.
These resources are commonly referred to as your bootstrap resources.
They include the following:
• Amazon Simple Storage Service (Amazon S3) bucket – Used to store
your CDK project files, such as AWS Lambda function code and assets.
• Amazon Elastic Container Registry (Amazon ECR) repository – Used
primarily to store Docker images.
• AWS Identity and Access Management (IAM) roles – Configured to
grant permissions needed by the AWS CDK to perform deployments. For
more information about the IAM roles created during bootstrapping