CloudFormation template fundamentals

1. CloudFormation template fundamentals

Welcome back! In this video, you'll author CloudFormation templates, use intrinsic functions like Ref and Fn::Sub, and run change sets and drift detection on a stack. Let's get started.

2. Why infrastructure as code

Picture a team where five engineers each changed the same resource in the console last Tuesday. Nobody remembers what changed. That's drift: the environment changes as different people make small edits over time. Infrastructure as code fixes that. You declare the desired state in a file, AWS reconciles your environment to match, and the file lives in source control. That makes the environment repeatable: you can recreate it anywhere, review every change in a pull request, and track its history in source control right next to your application code. CloudFormation is the foundation we'll cover first; SAM and the CDK come in the next video.

3. CloudFormation template anatomy

A CloudFormation template is a YAML or JSON file with a small set of named sections. Resources is the only required section: it lists the AWS resources you want CloudFormation to create. Parameters are inputs you pass at deploy time, like an environment name or instance size. Outputs are values the stack exposes after deployment, like a URL or queue ARN. Mappings, Conditions, and Transform are helpers that make templates flexible. Transform in particular is what enables the SAM extension you'll see in the next video.

4. Intrinsic functions

Intrinsic functions let templates reference values that don't exist until deploy time. Ref returns the logical name of a parameter or resource. The GetAtt function reads a specific attribute, like the ARN of a queue. The Sub function substitutes variables into a string: !Sub lets you build a name like ${StackName}-bucket from a parameter. Each has a short form prefixed with an exclamation mark: !Ref, !GetAtt, and !Sub. These are the building blocks of every reusable CloudFormation template.

5. Change sets preview updates

Change sets answer the question, "what will happen if I update this stack?" Before you run the update, CloudFormation generates a list of every Add, Modify, or Remove action it would take. Each modified resource gets a Replacement indicator of True, False, or Conditional. True means CloudFormation will delete and recreate the resource, which can lose data on stateful resources like databases. You review the change set, then execute it or throw it away. No surprise updates in production.

6. Drift detection

Drift happens when someone edits a resource directly in the console, bypassing CloudFormation. Drift detection scans the stack and reports each resource as IN_SYNC, MODIFIED, DELETED, or NOT_CHECKED. NOT_CHECKED means the resource type doesn't yet support drift detection. For modified resources, you get a side-by-side view showing the property values CloudFormation expected versus what's actually there. The fix is usually to re-deploy the original template, which reconciles the stack back to its declared state. Drift is the symptom; redeployment is the cure.

7. Deploying and updating stacks

You create a stack on the first deploy and update it each time the template changes. CloudFormation processes updates as a sequence of API calls and emits a stack event for every step, success or failure. Status values like CREATE_COMPLETE, CREATE_IN_PROGRESS, and ROLLBACK_IN_PROGRESS appear on each event row, so you can scan the log for the exact moment things went wrong. If any step fails, the default behavior is to roll the entire stack back to its previous state. Read events first, panic late.

8. Let's practice!

Now let's deploy a stack and read its events. Let's practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.