Infrastructure as Code on AWS: CloudFormation, CDK & SAM

In one line

AWS's native IaC: CloudFormation stacks in YAML/JSON with managed state, CDK to generate them from real programming languages, and SAM for serverless shortcuts, and how they compare with Terraform.

0/4 · 0%

Think of it like this

Building flat-pack furniture. CloudFormation is the official instruction sheet the manufacturer follows exactly and tracks for you; CDK is a smart assistant who writes those instructions from a short description; Terraform is a universal instruction format that works for furniture from many brands.

Key ideas

01
CLOUDFORMATION: a TEMPLATE (YAML/JSON) declares resources; deploying it creates a STACK whose state AWS manages (no state file for you to store or lock). CHANGE SETS preview changes (like terraform plan); failed deployments roll back automatically; DRIFT DETECTION finds manual changes; StackSets deploy the same stack to many accounts/regions (used by Control Tower).
02
CDK (Cloud Development Kit): define infrastructure in TypeScript, Python, Java, Go, or C#, using CONSTRUCTS (high-level building blocks like ApplicationLoadBalancedFargateService that create dozens of resources with good defaults). cdk synth generates CloudFormation; cdk diff and cdk deploy apply it. Loops, functions, and unit tests come from the language.
03
SAM (Serverless Application Model): a CloudFormation extension with short syntax for Lambda, API Gateway, and DynamoDB, plus sam local to run functions locally.
04
vs TERRAFORM (Terraform course): Terraform/OpenTofu is multi-cloud and multi-provider (GitHub, Datadog, Cloudflare), with a huge ecosystem, but you manage state. CloudFormation/CDK are AWS-only with managed state, day-one support for new AWS features, and automatic rollback. Many companies use Terraform org-wide; CDK is popular in AWS-centric teams (DevOps guide, tooling landscape).

In your stack

→
CDK works in Java: new ApplicationLoadBalancedFargateService(this, "Api", ApplicationLoadBalancedFargateServiceProps.builder()...build()), with the same constructs as TypeScript, so a Java team can keep infrastructure in the language it knows.

Code & diagrams

CloudFormation: an encrypted, private S3 bucketyaml

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  Env: { Type: String, AllowedValues: [dev, prod] }
Resources:
  Uploads:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    Properties:
      BucketName: !Sub shoplite-uploads-${Env}
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault: { SSEAlgorithm: aws:kms }
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
Outputs:
  BucketArn: { Value: !GetAtt Uploads.Arn }

deploy with a change set, and the CDK equivalentbash

aws cloudformation deploy --template-file bucket.yaml --stack-name shoplite-uploads-dev \
  --parameter-overrides Env=dev --no-execute-changeset     # review the change set first
aws cloudformation describe-stack-events --stack-name shoplite-uploads-dev --max-items 5

# CDK (TypeScript)
npx cdk init app --language typescript
npx cdk diff && npx cdk deploy

Explain it without notes

What does CloudFormation give you that you must handle yourself with Terraform?

Practice

A team wants to define a Fargate service with an ALB in the fewest lines, in Java. What do you recommend?

Trade-offs

↔
CDK's abstraction speeds development but hides details and generates large templates; plain CloudFormation is explicit but verbose; Terraform is portable but you operate state.

Done when you can

I can deploy a CloudFormation stack with a change set
I can explain CDK constructs and choose between CFN, CDK, SAM, and Terraform

Command Palette