AWS Zero to Hero: Infrastructure as Code (IaC) with AWS CloudFormation (CFT)

This chapter dives deep into AWS CloudFormation (CFT), exploring the principles of Infrastructure as Code (IaC), writing and deploying CFT templates, understanding template anatomy, managing stack updates and drift detection, and evaluating CloudFormation against industry alternatives like Terraform.

1. Why Do We Need Infrastructure as Code (IaC)?

In traditional software development, engineers write code to build applications (e.g., Java apps, Python apps). Infrastructure as Code (IaC) applies this exact same philosophy to infrastructure: writing declarative code to provision, configure, and manage cloud environments.

Status Quo vs. IaC Approach

Manual ClickOps (AWS Console): Prone to human error, impossible to audit easily, non-repeatable, and difficult to scale across environments (Dev, Staging, Prod).
Imperative Scripts (AWS CLI): Fast for quick commands or querying states, but requires writing step-by-step procedural execution logic that does not track desired end-states automatically.
Declarative IaC (CloudFormation): Defines the desired state of infrastructure. The IaC engine acts as a middleman, reading your declarative template and translating it into underlying cloud provider API calls.

2. Core Mental Model & The IaC Middleman Architecture

An Infrastructure as Code tool acts as an intelligent intermediary between the developer and the cloud provider(s).

CODE

Developer / DevOps Engineer
   |
   | submits declarative template (YAML / JSON)
   v
AWS CloudFormation Service (IaC Engine)
   |
   | translates template into target state
   v
AWS Cloud Provider APIs (EC2, S3, VPC, etc.)

Single-Cloud vs. Multi-Cloud IaC Tools

Cloud-Specific IaC Tools: Support only one cloud provider. Examples include AWS CloudFormation (CFT) for AWS and Azure Resource Manager (ARM) for Microsoft Azure.
Multi-Cloud IaC Tools: Support multiple cloud providers and on-premises environments. Examples include Terraform and Crossplane.

3. Declarative vs. Versioned Principles

To truly implement IaC, templates must adhere to two core principles:

Versioned (Version Control):
- Templates are stored in Git repositories, S3 buckets, or version-controlled artifact stores.
- Enables full code reviews, pull requests, audit trails, and the ability to roll back changes across time.
Declarative ("What You See Is What You Have"):
- By looking at the template, any engineer can immediately identify every resource that exists (or will exist) in the cloud architecture.
- Eliminates ambiguity regarding which route tables, security groups, or instances are deployed.

4. AWS CLI vs. AWS CloudFormation (CFT)

When should you use the AWS CLI versus CloudFormation? Use the following decision matrix:

Scenario / Goal	Recommended Tool	Rationale
Quick Exploratory Actions	AWS CLI	Fast queries (e.g., listing S3 buckets, checking instance health).
Inline Automation Scripts	AWS CLI	Embedding small AWS queries inside custom application scripts.
Provisioning Infrastructure Stacks	AWS CFT	Creating multi-resource architectures (VPCs, subnets, EC2, S3) reliably.
Repeatable Environment Builds	AWS CFT	Deploying identical Dev, Staging, and Production environments.

5. YAML vs. JSON in CloudFormation

AWS CloudFormation natively supports both YAML and JSON formats. However, YAML is the preferred industry standard for several key reasons:

Comments: YAML supports native commenting (# comment), allowing engineers to document code blocks. JSON does not support comments.
Readability: YAML relies on clean Python-style indentation rather than complex, error-prone curly braces ({}) and bracket syntax.
Complexity: YAML reduces syntax friction and is widely adopted across the broader DevOps ecosystem (Kubernetes, Ansible, CI/CD pipelines).

6. Anatomy of a CloudFormation Template (CFT Structure)

A CloudFormation template is structured into several modular sections. While only Resources is strictly mandatory, leveraging the full anatomy ensures enterprise-grade standardization.

YAML

AWSTemplateFormatVersion: "2010-09-09"
Description: >
  Template description outlining what infrastructure is provisioned.

Metadata:
  Author: DevOps Team
  Project: Zero-to-Hero

Parameters:
  EnvironmentType:
    Type: String
    Default: dev
    AllowedValues: [dev, staging, prod]

Rules:
  AvaliabilityZoneCheck:
    # Rule logic for validating parameters

Mappings:
  EnvironmentMap:
    dev:
      InstanceType: t2.micro
    prod:
      InstanceType: t2.large

Conditions:
  IsProduction: !Equals [!Ref EnvironmentType, prod]

Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: demo-aws-abb-example-com

Outputs:
  BucketARN:
    Value: !GetAtt MyS3Bucket.Arn

Section Breakdown:

AWSTemplateFormatVersion: Standard AWS template version (2010-09-09).
Description: Human-readable text explaining the template's purpose.
Metadata: Additional structured data describing authors, teams, or internal tagging.
Parameters: Runtime inputs passed into the template for flexibility and reuse.
Rules: Validation constraints applied to parameters (e.g., restricting instance types in production).
Mappings: Key-value association tables used to look up configuration values based on regions or environments.
Conditions: Boolean logic statements determining whether specific resources get created.
Resources (Mandatory): The actual AWS infrastructure components to provision (AWS::EC2::Instance, AWS::S3::Bucket, etc.).
Outputs: Values returned to the user or cross-stack references after successful deployment (e.g., Public IP, Bucket ARN).

7. Practical Demo 1: Provisioning an S3 Bucket via CFT

Step-by-Step Execution Workflow

Draft Template: Write a basic YAML template defining an S3 bucket resource.
Navigate AWS Console: Open the CloudFormation service dashboard.
Create Stack: Click Create stack -> With new resources (standard).
Upload Template: Upload the local template.yaml file from your workstation.
Configure Stack Details: Name the stack (e.g., s3-bucket-stack) and skip parameters for now.
Submit & Monitor: Review options, click Submit, and observe status progress from CREATE_IN_PROGRESS to CREATE_COMPLETE.

Sample S3 Template (`template.yaml`)

YAML

AWSTemplateFormatVersion: "2010-09-09"
Description: Creating a simple S3 bucket using CloudFormation

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: demo-aws-abb-example-com

8. Drift Detection: Catching Manual Configuration Changes

What is Drift?

Drift occurs when the actual state of your AWS infrastructure diverges from the expected state defined in your CloudFormation template (e.g., an engineer manually disables S3 bucket versioning or deletes a resource via the AWS Console).

Practical Drift Detection Workflow

Provision an S3 bucket with Versioning Enabled via CloudFormation.
Log into the AWS S3 Console and manually change versioning status from Enabled to Suspended.
Return to the CloudFormation console, select your stack, click Stack actions, and select Detect drift.
Once drift detection completes, click View drift results and View drift details to inspect exact discrepancies:
- Expected State: VersioningConfiguration.Status = Enabled
- Actual State: VersioningConfiguration.Status = Suspended

9. Pro Tips & Tricks for Writing CFTs

Leverage VS Code Extensions:
- Install the YAML extension (by Red Hat) for indentation validation and syntax highlighting.
- Install the AWS Toolkit extension to interact with AWS directly from your editor.
Consult Official AWS Documentation: Never memorize full resource syntaxes. Use the AWS CloudFormation Resource and Property Reference to copy-paste accurate resource blocks.
Use CloudFormation Designer: For beginners, utilize the visual drag-and-drop designer tool in the AWS console to generate structural boilerplate code.

10. AWS CloudFormation vs. Terraform

When choosing an IaC tool for enterprise environments, evaluate the following tradeoffs:

Feature / Criteria	AWS CloudFormation (CFT)	Terraform (HashiCorp)
Cloud Scope	Native to AWS only (monocloud).	Multi-cloud (AWS, Azure, GCP, on-prem).
Language	YAML or JSON.	HashiCorp Configuration Language (HCL).
State Management	Managed automatically by AWS behind the scenes.	Requires state file management (local or remote backend like S3/DynamoDB).
Ecosystem & Future	Ideal for 100% AWS-locked organizations.	Dominant industry standard for modern multi-cloud environments.

Interview Guidance: If your organization is strictly committed to AWS and has standardized operations around it, CloudFormation is fully supported and native. However, if multi-cloud agility (supporting Azure, GCP, or hybrid infrastructure) is required, Terraform is the preferred modern tool.

Summary and Key Takeaways

Infrastructure as Code (IaC) replaces manual ClickOps with declarative, version-controlled configuration templates.
CloudFormation Templates (CFT) act as a middleman, translating YAML/JSON declarations into AWS API calls.
Resources is the only mandatory section in a CFT, but parameters, rules, mappings, and outputs provide enterprise scalability.
Drift Detection allows DevOps engineers to audit infrastructure and catch unauthorized manual changes made via the AWS Console.
YAML is heavily favored over JSON due to its readability, support for indentation blocks, and native comment support.
VS Code Extensions (YAML by Red Hat and AWS Toolkit) drastically accelerate the speed and accuracy of template creation.
Terraform is recommended over CloudFormation for multi-cloud strategies, whereas CFT is optimal for dedicated single-cloud AWS environments.