HCP Terraform: The Bitter Taste of RUM

TL;DR: the RUM pricing model is stupid.

On HCP Terraform you pay for Resources Under Management (RUM).

A resource is under management if you have provisioned (or imported) it with Terraform and it has been recorded in a state file managed on HCP Terraform. You can identify these resources in the state file by "mode": "managed". It essentially means you are paying for every resource in your configuration, with a few exceptions¹.

On HCP Terraform you pay per RUM per month. Technically you pay per hour, but it is easier to talk about a monthly cost per resource.

There are three pricing tiers for HCP Terraform:

• Essentials - $0.10 per resource per month.
• Standard - $0.47 per resource per month.
• Premium - $0.99 per resource per month.

Each tier above Essentials gives you access to additional features that are not available in lower tiers.

There is a payment option called flex which is based on committing to spend a certain amount during a given time period. This gives you a better deal. However, as I will discuss later in this post this falls under the “contact sales” wall and I will not consider this anymore here.

Why is RUM a bad model:

• It is extremely difficult to reason about. I think this is the biggest issue with RUM. I don’t know how many resources I will manage as part of my new infrastructure project. If I’m lucky it is an exact copy of another project so I can see how many resources I will need. However, for a large organization with hundreds of teams using HCP Terraform you cannot possibly have an idea of how many resources you will manage. Predicting what your bill will be by the end of the month is impossible. The only thing you can be sure about is that your costs will increase by a lot as your Terraform footprint grows.
• It discourages best practices. Using infrastructure-as-code is a good practice. It’s even considered a best practice. Manage everything in code with Terraform on HCP Terraform and pay the price for following this best practice. You would be better off financially by not following this best practice².
• You pay more for resources you are already paying for. You are already paying for your cloud resources, and with Terraform on HCP Terraform you pay an additional fee for each resource per month.
• You pay for free resources. AWS security groups and their rules are free on AWS (and there are many more examples on AWS and on other cloud providers) but you are paying a fee for managing them with Terraform on HCP Terraform.
• You pay for idle resources. Idle resources are resources that you provision once, and rarely (or never) touch again. Perhaps you have a static piece of infrastructure that you provisioned once and have only occasionally updated during the past two years. If you are on the Premium tier and the workspace contains 50 resources you have been paying close to $50 per month for this infrastructure (on top of what you are paying the cloud provider). This is simply a fee for idleness.
• It is expensive. It is not uncommon to have tens of thousands or even hundreds of thousands of resources. That turns out to be very expensive in this model. Even if you are working for an organization where $100,000/month are peanuts, take a moment and really think about what you are paying for. Perhaps these $100,000/month could be better spent on a great party for all your employees instead?

With that said, I like HCP Terraform. I just don’t like the pricing model. RUM is unfair, difficult to reason about, encourages bad practices and in the end turns out the be very expensive.

How would I prefer to pay for HCP Terraform? In one of two ways:

• Pay-per-user: Pay for a license for each user on the platform³. This is how it used to be for HCP Terraform.
• Consumption-based: Pay for the resources (CPU and memory) used during terraform plan and terraform apply operations and related compute-intense actions plus a small fee for the storage (GBs) consumed for state files and any other file or metadata that must be stored. To be fair, I would have a hard time estimating what this would cost for a large organization but at least it does not come with the other drawbacks of the RUM model.

What is true for both of these models is that you would not be paying during periods where your Terraform environment is completely idle (apart from a small storage fee).

Unfortunately I think HashiCorp, and nowadays IBM, realize that by switching from the RUM model to something else would likely severely negatively influence their revenue. At least in the short term.

The HCP Terraform platform has to be so good that organizations want to use it. Combining a great platform with a pricing model that makes sense is a winning combination. Currently the platform is good, but the pricing model is not.

My suggestion to IBM is: switch to a different pricing model and keep investing to make HCP Terraform the single platform organizations want to use for their Terraform automation needs and I am sure the revenue will come. If not some other platform(s) will slowly attract customers away from HCP Terraform.

While I am on the topic of pricing I want to bring up the dreaded “Contact sales” wall that is so common for enterprise offerings.

If I understand it correctly this is because you want to be able to offer your customer custom pricing based on their environment and context. Also, perhaps you don’t want your competitors to easily find out what you charge for your product.

I think it would make more sense to have a base price that you announce on your website, with a little asterisk saying that you can contact sales to get a possible better offer base on commitments or whatever.

Cost transparency is awesome. If a product website can tell me exactly what it will cost: good job! If it can give me enough information to easily compute the cost myself (e.g. pay-per-user): good enough. If it is based on how many resources I have in my state files and for how long I have them there: do better.