Open Policy Agent for Terraform cost: cost rules as code

Quick answer

Open Policy Agent (OPA) evaluates Rego policies against structured input, and you can feed it a priced Terraform plan so cost becomes a policy dimension: deny a plan whose monthly delta exceeds a limit, or whose per-resource cost breaks a rule. You produce a cost-annotated plan with an estimator, pass it to OPA or Conftest in CI, and let the policy pass or fail the build. This gives you versioned, testable cost rules that live beside your security and compliance policies. The advantage over a hardcoded threshold is cost rules become auditable code, reviewed and tested like any other policy.

Many teams already gate Terraform on policy: no public S3 buckets, mandatory tags, approved regions only. Open Policy Agent is the common engine for those rules, expressed in Rego and run in CI with a tool like Conftest. Cost fits naturally into the same framework once you give OPA a priced plan to reason about, so a budget rule sits beside your security rules as versioned, reviewable code.

Why put cost in OPA

Approach	Cost rule lives as
Hardcoded CI threshold	A number in a script
OPA policy	Versioned, testable Rego

A threshold buried in a CI script is invisible and hard to test. The same rule as a Rego policy is reviewed in a pull request, tested with sample inputs, and stored alongside your other policies, so cost governance becomes as auditable as security governance. That is the case for expressing cost policy in OPA rather than ad hoc scripting, an extension ofcost policy as code.

Producing a priced plan for OPA

OPA reasons over JSON. The input it needs is a Terraform plan annotated with cost, so each resource change carries its estimated monthly cost and the plan carries a total and a delta. A cost estimator produces this by pricing theplan JSON against a catalog, with no cloud credentials, then emitting a JSON document OPA can evaluate. c3x can output a machine-readable cost breakdown that serves as this policy input.

Writing cost policies in Rego

With a priced plan as input, Rego rules are straightforward. A rule can deny when the total monthly delta exceeds a limit, when any single resource costs more than a cap, when an expensive resource type appears outside an approved list, or when a production change adds cost without an attached ticket. Because Rego is a real language, you can express nuanced rules, higher limits for production than for dev, exemptions for tagged resources, that a flat threshold cannot.

Running it in CI

In the pipeline, price the plan, emit the cost-annotated JSON, and run Conftest or opa eval against your policy set. A failing policy fails the build, blocking the merge, and the policy message explains which rule the plan violated. Because the cost estimate is static and needs no credentials, the whole evaluation runs in seconds beside your existing OPA security checks, sharing the same tooling. This slots into the same job asAtlantis or a GitHub Actions workflow.

Testing and evolving policies

Rego policies are testable: write sample priced plans, assert that the policy allows or denies them, and run those tests in CI. That lets you evolve cost rules with confidence, tightening a limit or adding an exemption without fear of breaking the pipeline. Price your plans against theresource catalog so the cost figures your policies evaluate reflect real rates and the rules fire on accurate numbers.

FAQ

How does Open Policy Agent evaluate Terraform cost?

OPA reasons over JSON input, so you feed it a Terraform plan annotated with cost where each resource change carries its estimated monthly cost and the plan carries a total and delta. A Rego policy then denies the plan when a cost rule is violated, such as a delta over a limit or a resource over a cap, and the check fails the build in CI.

Why use OPA for cost instead of a CI threshold?

A hardcoded threshold in a CI script is invisible and hard to test, while the same rule as a Rego policy is reviewed in a pull request, tested with sample inputs, and stored alongside your security and compliance policies. That makes cost governance as auditable and versioned as security governance, and lets you express nuanced rules a flat threshold cannot.

How do I produce a priced plan for OPA?

Run a cost estimator that prices the Terraform plan JSON against a catalog with no cloud credentials and emits a JSON document annotating each resource change with its monthly cost plus a total and delta. That document becomes the input OPA or Conftest evaluates your Rego cost policies against, sharing the same tooling as your existing policy checks.

What cost rules can I write in Rego?

You can deny when the total monthly delta exceeds a limit, when any single resource costs more than a cap, when an expensive resource type appears outside an approved list, or when a production change adds cost without a ticket. Because Rego is a real language, you can also express nuanced rules like higher limits for production than dev, or exemptions for tagged resources.

How does C3X work with OPA for cost policy?

C3X prices your Terraform plan statically against a live catalog with no cloud credentials and can output a machine-readable cost breakdown that serves as the input for OPA or Conftest. Your Rego cost policies then evaluate that breakdown in CI beside your existing security policies, failing the build when a plan violates a cost rule, so cost governance runs in the same policy pipeline.

What to do next

Make cost rules auditable code. C3X emits a machine-readable cost breakdown your OPA policies can evaluate in CI. Start with the quickstart.