Infrastructure as code on AWS: CloudFormation and CDK

CloudFormation: the declarative core

CloudFormation is AWS’s native infrastructure-as-code service. You write a template — a YAML or JSON document — that declares the desired end state of your infrastructure. A template has a handful of top-level sections: Resources (the only required one — the actual AWS resources to create), Parameters (typed inputs you pass at deploy time), Mappings (static lookup tables, e.g. region to AMI), Conditions (booleans that gate whether a resource or property is included), and Outputs (values the stack exports, like a VPC ID another stack can import). You describe what you want; CloudFormation figures out the order, the dependencies, and the API calls.

A stack is a deployed instance of a template — the running collection of resources CloudFormation created and now manages as one unit. The relationship is exactly like class and object: one template can back many stacks (dev, staging, prod). Crucially, CloudFormation manages the state for you. There is no state file to store, lock, or corrupt — AWS tracks which real resources belong to which stack server-side. That is the single biggest operational difference from third-party IaC tools.

AWSTemplateFormatVersion: "2010-09-09"
Description: A bucket and a table, parameterized by environment.

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, prod]
    Default: dev

Conditions:
  IsProd: !Equals [!Ref Environment, prod]

Resources:
  AssetsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "myapp-assets-${Environment}"
      VersioningConfiguration:
        Status: !If [IsProd, Enabled, Suspended]

  SessionsTable:
    Type: AWS::DynamoDB::Table
    Properties:
      # Renaming a DynamoDB table requires REPLACEMENT — a new table, data gone.
      TableName: !Sub "sessions-${Environment}"
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: sessionId
          AttributeType: S
      KeySchema:
        - AttributeName: sessionId
          KeyType: HASH

Outputs:
  BucketName:
    Value: !Ref AssetsBucket
    Export:
      Name: !Sub "${Environment}-assets-bucket"

When you update a stack, CloudFormation compares the new template against the current stack and produces a change set — a preview of exactly what will happen before anything changes. The change set classifies each resource as add, modify, or remove, and for modifications it tells you the update behavior: No interruption (the resource is updated in place with no downtime), Some interruption (updated in place but briefly disrupted), or — the dangerous one — Replacement (CloudFormation creates a new resource, then deletes the old one). Replacement is property-specific: certain properties simply cannot be changed on a live resource, so changing them recreates it. For a database or a stateful store, Replacement can be destructive — the new resource is empty and the old one is deleted. The whole point of a change set is to surface that word Replacement before you execute, not after.

CloudFormation also rolls back on failure: if any resource in an update fails, it attempts to return every resource to its previous state. That safety net has a notorious failure mode of its own — UPDATE_ROLLBACK_FAILED, where the rollback itself can’t complete (often because a resource was changed out-of-band), and the stack is wedged until you manually fix or skip the offending resource.

Drift: when reality stops matching the template

The 2 a.m. console edit in the hook has a name: drift. CloudFormation defines drift as a stack’s actual configuration differing from its expected configuration as recorded in the template. Any change made outside CloudFormation — through the console, the CLI, or another tool, often called ClickOps — can introduce it. Drift detection compares each supported resource’s live property values against the template and reports a status: IN_SYNC when they match, MODIFIED when a property value differs, DELETED when the resource was removed out-of-band, and NOT_CHECKED for resource types that don’t support drift detection. A stack is DRIFTED if even one resource has drifted.

Drift is not just cosmetic. As the hook showed, the next deploy diffs against the template’s view of the world, so an out-of-band change can be silently reverted — or, worse, can interact with a Replacement property to destroy data. Mature teams run drift detection on a schedule and treat any DRIFTED stack as an incident, because it means the code is no longer the source of truth. The discipline that makes IaC valuable is not editing around it; drift detection is the alarm that tells you someone did.

For large systems you split templates: nested stacks (a parent stack whose resources are themselves child stacks) and cross-stack references (one stack’s Outputs exported and imported by another via Fn::ImportValue) let you compose infrastructure without one unmanageable 3,000-line file. Note one sharp edge: drift detection on a parent stack does not recurse into nested stacks — you detect drift on each nested stack directly.

CDK: a real language that compiles to CloudFormation

Hand-writing YAML gets painful fast: no loops, no real conditionals, no types, and a five-resource intent ballooning into hundreds of lines. The AWS Cloud Development Kit (CDK) is the answer — you define infrastructure in a general-purpose language (TypeScript, Python, Java, C#, Go) using constructs, the reusable building blocks. Constructs come in three levels: L1 (Cfn* classes) are raw one-to-one mappings of CloudFormation resources; L2 wrap them with sensible, secure defaults and helper methods (an s3.Bucket that wires up encryption and a removal policy for you); L3 are patterns that compose many resources into one opinionated unit (an ApplicationLoadBalancedFargateService that stands up a VPC, cluster, load balancer, and service together).

The mechanism is the key insight: cdk synth synthesizes your code into a CloudFormation template, and cdk deploy hands that template to CloudFormation to provision. CDK is a higher-level generator on top of CloudFormation, not a replacement for it. You still get stacks, change sets, rollback, and drift detection — because what actually runs is still a CloudFormation stack. A few dozen lines of CDK routinely emit a 500+ line template and 50+ resources.

import { Stack, StackProps, RemovalPolicy } from "aws-cdk-lib";
import { Construct } from "constructs";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";

export class AppStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const isProd = id.includes("prod");

    // L2 construct: sensible, secure defaults (encryption on by default).
    new s3.Bucket(this, "AssetsBucket", {
      versioned: isProd,                      // a real boolean, not a CFN Condition
      removalPolicy: isProd
        ? RemovalPolicy.RETAIN                // protect prod data on stack delete
        : RemovalPolicy.DESTROY,
    });

    new dynamodb.Table(this, "SessionsTable", {
      partitionKey: { name: "sessionId", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
    });
  }
}
// `cdk synth` turns this into the CloudFormation template above (and more);
// `cdk deploy` runs it through CloudFormation as a stack.

The tradeoff is real. CDK buys you loops, conditionals, type-checking, unit tests, and shareable abstractions — the full toolbox of a programming language applied to infrastructure. It costs you a build step, generated templates that can be large and hard to read, and the obligation to understand the CloudFormation it emits. Raw CloudFormation is the opposite: more verbose and less reusable, but utterly transparent — what you write is exactly what deploys, with no synthesis layer to reason about.