You've written a CDK stack. It's ready to deploy. But how much will it cost?
If you're expecting a simple cdk estimate command, you're in for a surprise. AWS doesn't have one. Despite five years of community requests, there's no native CDK cost estimation tool. That RFC from 2018? Still open, with comments like "5 years on...and still no viable tool is very disappointing."
But here's the good news: you don't have to deploy blind. By the end of this guide, you'll know exactly how to estimate CDK stack costs using four different methods, from native AWS workarounds to automated CI/CD solutions that catch expensive changes in pull requests before they hit production.
The CDK Cost Estimation Problem (Why No Native Tool Exists)
Before diving into solutions, it helps to understand why this problem exists in the first place. AWS has invested heavily in CDK as their modern Infrastructure as Code solution, yet cost estimation remains an afterthought.
The 5+ Year Gap in AWS Tooling
The timeline tells the story. RFC #70 was opened in 2018, requesting cost estimation capabilities for CDK. As of January 2026, it's still open with 53+ upvotes and growing frustration from the community.
AWS's focus has been on the CloudFormation layer rather than CDK-specific tooling. While CloudFormation has a basic estimate-template-cost API, CDK users are left to piece together their own workflows. This gap creates real pain for teams trying to implement FinOps practices or get cost approval before deploying new infrastructure.
How CDK Synthesis Creates the Opportunity
Here's the key insight that makes cost estimation possible: CDK synthesizes to CloudFormation templates.
When you run cdk synth, the CDK CLI executes your application code and produces a cloud assembly that includes CloudFormation templates for each stack. These templates are saved to the cdk.out/ directory in JSON format, containing all resource configurations like instance types, storage sizes, and capacity settings.
cdk synth
ls cdk.out/
# MyStack.template.json
# manifest.json
# tree.json
This is the hook. If you can parse CloudFormation templates, you can estimate costs. Every method I'll show you leverages this synthesized output in some way.
Method 1: CloudFormation estimate-template-cost (Native AWS Approach)
The only native AWS solution for pre-deployment cost estimation is the CloudFormation EstimateTemplateCost API. It's not perfect, but it works without any third-party tools.
Step-by-Step Workflow
The process is straightforward but manual:
Step 1: Synthesize your CDK app:
cdk synth
Step 2: Locate your template in the output directory:
ls cdk.out/MyStack.template.json
Step 3: Run the estimate command:
aws cloudformation estimate-template-cost \
--template-body file://cdk.out/MyStack.template.json
Step 4: Open the returned URL to view estimates. The output looks like:
{
"Url": "http://calculator.s3.amazonaws.com/calc5.html?key=cf-2e351785-e821-450c-9d58-625e1e1ebfb6"
}
Example with TypeScript CDK Stack
Let's walk through a real example. Here's a simple CDK stack with an EC2 instance and S3 bucket:
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';
export class MyAppStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, 'VPC', {
maxAzs: 2
});
new ec2.Instance(this, 'WebServer', {
vpc,
instanceType: ec2.InstanceType.of(
ec2.InstanceClass.T3,
ec2.InstanceSize.MEDIUM
),
machineImage: ec2.MachineImage.latestAmazonLinux2()
});
new s3.Bucket(this, 'Assets', {
versioned: true
});
}
}
After running cdk synth && aws cloudformation estimate-template-cost --template-body file://cdk.out/MyAppStack.template.json, you'll get a calculator URL pre-filled with your EC2 instance type, VPC resources, and S3 configuration.
Limitations of This Approach
This native method has significant limitations you need to know about:
- Only returns a URL: No programmatic access to cost data. You must manually navigate to the URL to view estimates.
- Links to legacy calculator: The Simple Monthly Calculator it links to is outdated compared to the modern Pricing Calculator.
- Template size limit: The template body must be under 51,200 bytes. Larger templates need S3 hosting.
- No CI/CD integration: Requires manual execution for each change.
- Fixed costs only: Variable costs like data transfer and API calls aren't captured.
For a quick sanity check during development, this works. For production workflows, you need something more automated.
Method 2: AWS Pricing Calculator (Manual but Accurate)
When you need accurate estimates that account for Reserved Instances, Savings Plans, or complex pricing scenarios, the AWS Pricing Calculator is your best option.
Enhanced Pricing Calculator Features (2025)
The authenticated AWS Pricing Calculator (generally available since May 2025) offers significantly more capabilities than the public version:
Two types of estimates:
- Workload Estimates: Free, available to all account types. Estimate costs for specific resources or applications.
- Bill Estimates: Available to management or standalone accounts. First 5 per month free, then $2 each. Shows impact on your entire consolidated bill including existing commitments.
Rate configuration options:
- Before discounts (on-demand pricing)
- After discounts (negotiated pricing)
- After discounts and purchase commitments (Savings Plans, Reserved Instances)
This lets you see the real impact of your pricing strategy on new infrastructure.
Using the Pricing Calculator API Programmatically
The Pricing Calculator API enables programmatic access to cost estimates. Key operations include:
CreateWorkloadEstimate: Create a new estimateBatchCreateWorkloadEstimateUsage: Add usage items in batchBatchUpdateWorkloadEstimateUsage: Update existing items
Each usage item requires a service code (like "AmazonEC2"), usage type, and amount. The response includes totalCost in USD.
Integration opportunity: With custom tooling, you could parse CloudFormation templates, map resources to pricing dimensions, and call this API to generate estimates. It's not trivial, but it's possible for teams with specific requirements.
When to Use This Approach
The Pricing Calculator is best for:
- New architecture planning: Model costs before writing any CDK code
- Pricing scenario modeling: Compare Reserved Instances vs Savings Plans vs on-demand
- Executive presentations: Create shareable estimates with detailed breakdowns
- Complex pricing analysis: When you need accuracy over automation
The trade-off is clear: high accuracy, zero automation.
Method 3: Amazon Q CLI with AWS Pricing MCP Server
Amazon Q CLI with the AWS Pricing MCP server represents AWS's newest approach to cost estimation. It uses the Model Context Protocol (MCP) for AI-powered analysis.
Setup and Configuration
Getting started requires several components:
- Install Amazon Q Developer CLI
- Install Python 3.10+ and supporting tools (Pandoc, uv)
- Configure the MCP server in
~/.aws/amazonq/mcp.json - Set up AWS credentials with appropriate permissions
Here's what the MCP configuration looks like:
{
"mcpServers": {
"aws-pricing": {
"command": "uvx",
"args": ["--from", "aws-pricing-mcp", "aws-pricing-mcp"],
"env": {
"AWS_REGION": "us-east-1",
"FASTAPI_MCP_DEBUG": "false"
}
}
}
}
This configuration tells Amazon Q where to find the pricing MCP server and which AWS region to use for pricing queries. The server runs locally and connects to AWS pricing APIs on your behalf.
The MCP server provides several tools:
get_pricing: Retrieve real-time AWS pricing datagenerate_cost_report: Create detailed cost reportsanalyze_cdk_project: Analyze CDK projects and estimate costsget_bedrock_patterns: Get cost patterns for Amazon Bedrock
Analyzing CDK Projects
Once configured, you interact using natural language:
"Analyze my CDK project and estimate monthly costs"
The output includes:
- Service costs breakdown
- Unit pricing details
- Usage quantities
- Calculation methodology
- Assumptions and exclusions
- Optimization recommendations
This last point is valuable. Unlike other methods that just tell you what things cost, Amazon Q can suggest cheaper alternatives.
Advantages and Limitations
Advantages:
- Automated analysis of entire project structure
- Real-time pricing data (not cached or outdated)
- Optimization recommendations included
- Natural language interface reduces friction
Limitations:
- Relatively new (still emerging adoption)
- Requires setup and configuration
- Learning curve for MCP concepts
- Availability may vary by region
For teams already using Amazon Q, this is worth exploring. For everyone else, the setup overhead might not justify the benefits.
Method 4: CloudBurn - Automated Pre-Deployment Cost Estimation
The first three methods require manual effort. CloudBurn automates cost estimation directly in your development workflow, posting estimates as PR comments.
Key capabilities:
- Automatic cost estimates on every PR
- Cost delta showing impact of changes
- Service-by-service breakdown
- Works with existing GitHub workflows
- Uses official AWS Pricing API for accuracy
Pricing that makes sense for teams of any size:
- Community: Free forever (1 repository)
- Starter: $29/month (5 repositories)
- Team: $49/month (10 repositories)
- Business: $99/month (25 repositories)
For a behind-the-scenes look at how we built CloudBurn and the challenges we solved, check out our lessons learned post.
Why Shift-Left FinOps Matters
Cost surprises in production are expensive and disruptive. By the time you see the bill, the damage is done. Engineers who made the infrastructure decisions have moved on to other work. Fixing an expensive deployment takes weeks of planning and careful migration.
Shift-left FinOps flips this equation. When cost estimates appear in pull requests:
- Engineers see cost impact during code review
- Expensive decisions are caught when they take seconds to fix
- Team builds cost awareness naturally through daily workflow
- No separate FinOps review process needed
This aligns with the AWS Well-Architected Framework Cost Optimization pillar, which emphasizes understanding spending at the point of decision.
Installing the CloudBurn GitHub App
Setup takes about two minutes:
- Navigate to GitHub Marketplace - CloudBurn
- Click "Install" and select your repositories
- Grant the necessary permissions
- CloudBurn automatically starts analyzing PRs
For detailed configuration options, see the CloudBurn documentation.
GitHub Actions Workflow Configuration
CloudBurn works with your existing CDK workflow. Here's an example:
name: CDK Cost Estimation
on:
pull_request:
branches: [main]
jobs:
estimate:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
- name: CDK Synth
run: npx cdk synth
# CloudBurn automatically analyzes cdk.out/ and posts cost comment
Interpreting Cost Estimates in Pull Requests
CloudBurn posts a comment on your PR with:
- Total monthly cost estimate for the proposed infrastructure
- Cost delta showing increase or decrease from current state
- Service breakdown itemizing costs by AWS service
- Resource-level details for high-cost items
When costs are higher than expected, you can:
- Review the specific resources driving costs
- Consider right-sizing (smaller instance types, less storage)
- Evaluate Reserved Instances or Savings Plans for production workloads
- Discuss trade-offs with your team before merging
Other Third-Party Tools for CDK Cost Estimation
While CloudBurn focuses on pre-deployment PR integration, other tools address different parts of the cost visibility problem. Here's how they compare.
Cost Monitoring Construct: Post-Deployment Monitoring
The Cost Monitoring Construct from DataChef is an open-source CDK library for monitoring costs after deployment.
Features:
- Set budgets and alerts
- Generate cost reports for stakeholders
- Free and open-source
Important distinction: This is post-deployment monitoring, not pre-deployment estimation. It complements rather than replaces pre-deployment tools like CloudBurn.
CDK Cost Limit: Budget Enforcement
CDK Cost Limit enforces cost limits on CDK stacks and can disable resources exceeding limits. It's useful for development and testing environments where you want hard spending caps.
Infracost: Terraform Leader (CDK Support in Early Access)
Infracost is the market leader for Terraform cost estimation. CDK/CloudFormation support is now in early access.
Pricing comparison is critical:
- Infracost Cloud: $1,000/month
- Infracost CI/CD: $250/month for 10k runs
- CloudBurn Starter: $29/month (or free forever for 1 repository)
The open-source CLI is available, but key features like CI/CD integration and cloud dashboard require paid plans.
Tool Comparison Matrix
| Feature | CloudBurn | Cost Monitoring Construct | CDK Cost Limit | Infracost |
|---|---|---|---|---|
| Pre-deployment estimation | Yes | No | No | Early Access |
| Post-deployment monitoring | No | Yes | Yes | No |
| CI/CD PR integration | Yes | No | No | Yes |
| CDK support | Yes | Yes | Yes | Early Access |
| Real-time pricing | Yes | N/A | N/A | Yes |
| Cost delta on changes | Yes | N/A | N/A | Yes |
| Open source | No | Yes | Yes | Partial (CLI only) |
| Pricing | Free - $99/mo | Free | Free | $250-$1,000/mo |
Post-Deployment Cost Monitoring
Pre-deployment estimation tells you what infrastructure should cost. Post-deployment monitoring tells you what it actually costs. You need both for complete cost visibility.
Cost Allocation Tags in CDK
Tags are the foundation of post-deployment cost tracking. Apply them at the stack level for automatic propagation:
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
export class CostTrackedStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// Apply cost allocation tags at stack level
cdk.Tags.of(this).add('Environment', 'Production');
cdk.Tags.of(this).add('CostCenter', 'Engineering');
cdk.Tags.of(this).add('Project', 'WebApplication');
cdk.Tags.of(this).add('Owner', 'platform-team@example.com');
// All resources in this stack inherit these tags
}
}
Critical step: After deploying, activate your tags in the Billing and Cost Management console. Tags take up to 24 hours to appear in cost reports after activation.
Tag limits to remember:
- Up to 50 tags per stack
- Keys up to 127 characters
- Values up to 255 characters
- Cannot use
aws:prefix (reserved for AWS-generated tags)
Setting Up AWS Budgets via CDK
Define budgets as part of your infrastructure code:
import * as budgets from 'aws-cdk-lib/aws-budgets';
import * as cdk from 'aws-cdk-lib';
export class BudgetStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
new budgets.CfnBudget(this, 'MonthlyBudget', {
budget: {
budgetName: 'monthly-infrastructure-budget',
budgetType: 'COST',
timeUnit: 'MONTHLY',
budgetLimit: {
amount: 1000,
unit: 'USD'
},
costFilters: {
TagKeyValue: ['user:Project$WebApplication']
}
},
notificationsWithSubscribers: [
{
notification: {
notificationType: 'ACTUAL',
comparisonOperator: 'GREATER_THAN',
threshold: 80,
thresholdType: 'PERCENTAGE'
},
subscribers: [{
subscriptionType: 'EMAIL',
address: 'team@example.com'
}]
},
{
notification: {
notificationType: 'FORECASTED',
comparisonOperator: 'GREATER_THAN',
threshold: 100,
thresholdType: 'PERCENTAGE'
},
subscribers: [{
subscriptionType: 'EMAIL',
address: 'team@example.com'
}]
}
]
});
}
}
Budget pricing: First 2 budgets free, then $0.002/day (~$0.06/month) for additional budgets.
Using Cost Explorer for Deployed Stacks
Once tags are activated, Cost Explorer becomes powerful. Here's a practical workflow:
Navigate to Cost Explorer:
- Open AWS Console → Billing and Cost Management → Cost Explorer
- Select "Tag" as your primary grouping dimension
- Choose your activated cost allocation tag (e.g., "Project")
- Filter to your specific CDK stack or application
Useful views for CDK cost analysis:
- Daily costs by service: Identify which AWS services drive spending for your stack
- Monthly trend by tag: Track how costs evolve as your application scales
- Cost by resource: Drill down to specific resources when costs spike unexpectedly
Compare estimates to reality:
| What to Compare | Where to Find It |
|---|---|
| Pre-deployment estimate | CloudBurn PR comment or manual estimate |
| Actual monthly cost | Cost Explorer filtered by stack tags |
| Variance | Calculate the delta and investigate differences |
This feedback loop is essential. Regular comparison of estimates to actuals helps you refine future estimates, catch pricing model changes, and identify optimization opportunities. If actual costs consistently exceed estimates, your usage patterns may differ from assumptions, or you might have resources provisioned larger than necessary.
Understanding CDK Cost Estimation Limitations
Honest expectations lead to better outcomes. Here's what cost estimation can and cannot do.
Fixed Costs vs Variable Costs
Fixed costs (estimable from templates):
- EC2 instance hours
- RDS provisioned capacity
- EBS volume storage
- NAT Gateway hourly charges
- Provisioned DynamoDB capacity
Variable costs (cannot be predicted from templates):
- Data transfer between services and regions
- API request volumes
- Lambda execution time and memory
- S3 request costs
- DynamoDB on-demand reads/writes
- CloudWatch log ingestion
Templates contain fixed cost information. Variable costs require usage modeling based on traffic patterns, user behavior, and historical data.
What Cannot Be Estimated
Be aware of these blind spots:
- Cross-region data transfer: Templates don't capture traffic patterns
- API call volumes: Depends on application behavior
- Lambda execution time: Varies by code efficiency and input size
- S3 request costs: Based on access patterns
- Third-party marketplace costs: Not covered by AWS pricing APIs
- Support plan costs: Separate from infrastructure
Multi-stack estimation challenges: If your application spans multiple CDK stacks (common in larger architectures), you'll need to estimate each stack separately and sum the results. Cross-stack dependencies like data transfer between stacks sharing a VPC, or Lambda functions invoking resources in another stack, add complexity that most tools don't automatically capture. For accurate multi-stack estimates, document inter-stack communication patterns and model those costs manually.
Improving Estimate Accuracy
To get closer to actual costs:
- Use historical Cost Explorer data to model variable costs
- Document usage assumptions in your architecture decisions
- Create multiple scenarios (low/medium/high traffic)
- Compare estimates to actuals monthly and adjust your models
- Add buffer for variable costs (20-30% is reasonable for new projects)
Best Practices for CDK Cost Analysis
Let me share what actually works in production environments.
Pre-Deployment Estimation Workflow
- Always run
cdk synthbefore deployment to catch synthesis errors - Use
cdk diffto understand changes before estimating costs - Automate cost estimation in CI/CD so it happens on every PR
- Review estimates before merge as part of code review
- Set cost thresholds for changes that require additional approval
Tagging Strategy for Cost Tracking
Consistent tagging is non-negotiable for cost visibility:
import { IAspect, Annotations, Tags } from 'aws-cdk-lib';
import { IConstruct } from 'constructs';
import * as cdk from 'aws-cdk-lib';
export class RequiredTagsAspect implements IAspect {
constructor(private requiredTags: string[]) {}
visit(node: IConstruct): void {
if (node instanceof cdk.CfnResource) {
// Validate required tags exist
const stack = cdk.Stack.of(node);
for (const tag of this.requiredTags) {
// Add validation or enforcement logic
}
}
}
}
// Apply to your app
const app = new cdk.App();
const stack = new MyStack(app, 'MyStack');
cdk.Aspects.of(stack).add(
new RequiredTagsAspect(['Environment', 'CostCenter', 'Project', 'Owner'])
);
Development Workflow Integration
- Local estimation during development: Run cost checks before committing
- PR cost comments: Visible to entire team during review
- Cost gates: Consider blocking deployments above certain thresholds
- Sprint retrospectives: Include cost review as a regular agenda item
Conclusion
AWS has no native CDK cost estimation tool, but that doesn't mean you have to deploy blind. Whether you use the native CloudFormation API for quick checks, AWS Pricing Calculator for detailed analysis, Amazon Q CLI for AI-powered insights, or CloudBurn for automated CI/CD integration, you have options.
My recommendation: start with automated cost estimation in your pull requests. It's the highest-impact change you can make for cost visibility, and it builds cost awareness naturally into your team's workflow.
Post-deployment monitoring via tags and budgets complements this perfectly, giving you the full picture of what infrastructure should cost versus what it actually costs.
Have you implemented cost estimation in your CDK workflow? I'd love to hear what's working for your team in the comments below.
Stop Deploying Blind: Get Cost Visibility in Every PR
CloudBurn analyzes your CDK infrastructure changes and posts cost estimates directly in pull requests. Works with AWS CDK and Terraform. Free tier available.