Same Language, Same Visibility: AWS CDK Support is Here
When engineers choose AWS CDK, they’re making a bet on unification. One language for their application code and their infrastructure. TypeScript all the way down, or Python from Lambda to load balancer. It’s an elegant proposition.
But until now, that choice came with a trade-off: the cost visibility that Terraform teams take for granted simply wasn’t available.
As of today, Infracost Cloud now supports AWS CDK natively (TypeScript, JavaScript, and Python).
Why CDK, and why now
The infrastructure-as-code landscape continues to fragment. Some teams standardize on Terraform. Others inherit CloudFormation stacks. And increasingly, we’re seeing a third pattern: engineering organizations choosing CDK as their strategic default for all new applications.
The logic is straightforward: when your backend runs TypeScript and your infrastructure is TypeScript, you eliminate an entire category of context-switching. Your developers can contribute to infrastructure without learning HCL. Your type system catches errors before deployment. Your constructs become shareable libraries with the same package management you already use.
AWS continues to invest heavily in CDK. Large enterprises tell us they’re standardizing on it precisely because it lets their teams stay in their native programming language. We’re hearing this especially from organizations that believe in self-service and want their application developers contributing to infrastructure without requiring them to learn a new language to do it.
How it works
When you connect a CDK repository to Infracost Cloud, we analyze your code directly. No pipeline changes required. No cdk synth output to manage. You just need to connect us to your repo.
We’ve built native parsing for TypeScript, JavaScript, and Python initially because they are the languages that make up the overwhelming majority of CDK usage. Under the hood, we’re running cdk synth: resolving your stacks, following your construct references, fetching the packages you depend on from npm, GitHub Packages, Artifactory or wherever they live.
The result is that Infracost can show you cost estimates for your main branch, and for every pull request, just like we do for Terraform and CloudFormation.
But we go further than cost estimates.
Policies that point to the problem
One of the most powerful capabilities in Infracost Cloud is policy enforcement — checking that infrastructure changes meet your organization’s FinOps and tagging standards before they’re merged.
With CDK support, these policies don’t just tell you that something is wrong. They show you exactly where to fix it!
When a tagging policy fails, we pinpoint the exact lines in your TypeScript or Python code that need to change. If your production environment tag says “Prod” when it should say “Production,” the PR comment links directly to the relevant lines in your source file.
This is shift-left in the truest sense: catching issues where engineers are already working, with enough context to fix them immediately.
Beyond costs: catching problems early
Because we run cdk synth, we can identify more than just infrastructure costs. If your code has issues that would cause synthesis to fail (for example duplicate construct names, invalid configurations, missing context values) we surface them in the PR before you discover them during deployment.
It’s faster feedback. Engineers see the problem while they’re still in the code review context, not after they’ve context-switched to deployment and have to trace back to figure out what went wrong.
The engineers who asked for this
We’ve again developed this in partnership with the engineers in our community and our Ustomers, working closely with them as they shared their use cases, requirements, and workflow contexts.
What we learned from those conversations shaped how we built this. The engineers using CDK aren’t looking for a separate tool or a new workflow. They want cost visibility that fits naturally into how they already work — in their IDE, in their pull requests, in the language they chose specifically to avoid tool sprawl.
That feedback, combined with what we learned building CloudFormation support, brought us here.
Get started
Already using Infracost Cloud?
CDK support is available now in early access. Connect your repositories containing CDK applications, and email hello@infracost.io to request early access.
New to Infracost?
Sign up for Infracost Cloud. It’s free to get started. Connect your preferred version control provider (GitHub, GitLab, or Azure Repos), add your CDK repositories, and email hello@infracost.io to request early access and experience shift-left cost visibility for the first time.
What’s next
This launch is Infracost Cloud-first. CLI and IDE support for CDK are on the roadmap for 2026 and we’ll share more as those pieces come together.
In the meantime, we want to hear from you. What’s working? What’s missing? What would make this even more useful for your team?
Join our community Slack and let us know. The best features start as conversations.
