DEV Community: Silas Stone

"Did I just spend $2,000?" Adding "Cost Guardrails" to Terraform

Silas Stone — Mon, 26 Jan 2026 15:46:11 +0000

The "SKU Blindness" Problem

I was debugging a slow app last week and decided to bump the VM size to improve performance.

I scanned the list and Standard_D64s_v3 looked perfect. I updated my Terraform code.

But then came the context switching.

I had to Alt-Tab out of my editor, open the Azure Pricing Calculator, select my region, search for the specific SKU, and do the math... just to figure out if this change was going to cost me an extra $50 or an extra $2,000.

It felt clunky. Hunting for pricing tables every time I changed a line of code wasn't a good idea.

The "Shift Left" Gap

I looked at existing solutions (like Infracost). They are powerful, but they often feel like a separate layer on top of the workflow—requiring separate CLI binaries, API keys, or parsing JSON outputs in a CI pipeline.

If the cost estimation happens inside the Terraform lifecycle, and treats cost just like any other resource attribute, it should catch expensive mistakes naturally during the plan phase, without needing external scripts.

To solve this, I built an open-source provider: terraform-provider-plancost.

Two Layers of Defense: Awareness & Blocking

I designed this provider to help in two distinct ways:

1. The "Soft" Guardrail: Visual Awareness

Because the cost is modeled as a resource in the Terraform state, we get Terraform's native visual diff for free.

When you change that SKU from B2s to D64s, Terraform presents the financial impact side-by-side with your infrastructure changes:

~ resource "plancost_estimate" "this" {
  ~ monthly_cost: "$41.00" -> "$3,200.00" (+7700%)
}

This immediate feedback acts as a sanity check: "Whoa, did I really mean to increase costs by 7000%?"

2. The "Hard" Guardrail: Budget Blocking

For the times when you (or a teammate) miss the visual warning, you can set a hard budget_limit.

If a planned deployment exceeds your defined threshold, the provider will block the deployment during the plan phase.

How to use it (in 30 seconds)

Here is how you can protect your wallet in 3 steps.

Step 1: Add the provider

(Currently supports Azure resources)

terraform {
  required_providers {
    plancost = {
      source = "plancost/plancost"
    }
  }
}

Step 2: Define your cost budget

Let's say this is a dev environment, and I don't want anyone creating resources that cost more than $500/month. We define a plancost_estimate resource to enforce this.

resource "plancost_estimate" "this" {
  working_directory = abspath(path.module)

  # The Safety Net: Block deployment if cost > $500
  guardrail {
    condition = "monthly_cost_budget"
    threshold = 500
    action    = "block"
  }
}

Step 3: Run Plan

Now, if I try to provision that expensive Standard_D64s_v3 VM, Terraform will stop me:

$ terraform plan

╷
│ Error: Guardrail Violation
│ 
│   with plancost_estimate.this,
│   on main.tf line 0, in resource "plancost_estimate" "this":
│ 
│ Monthly cost $1250.00 exceeds budget $500.00.
╵

The plan fails. The bad infrastructure is never created. Crisis averted.

Why I built this? (The "Cost as a Resource" Pattern)

I built this to experiment with the idea of treating FinOps data as a logical resource within the Terraform state (terraform.tfstate), rather than just metadata printed to the console.

It’s fully open-source (MPL 2.0) and available on the Registry.

GitHub: plancost/terraform-provider-plancost
Terraform Registry: plancost/plancost

See Cloud Costs Directly Inside terraform plan with plancost

Silas Stone — Thu, 22 Jan 2026 12:45:35 +0000

We've all experienced "Terraform Apply Anxiety."

You write your infrastructure code, the plan looks green, and you hit apply. A month later, the CFO (or your manager) slack messages you asking why the cloud bill just spiked by 40%.

For a long time, the solution to this was using external CLI tools. You know the drill: install a separate binary, wrap your CI pipeline, export the plan to JSON, parse it, and send it to a dashboard. It works, but it breaks the workflow. It feels like an add-on, not part of the infrastructure itself.

I built plancost to change that.

Today, I’m excited to announce the release of the plancost Terraform Provider.

What is plancost?

plancost allows you to estimate, track, and optimize cloud costs directly within your Terraform workflow.

Unlike other tools that function as CLI wrappers, plancost is a genuine Terraform Provider. This means:

Zero Extra Install: No brew install, no curl scripts, no separate binaries. It downloads with terraform init.
Native Experience: Cost estimates appear directly in your standard terraform plan output.
Cost as State: Cost data is stored in your state file, accessible to other resources.
Instant Diff: See exactly how much a change (like upgrading a VM SKU) will cost before you apply it.

Quick Start: Seeing is Believing

Let's see it in action. You don't need to sign up for anything to try it locally.

Here is a demo where I downgrade an Azure Kubernetes Service (AKS) node pool to save money. Notice how plancost catches the price difference instantly inside the plan output.

1. The Configuration

It takes seconds to set up. Just add the provider and the estimate resource to your main.tf.

terraform {
  required_providers {
    plancost = {
      source = "plancost/plancost"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
    }
  }
}

# This single resource enables cost estimation for your module
resource "plancost_estimate" "this" {
  working_directory = abspath(path.module)
}

2. The Result

When you run terraform plan, plancost scans your resources (like the AKS cluster below) and generates a cost breakdown.

The output is a native resource, so it shows up beautifully in your terminal or CI logs.

The Power of "Native Diff"

The real magic happens when you modify existing infrastructure. Because plancost is a resource, Terraform treats cost changes just like configuration changes.

In the example below, I am downgrading the AKS Node Pool from Standard_D2d_v4 to Standard_A2_v2. Terraform shows the config change, and plancost shows the money.

True "Cost as Code": Guardrails

Since we are inside the HCL configuration, we can enforce policies using code. No external policy engines (like OPA) are strictly necessary for basic checks.

You can define Guardrails to block a deployment if it exceeds your budget or if the cost spikes too aggressively.

resource "plancost_estimate" "this" {
  working_directory = abspath(path.module)

  # Fail the plan if total cost exceeds $1000
  guardrail {
    condition = "monthly_cost_budget"
    threshold = 1000
    action    = "block"
  }

  # Warn me if this specific plan increases cost by more than $50
  guardrail {
    condition = "monthly_cost_increase_amount"
    threshold = 50
    action    = "warning"
  }
}

If you violate the guardrail, terraform plan will actually fail with a clear error message:

Simplifies CI/CD

This is my favorite part. If you have ever tried to integrate cost tools into GitHub Actions or GitLab CI, you know the pain of managing API keys, downloading binaries, and scripting comments.

With plancost, if your pipeline can run terraform plan, it can run cost estimation. It works out of the box in Atlantis, Terraform Cloud, GitHub Actions, Jenkins, etc.

What's Next?

We are launching with robust support for Microsoft Azure, covering over 500+ resources—from standard VMs and SQL Databases to complex networking components.

👉 Check out the full list here: Supported Resources Guide

Our roadmap includes:

🚧 AWS Support (Coming soon)
🚧 GCP Support
✨ More Optimization Recommendations (Advanced right-sizing advice)

Try it out!

I’d love for you to try it out and let me know what you think.

Registry: registry.terraform.io/providers/plancost/plancost
GitHub: github.com/plancost/terraform-provider-plancost
Website: plancost.io

Drop a comment below if you have any feature requests or questions about the implementation! Happy coding (and saving)! 💸