---
title: AWS CDK vs CloudFormation vs AWS Blocks: Enterprise IaC Decision Guide (2026)
description: On a 120-stack AWS Organization, CloudFormation StackSets for platform baseline plus CDK for app teams cut org-wide guardrail rollout from 6 weeks to 2 — with Application Composer for spikes and Blocks for greenfield TypeScript only at preview.
url: https://www.factualminds.com/blog/aws-cdk-vs-cloudformation-vs-blocks-enterprise-decision-guide-2026/
datePublished: 2026-07-05T00:00:00.000Z
dateModified: 2026-07-05T00:00:00.000Z
author: palaniappan-p
category: DevOps & CI/CD
tags: cdk, cloudformation, aws-blocks, application-composer, infrastructure-as-code, devops, architecture
---

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

> On a 120-stack AWS Organization, CloudFormation StackSets for platform baseline plus CDK for app teams cut org-wide guardrail rollout from 6 weeks to 2 — with Application Composer for spikes and Blocks for greenfield TypeScript only at preview.

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](/blog/terraform-vs-cloudformation-aws-enterprise-decision-guide-2026/) (multi-cloud state management), **not** [Terraform vs CDK](/blog/terraform-vs-aws-cdk-infrastructure-as-code-decision-guide/) (Terraform authoring), and **not** the [CloudFormation best practices runbook](/blog/aws-cloudformation-best-practices-infrastructure-as-code/) alone.

Artifacts: [native IaC decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/native-iac-decision-matrix.md), [enterprise scenario worksheet CSV](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/enterprise-scenario-worksheet.csv), [migration path checklist](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/migration-path-checklist.md).

> **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:

| Concept              | Meaning for AWS native IaC                                         |
| -------------------- | ------------------------------------------------------------------ |
| Declarative          | Template describes end state; CloudFormation computes changes      |
| Immutable preference | Replace rather than SSH-and-patch where possible                   |
| Drift                | Live resource differs from template — CFN drift detection flags it |
| Version control      | Git is source of truth; PR review gates changes                    |
| CI/CD                | Synth/plan → review → deploy with least-privilege IAM              |

**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](/blog/aws-terraform-opentofu-ansible-iac-decision-guide/).

## 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

| Feature             | Enterprise use                             |
| ------------------- | ------------------------------------------ |
| **Change sets**     | Preview blast radius before apply          |
| **Drift detection** | Find console overrides                     |
| **StackSets**       | Deploy baseline to OUs across accounts     |
| **Nested stacks**   | Decompose large templates                  |
| **Imports/exports** | Cross-stack references (`Fn::ImportValue`) |
| **Hooks**           | Proactive compliance at deploy time        |
| **Stack policies**  | Prevent replacement of critical resources  |

### 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](/blog/aws-cloudformation-best-practices-infrastructure-as-code/))
- **Pre-deployment validation** — CreateStack/UpdateStack validates before provisioning; keep enabled in prod

```yaml
# 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:

| Level  | Description                                                 | Example                           |
| ------ | ----------------------------------------------------------- | --------------------------------- |
| **L1** | Auto-generated CFN resource (`CfnBucket`)                   | Escape hatch, day-zero properties |
| **L2** | Opinionated AWS construct (`s3.Bucket`)                     | Defaults, grants, sensible IAM    |
| **L3** | Pattern construct (`ApplicationLoadBalancedFargateService`) | Entire architecture pattern       |

### 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](/blog/github-actions-aws-cicd-security-best-practices/))

```typescript
// 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](/blog/aws-cdk-cost-estimation-shift-left-finops-iac/))
- **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](/blog/aws-application-composer-iac-generator/).

> **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

| Dimension           | AWS Blocks                         | Application Composer        |
| ------------------- | ---------------------------------- | --------------------------- |
| Primary artifact    | TypeScript backend code            | CFN/SAM template            |
| Local dev           | Full stack without AWS credentials | None (console/VS Code only) |
| Output              | CDK → CloudFormation               | CloudFormation / SAM        |
| User                | Full-stack TypeScript developer    | Architect / IaC author      |
| Production maturity | Preview                            | GA for template generation  |

### 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](/blog/aws-blocks-application-backends-preview/).

## Deep feature comparison

| Dimension                 | CloudFormation           | AWS CDK                      | Application Composer | AWS Blocks               |
| ------------------------- | ------------------------ | ---------------------------- | -------------------- | ------------------------ |
| Learning curve            | Medium (YAML)            | High (code + CFN)            | Low–medium           | Medium (TS + Blocks API) |
| Enterprise readiness      | **High** (StackSets)     | **High**                     | Medium (spikes/docs) | Low (preview)            |
| AWS support               | Native engine            | First-class                  | GA                   | Preview                  |
| IaC maturity              | **Highest**              | **High**                     | Medium               | Emerging                 |
| Maintainability           | Low at scale             | **High** with constructs     | Low as SoT           | Medium                   |
| Scalability               | Nested stacks            | Large apps; limits exist     | Poor >500 resources  | App-scoped               |
| Extensibility             | Macros, custom resources | **L1 escape hatches**        | Limited              | CDK escape hatch         |
| Programming support       | None                     | **TS, Python, Java, Go, C#** | Visual + NL          | TypeScript only          |
| Visual modeling           | Designer (limited)       | cdk-dia, Composer import     | **Best**             | None                     |
| Code generation           | N/A                      | Synth to CFN                 | **CFN/SAM**          | Infra from code          |
| CI/CD compatibility       | **Excellent**            | **Excellent**                | Manual export        | npm scripts + CDK        |
| Git friendliness          | **Excellent** (YAML)     | Good (review synth)          | Export required      | **Excellent**            |
| Reviewability             | **Direct diff**          | Needs synth step             | AI output risky      | App code review          |
| Testing                   | TaskCat, cfn-lint        | Unit + cdk-nag               | None built-in        | Local dev tests          |
| Drift detection           | **Built-in**             | Via CFN stacks               | N/A                  | Via CFN stacks           |
| Rollbacks                 | **Stack rollback**       | Same                         | Same                 | Same                     |
| Governance                | **Hooks, StackSets**     | + cdk-nag                    | Weak                 | Preview only             |
| Compliance                | Audit templates          | Synth artifacts              | Review IAM manually  | Preview caution          |
| Multi-account             | **StackSets**            | Pipelines per account        | No                   | Single-app focus         |
| Multi-region              | Stack instances          | Stage per region             | No                   | Commercial regions       |
| Team collaboration        | PR on YAML               | PR on code + synth           | Share canvas/export  | Monorepo TS              |
| IDE support               | VS Code CFN              | **Full IDE**                 | VS Code Toolkit      | VS Code                  |
| Reusability               | Nested stacks, modules   | **Construct library**        | None                 | Block npm packages       |
| Modularity                | Nested stacks            | Stacks + constructs          | Single template      | Blocks compose           |
| Cost                      | Free (pay AWS resources) | Free                         | Free                 | Free (preview)           |
| Long-term maintainability | Poor without CDK         | **Strong**                   | Not as SoT           | TBD post-GA              |

## Real enterprise scenarios

| Scenario                    | Recommendation         | Why                                                                                                                        |
| --------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Startup (greenfield TS)     | Blocks or CDK          | Blocks for full-stack speed at preview; CDK if infra ownership matters day one                                             |
| SaaS platform               | CDK + StackSets        | L3 constructs for services; StackSets when multi-account                                                                   |
| Enterprise platform         | Hybrid StackSets + CDK | Platform baseline vs app separation                                                                                        |
| Banking / regulated         | StackSets + CDK        | Hooks audit trail; app teams on CDK with synth in Git                                                                      |
| Healthcare (HIPAA)          | StackSets + CDK        | Config conformance via StackSets ([HIPAA architecture](/blog/how-to-implement-hipaa-compliant-architecture-aws/))          |
| Government / FedRAMP        | StackSets + raw CFN    | Partition packages; verify resource availability                                                                           |
| Manufacturing IoT           | CDK                    | SiteWise, IoT Core — complex integrations                                                                                  |
| E-commerce                  | CDK                    | Multi-service, seasonal scaling                                                                                            |
| Internal developer platform | CDK L3 constructs      | Golden paths as shared library                                                                                             |
| Platform engineering        | StackSets + CDK        | Guardrails + self-service ([maturity model](/blog/aws-devops-platform-maturity-model-2026/))                               |
| Multi-account landing zone  | **StackSets**          | Control Tower baseline is CFN-native ([landing zone guide](/blog/aws-multi-account-strategy-landing-zone-best-practices/)) |
| Serverless / Lambda         | CDK or Composer→CDK    | Composer for spike only                                                                                                    |
| Containers (ECS)            | CDK                    | Mature L2 patterns ([ECS vs EKS guide](/blog/aws-ecs-vs-eks-container-orchestration-decision-guide/))                      |
| Containers (EKS)            | CDK                    | Cluster add-ons, IRSA patterns                                                                                             |
| Event-driven                | CDK                    | Step Functions + EventBridge constructs                                                                                    |
| Greenfield Blocks pilot     | Blocks + CDK escape    | One product at preview; plan `index.cdk.ts` before hardening                                                               |

Use [enterprise-scenario-worksheet.csv](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/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](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/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](/blog/aws-environment-parity-dev-staging-production/))
- 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](/blog/cost-aware-cicd-pipelines-aws/) — 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](/blog/aws-enterprise-governance-guardrails-ou-taxonomy-2026/).

## Common mistakes

| Mistake                            | Consequence                      | Fix                              |
| ---------------------------------- | -------------------------------- | -------------------------------- |
| Overusing raw CFN at app scale     | Copy-paste YAML; drift           | CDK constructs                   |
| Poor CDK construct design          | God-stack; 45-min synth          | Split stacks; L3 per domain      |
| Ignoring drift detection           | Console fixes reverted on deploy | Weekly drift job + SCP           |
| Mixing manual + IaC                | Rollback surprises               | Deny console on prod resources   |
| No environment isolation           | Prod creds in dev pipeline       | Account per env                  |
| Hardcoded config                   | Wrong region deploy              | SSM/Parameter Store              |
| Missing review of synth output     | IAM `*` reaches prod             | Mandatory cdk-nag in CI          |
| Composer as production SoT         | Unreviewed AI IAM                | Port to CDK within sprint        |
| Blocks in prod without escape plan | Hit Block ceiling under load     | Architecture review before pilot |
| One-tool mandate                   | Platform vs app fight            | Hybrid layer assignment          |

## Migration strategies

| From           | To             | Risk                  | Recommended approach                    |
| -------------- | -------------- | --------------------- | --------------------------------------- |
| Manual console | CloudFormation | Import failures       | Bounded stack pilot; drift after import |
| Manual         | CDK            | Bootstrap gaps        | Bootstrap first; greenfield stack       |
| CloudFormation | CDK            | Logical ID changes    | `CfnInclude` incremental port           |
| Composer       | CDK            | IAM too broad         | Spike only; rewrite as L2               |
| Composer       | CFN            | Over-permissive roles | Access Analyzer + least privilege       |
| Blocks         | CDK escape     | Abstraction limits    | `index.cdk.ts` before scale event       |

Checklist: [migration-path-checklist.md](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/migration-path-checklist.md).

For account-wide migration programs, see [AWS migration services](/services/aws-migration/) and [application modernization](/services/aws-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](/blog/terraform-vs-cloudformation-aws-enterprise-decision-guide-2026/) for hybrid with StackSets baseline.

Need pipeline design or IaC standardization? [DevOps pipeline setup](/services/devops-pipeline-setup/) · [Contact us](/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](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/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](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/migration-path-checklist.md)).
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](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/native-iac-decision-matrix.md) and [enterprise-scenario-worksheet.csv](https://www.factualminds.com/examples/architecture-blog-2026/cdk-vs-cfn-vs-blocks/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](/blog/terraform-vs-cloudformation-aws-enterprise-decision-guide-2026/), [Terraform vs CDK](/blog/terraform-vs-aws-cdk-infrastructure-as-code-decision-guide/), [OpenTofu vs Pulumi](/blog/terraform-opentofu-vs-pulumi-aws-2026/).
- **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](/blog/aws-blocks-application-backends-preview/) covers comparison.

**Related:** [DevOps pipeline setup](/services/devops-pipeline-setup/) · [GitHub Actions on AWS](/integrations/github-actions-aws/) · [DevOps engineer persona](/for/devops-engineer/)

## FAQ

### When should we use raw CloudFormation instead of CDK?
Use raw CloudFormation for org-wide StackSets baseline (Hooks, GuardDuty, Config), when auditors require human-readable YAML in Git without synthesis indirection, or when stacks are small and static with no reuse. Platform teams deploying identical guardrails to 40+ accounts should not add CDK bootstrap overhead for five-resource templates.

### When should we NOT use Application Composer for production?
Skip Composer-as-source-of-truth for production if IAM policies are not human-reviewed (AI output tends toward s3:* and lambda:*), you need CDK or Terraform export (Composer outputs CFN/SAM only), or you require complex cross-stack computed values. Composer excels at spikes and documentation — not governed production deploys without a port to CDK or reviewed CFN.

### When should we NOT adopt AWS Blocks at preview?
Avoid Blocks as org-wide IaC standard at preview if your team cannot absorb breaking npm API changes, you mandate Terraform-first governance, primary language is not TypeScript, or you need fine-grained multi-account VPC topology on day one. Blocks optimizes greenfield full-stack TypeScript — not landing-zone migration.

### Does CDK replace CloudFormation?
No. CDK synthesizes CloudFormation templates — every cdk deploy ends as CreateStack or UpdateStack. CDK is an authoring layer; CloudFormation is the deployment engine with change sets, drift detection, and rollback. You cannot opt out of CFN semantics when using CDK.

### Can Application Composer output CDK code?
No. Application Composer generates CloudFormation and SAM templates only. CDK teams use Composer for AI-assisted SAM spikes or visualizing existing CFN templates (including cdk synth output loaded for documentation), then port resources to constructs manually.

### How do CloudFormation StackSets work with CDK apps?
StackSets deploy CFN templates org-wide — typically raw CFN for platform baseline. CDK app stacks deploy per account/region via cdk deploy and synthesize to standard CFN stacks. Hybrid pattern: StackSets own guardrails; CDK owns application stacks. CDK does not replace StackSets for OU-wide auto-deployment to new accounts.

### What breaks when mixing manual console changes with IaC?
The next IaC deploy may fail (property conflicts), replace resources unexpectedly, or revert manual fixes. CloudFormation drift detection surfaces differences but does not auto-merge. Symptom: UpdateStack rollback after someone changed security group rules in console. Fix: import drift into template or revert manual change — then enforce SCP deny on unapproved resource types.

### Can we use Blocks, CDK, and Composer together?
Yes, with clear ownership. Example: StackSets (CFN) for baseline, CDK for microservices, Composer for RFC spikes ported to CDK within one sprint, Blocks for one greenfield TypeScript product at preview. Failure mode: three sources of truth for the same stack — assign layer per team and never deploy the same resources from two tools.

---

*Source: https://www.factualminds.com/blog/aws-cdk-vs-cloudformation-vs-blocks-enterprise-decision-guide-2026/*