The code for this chapter can be found in this book’s GitHub repository at https://github.com/PacktPublishing/Mastering-AWS-CloudFormation-Second-Edition/tree/main/Chapter01.

Check out the following video to see the Code in Action: https://packt.link/efSwY.

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, we need to perform an ec2:RunInstances call.

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 errors 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:

// my_bucket.yamlAWSTemplateFormatVersion: "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://my_bucket.yaml

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

Now, let’s add some public access to our bucket:

// my_bucket.yamlAWSTemplateFormatVersion: "2010-09-09"
Description: This is my first bucket
Resources:
  ...

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 humans (yourself and your co-workers) and machines (build systems, other AWS services or resources, and so on). Ignoring the least privilege principle may lead to disastrous security breaches, which is why controlling access for CloudFormation is important.

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

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

CloudFormation, as a service, often refers to the term state. The state is inventory information that contains a pair of values: the logical resource name, such as what name we define in the template, and the physical resource ID that is assigned by AWS, such as the EC2 Instance ID, DynamoDB table name, and so on.

CloudFormation uses its state to understand which resources to create or update. If we create a stack with a resource with a logical name of 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 constraints. For example, it will not update the stack if we do not introduce changes to it. If we make manual changes to the resource, then CloudFormation will change them only when we make changes to the template.

Cloud engineers had to rethink their way of managing the infrastructure once they started using CloudFormation...

In this refresher chapter, we renewed our knowledge 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 was 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 dive deep into the internals of the CloudFormation template, which is what we will 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