Book Image

Mastering AWS CloudFormation

By : Karen Tovmasyan
Book Image

Mastering AWS CloudFormation

By: Karen Tovmasyan

Overview of this book

DevOps and the cloud revolution have forced software engineers and operations teams to rethink how to manage infrastructures. With this AWS book, you'll understand how you can use Infrastructure as Code (IaC) to simplify IT operations and manage the modern cloud infrastructure effectively with AWS CloudFormation. This comprehensive guide will help you explore AWS CloudFormation from template structures through to developing complex and reusable infrastructure stacks. You'll then delve into validating templates, deploying stacks, and handling deployment failures. The book will also show you how to leverage AWS CodeBuild and CodePipeline to automate resource delivery and apply continuous integration and continuous delivery (CI/CD) practices to the stack. As you advance, you'll learn how to generate templates on the fly using macros and create resources outside AWS with custom resources. Finally, you'll improve the way you manage the modern cloud in AWS by extending CloudFormation using AWS serverless application model (SAM) and AWS cloud development kit (CDK). By the end of this book, you'll have mastered all the major AWS CloudFormation concepts and be able to simplify infrastructure management.
Table of Contents (17 chapters)
1
Section 1: CloudFormation Internals
4
Section 2: Provisioning and Deployment at Scale
9
Section 3: Extending CloudFormation

The internals of the underlying Lambda function

Lambda function is a code that is triggered by an event. Once run, it receives event and context objects and runs internal code that will process these objects.

While the context is just metadata of the Lambda function's execution and can be used for self-maintenance and graceful shutdown, the event object contains the payload that we want to focus on.

In the case of CRs, we will need to parse the stack's information, run our logic, and respond to CloudFormation. The response should contain the following fields:

  • Status (either success or failed)
  • Physical resource ID (since it is custom, we need to come up with our own resource ID)
  • Stack ID (the same as from the CR request)
  • Request ID (the same as from the CR request)
  • Logical resource ID (the same as from the CR request)
  • Data (may or may not be unnecessary, used for the intrinsic Fn::GetAtt function)
  • After processing and running provisioning...