AWS CDK vs CloudFormation vs AWS Blocks: Enterprise IaC Decision Guide (2026)

On June 30, 2026, AWS shipped CloudFormation Express mode and pre-deployment validation on CreateStack/UpdateStack — both affect every path that deploys through CloudFormation, including AWS CDK (cdk deploy) and AWS Blocks (npm run deploy). On June 16, 2026, AWS Blocks entered public preview as an open-source TypeScript framework that generates CDK under the hood. Application Composer now supports 1100+ CloudFormation resource types with AI-assisted generation in VS Code.

The enterprise question is not “CDK or CloudFormation?” — CDK synthesizes to CloudFormation. The real question is which authoring layer owns which layer of your estate, and whether Blocks or Composer belong in your toolchain at all.

This post compares CloudFormation, AWS CDK, Application Composer, and AWS Blocks on the native AWS IaC spectrum. It is not Terraform vs CloudFormation (multi-cloud state management), not Terraform vs CDK (Terraform authoring), and not the CloudFormation best practices runbook alone.

Artifacts: native IaC decision matrix, enterprise scenario worksheet CSV, migration path checklist.

Benchmark pattern (not a cited client) — 120-stack AWS Organization across 35 accounts, mixed manual baselines and ad hoc CFN. Platform team adopted StackSets (Config, GuardDuty, Hooks) plus CDK for application teams — org-wide guardrail rollout 6 weeks → 2 weeks. Application Composer used for 4 serverless spikes (ported to CDK within 2 sprints). Blocks piloted on 1 greenfield TypeScript SaaS; not org standard at preview.

Why the native AWS IaC choice matters

Infrastructure at enterprise scale fails on governance, not syntax. The wrong standard creates:

• Unrepeatable environments — staging diverges from production because one team uses console clicks
• Slow compliance — auditors ask for template history; you have Slack screenshots
• Fragile rollouts — org-wide guardrails deployed account-by-account instead of via StackSets
• Review bottlenecks — 800-line YAML nobody can diff, or CDK synth output nobody reads

Choosing CloudFormation, CDK, Composer, or Blocks is choosing who can change what, how changes are reviewed, and what deploy engine enforces rollback and drift. All four paths that matter for AWS-native shops converge on CloudFormation stacks — the difference is how humans (and AI) author the template.

What is Infrastructure as Code?

Infrastructure as Code (IaC) declares desired state in version-controlled files. Automation reconciles live AWS resources to that state. Core concepts that apply regardless of tool:

Declarative vs imperative: Raw CloudFormation and Composer output are declarative. CDK and Blocks are imperative authoring that generates declarative CFN. For broader IaC including Terraform and Ansible, see AWS IaC in 2026: Terraform vs OpenTofu vs Ansible.

AWS CloudFormation — the deployment engine

CloudFormation is AWS’s native service for provisioning and updating resources as stacks. Every CDK deploy and Blocks production deploy ends here.

Architecture and workflow

1. Submit template (YAML/JSON) via CLI, API, or pipeline
2. CloudFormation creates change set (optional but recommended for prod)
3. Execute change set — resources created/updated/deleted in dependency order
4. Stack reaches CREATE_COMPLETE or UPDATE_COMPLETE (or rolls back on failure)

Stack lifecycle features enterprises use

June 2026 changes that affect all CFN paths

• Express mode — faster completion; rollback disabled by default; best for dev/test iteration (details in CFN best practices post)
• Pre-deployment validation — CreateStack/UpdateStack validates before provisioning; keep enabled in prod

# Context: CloudFormation StackSet — service-managed permissions (July 2026)
# Enable Organizations trusted access before OU-wide deploy.
Resources:
  OrgCloudTrail:
    Type: AWS::CloudTrail::Trail
    Properties:
      IsLogging: true
      S3BucketName: !Ref AuditBucket

CloudFormation advantages

• No remote state file — AWS holds stack state; one less leak surface
• Native drift detection — DetectStackResourceDrift per resource
• StackSets + Organizations — auto-deploy baseline to new accounts
• Day-zero AWS features — new services appear in CFN resource types first
• Audit-friendly — template in Git matches what deployed

CloudFormation disadvantages

• YAML/JSON verbosity — loops and reuse require macros or copy-paste
• Slow iteration for app teams — without CDK, dynamic environments hurt
• Template size limits — 1 MB template; nested stacks add ops overhead
• No application runtime — templates are infra only, not app code

Production examples

• Landing zone baseline — Config, GuardDuty, CloudTrail via StackSets
• Network hub — Transit Gateway, RAM shares — stable, reviewed quarterly
• Regulated audit — raw CFN in Git for third-party assessors

AWS CDK — programmatic authoring on top of CFN

AWS CDK (v2 only — v1 EOL June 1, 2023) lets you define infrastructure in TypeScript, Python, Java, C#, or Go. cdk synth produces CloudFormation; cdk deploy drives the stack API.

How synthesis works

CDK app (code) → cloud assembly → *.template.json → CloudFormation deploy

Constructs are the unit of reuse:

Enterprise CDK topics

• Bootstrap — SSM parameters, staging bucket, IAM roles per account/region; platform team owns lifecycle
• Assets — Lambda zip and Docker images uploaded to bootstrap bucket during deploy
• Context — cdk.context.json pins AZ lookups; commit intentionally
• Tokens — late-bound values (Fn::GetAtt) resolved at synth time
• Escape hatches — bucket.node.default_child for L1 properties L2 lacks
• CDK Pipelines — self-mutating pipeline construct; alternative is CodePipeline + cdk deploy
• Multi-account — pipeline stage per account; or separate pipelines with OIDC from GitHub Actions (GitHub Actions AWS guide)

// Context: aws-cdk-lib 2.x, TypeScript — L2 with cdk-nag in CI
import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class ApiStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    new lambda.Function(this, 'Handler', {
      runtime: lambda.Runtime.NODEJS_22_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
    });
  }
}

CDK advantages

• Reuse via constructs — internal L3 library enforces golden paths
• Programming language features — loops, conditions, unit tests
• Faster app team velocity — especially TypeScript/Python shops
• cdk-nag — policy-as-code on synth output (FinOps in PRs)
• Same deploy semantics as CFN — change sets, rollback, drift

CDK disadvantages

• Indirection — reviewers must read diff or synth output, not just TypeScript
• Bootstrap operational overhead — every account/region needs bootstrap stack
• CFN synthesis limits — very large apps hit template size or resource count limits
• Learning curve — constructs, aspects, tokens confuse teams new to IaC

AWS Application Composer — visual and AI-assisted CFN/SAM

Application Composer is not AWS Blocks. Composer is a visual and AI-assisted tool for CloudFormation and SAM templates — infrastructure diagrams and generated YAML, not application runtime code.

Four modes (2025/2026)

1. Visual drag-and-drop — canvas linked to live CFN/SAM template
2. AI-assisted generation — natural language → SAM/CFN via Amazon Q Developer
3. Bidirectional sync — edit YAML, canvas updates; drag resource, YAML updates
4. Existing template visualization — upload inherited template → architecture diagram

Composer supports 1100+ CloudFormation resource types in the canvas. Output is CFN/SAM only — no CDK or Terraform export.

Advantages

• Fast serverless spikes — Lambda + API Gateway + DynamoDB in minutes
• Documentation — visualize 600-line template for architecture review
• VS Code integration — AI suggestions validated against CFN schema
• Low barrier — architects who think in diagrams, not HCL

Disadvantages

• IAM policies need human review — AI tends toward overly broad actions
• Not a governance layer — no StackSets, Hooks, or org-wide rollout
• No complex logic — conditionals and cross-stack patterns weak vs CDK
• Production risk — deploying AI output without port to CDK or review

For deep dive on Composer workflows, see Application Composer: AI-Assisted IaC Generation.

What broke — Team deployed AI-generated SAM template to staging without IAM review. Lambda execution role included s3:* on *. Access Analyzer flagged it; deploy blocked at prod gate. Fix: least-privilege rewrite + port to CDK L2 constructs with cdk-nag — 2 days lost to spike that should have been RFC-only.

AWS Blocks — infrastructure-from-code for TypeScript backends

AWS Blocks (public preview since June 16, 2026) is an open-source TypeScript framework for full-stack application backends. Each Block bundles app code, local dev mocks, and CDK infrastructure. Blocks apps are CDK apps — escape via aws-blocks/index.cdk.ts.

How Blocks differs from Composer

Blocks workflow

npm run dev     → local mocks (no AWS account)
npm run sandbox → real AWS services, hot-swap Lambda
npm run deploy  → full CDK deploy (CloudFront, WAF, etc.)

Advantages

• Local-first — Postgres, auth, realtime on laptop
• Type safety — frontend imports backend API types directly
• Zero-change deploy — same code local and prod
• CDK escape hatch — add VPC, custom SGs when Block defaults insufficient

Disadvantages (preview)

• Preview API volatility — pin npm versions; read release notes
• TypeScript-only — not org-wide IaC for polyglot shops
• Not a landing-zone tool — greenfield SaaS, not multi-account migration
• Sandbox vs deploy confusion — sandbox has no public CloudFront URL

Full Blocks guide: AWS Blocks Preview.

Deep feature comparison

Real enterprise scenarios

Use enterprise-scenario-worksheet.csv to score your org.

Decision matrix

Step 1: Is it org-wide baseline every account must inherit?
  YES → CloudFormation StackSets (+ Hooks)
  NO  → Step 2

Step 2: Is it a greenfield TypeScript full-stack app at preview tolerance?
  YES → AWS Blocks (plan CDK escape hatch)
  NO  → Step 3

Step 3: Is it a time-boxed spike or inherited template documentation?
  YES → Application Composer → port to CDK within 1 sprint
  NO  → Step 4

Step 4: Default → AWS CDK for application infrastructure
        Exception → raw CFN for tiny static stacks or auditor mandate

Full matrix: native-iac-decision-matrix.md.

Hybrid is the enterprise norm — not a compromise:

Platform:  StackSets (CFN) → Config, GuardDuty, Hooks, CloudTrail
Apps:      CDK → microservice stacks
Spikes:    Composer → SAM draft → CDK port
Pilot:     Blocks → one TS product (preview)

Best practices across tools

Git and review

• Raw CFN — template is the artifact; PR diff is the review
• CDK — PR on code; CI runs cdk synth and posts template diff
• Composer — never prod from console-only; export to Git same day
• Blocks — treat aws-blocks/ as app repo; pin dependencies

Environment separation

• Separate AWS accounts per environment (environment parity guide)
• CDK context or SSM parameters for env-specific values — no hardcoded account IDs
• StackSets for prod OU only after 2-account pilot

Security and governance

• Least privilege IAM — reject Composer AI IAM without review
• cdk-nag + CFN Guard + Hooks — defense in depth
• Secrets — Secrets Manager/SSM; never in templates or CDK context committed to Git
• SCPs — deny unapproved resource types; IaC cannot override SCP

CI/CD

• Change sets for production CFN deploys
• Cost-aware pipelines — cdk diff + cost estimate on PR
• Express mode in dev only unless documented risk acceptance

Testing and validation

• cfn-lint on all CFN templates (including CDK synth output)
• TaskCat for multi-region CFN modules
• CDK unit tests for construct logic

Align platform governance with enterprise OU taxonomy.

Common mistakes

Migration strategies

Checklist: migration-path-checklist.md.

For account-wide migration programs, see AWS migration services and application modernization.

FactualMinds expert recommendation

Opinionated take: Standardize on layers, not one tool.

1. CloudFormation StackSets + Hooks — platform and security baseline every account inherits. Do not use CDK for five-resource guardrail templates unless you already have bootstrap everywhere.

2. AWS CDK — default for application teams shipping TypeScript or Python. Invest in an internal L3 construct library so golden paths are one import, not 200 lines per service.

3. Application Composer — RFC spikes and inherited-template visualization only. Export to Git, review IAM, port to CDK within one sprint. Never let Composer be the source of truth for production.

4. AWS Blocks — greenfield TypeScript SaaS at preview where local-first velocity beats landing-zone complexity. Plan aws-blocks/index.cdk.ts in the architecture review, not after incident. Do not replace org IaC standards with Blocks at preview.

5. Hybrid is success — StackSets + CDK + occasional Composer is what we see in production-ready orgs, not tool consolidation for its own sake.

When Terraform owns app stacks today, do not force CDK migration for politics — see Terraform vs CloudFormation enterprise guide for hybrid with StackSets baseline.

Need pipeline design or IaC standardization? DevOps pipeline setup · Contact us.

Frequently Asked Questions

Does AWS CDK create resources without CloudFormation?

No. CDK always synthesizes CloudFormation templates. There is no parallel deploy path.

Is AWS Blocks the same as Application Composer?

No. Blocks is TypeScript infrastructure-from-code for application backends. Composer is visual/AI CFN/SAM generation. Blocks deploys through CDK; Composer exports templates.

Which tool has the best AWS service coverage?

CloudFormation resource types are the superset. CDK L2 coverage lags slightly on day-zero services — use L1 escape hatches. Composer supports 1100+ CFN types in canvas. Blocks covers common backend patterns via Blocks catalog.

Can I use CDK for StackSets?

CDK can model StackSets, but most platform teams use raw CFN YAML for baseline templates because StackSets templates change rarely and auditors prefer plain CFN.

How do I choose between CDK TypeScript and Python?

Choose the language your application team already uses. Infrastructure code in the same language as app code reduces context switching. Platform teams often standardize one language org-wide.

What is CDK bootstrap and do I need it?

Bootstrap provisions S3 bucket and IAM roles for CDK assets (Lambda code, Docker images). Required for cdk deploy in each account/region. Platform team should own bootstrap lifecycle.

Does Application Composer replace the CDK Developer Guide?

No. Composer accelerates initial templates; CDK is for production maintainability, testing, and construct reuse.

Is CloudFormation still relevant if we adopt CDK?

Yes. CDK teams still need CFN literacy for debugging stack events, drift, and rollback failures. Synth output is CloudFormation.

Can Blocks run without ever touching CDK?

Most developers never edit CDK when using Blocks. Production hardening often requires index.cdk.ts for VPC, WAF, or custom resources Blocks do not expose.

What testing tools work with CDK?

cdk-nag, cfn-guard on synth output, unit tests with @aws-cdk/assertions, and integration tests deploying to sandbox accounts.

How does drift detection work with CDK stacks?

Same as any CFN stack — DetectStackDrift on the deployed stack. CDK does not add separate drift semantics.

Should startups skip CloudFormation and use CDK only?

Startups still deploy CFN stacks via CDK. For minimal ops, CDK or Blocks (preview) for apps; add StackSets when you hit a second AWS account.

What is the difference between SAM and CDK?

SAM is a CFN transform for serverless resources. CDK can produce SAM or raw CFN. Composer often generates SAM for Lambda patterns.

How do Hooks interact with CDK deploys?

Hooks run on CloudFormation create/update — including stacks deployed by CDK. Non-compliant synth output fails at deploy time.

Can I visualize CDK apps in Application Composer?

Export synth template JSON/YAML and load into Composer visualization mode — useful for onboarding and architecture review.

Is AWS Blocks free?

Blocks software is open source with no additional charge. You pay for underlying AWS services (Lambda, DynamoDB, etc.).

What breaks CDK bootstrap across accounts?

Deleting bootstrap stack while app stacks exist, or bootstrap version drift across regions. Symptom: asset upload failures on deploy.

How do we govern CDK construct versions?

Internal construct library with semver; pin aws-cdk-lib in package.json; CI runs synth on every PR.

When should we stay on raw CloudFormation instead of migrating to CDK?

Small static stacks, auditor mandate for YAML, or platform StackSets that change quarterly with no loops — migration cost exceeds benefit.

How does this relate to Terraform in our org?

Terraform is a separate deploy engine with remote state. Native AWS IaC (this post) all uses CloudFormation as engine. Many orgs run StackSets (CFN) + Terraform apps — see the Terraform enterprise guide.

What to do this week

1. Assign platform vs app layer — StackSets owner and CDK owner named in writing.
2. Run enterprise-scenario-worksheet.csv for your industry and account count.
3. If no StackSets baseline: pilot 2 accounts in one OU before org-wide (checklist).
4. If CDK app teams exist: add cdk synth + cdk-nag to CI this sprint.
5. Retire any Composer console-only production deploys — export to Git and port to CDK.
6. If evaluating Blocks: architecture review must include CDK escape hatch criteria before pilot.

Reproduce this — Download native-iac-decision-matrix.md and enterprise-scenario-worksheet.csv. Score your top three scenarios; if StackSets wins platform layer, start 2-account OU pilot before standardizing CDK construct library.

What this post doesn’t cover

• Terraform, OpenTofu, Pulumi, Ansible — Terraform vs CloudFormation, Terraform vs CDK, OpenTofu vs Pulumi.
• SAM-only deep dive — Composer generates SAM; production patterns live in CDK serverless constructs.
• GovCloud partition edge cases — verify resource type availability per partition before standardizing.
• Amplify Gen 2 vs Blocks — Blocks preview post covers comparison.

Related: DevOps pipeline setup · GitHub Actions on AWS · DevOps engineer persona