Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Contracts Now Meter Your Terraform Plan Runs
Transcript
- Lucas: If these conversations are useful for what you're building or running, this is an episode you're gonna want to hear. We're talking about a new line item that's quietly showing up on cloud bills — charges for running Terraform plans. Luna: Terraform plans. As in, the 'terraform plan' command you run a hundred times a day to preview infrastructure changes before applying them? Lucas: Exactly that. AWS has started metering plan runs in Terraform Cloud and Terraform Enterprise. And we're not talking about a rounding error. I've seen a case where a mid-size company got hit with an eight-thousand-dollar quarterly charge just for plan operations. Luna: That's significant. So let's back up — how did we get here? Who's actually charging for this? Lucas: Right. So the mechanism is interesting. It's not AWS directly billing you per plan run on the AWS invoice. It's Terraform Cloud — HashiCorp's SaaS platform — that now charges based on the number of plan runs you execute. And because most Terraform Cloud users are managing AWS infrastructure, the cost shows up as a line item in your overall cloud spend. Luna: Okay, but HashiCorp has always had licensing tiers. What changed? Lucas: What changed is that in 2023, HashiCorp switched from the Mozilla Public License to the Business Source License, or BSL. That move was largely about protecting their commercial products like Terraform Cloud and Vault. But the less-discussed follow-up: they started refining how they meter usage on the cloud platform. And plan runs became a metered unit. Luna: So the 'terraform plan' command — which developers run constantly during development, CI/CD, code reviews — now has a per-run cost attached. Lucas: That's the core of it. In Terraform Cloud, every time you run a plan — whether it's triggered by a pull request, a scheduled run, or a manual execution — it counts toward your consumption. Each plan consumes one 'run credit,' and once you exceed the number included in your tier, you start paying per additional run. Luna: What are the actual numbers? Give us a sense of scale. Lucas: So the free tier of Terraform Cloud gives you a certain number of runs per month — I believe it's around 500 for the free tier. The Team tier starts at about $20 per user per month and includes a higher run allowance. But for enterprises running hundreds of workspaces with continuous deployment, the overage can pile up fast. Luna: And you said eight thousand dollars a quarter. Walk us through that case. Lucas: This was a company with about 150 Terraform workspaces, each running multiple plans per day. They had a mix of scheduled runs, pr driven plans, and manual runs for troubleshooting. They were on the Team tier, but their run volume was around 25,000 runs per month. The included runs in their plan covered maybe 5,000. The overage — at roughly 10 cents per additional run — added up to about $2,000 per month. Over a quarter, that's $6,000 in overage fees plus the base subscription. Luna: And this is just for the plan phase. Not even the apply. Lucas: Correct. The apply is a separate operation and also consumes credits. So if you're doing a full plan and apply workflow for every change, you're burning two credits per deployment. This company was heavy on iterative development, so they were running plans frequently without always applying. Luna: Which is exactly how infrastructure as code is supposed to work — plan early, plan often, catch problems before they hit production. Now that workflow has a cost. Lucas: And that's the tension. HashiCorp and AWS — since Terraform Cloud runs on AWS infrastructure, by the way — are essentially monetizing what was previously a friction-free operation. The argument from the provider side is that each plan consumes compute, storage, and network resources. But for teams, it feels like a tax on good practices. Luna: Let's zoom out. Is this a Terraform-specific issue, or are we seeing broader industry movement toward metering the tooling layer? Lucas: It's broader. Last year, GitHub started charging for Actions minutes beyond the free tier. GitLab has compute minutes for CI/CD. Even providers like Datadog meter API calls. So the pattern is: once you're locked into a platform, the platform starts charging for the operations you perform on it. Luna: The thing is, with Terraform, there's an open-source alternative — the Terraform CLI that talks directly to providers without going through Terraform Cloud. So why are teams still paying for this? Lucas: Because the value of Terraform Cloud isn't just running plans. It's state management, remote execution, collaboration, policy enforcement with Sentinel or OPA, and integration with version control. Once you have a team of ten or more engineers managing hundreds of resources, the operational complexity of managing your own state backend and coordinating applies becomes significant. So teams trade that complexity for a metered service. Luna: So the question becomes: how do you manage those costs without losing the benefits? Lucas: There are a few strategies. First, plan caching. Terraform Cloud has a feature called 'plan caching' that can reuse a cached plan if the configuration and variables haven't changed. That reduces redundant runs. Second, consolidating workspaces — fewer workspaces means fewer independent runs. Third, adjusting your run triggers: only run plans on PRs that actually change Terraform code, not on every commit. Luna: But that third one — selective triggering — requires discipline. Developers often push a PR just to trigger a plan to see if their changes are valid. That's a cultural shift. Lucas: Absolutely. And it's the kind of shift that FinOps teams are now having to manage. Cost optimization for infrastructure as code is a relatively new domain. A year ago, nobody was thinking about the cost of a 'terraform plan.' Now it's a line item. Luna: Before we go deeper, I want to acknowledge something. If you're listening and this kind of granular breakdown is useful for your work — understanding how cloud contracts are evolving, how to spot new charges before they blindside your finance team — this podcast stays ad-free because of listener support. If you find value in what we do, you can keep it going at buy me a coffee dot com slash fexingo. No pressure, it's just a way to help us keep doing episodes like this. Lucas: Yeah, and we appreciate that. It's what lets us dig into these topics without any sponsor influence. So, back to the metering of plan runs — one of the more subtle implications is how this changes the economics of multi-cloud. Luna: How so? Lucas: If you're running Terraform Cloud to manage resources across AWS, Azure, and GCP, every plan run costs the same regardless of which cloud provider it targets. But the cost of the underlying resources you're provisioning varies. So you might have a team that runs a lot of plans for a small AWS workload, and another team that runs few plans for a large GCP workload. The billing per plan run doesn't differentiate. Luna: So the plan run cost is a fixed overhead that lands hardest on teams that iterate rapidly, regardless of the actual infrastructure spend. Lucas: Exactly. That creates an incentive to batch changes or reduce plan frequency, which can slow down development velocity. It's a trade-off that FinOps teams have to model. Luna: Is there any competitive pressure that might force HashiCorp to change this? For example, alternatives like Pulumi or Crossplane? Lucas: Pulumi has a SaaS offering called Pulumi Cloud that includes state management and deployment, but they charge per user, not per operation. So far, they haven't metered plan runs. Crossplane is fully open-source and doesn't have a managed offering yet. So HashiCorp's pricing model is somewhat unique in this space. But if enough customers complain, they might adjust the thresholds. Luna: Do you think this is going to become the norm across all infrastructure as code platforms? Lucas: I think it's likely. Cloud providers are looking for new revenue sources as growth in core compute and storage slows. Metering the operations layer — API calls, plans, scans — is a way to extract more value from existing customers. We saw AWS introduce charges for things like VPC flow logs and CloudTrail events. So adding plan run charges fits the pattern. Luna: What should a team do today to get ahead of this? Lucas: First, audit your current run volume. Terraform Cloud has usage reports that show how many runs per workspace per month. Identify workspaces with high plan to apply ratios — those are the ones generating cost without value. Second, implement plan caching and workspace consolidation. Third, consider whether you need Terraform Cloud for every workspace. Some teams use the open-source Terraform CLI with a remote state backend for non-critical projects. Luna: And if you're already over budget, any negotiation leverage? Lucas: HashiCorp does offer custom pricing for large enterprises. If you're a significant customer, you can negotiate a higher included run allowance or a lower per-run rate. But that requires having a relationship with their sales team and being willing to commit to a multi-year contract. Luna: So the lesson here is: treat plan runs as a metered resource, just like compute or storage. Track them, optimize them, and factor them into your cloud cost forecasts. Lucas: Exactly. And as more providers follow this path, the ability to manage the cost of operations themselves — not just the infrastructure — will become a core FinOps skill. Luna: Alright, we'll be back next week with another angle on the evolving cloud contract landscape. Thanks for listening.