CloudFormation vs Terraform: AWS's native IaC option

Both CloudFormation and Terraform solve the same core problem from the Cloud Computing domain's IaC lesson — declare infrastructure as code instead of clicking through a console — but they differ in scope and philosophy in ways that matter practically:

The same kind of S3 bucket resource seen throughout this domain in Terraform, in CloudFormation:

Structurally similar to the Terraform equivalent — resources, properties, outputs — but state is entirely AWS's problem: a CloudFormation stack tracks what it created and its current status internally, with no separate state file to store, secure, or lock yourself.

Terraform's provider model is the deciding factor for most teams: a single Terraform configuration can declare AWS resources, a Cloudflare DNS record, a Datadog monitor, and a GitHub repository setting, all in one place, using one consistent language and workflow — something CloudFormation structurally cannot do, since it only understands AWS resources. Even for a team that's genuinely AWS-only today, that flexibility is cheap optionality: if a non-AWS dependency (a DNS provider, a monitoring tool, a SaaS integration) ever needs to be managed as code, Terraform already supports it without adopting a second IaC tool.

This isn't one-sided — CloudFormation has genuine strengths that matter in specific contexts:

Worth knowing about even briefly: AWS CDK lets you define infrastructure in TypeScript, Python, or another supported language, then synthesizes it down to a CloudFormation template at deploy time — combining a real programming language's abstractions (loops, functions, classes) with CloudFormation's AWS-native state management underneath.

This produces (roughly) the same CloudFormation template shown earlier, generated from actual TypeScript rather than hand-written YAML — a real option for a team that wants CloudFormation's state-management model but finds YAML awkward for anything with real logic or repetition.

Neither tool is simply "correct" — Terraform's multi-provider flexibility and this curriculum's own consistent use of it (matching most real-world teams outside pure AWS-native shops) makes it the default worth learning first; CloudFormation (or CDK) is worth knowing at least at a reading level, since a genuinely large fraction of official AWS documentation, examples, and AWS-native tooling assumes it, and a team that chose CloudFormation for good reasons (heavy AWS SAM/CDK usage, wanting AWS to own state management entirely) isn't making an unreasonable choice.