I want to start by saying: HCP Terraform is not the Terraform CLI that I’ve used for years building automation pipelines on Azure DevOps or GitHub Actions - it’s the hosted service of Terraform operated by HashiCorp. 

I like HCP Terraform, and I especially like Stacks. I’ve been using them for a while now, since before Stacks became generally available, and I’ve been running real workloads with meaningful scale. 

This article isn’t written from the perspective of a drive‑by critic. It’s written from the perspective of someone who is actively using the platform and wants it to succeed. 

That context matters, because when the recent wave of chatter about the HCP Terraform Free Tier erupted - sparked in large part by a Reddit post claiming a jump from $0 to $15,000 per year - I didn’t want to react emotionally. I wanted to understand what was actually happening, why people were seeing these numbers, and whether the pricing model made sense when applied to modern cloud workloads.

What I landed on is this: the problem isn’t the Free Tier changing. The problem is the RUM (Resource Unit of Management) pricing model itself, and the incentives (and disincentives) it creates. 

Not because it’s expensive in every case - it isn’t - but because it actively discourages Terraform usage in ways that run counter to both HashiCorp’s goals and their customers’ goals. That’s a lose‑lose outcome.

RUM Pricing and the Reality of Modern Cloud Infrastructure

RUM pricing charges per managed resource per hour, using the hourly peak resource count. Conceptually, this sounds straightforward. In practice, it collides badly with how cloud infrastructure has evolved.

The early cloud era was dominated by large, coarse‑grained primitives: VMs, networks, load balancers. Counting resources felt roughly aligned with “size.” But modern cloud platforms are built from fine‑grained configuration objects. Many “resources” today are little more than rows in a control-plane database: role assignments, API definitions, event subscriptions, policy bindings.

When Terraform manages those configurations, each one becomes a billable unit. The effect is subtle but important: the pricing model begins to penalize completeness and correctness, rather than scale.

This is especially visible when you implement best practices like least privilege. Doing identity and access management properly often requires many small, narrowly scoped role assignments. Each of those is cheap for the cloud provider to host. Each of those is cheap for HashiCorp to store and process. But under RUM, each one carries the same recurring cost as a much heavier resource.

The result is not runaway bills for everyone - but a persistent pressure to ask the wrong question.

The Wrong Question: “Is This Worth Automating?”

Terraform’s value proposition has always been clear:

  • Declarative infrastructure
  • Reproducibility
  • Drift detection
  • Safe refactors
  • No snowflakes
  • No ClickOps

RUM pricing subtly reframes that value proposition. Instead of asking, “Should this be managed as code?” teams start asking, “Is this worth paying for it every month?”

That shift is clutch. It discourages bringing certain classes of resources under Terraform management, not because Terraform is a bad fit, but because the pricing model makes them feel economically irresponsible. Identity, RBAC, API definitions, monitoring checks - these are exactly the areas where drift and tribal knowledge cause long‑term pain, yet they’re often the first things teams pull out of Terraform to control RUM counts.

That outcome isn’t good for customers, because more configuration is handled by bespoke or even worse, manual activity. It’s also not good for HashiCorp - less Terraform usage, more usage of other tools but probably most importantly he automation first ethos and culture they might’ve burgeoned and thrived is squashed. This culture is what makes Hashicorp customers sticky.

When I read the Mr. Notoriousbpg’ post on reddit, I paused. My gut instinct? He’s likely using a ton of lightweight resources, the kind of “cloud-native” primitives that are little more than records in a database.

As a result, the product he built on AWS and automated and managed through HCP Terraform costs $700 a month to run on AWS but it costs $1,300 a month to operate it on HCP Terraform! He is not getting $1,300 a month of value from HCP Terraform when he could pay $0.50 a month in S3 to host the state file and $1.00 a month on Github Actions minutes. He knows this. Which means he translates this roughly to HCP Terraform’s own hosting costs on AWS and realizes that HCP Terraform is charging him 900 X what it costs them to host. This makes him extremely pissed off.

And this perfeclt illustrates the heart of the issue: Terraform’s RUM (Resource Unit of Management) pricing model doesn’t make sense.

A Practical Example from a Real Workload

Now let’s look at our workload that I built where the economic impact is not so asymmetric. I’ve currently configured three main projects across several stacks:

  • corporate-governance: Manages Azure Policies and Defender for Cloud.
  • corporate-infrastructure: Currently just contains a global Virtual WAN.
  • main workload: This is the largest, with 13 stacks, each managing different parts of a microservice. The dev environment provisions 421 resources total.

Alt

Stack Components

  • access-control: Implements least-privilege RBAC
  • api: Connects to a pre-existing API Management instance
  • dependencies: References shared infrastructure
  • global: Shared resources across regions
  • regional-stamp: A single region deployment (one per region, currently one deployed)

Here is the detailed breakdown of all the resources that I provision across these stacks.

- access-control
  - [3] azuread_group
  - [6] azuread_group_member
- api
  - [1] azurerm_api_management_api
  - [1] azurerm_api_management_api_policy
  - [1] azurerm_api_management_product_api
- dependencies
  - [1] azurerm_role_assignment
- global
  - [1] azurerm_resource_group
  - [1] azurerm_monitor_action_group
  - [1] azurerm_monitor_activity_log_alert
  - [1] azurerm_container_registry_task
  - [2] azurerm_cosmosdb_sql_container
  - [1] random_string
- regional-stamp
  - [1] azurerm_resource_group
  - [1] azurerm_user_assigned_identity
  - [2] azurerm_cognitive_account
  - [2] azurerm_cognitive_deployment
  - [14] azurerm_role_assignment
  - [1] azurerm_api_management_backend
  - [1] azurerm_container_app
  - [1] azurerm_container_app_environment
  - [1] random_uuid
  - [1] azurerm_cosmosdb_sql_role_assignment
  - [1] azurerm_storage_account
  - [1] azurerm_storage_queue
  - [2] azurerm_storage_container
  - [1] azurerm_eventgrid_event_subscription
  - [1] azurerm_application_insights_standard_web_test

Managed Resource Count (RUM)

  • access-control: 9
  • api: 3
  • dependencies: 1
  • global: 7
  • regional-stamp: 31

Total: 51 managed resources

Estimated Monthly Cost (Based on Pricing Tier)

  • Essentials: 51 × $0.10 = $5.10/month
  • Standard: 51 × $0.47 = $23.97/month
  • Premium: 51 × $0.99 = $50.49/month

It’s not outrageous. Even after I deploy 10 more microservices and my shared infrastructure I am at about 400 resources or $50/mo. 

Alt

My Azure spend is around $1,800/month, and my HCP Terraform bill is about $50/month, which feels acceptable for the automation and peace of mind I get. 

I might probably paying more than what I would pay if I set up my terraform state on Azure Blob Storage and stitched together in my own Github Actions? Yes. But I derive sufficient value from the operational improvements that terraform stacks provides me to justify the additional cost that I incur, and that I ultimately pay to HCP terraform. 

In economics, I believe this is called price elasticity. Where the value derived from a particular product or service is sufficient to warrant or justify (in the minds of the purchaser), a commiserate amount of cost. if the price far exceeds the derived value, then the potential customer is not willing to pay the price: enter Mr. Notoriousbpg.

In my situation, I’m happy with the value that i get for the price. But that’s my situation. When coming up with an equitable pricing model it’s important to have it aligned with your market otherwise you might only be a market fit for a tiny sliver of your addressable market. I think that’s what’s happening with rum pricing because there’s a tremendous amount of diversity in the workloads and the structures of the platforms and the configuration that people automate.

It’s Not About Me - It’s About the Model

While I feel like I’m getting a good deal, someone like notoriousbpg - with 13,000 managed resources - sees a bill over $1,200/month and flips his lid! 

It comes down to is the price reflective of the actual load he’s putting on HashiCorp’s infrastructure and COGS (cost of goods sold)?

Almost certainly not.

Terraform’s hosted backend cost doesn’t scale with resource count the way RUM pricing implies. It scales with how many compute cycles, how much memory usage, and how large your state is. If my 51-resource state uses less compute as his 13,000-resource one but not 900x!!!!It might be 20–30% more - maybe double. Not 900X.

RUM punishes good practices. It punishes completeness. It punishes correctness.

Cost-Optimization: Where to Trim

So what am I supposed to do, if I am in a situation like Mr. notoriousbpg and due to the RUM pricing model my HCP Terraform costs radically exceed my actual cloud bill? I have to optimize for costs. Automation costs. That means I have to make tough decisions about what I can and cannot afford to automate.

So if I want to reduce my RUM count I have to start thinking about stuff that I can survive without automating. Again, this is not the thought process a cloud automation company wants their customers to actively be engaged in.

In my example, I am spending 29.4% on Azure Role Assignments. I can solve that by either ClickOps’ing access control or just not implementing the principle of least privledge. Both of these solutions have negative outcomes. They either make my solution more difficult to operate (by adding ClickOps to manage authorization rules), less security (granting more privledges to avoid intricate authorization rules refined for only the access needed to my resources), or both.

So with RUM pricing I’ll start having conversations like this:

  • Stop managing group memberships via Terraform and let Entra administrators handle it.
  • Avoid automating things that don’t change very often like my App Insights synthetic tests or my API Management policies or my Cognitive model deployments.
  • Collapse role assignments to higher scopes or fewer principals.

Doing this in my own stack would reduce my resource count from 51 to somewhere around 30–33, bringing my bill down to about $3.00–3.30/month on Essentials.

But, again, that’s the wrong conversation.

Alt

Terraform Was Supposed to Eliminate Drift, Not Create It

Infrastructure-as-code was meant to kill ClickOps, eliminate snowflakes, and give teams confidence that everything is known, reviewable, and reproducible. That’s my goal when I use Terraform - it should be no different when I use Terraform through a hosted service like HCP Terraform.

But RUM pricing introduces the exact behavior Terraform was meant to destroy:

  • Split-brain systems: “That’s managed by Terraform; that isn’t.”
  • Manual state: “We don’t manage that piece in code anymore.”
  • Lost drift detection: “We didn’t notice it changed - because Terraform doesn’t manage it.”

Every time you’re forced to ask “Is this worth $0.10/month to automate?”, you’re being nudged back into the world of pets, snowflakes and shadow IT.

Why RUM Pricing Is Fundamentally Flawed

1. It Actively Discourages You from Using Terraform

The entire value of Terraform is in bringing infrastructure under code management. Yet RUM pricing makes you pause and ask, “Is it worth paying to automate this?” That’s a backward incentive model. It discourages infrastructure-as-code, which is literally the point of Terraform.

2. It Ignores the Modern Cloud Reality

The cloud has moved on from VMs and networks. Today’s workloads involve thousands of lightweight, abstracted resources - API endpoints, role assignments, queue configurations, identity bindings - that are just rows in a database. Imagine being charged $0.10 per database row. That’s effectively what RUM does. And if you’re implementing least privilege correctly, you’re looking at potentially dozens of Azure role assignments per workload, each treated as a separate billable resource.

No. 3 It’s Not Tied to HashiCorp’s Actual Costs

HashiCorp isn’t charged per resource. The costs of serving a workload on Terraform Cloud are tied to compute, memory, and state file size, not how many resources happen to be defined in that state. Whether my state file has 30 role assignments or 300, the operational cost on their side is about the same. So why am I being charged 900x more for doing things the “right” way?

Conclusion

The current pricing model isn’t just frustrating - it’s harmful. It penalizes users for embracing the very model of infrastructure that Terraform evangelizes. Worse, it creates a perverse incentive structure where correctness, reproducibility, and full-system modeling are seen as costly luxuries rather than best practices. It’s bad for HashiCorp, because it discourages people from using more of their product.

It’s bad for customers, because it fractures automation and drives up long-term maintenance costs. This model needs a rethink. RUM pricing doesn’t scale with customer value or with HashiCorp’s cost to serve. It punishes behavior Terraform was built to encourage.

And yet, if you’re a small startup with a single app under 500 resources?

You’re probably fine. $0/month or $50/month isn’t a dealbreaker. But that’s a narrow use case. For modern cloud-native apps, and for orgs trying to do automation right, the RUM model turns correctness into a tax.

And that’s not just bad pricing. That’s bad design. It needs to change. Now.