Skip to main content
AWS CDK is an excellent infrastructure tool for many AWS teams. It is not the best tool for every team. Updated October 9, 2026. CDK lets you define infrastructure with TypeScript, Python, Java, C#, or Go. It synthesizes that program into CloudFormation templates, and CloudFormation performs the deployment. You get programming-language abstractions while retaining the AWS deployment engine. Whether that is an advantage depends on what your team wants to own.

​
Where CDK is strong

CDK is effective when your infrastructure is primarily AWS and your engineers are comfortable maintaining application-like code.
  • Constructs package repeated patterns into reusable components.
  • Loops, functions, types, and tests reduce copy-and-paste templates.
  • CloudFormation manages resource ordering and deployment state.
  • cdk diff provides a useful preview of template changes.
  • L1 constructs expose CloudFormation resources quickly, while L2 and L3 constructs provide higher-level defaults.
  • The synthesized template remains available for review and policy checks.
A platform team can define a secure service pattern once, then let product teams supply a smaller set of inputs. That is more valuable than replacing YAML with TypeScript line for line.

​
Where CDK becomes difficult

CDK adds an abstraction layer above CloudFormation. Engineers still need to understand CloudFormation behavior, replacement rules, IAM, networking, and the generated template. Common problems include:
  • A convenient construct creates more resources or permissions than expected.
  • A library upgrade changes the synthesized template.
  • Tokens and lazy values make debugging less direct.
  • Engineers write imperative-looking code and forget that the result is a declarative graph.
  • Cross-stack references create deployment coupling.
  • Custom constructs become internal frameworks that only their authors understand.
A passing TypeScript compile does not prove that a deployment is safe. Always inspect the infrastructure diff and understand which resources will be replaced.

​
How the alternatives differ

None of these removes the need to understand destructive changes, identity, state, and drift.

​
Choose with operational questions

Ask these questions before choosing:
  1. Is the infrastructure mostly AWS or genuinely multi-cloud?
  2. Who reviews generated resource changes?
  3. Where does deployment state live, and who recovers it?
  4. How will you test security and replacement behavior?
  5. Does the team need reusable platform components or only a few stable stacks?
  6. How quickly can a new engineer understand the toolchain?
  7. Who owns upgrades to providers, constructs, and the deployment engine?
The best tool is the one your team can operate safely for years, not the one that makes the first demo shortest.

​
A good CDK operating model

If you choose CDK, keep the boundary disciplined:
  • Build small constructs around stable product capabilities.
  • Prefer explicit inputs over hidden environment lookups.
  • Pin dependencies and review synthesized diffs during upgrades.
  • Add assertion tests for security-critical resources and policies.
  • Separate stateful resources from frequently changing compute where practical.
  • Keep escape hatches visible when a construct hides an important setting.
  • Document bootstrap, deployment, rollback, and deletion behavior.

​
The answer for a small team

For an AWS-native product with several repeated resource patterns, CDK is often a strong choice. For one simple service, raw CloudFormation may be enough. For infrastructure spanning many providers, Terraform, OpenTofu, or Pulumi may produce a clearer operating model. Springwinter uses repeatable AWS infrastructure patterns so customers do not have to build this layer for each workload. You can still own the AWS resources without owning every construct, deployment script, and upgrade path. That is a different choice from selecting an infrastructure-as-code syntax, and for many product teams it is the more important one.

​
Frequently asked questions

AWS CDK is often stronger for AWS-focused teams that want typed constructs and CloudFormation deployment state. Terraform or OpenTofu is often stronger for multi-provider estates and teams standardized on HCL. The better choice depends on state ownership, review workflow, portability, and team expertise.
AWS CDK does not replace CloudFormation. CDK executes application code to synthesize CloudFormation templates, and CloudFormation deploys the resources. Teams using CDK still need to understand CloudFormation replacement behavior, stack state, IAM permissions, rollback, and generated template changes.
AWS CDK adds dependencies, construct abstractions, bootstrap requirements, and a generated-template layer. Library upgrades can change infrastructure unexpectedly, tokens complicate debugging, and internal constructs can become a framework. Pin versions, inspect diffs, test policies, and keep abstractions small.

​
Sources and further reading

Last modified on October 8, 2026