How to Estimate AWS CDK Costs Before Deploying (4 Methods)

Learn how to estimate AWS CDK stack costs before deployment with 4 methods from native CloudFormation tools to automated CI/CD solutions.

January 5th, 2026
15 min read
0 views
--- likes

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:

  1. Workload Estimates: Free, available to all account types. Estimate costs for specific resources or applications.
  2. 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 estimate
  • BatchCreateWorkloadEstimateUsage: Add usage items in batch
  • BatchUpdateWorkloadEstimateUsage: 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:

  1. Install Amazon Q Developer CLI
  2. Install Python 3.10+ and supporting tools (Pandoc, uv)
  3. Configure the MCP server in ~/.aws/amazonq/mcp.json
  4. 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 data
  • generate_cost_report: Create detailed cost reports
  • analyze_cdk_project: Analyze CDK projects and estimate costs
  • get_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:

  1. Navigate to GitHub Marketplace - CloudBurn
  2. Click "Install" and select your repositories
  3. Grant the necessary permissions
  4. 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:

  1. Review the specific resources driving costs
  2. Consider right-sizing (smaller instance types, less storage)
  3. Evaluate Reserved Instances or Savings Plans for production workloads
  4. 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

FeatureCloudBurnCost Monitoring ConstructCDK Cost LimitInfracost
Pre-deployment estimationYesNoNoEarly Access
Post-deployment monitoringNoYesYesNo
CI/CD PR integrationYesNoNoYes
CDK supportYesYesYesEarly Access
Real-time pricingYesN/AN/AYes
Cost delta on changesYesN/AN/AYes
Open sourceNoYesYesPartial (CLI only)
PricingFree - $99/moFreeFree$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:

  1. Open AWS Console → Billing and Cost Management → Cost Explorer
  2. Select "Tag" as your primary grouping dimension
  3. Choose your activated cost allocation tag (e.g., "Project")
  4. 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 CompareWhere to Find It
Pre-deployment estimateCloudBurn PR comment or manual estimate
Actual monthly costCost Explorer filtered by stack tags
VarianceCalculate 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:

  1. Use historical Cost Explorer data to model variable costs
  2. Document usage assumptions in your architecture decisions
  3. Create multiple scenarios (low/medium/high traffic)
  4. Compare estimates to actuals monthly and adjust your models
  5. 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

  1. Always run cdk synth before deployment to catch synthesis errors
  2. Use cdk diff to understand changes before estimating costs
  3. Automate cost estimation in CI/CD so it happens on every PR
  4. Review estimates before merge as part of code review
  5. 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.

Frequently Asked Questions

How do I estimate costs for CDK stacks?
Use one of four methods: (1) CloudFormation estimate-template-cost for native AWS approach, (2) AWS Pricing Calculator for manual but accurate estimates, (3) Amazon Q CLI for AI-powered analysis, or (4) CloudBurn for automated CI/CD integration.
Can I see CDK costs before deploying?
Yes. The most automated approach is CloudBurn, which posts cost estimates directly in your pull requests before any code is deployed.
What's the cost of my CDK application?
Your CDK application cost consists of fixed costs (instance hours, provisioned capacity) and variable costs (data transfer, API calls). Fixed costs can be estimated from templates; variable costs require usage modeling. Use Cost Explorer after deployment to see actual costs.
How do I monitor CDK infrastructure costs?
Apply cost allocation tags via CDK, activate them in the Billing console, then use Cost Explorer to filter and analyze costs by tag. Set up AWS Budgets for automated alerts when spending exceeds thresholds.
Why doesn't AWS CDK have a native cost estimation command?
Despite community requests since 2018 (RFC #70), AWS has not prioritized this feature. AWS's focus has been on the CloudFormation layer rather than CDK-specific tooling. Third-party tools like CloudBurn have emerged to fill this gap.
How accurate are CDK cost estimates?
Fixed costs (EC2, RDS provisioned) are highly accurate. Variable costs (data transfer, Lambda) cannot be estimated from templates alone. Overall accuracy improves when you combine template-based estimation with usage assumptions from historical data.

Share this article on ↓

Subscribe to our Newsletter