Infrastructure as Code: AWS CloudFormation Templates and Stacks

In the AWS ecosystem, Infrastructure as Code (IaC) is primarily handled by AWS CloudFormation. It allows you to model, provision, and manage AWS and third-party resources by treating your infrastructure just like application code. This ensures consistency, scalability, and repeatability across environments.

Real-World Analogy: Think of a Template as a detailed architectural blueprint for a building. The Stack is the actual physical building constructed using that blueprint. If you need ten identical buildings, you don’t design them ten times; you just use the blueprint ten times.

Core Concepts: Templates vs. Stacks

1. The Template

A JSON or YAML formatted text file. YAML is generally preferred for readability and the ability to add comments. The template is the “source code” of your infrastructure.

Parameters: Input values provided at runtime (e.g., InstanceType).
Mappings: Static variables (e.g., mapping Region to specific AMI IDs).
Resources: The only mandatory section. Defines the AWS objects to create (S3, EC2, RDS).
Outputs: Values returned after creation (e.g., a Load Balancer URL) that can be imported into other stacks.

2. The Stack

A Stack is a single unit of management. When you “up” a template, CloudFormation creates a Stack. All resources in a stack are created, updated, or deleted together.

Advanced Stack Management

Nested Stacks

Used for modularity and reusability. Instead of one massive template, you break it into smaller pieces (e.g., a VPC template, a DB template). A “Root Stack” calls these “Child Stacks” using the AWS::CloudFormation::Stack resource. This helps overcome the 50,000-byte template size limit.

StackSets

Extends the functionality of stacks by letting you create, update, or delete stacks across multiple accounts and regions with a single operation. This is crucial for enterprise-wide compliance and centralized logging setups.

Comparison: Stack Types

Feature	Standard Stack	Nested Stack	StackSet
Scope	Single Account / Single Region	Modular Hierarchy (Parent/Child)	Multi-Account / Multi-Region
Primary Use	Simple applications	Reusing common components (VPC/Security)	Enterprise governance & landing zones
Management	Individual	Managed via the Root Stack	Managed via Administrator Account

Decision Matrix / If–Then Guide

✅ If you need to preview changes before applying them… Then use Change Sets.
✅ If you need to ensure resources aren’t deleted when a stack is deleted… Then set a DeletionPolicy: Retain.
✅ If your infrastructure has drifted from the template config… Then use Drift Detection.
✅ If you need to share information between stacks… Then use Cross-Stack References (Export/ImportValue).
✅ If you need to deploy a security agent to every account in your Organization… Then use StackSets.

Exam Tips and Gotchas

Rollback Configuration: By default, if a stack creation fails, CloudFormation deletes all created resources (Rollback). You can disable this for troubleshooting.
DeletionPolicy: Crucial for Databases (RDS) and S3 buckets. Always remember that DeletionPolicy: Retain prevents accidental data loss during stack deletion.
WaitConditions: Use these to pause stack creation until an external signal is received (e.g., after a software install script finishes on an EC2).
UpdateStack vs. Replacement: Some property updates cause “Interrupt” or “Replacement”. Replacing an RDS instance means data loss if not handled correctly! Always check the docs for “Update requires: Replacement”.
Circular Dependencies: Stack A cannot depend on Stack B if Stack B also depends on Stack A. This will fail.

Topics covered:

Summary of key subtopics covered in this guide:

Template Structure (Parameters, Mappings, Resources, Outputs)
Stack Lifecycle (Creation, Updates, Deletion)
Nested Stacks for modularity
StackSets for multi-account/region deployment
Change Sets and Drift Detection
Deletion Policies and Rollback behavior

CloudFormation Workflow Infographic

Service Ecosystem

IAM: Use “Service Roles” to give CloudFormation permission to create resources.

CloudTrail: Logs all API calls made by CloudFormation for auditing.

SNS: Integrate to receive notifications on stack status changes.

Performance & Scaling

Parallelism: CloudFormation analyzes dependencies and creates independent resources simultaneously to speed up deployment.

Limits: 2000 stacks per region. Use Nested Stacks to stay organized.

Cost Optimization

Free Tier: CloudFormation itself is free. You only pay for the underlying resources (EC2, RDS, etc.) it manages.

Quick Cleanup: Deleting a stack ensures all associated resources are removed, preventing “zombie” costs.

Production Use Case: Disaster Recovery

A company maintains a CloudFormation template of their entire production environment in S3. In the event of a regional failure, they use StackSets to trigger a deployment of that template into a secondary region, achieving a low RTO (Recovery Time Objective).