Terraform Cost Estimation: Tools and How It Works
Terraform makes it easy to provision infrastructure fast, but without cost visibility built into your workflow, the bill is often the first sign that something went wrong. This guide covers what drives Terraform costs, how to estimate them, and which tools actually help.
terraform plan output, with no separate integration required.
Engineers can read a terraform plan and see exactly which resources are going to be created, changed, or destroyed, often down to the individual attribute. The graph is there. The diff is there. The intent is there. The missing signal, far too often, is the thing everyone eventually cares about: what that change is going to cost once it lands in AWS, GCP, or Azure.
Infrastructure changes move faster than billing systems. A larger instance type, another NAT gateway, a managed database left running in a preview environment, a storage class picked without thinking about access patterns, all of these can look ordinary in code and expensive on the invoice.
By the time actual costs show up in a cloud bill, the context has usually disappeared into merged pull requests, applied plans, and half-remembered Slack threads.
Effective Terraform cost estimation can close that loop earlier. It does not make cloud pricing simple (nothing does), and it should not be treated as a precise forecast. However, it gives engineers, reviewers, and FinOps practitioners cost information at the point where decisions are still cheap to change.
This guide covers what Terraform cost actually consists of, how HCP Terraform pricing fits into the picture, and which Terraform cost estimation tools are worth understanding before your next terraform apply.
What Terraform cost actually consists of
Terraform itself, meaning the open-source CLI, is free to use.
The real cost of Terraform is usually somewhere else, in the cloud resources the Terraform configuration creates, and in the tooling layer a team uses to manage plans, policy checks, remote state, CI/CD workflows, approvals, and visibility.
That distinction sounds obvious, but it is the source of a lot of confusion. Terraform code can create compute, storage, load balancers, managed databases, queues, caches, networking resources, DNS zones, logging pipelines, and cloud services whose pricing models vary by region, usage, redundancy, retention, throughput, and time.
Some resources are mostly baseline costs, such as an instance running for a month. Others depend heavily on usage patterns, such as data transfer, object storage requests, or serverless invocations.
A useful estimate has to read the plan, identify the supported resources, map those resources to public pricing data, and then make assumptions where the Terraform provider cannot know future usage.
Estimating and optimizing that cost is important. For example, the FinOps Foundation’s 2025 State of FinOps report surveyed 861 respondents representing about $69 billion in public cloud spend, with workload optimization and waste reduction named as the top priority for FinOps practitioners.
HCP Terraform pricing
HCP Terraform, formerly Terraform Cloud, is the managed platform layer around Terraform. It is where pricing can enter separately from cloud infrastructure costs, especially for teams using hosted runs, remote state, policy checks, run tasks, private registries, agents, and Terraform Enterprise-style governance.
HashiCorp now describes HCP Terraform pricing around managed resources, also called Resources Under Management, or RUM.
A managed resource is a resource in an HCP Terraform managed state file where mode = "managed", with exclusions for null_resource and terraform_data. HCP Terraform combines workspace and Stacks resources when calculating costs.
For Essentials pay-as-you-go billing, HashiCorp charges per managed resource per hour, partial hours are billed as a full hour, and the peak managed resources in that hour determine the charge.
The free Terraform plan has also changed. Legacy Free plan users needed to move to the enhanced Free tier by March 2026, and the enhanced Free tier includes up to 500 managed resources, unlimited users, and additional capabilities such as SSO, Sentinel, and OPA policy as code, run tasks, and agents.
HCP Terraform also includes native cost estimation, although it is disabled by default and must be enabled in organization settings. Once enabled, it runs between plan and apply, shows hourly and monthly cost estimates for estimable resources, displays the monthly delta, and can expose cost estimate data to Sentinel policy checks in the legacy policy execution mode.
However, some resources lack cost information, and unpredictable usage-based pricing reduces accuracy, which is essentially true of any cost estimation feature.
Terraform cost estimation tools
The best Terraform cost estimation tool depends on where the team wants cost visibility to appear.
Which do you want?
- Pull request comments in GitHub or GitLab
- A CLI they can run locally or inside a CI pipeline
- Cost guardrails in policy checks
- The output to appear directly inside the
terraform plan, without a separate integration
Here are some of the solutions.
Stategraph Cost
Stategraph Cost is our new solution built for teams that want cost visibility where they already review infrastructure changes, directly in the terraform plan output.
Unlike Infracost or Terracost, it does not require a separate integration, a separate CLI wrapper, or a separate CI/CD step. The estimate appears alongside the normal resource summary, which means the engineer reviewing the plan sees the infrastructure diff and the cost signal together.
Who it’s best for
It is best for teams already using Stategraph for Terraform state management, or evaluating Stategraph because they want better visibility across state files, plans, applies, and resources.
Stategraph as a whole offers state storage, insights, inventory, orchestration, PR-based plans, policy enforcement, drift detection, and cost estimates, with the solution running either as hosted SaaS or self-hosted infrastructure, depending on the deployment model.
Key features
Stategraph Cost’s key features are:
- Fast estimates that load in under a second, appearing in the
terraform planoutput with negligible performance impact - It provides actual cost versus original estimate within a day, using public pricing data from AWS, GCP, and Azure
- Monthly and hourly totals by state file
- Resource-level drill-down
- Filtering by provider, resource type, and tags.
Stategraph Cost’s initial estimations are directional rather than exact, which means they will not reflect enterprise pricing, custom pricing, reserved instances, every usage variable, or every discount arrangement between an organization and its cloud providers.
But that is the limitation of every cost estimation product. The advantage is that Stategraph Cost puts a useful estimate at the point of review, without asking teams to wire in another service before they get cost visibility. Plus, the tool compares estimates versus actuals shortly after usage.
Infracost
Infracost is a popular Terraform cost estimation solution, largely because it meets engineers where they already work, in the terminal, editor, CI/CD pipeline, and pull requests.
It parses Terraform HCL, plan JSON, CloudFormation templates, and AWS CDK projects, looks up pricing data, and produces cost estimates before infrastructure is deployed. The CLI auto-detects the IaC type and uses pricing data to estimate costs without requiring cloud credentials.
Who it’s best for
Infracost is best for teams that want PR-level cost diffs and FinOps policies inside established code review workflows.
Key features
- Monthly cost estimates
- Cost diffs
- GitHub, GitLab, and Azure DevOps integrations
- Support for AWS, Azure, and Google Cloud
- Policy or guardrail capabilities in Infracost Cloud
Its Cloud Pricing API covers public prices from AWS, Azure, and Google and contains more than 10 million prices, updated continuously as providers add, change, and deprecate pricing.
Infracost’s main strength is maturity. It is familiar, well-documented, and broadly integrated into CI/CD practices.
Its main weakness is that it remains a separate integration from Terraform itself. The workflow is still terraform plan plus another tool, another configuration surface, and usually another system to manage.
Infracost can handle usage-based resources through usage defaults or an infracost-usage.yml file, but that also highlights the estimation problem itself, because usage has to come from assumptions or historical data rather than the Terraform code alone.
Terracost by Cycloid
Terracost is a different kind of tool. It is an open-source Go library and CLI from Cycloid, licensed under MIT, built for estimating Terraform costs from the CLI and from Terraform plan data. The project describes itself as cloud cost estimation for Terraform in your CLI, with AWS, Azure, and GCP as topics in the repository.
Who it’s best for
Terracost is best for teams that want a building block rather than a packaged product.
Key features
- Open-source Go library and CLI for Terraform cost estimation
- Uses
terraform plandata to estimate resource costs - Shows how costs change between deployments
- Can read Terraform plan JSON, HCL, or tfstate files
- Matches Terraform resources to ingested cloud vendor pricing data
- Uses pricing data from AWS, GCP, and Azure
- Requires a MySQL-compatible database to store pricing data
- Works better as a building block for APIs, internal tooling, or standalone programs than as a fully managed product
The main strength of the solution is flexibility. If a platform team wants to build cost estimation into its own internal developer platform, Terracost gives them library-level primitives rather than forcing a SaaS workflow.
The downside is operational overhead. Pricing data has to be ingested and stored before plan estimation works, and the Go package documentation shows the need to generate a plan, convert it to JSON, open a MySQL backend, and then estimate the plan from that data. That is powerful, but it is not turnkey.
HCP Terraform cost estimation
The main advantage of this option is that it appears inside the workspace run flow, not as an external pull request bot or separate CLI step. When enabled, the output shows total monthly cost by default, with an expandable itemized list of resource costs and unestimated resources.
Who it’s best for
HCP Terraform cost estimation is best for teams already committed to HCP Terraform or Terraform Enterprise.
Key features
- Per-resource hourly and monthly cost estimates
- Monthly delta
- Support for many resources across AWS, GCP, and Azure
- An integration with Sentinel policy checks
The pros are obvious. If HCP Terraform already controls runs, remote state, policy checks, and approvals, then native cost estimation keeps cost information in the same workflow.
The cons are just as clear. Teams must be using HCP Terraform or Terraform Enterprise, cost estimation is disabled by default, and availability depends on the plan and policy execution model. It also appears in the HCP Terraform run UI rather than directly in the local terraform plan output, which affects teams that review plans outside that system.
Now, let’s compare the tools together.
| Tool | Best fit | Pros | Cons |
|---|---|---|---|
| Infracost | Teams that want PR comments, CI/CD integration, and FinOps policies around Terraform code | Mature ecosystem, AWS, Azure, and GCP support, strong pull request workflow, and usage override support | Separate integration, separate configuration, not embedded directly in terraform plan, estimate quality still depends on assumptions |
| Terracost | Platform teams building their own cost estimation tooling | Open-source, MIT licensed, usable as a Go library, flexible for internal platforms | Requires MySQL-compatible pricing data storage, more building blocks than a product, operational setup required |
| HCP Terraform cost estimation | Teams already using HCP Terraform or Terraform Enterprise | Native run flow integration, hourly and monthly estimates, Sentinel policy checks | Disabled by default, tied to HCP Terraform, plan, and policy model constraints |
| Stategraph Cost | Teams that want cost estimates directly in Terraform plan output and state-aware reporting | No separate integration needed, fast in-workflow estimates, state file reporting, resource drill-down, compares actuals vs. estimates | Directional estimates, public pricing data only |
Why we built Stategraph Cost
We built Stategraph Cost because the missing signal was obvious. Teams using Stategraph already had their Terraform plan output, state management, resource history, and infrastructure visibility in one place, but cost was still living somewhere else, usually after the fact, usually in a cloud console, and usually too late to shape the change that caused it.
The design choice was not to create another integration. There are already good standalone tools for that.
The Stategraph approach is to put cost estimation directly where the decision happens, next to the plan, next to the resources, next to the state file, and next to the workflow that engineers are already using. Stategraph Cost appears in the plan output rather than asking a team to adopt a separate review surface just to see a monthly cost.
Stategraph cost is not a billing system. It does not know every enterprise discount, every reserved instance, every savings plan, every committed use discount, or every future usage pattern. It uses public pricing data and Terraform resource information to produce a directional estimate, which means it is designed to answer whether this change is probably cheap, probably expensive, or probably worth a closer review.
A fast, in-workflow signal beats a precise number that arrives after the decision has already been applied. Regardless, you still get an actual vs. estimate comparison using daily refreshes from cloud providers, so your team can see not only what the plan was expected to cost, but how the deployed infrastructure behaved once real usage showed up.
Book a demo with us or start for free to try Stategraph.
Terraform cost estimation belongs in the review process
Terraform cost visibility does not have to live in a separate spreadsheet, and it should not arrive first as a billing surprise. Whether a team uses Infracost for pull request diffs, HCP Terraform cost estimation inside workspace runs, Terracost as a library for internal tooling, or Stategraph Cost embedded directly in the plan output, the goal is the same: cost as part of infrastructure review rather than as historical data.
A Terraform cost estimation will not make cloud pricing perfect, and it will not remove the need for FinOps practices, budget ownership, or cost guardrails, but it gives engineers better visibility before they create infrastructure, and that is where the leverage is.
Terraform cost estimation FAQs
Is Terraform cost estimation accurate?
Terraform cost estimation is directional, not exact. It is usually good at showing the relative cost impact of provisioned resources, especially compute, storage, managed databases, and other resources with clear baseline pricing, but it can differ from actual costs when usage patterns, data transfer, reserved instances, negotiated discounts, custom pricing, regional differences, or unsupported resources affect the bill.
Does Terraform have built-in cost estimation?
The open-source Terraform CLI does not include native cost estimation. HCP Terraform and Terraform Enterprise include a cost estimation feature that can show hourly and monthly estimates in the run flow when enabled, while tools such as Infracost, Terracost, and Stategraph Cost provide different ways to bring cost estimates into Terraform workflows.
Why do Terraform cost estimates differ from my actual cloud bill?
Terraform describes desired infrastructure, not future behavior. A plan can know that a storage bucket, database, instance, or load balancer will exist, but it may not know how much traffic will pass through it, how many requests it will serve, whether a reserved instance will apply, what enterprise discount the account receives, or whether another team will change usage after deployment.
As a result, the estimate is useful as an early warning and review signal, while the cloud bill remains the source of truth for actual costs.