Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Cloud Contracts Now Meter Your Terraform State File Reads
Transcript
- Lucas: So, if your team uses Terraform — and most cloud-native teams do — there's a new line item on your bill that probably wasn't there three months ago. The big three cloud providers have quietly started metering Terraform state file reads. Luna: Metering reads of a state file? That's a pretty deep plumbing level to start charging for. How does that even show up? Lucas: It shows up as a per-operation charge on the storage backend where you keep your state. If you're using an S3 bucket, Azure Blob Storage, or a GCS bucket as your remote backend, every time Terraform reads the state file — which happens on every plan, apply, or refresh — you get charged a few tenths of a cent per read. Luna: That sounds tiny. But at scale, lots of reads add up. What kind of numbers are we talking? Lucas: Right, individual reads are negligible. AWS charges roughly $0.0004 per 1,000 GET requests on S3 standard. That's four ten-thousandths of a cent per read. But consider a team running 200 Terraform runs per day across 50 developers, each run hitting a state file that's maybe 2 megabytes. That's 365,000 read operations a year. On the surface, that's about 15 cents — not even a rounding error. Luna: Fifteen cents a year? Who would even notice that? There has to be more to it. Lucas: There is. That calculation assumes a single state file. Most enterprises don't have one state file — they have hundreds, sometimes thousands. Each microservice, each environment, each region often gets its own state. And then you factor in CI/CD pipelines that hammer state files constantly. One mid-sized SaaS company I spoke with last week — they run about 800 state files and do roughly 12,000 Terraform runs per day across dev, staging, and production. At that scale, the read charges hit about $4,200 a month. Luna: Wait, $4,200 a month just for state file reads? That's not a rounding error. That's a new cost center. Lucas: Exactly. And the providers didn't change their published pricing — they just started enforcing the existing per-operation fees more strictly. For years, most teams used S3 with versioning enabled and never paid attention to the GET request costs because they were so low. But as infrastructure as code adoption exploded, the volume of state reads grew exponentially. The cloud providers finally noticed and started billing more aggressively. Luna: So it's not a new price — it's a new enforcement. Did they announce this anywhere? Lucas: Not with a press release. AWS updated its billing documentation quietly in April. Azure followed in May. GCP's change went into effect June 1st. The official line is that these charges were always in the terms of service, and they're just improving billing accuracy. But the practical effect is a tax on infrastructure as code workflows. Luna: That feels like a shift in the cloud value proposition. One of the big selling points of IaC was that automation was essentially free after the compute costs. Now every plan and apply has a micro-cost attached. Lucas: Yeah, and the problem compounds. Terraform's default behavior polls the state file on every operation. If you run a plan every time a developer pushes a commit — which is common in GitOps workflows — you're generating hundreds of reads per minute. Plus, if you use Terraform Cloud or Terraform Enterprise, those platforms also read the state remotely. So the charge applies there too. Luna: Are there any workarounds? Can teams cache the state locally or reduce read frequency? Lucas: There are some strategies. One is to use partial configurations so that each state file is smaller and reads are faster — but that doesn't reduce the number of reads. Another is to use the -refresh=false flag to skip state refresh when you know the state is up to date. That can cut read volume significantly. But it's risky because you might plan against stale state. Luna: Right, that's how you accidentally destroy infrastructure. Not ideal for production. Lucas: Exactly. A safer approach is to consolidate state files. Instead of one state per microservice, group related resources into fewer state files. That reduces the total read count. But it increases the blast radius of any state lock — one bad apply can affect more services. It's a trade-off. Luna: What about using a dedicated state storage class? S3 has infrequent access tiers that are cheaper per read. Lucas: Good thought. S3 Intelligent-Tiering or S3 One zone ia have lower per-request costs for GETs. But you have to be careful with the minimum storage duration charges. Terraform state files are typically small, so the per gb storage cost is negligible anyway. The real savings come from reducing read volume, not optimizing storage class. Luna: So the meta lesson here is that cloud providers are now monetizing the automation layer itself. First it was Kubernetes control plane CPU, then container image pulls, now Terraform state reads. What's next? Lucas: I think we're seeing a pattern. The hyperscalers have realized that the value in cloud is shifting from raw compute to the ecosystem of tools and APIs. Ten years ago, they charged for VMs and storage. Now they charge for every API call, every log line, every state read. It's a death by a thousand cuts for enterprises that don't actively manage their cloud bills. Luna: Speaking of managing bills, if you're finding these cost breakdowns useful for what you're building or running, there's a simple way to support the show. It keeps us ad-free and focused on exactly these kinds of operational details. Lucas: Yeah, we've had listeners ask if there's a way to chip in. If the show saves you time or helps you catch a billing surprise like this one, you can find us at buy me a coffee dot com slash fexingo. All lowercase. And it genuinely helps us keep digging into the contract fine print. Luna: Exactly. Now, back to the Terraform issue — one more thing I'm curious about. Do any of the providers offer a credit or discounted rate for high-volume state reads? Like an enterprise agreement could negotiate that? Lucas: They do, but you have to ask. Standard enterprise agreements with AWS or Azure often include a bucket of S3 or Blob Storage credits that can cover these reads. But most teams don't realize they need to negotiate for it. If you're on a pay as you go plan, you're stuck with the per-operation rates. The key is to have your FinOps team model the state read volume before you sign or renew. Luna: So essentially, the cloud providers are forcing infrastructure teams to think like cost accountants. Every plan, every apply, every refresh now has a line item. Lucas: That's exactly right. And I think we'll see more of this. The next frontier might be metering Terraform provider downloads — they're already served from a registry, and each download has a cost. Or metering the state lock operations, which trigger database writes. The contracts are getting more granular every quarter. Luna: It makes you wonder if the era of 'cloud is cheap' is officially over. Not because compute got more expensive — but because all the invisible plumbing now has a meter on it. Lucas: The era of 'cloud is cheap' ended about the time the first $100,000 surprise bill hit a startup. Now it's about being deliberate. Use -refresh=false in dev, consolidate state where it's safe, and always model the read costs in your FinOps dashboard. Because the cloud providers are watching the meter, and they're not going to turn it off. Luna: I'll say. Well, next episode, let's look at whether they're starting to meter Terraform plan outputs — I've heard rumblings. Lucas: I've heard the same. Let's dig into that next time.