6. Terraform is the provisioning-time cost control layer that most FinOps programmes either ignore or misuse

The situation

Infrastructure as Code manages 70%+ of cloud provisioning in mature organisations. Terraform has 3,000+ providers and 15M+ users. Every terraform apply is a spending decision. A single line change can increase monthly spend by thousands. Yet most FinOps programmes treat Terraform as engineering-only.

This is a mistake born of organisational structure. FinOps sits in finance or a central governance function. Terraform sits in platform engineering. The two teams rarely share a backlog, attend each other's stand-ups, or review each other's work. The result is that the most powerful preventive cost control in the cloud goes ungoverned by the people whose job is to govern cost.

The complication

Terraform operates at provisioning time. It declares what should exist and creates it. It does not monitor runtime. An m5.xlarge instance stays m5.xlarge even at 8% CPU for six months. This creates false control: infrastructure is declared, not managed. Runtime feedback loops are needed alongside Terraform. Treating Terraform as the complete cost solution is like treating a building permit as fire prevention.

The resolution: Terraform as FinOps control plane

Six capabilities that reduce cloud spend

1. Tagging enforcement at provisioning. Require tags (team, env, cost-centre) on every resource via variable validation, custom modules, and Sentinel/OPA policies. Untagged resources fail to provision. This is more effective than retroactive tag audits because it prevents the problem rather than detecting it. Retroactive tagging requires finding the resource owner, explaining why tags matter, and waiting for them to add tags to resources they may have forgotten about. Preventive tagging takes 30 seconds at provisioning time.

2. Instance size governance. Custom modules restrict instance types per environment. Dev allows t3.medium max. Production allows up to m5.2xlarge. Engineers cannot accidentally provision GPU instances in dev. Without limits, dev instances routinely end up larger than their production equivalents; nothing stops an engineer selecting a bigger machine for a quick test and leaving it in place.

3. Cost estimation in CI/CD. Infracost shows cost impact per pull request. An engineer sees +$1,200/month before merging. This shifts cost awareness from monthly reports to the decision point. The setup takes 30 minutes. The return is immediate: engineers who see cost in every PR develop cost intuition faster than engineers who see cost in monthly reports.

4. Lifecycle policies and auto-cleanup. Dev modules include TTL tags and scheduled cleanup functions. This eliminates the biggest source of zombies: forgotten dev environments. One financial services review found 40% of compute spend on dev/test environments running 6+ months with no active users.

5. Reserved capacity alignment. Terraform state contains the exact resource inventory. Cross-reference with RI/SP portfolio to find coverage gaps. Some organisations run nightly pipelines comparing state against reservations and generating alerts when coverage drops below target.

6. Drift detection. terraform plan -detailed-exitcode catches manual changes. An engineer resizes via console for testing and forgets to revert. Drift detection catches this. Run it daily. Automate alerts for any state file that shows drift.

Terraform cost governance architecture

Common Terraform cost mistakes

Hardcoded instance types make rightsizing a code change rather than a configuration update. No environment differentiation deploys prod-grade infrastructure to dev. Ignoring data transfer costs when deploying across regions creates hidden recurring charges. No TTL on dev resources is the single largest source of compute waste in organisations with active development teams.

Infracost integration patterns

Pull request comments show cost breakdown as a PR comment with the monthly delta. Takes under 30 minutes to set up. Cost policies through Infracost Cloud set thresholds: PRs adding more than $500/month require FinOps approval. Slack notifications alert the FinOps channel when high-cost changes are proposed, providing real-time awareness without requiring anyone to check a dashboard.

The setup for GitHub Actions is minimal. Add the Infracost GitHub Action to your repository workflow, provide an API key (free tier covers most teams), and configure the PR comment format. Within 30 minutes, every pull request that touches Terraform files will show a comment with the monthly cost delta. Engineers see '+$1,200/month' or '-$340/month' on every infrastructure change. The psychological impact is immediate: engineers who have never thought about cost start asking whether they really need that instance size.

Infracost Cloud adds policy enforcement on top of the PR comments. Set rules such as: any PR adding more than $500/month requires approval from the FinOps team. Any PR provisioning GPU instances requires CTO approval. Any PR creating resources in non-approved regions is blocked. These policies codify your cost governance into the CI/CD pipeline, which is where engineering decisions are made. A policy in a governance document is a suggestion. A policy in the CI/CD pipeline is a guardrail.

The Terraform and runtime tool relationship

The most common architectural mistake in FinOps is treating Terraform and runtime tools as alternatives rather than complements. They operate at different times and address different problems. Terraform sets the initial state. Runtime tools optimise the running state. Without Terraform governance, engineers repeatedly create over-provisioned resources that runtime tools then flag for right-sizing. Without runtime tools, resources deployed at the correct size via Terraform drift toward waste as usage patterns change.

The correct architecture uses both. Terraform enforces tagging, instance size limits, and lifecycle policies at provisioning time. CAST AI or Karpenter optimises running Kubernetes workloads. AWS Compute Optimizer flags instances for right-sizing. Trusted Advisor detects orphaned resources. Each tool operates at its optimal layer. Data flows between them: runtime recommendations should feed back into Terraform module defaults so that the next provisioning cycle starts closer to optimal.

One practical integration pattern: run a weekly script that compares Terraform state (what you declared) against AWS Cost Explorer data (what you spent). Discrepancies indicate either drift (resources changed outside Terraform) or cost patterns that Terraform does not control (data transfer, API calls, logging). This comparison report is one of the most actionable outputs a FinOps team can produce because it identifies both governance failures and cost blind spots in a single view.