AWS CDK: Advantages, Disadvantages, and When It Isn't the Answer

An infrastructure as code (IaC — defining and provisioning servers, networks, and databases through code instead of manual console clicks) decision doesn't reverse easily. Once a hundred microservices depend on a naming convention, a deployment pattern, and a specific language, switching tools costs months of work, not a sprint. That's why it's worth looking at AWS CDK (Cloud Development Kit) with current evidence, not the reputation it had three years ago.

What it actually is and why it exists#

AWS CDK is an open-source framework that lets you define infrastructure resources in familiar programming languages instead of declarative templates. It is an open source software development framework that lets you define your cloud application resources by using familiar programming languages, and it supports JavaScript, TypeScript, Python, Java, C#, and Go. Underneath, it doesn't replace CloudFormation — it generates it. The AWS CDK provisions your resources in a safe, repeatable manner through AWS CloudFormation, and when you synthesize your AWS CDK code, the result is a CloudFormation template.

That distinction matters for the business: anything you already know about governance, CloudFormation limits, or deployment behavior in AWS still applies. CDK isn't a parallel platform. It's an authoring layer over the same machinery.

The real advantages#

• Development speed: teams use loops, classes, and strong types instead of copy-pasting YAML, reducing configuration errors at scale.
• Reuse at scale: constructs (components representing one or more CloudFormation resources) get packaged, versioned, and shared like any software library.
• Programmatic governance: CDK aspects let you apply standards — like mandatory tagging or default encryption — across all constructs in a given scope, without relying on every developer remembering.
• Immediate access to new AWS features, because CDK and CloudFormation are natively aligned with the platform.

Thomson Reuters' case shows the real enterprise adoption pattern: not using CDK out of the box, but building an internal layer on top of it. Large organizations often struggle with infrastructure management challenges including compliance issues, development bottlenecks and errors from inconsistent AWS resource creation across teams. Their solution was to extend CDK with a proprietary library to standardize names, tags, and policies without forcing every developer to learn custom classes. A key design principle was to minimize the custom code a user of TR AWS CDK needs compared to vanilla AWS CDK, reducing the learning curve for developers.

The disadvantages — and why they aren't a design flaw#

AWS's own documentation is surprisingly direct about the limitations. CDK requires a bootstrapped environment in each AWS account — a one-time action you must perform for every environment you deploy resources into — and it can be used to deploy IaC only in the AWS Cloud. Bootstrapping isn't a minor detail: it creates an S3 bucket, an ECR repository, and a set of IAM roles in every account and region you use. Bootstrapping prepares your AWS environment by provisioning specific resources used by the CDK, including an S3 bucket for project files, an ECR repository for Docker images, and IAM roles configured to grant the permissions the CDK needs.

For an organization with dozens of accounts and strict security teams, that default bootstrap rarely fits without friction. GoDaddy publicly documented how it had to build its own 'bootstrapless' approach because its encryption, tagging, and permission-boundary requirements exceeded what the standard bootstrap offered. The default CDK setup includes security measures, but GoDaddy's enterprise governance requirements had additional specifications that created difficulty with the default bootstrap resources: S3 buckets needed additional encryption, logging, and compliance settings, and IAM roles required alignment with specific permission boundaries. This isn't a CDK failure. It's what happens when a tool designed for the general case meets an organization's own compliance rules — the same pattern that shows up with any framework at scale.

This has been a significant pain point: any change to a resource's logical ID caused by renaming or moving a construct would force AWS CloudFormation to delete and then recreate the resource, a destructive process that often led to data loss and downtime for stateful resources like databases. AWS shipped a refactor command to fix this, but it's still in a pre-release state and requires the --unstable=refactor flag, and developers must also re-bootstrap their CDK environment to get the necessary permissions. Translated to business terms: today, reorganizing your infrastructure code still requires careful review, not a simple rename-and-deploy.

The real decision point: AWS-native vs. multi-cloud#

The most honest comparison isn't 'CDK good, Terraform bad' — it's about where your infrastructure lives. CloudFormation and CDK take a different approach, with much tighter alignment to AWS-native capabilities, which can provide faster access to new AWS features, while Terraform's advantage remains its broad ecosystem, multi-cloud model, and mature state-driven workflow. Terraform keeps its strength in module volume and maturity: it remains popular for its ecosystem and simple setup — a single binary, a CLI workflow, and a mature library of modules.

AWS's own guidance lays out the decision criteria plainly: if you're managing your infrastructure entirely on AWS, CloudFormation and the AWS CDK are good options because they provide out-of-the-box state management and native access to new features; if you want a multi-provider utility, especially for multi-cloud or hybrid-cloud infrastructure, Terraform might be a good choice because it is platform agnostic. And on Pulumi: if your organization can tolerate a high level of risk and needs to support multi-cloud or hybrid-cloud environments, consider using Pulumi.

A competitor that no longer competes: CDK for Terraform#

For years, CDKTF (CDK for Terraform — a joint AWS/HashiCorp project letting you write Terraform configuration in languages like TypeScript or Python) looked like the best of both worlds: CDK syntax, Terraform's ecosystem. That's over. The Cloud Development Kit for Terraform is deprecated as of December 10, 2025; HashiCorp no longer supports or maintains it. For any team evaluating CDKTF as a bridge between ecosystems, that option is no longer viable long-term — a reminder that integration tools between infrastructure platforms carry their own lifecycle, independent of the platforms they connect.

Other names in the conversation#

Crossplane approaches from a different angle: instead of running from a CLI, it turns Kubernetes into infrastructure's control plane. Pulumi and CDK emphasize infrastructure as real programming languages, while Crossplane treats infrastructure as Kubernetes resources controlled by operators and policy. It has gained serious enterprise traction — public users include Nike, Autodesk, NASA Science Cloud, Elastic, SAP, IBM, and Nokia — but it requires an organization already running Kubernetes as an internal platform, not an isolated IaC decision.

What this means for a business decision#

CDK isn't 'better' or 'worse' than Terraform or Pulumi in the abstract. It's the right choice when your infrastructure lives almost entirely in AWS and your organization already has strong TypeScript, Python, or Java developers — because then the learning curve for new syntax disappears. The key is to align the chosen IaC tool with your organization's goals and the skillsets of your developers; for example, if your team is proficient in JavaScript, you might choose AWS CDK with TypeScript because it optimizes your development workflow.

The hidden cost isn't in the syntax. It's in ongoing operations: bootstrapping per account, governance aspects that someone must keep current, refactors that still require manual review while the native feature sits in pre-release, and an internal community of practice — as AWS itself recommends — so knowledge doesn't live in one person's head. None of this shows up in the initial demo. It shows up six months later, when the first stateful stack needs reorganizing and nobody wrote the unit tests protecting the logical IDs.

For organizations already running AWS infrastructure with Infrastructure as Code as part of their stack, the question isn't which tool wins in the abstract. It's who's watching that infrastructure continuously — who bootstraps every new account with the right policies from day one, who reviews every refactor before it deletes a database, who keeps the internal construct library current with new AWS features. That's permanent operational work, not a project that closes.