Cloud computing introduced a brand-new way of managing the infrastructure.

As the demand for the AWS cloud grew, the usual routine and operational tasks became troublesome. The AWS cloud allowed any type of business to rapidly grow and solve all the business needs regarding compute power; however, the need to maintain a certain stack of resources was hard.

DevOps culture brought a set of methodologies and ways of working, and one of those is called infrastructure as code. This process is about treating your infrastructure—network, virtual machines, storages, databases, and so on—as a computer program.

AWS CloudFormation was developed to solve this kind of problem.

You will already have some working knowledge of CloudFormation, but before we dive deep into learning advanced template development and how to provision at scale, use CloudFormation with CI/CD pipelines, and extend its features, let's quickly refresh our memory and look...

The code used in this chapter can be found in the book's GitHub repository at 
https://github.com/PacktPublishing/Mastering-AWS-CloudFormation/tree/master/Chapter1.

Check out the following video to see the Code in Action:

https://bit.ly/2WbU5Lh

AWS services consist of three parts:

• API
• Backend
• Storage

We interact with AWS by making calls to its API services. If we want to create an EC2 instance, then we need to perform a call, ec2:RunInstances.

When we develop our template and create a stack, we invoke the cloudformation:CreateStack API method. AWS CloudFormation will receive the command along with the template, validate it, and start creating resources, making API calls to various AWS services, depending on what we have declared for it.

If the creation of any resource fails, then CloudFormation will roll back the changes and delete the resources that were created before the failure. But if there are no mistakes during the creation process, we will see our resources provisioned across the account.

If we want to make changes to our stack, then all we need to do is update the template file and invoke the cloudformation:UpdateStack API method. CloudFormation...

I'm sure you've done this before.

We begin by developing our template first. This is going to be a simple S3 bucket. I'm going to use YAML template formatting, but you may use JSON formatting if you wish:

MyBucket.yaml

AWSTemplateFormatVersion: "2010-09-09"
Description: This is my first bucket
Resources:
  MyBucket:
    Type: AWS::S3::Bucket

Now we just need to create the stack with awscli:

$ aws cloudformation create-stack \
                     --stack-name mybucket\
                     --template-body file://MyBucket.yaml

After a while, we will see our bucket created if we go to the AWS console or run aws s3 ls.

Now let's add some public access to our bucket:

MyBucket...

We already know that CloudFormation performs API calls when we create or update the stack. Now the question is, does CloudFormation have the same powers as a root user?

When you work with production-grade AWS accounts, you need to control access to your environment for both humans (yourself and your coworkers) and machines (build systems, AWS resources, and so on). That is why controlling access for CloudFormation is important.

By default, when the user runs stack creation, they invoke the API method cloudformation:CreateStack. CloudFormation will use that user's access to invoke other API methods during the stack creation.

This means that if our user has an IAM policy with an allowed action ec2:*, but attempts to create an RDS instance with CloudFormation, the stack will fail to create with an error, User is unauthorized to perform this action.

Let's try this. We will create an IAM role with ec2:*, assume that role...

CloudFormation as a service often refers to the term state. The state is basically inventory information that contains a pair of values: the logical resource name and the physical resource ID.

CloudFormation uses its state to understand which resources to create or update. If we create a stack with a resource with a logical name foo, change the property of this resource (foo) in a template, and run an update, then CloudFormation will change the corresponding physical resource in the account.

CloudFormation has a set of limitations. For example, it will not update the stack if we do not introduce changes to it. If we perform manual changes to the resource, then CloudFormation will change them only when we make changes to the template.

Developers had to rethink their way of managing the infrastructure once they started using CloudFormation, but we will get to that in the later chapters. For now, we would like to show you a feature that doesn't solve problems...

In this refresher chapter, we refreshed our memory as to what CloudFormation is, how we create and update stacks, why service roles are important, and how to implement them. We also remembered what drifts in CloudFormation are, when they occur, and how to detect them.

While this is an introductory chapter, we covered the fundamental building blocks of CloudFormation. In the following chapters, we will use service roles and drift detection again, but first, we need to deep dive into the internals of the CloudFormation template, which we are going to do in the next chapter.

1. Which API method is invoked when we create a CloudFormation stack?
2. What is a CloudFormation service role?
3. Which IAM policies are used if we do not specify the CloudFormation service role?
4. How is the information about stack resources stored in CloudFormation?
5. What happens if we delete the resource created by CloudFormation and try to create the same stack?
6. What happens if we delete the resource created by CloudFormation and try to update the same stack?
7. Why can't CloudFormation recreate the deleted resource?

• CloudFormation service roles: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html
• Drift detection in CloudFormation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html