Monorepo Terraform cost estimation: estimate per stack, scoped to the change

Quick answer

In a Terraform monorepo, estimate per stack scoped to what changed — not the whole repo on every PR. Detect affected root modules with git diff, run the cost estimate on each (a CI matrix works well), and aggregate the per-stack deltas into one PR comment. That keeps CI fast and attributes cost to the specific stacks a change touches.

A Terraform monorepo holds many independent root modules — per service, per environment, per region. Cost estimation has to respect that structure: running an estimate across hundreds of unrelated stacks on every pull request is slow, noisy, and obscures the thing that matters, which is the cost delta in the stacks the PR actually changed.

Estimate per stack, scoped to the change

The pattern has three steps:

Detect changed stacks. Diff against the base branch to find changed paths and map them to their root modules (usually by directory convention).
Estimate the affected stacks only. Run the cost estimate per changed stack — a CI matrix runs them in parallel, one job per stack.
Aggregate. Sum the monthly costs and deltas into a single PR comment, with a per-stack breakdown.

Why not estimate everything

Re-running across the whole monorepo on every PR wastes CI time and buries signal — a one-line change to one service shouldn't trigger a repo-wide cost report. Scoping to changed stacks keeps the pipeline fast and makes the cost delta legible: "this PR changes the payments stack, +$120/month," not a wall of unchanged numbers.

Aggregate for the reviewer

Reviewers want both views: the per-stack detail (which stack, how much) and the aggregate (total impact of the change set). Summing the per-stack estimates into one comment, ideally with the delta versus the base branch, gives both — the monorepo version of the cost-in-the-PR workflow.

Terragrunt monorepos

Terragrunt is a common way to structure a Terraform monorepo, and the same scoping applies — detect changed units and estimate the affected stacks, resolving Terragrunt's module composition. See Terragrunt cost estimation for the resolution details, and feed each stack's plan JSON for the most accurate per-stack number.

FAQ

How do I estimate Terraform cost in a monorepo?

Estimate per stack, scoped to what changed. A monorepo has many independent Terraform root modules; rather than estimating everything on every PR, detect which stacks a change touches and run the cost estimate only on those, then aggregate. This keeps CI fast and attributes cost to the specific stack that changed.

Should I estimate the whole monorepo on every PR?

No — that's slow and noisy. Use path-based change detection to find the affected stacks and estimate only those. The cost that matters for a PR is the delta in the stacks it touches, not a re-run across hundreds of unrelated modules.

How do I detect which stacks changed?

Use git diff against the base branch to find changed paths, map them to the root modules they belong to (often by directory convention), and run the estimate per affected stack. CI tools and matrix builds make this straightforward — one estimate job per changed stack, in parallel.

Can I get one total cost across all changed stacks?

Yes. Run the per-stack estimates and sum the monthly costs (and the deltas versus the base branch) into a single PR comment. Reviewers see both the per-stack breakdown and the aggregate impact of the change set.

Does this work with Terragrunt monorepos?

Yes. Terragrunt is a common monorepo pattern, and the same approach applies — detect changed units, estimate the affected stacks resolving Terragrunt's composition, and aggregate. See the dedicated Terragrunt guide for the resolution details.

How does C3X handle monorepo estimation?

C3X estimates a Terraform directory or plan, so in a monorepo you point it at each affected stack (or feed each stack's plan) in a CI matrix, then aggregate the results. It scopes naturally to per-stack estimation rather than forcing a whole-repo run.

What to do next

Point C3X at each affected stack in a CI matrix and aggregate the results. It estimates a directory or plan, so it scopes naturally to per-stack monorepo estimation. The CI/CD guide covers change detection and matrix setup, and the quickstart gets you a single-stack estimate first.