Infrastructure as Code and Cloud Cost: Catch It at the Plan

Infrastructure as code (IaC) is defining cloud resources in declarative configuration files that are versioned, reviewed, and applied by a tool, rather than created by hand in a console. Terraform and OpenTofu, an open-source fork of Terraform now under the Linux Foundation, are the tools this page uses as examples.

The workflow that matters for cost

The core workflow has three stages: write the configuration, plan, and apply. Two artefacts make IaC useful for cost control:

• The plan. terraform plan creates an execution plan that previews the changes Terraform would make, without carrying them out. A plan is the exact list of resources to be created, changed, or destroyed, which makes it the natural place to price a change and to review it.
• The state. Terraform uses state to map the resources in your configuration to real-world objects, and expects a one-to-one mapping between configured resource instances and remote objects. terraform show -json renders either the state or a saved plan file as machine-readable JSON, which is what policy tools read.

Because every change passes through a plan, a pull request that adds a fleet of large instances or a provisioned-throughput database can be priced and questioned before merge, instead of discovered on the next bill.

Policy as code

A policy engine evaluates the plan or state JSON against rules and returns a decision. Open Policy Agent (OPA) is a general-purpose policy engine whose policies are written in a declarative language called Rego. One practical enforcement point is the repository: GitHub branch protection can require specific status checks to pass before a pull request merges, so a failing policy check blocks the merge.

Useful cost rules at this stage include a ceiling on the monthly cost of a change, a total budget cap for a workspace, and a limit on how much a single change may increase cost, alongside the tagging and security rules that make later allocation possible.

IaC governance in ZopNight

ZopNight’s IaC governance evaluates customers’ own Terraform and OpenTofu. It reads plan output as a pull request gate and show -json state for an inventory scan. ZopNight acts as the policy decision point; the customer’s GitHub required check is what enforces. It never runs apply. Policies are either built-in rules across categories such as governance, security, IAM, networking, cost, reliability, and Kubernetes, each tagged with compliance frameworks, or custom Rego run in a sandbox with no network or clock access.

Cost governance lives in the same engine: priced-plan guardrails for maximum monthly cost, a total budget cap, and maximum cost change put a dollar-per-month figure in the pull request. Inventory scans link declared resources to discovered ones, separating managed resources from orphans that exist in the cloud but in no configuration. CI onboarding opens a pull request that adds a Terraform- or OpenTofu-aware GitHub Action with a scoped scan token, and overrides of a failed check are governed and audited.

IaC and runtime cost tools together

IaC decides what exists; runtime tools decide when it runs and whether it is still worth running. A few practices keep them from fighting:

• Put tags in modules so every resource launched from code carries owner and environment; see tagging best practices.
• Review orphans found by an inventory scan before deleting them: an orphan is either waste or someone’s unrecorded dependency.
• Keep schedules and overrides out of the configuration’s desired state unless your tool models them; see cloud scheduling best practices.

Related: cloud cost governance framework and audit trails.