Terragrunt module cost inheritance: pricing DRY infrastructure

Quick answer

Terragrunt keeps configuration DRY by layering inputs, shared values at the root, environment overrides below, so a resource's final cost depends on inherited variables scattered across the hierarchy, not on one file. You estimate Terragrunt cost by running terragrunt plan for each unit, which resolves the full inherited configuration, then pricing the resulting plan, so the estimate reflects the merged inputs each environment actually applies. Because inheritance means a change to a shared input affects many units, price the affected units together. The rule is price the resolved plan per unit, since inheritance decides the final, billable configuration.

Terragrunt exists to avoid repeating Terraform configuration across environments: you define shared inputs once at a root level and override only what differs per environment. This DRY structure is powerful, but it scatters the values that drive cost across an inheritance hierarchy, so the final cost of a resource depends on merged inputs that no single file shows. Estimating Terragrunt cost means resolving that inheritance.

How inheritance shapes cost

Level	Provides
Root config	Shared inputs across all units
Environment config	Per-environment overrides
Unit config	Resource-specific inputs

A unit's final configuration is the merge of root, environment, and unit inputs. The instance size that determines cost might be set at the root as a default, overridden for production, and referenced in the unit, so no one file tells you what production actually deploys. Only the resolved configuration does, which is what you must price.

Pricing the resolved plan

The reliable way to estimate a Terragrunt unit is to run terragrunt plan, which resolves the full inheritance and produces a Terraform plan reflecting the merged inputs, then price that plan. Because the plan captures the final configuration, static pricing of theplan JSON gives the true cost each environment deploys, inheritance already applied. c3x prices whatever plan you hand it, so pricing each unit's resolved plan yields a per-unit, per-environment cost. It builds on theTerragrunt estimation approach.

The shared-input blast radius

Inheritance means a change to a shared root input propagates to every unit that inherits it. Bumping a default instance size at the root raises the cost of every environment that does not override it, which can be many units at once. So a Terragrunt change to a shared value has a wide cost blast radius, and estimating it requires pricing all affected units, not just one. This is the DRY tradeoff: one edit, many priced outcomes.

Estimating changes in CI

In a Terragrunt pull request, identify which units the changed configuration affects, run terragrunt plan for each, and price them, so the PR shows the total cost impact across every inheriting unit. A change to a production-only override affects one unit; a change to a shared root affects many, and the estimate should reflect that breadth. Reporting the summed delta across affected units gives reviewers the real cost of a shared-config change.

Keeping DRY infrastructure cost-clear

Document where cost-driving inputs live in the hierarchy so a reviewer knows a root-level change is high-blast by nature, keep environment overrides explicit for costly resources, and price the resolved units in CI so inheritance never hides a cost increase. Price each unit against theresource catalog so the merged, inherited configuration each environment deploys is a known number before it applies.

FAQ

How does Terragrunt inheritance affect cost?

Terragrunt layers inputs, shared values at the root, environment overrides below, so a resource's final cost depends on merged inputs scattered across the hierarchy rather than one file. The instance size driving cost might be a root default, overridden for production, and referenced in the unit, so only the resolved configuration shows what an environment actually deploys and costs.

How do I estimate Terragrunt cost?

Run terragrunt plan for each unit, which resolves the full inheritance and produces a Terraform plan reflecting the merged inputs, then price that plan. Because the plan captures the final configuration with inheritance applied, static pricing of the plan JSON gives the true per-unit, per-environment cost each environment deploys, without needing to trace the hierarchy by hand.

Why does a shared Terragrunt input have a wide cost impact?

Because inheritance means a change to a shared root input propagates to every unit that inherits it: bumping a default instance size at the root raises the cost of every environment that does not override it, which can be many units at once. So a change to a shared value has a wide cost blast radius, and estimating it requires pricing all affected units.

How do I estimate a Terragrunt change in CI?

Identify which units the changed configuration affects, run terragrunt plan for each, and price them, so the pull request shows the total cost impact across every inheriting unit. A change to a production-only override affects one unit while a change to a shared root affects many, and reporting the summed delta gives reviewers the real breadth of a shared-config change.

How does C3X handle Terragrunt cost?

C3X prices whatever Terraform plan you hand it against a live catalog with no cloud credentials, so pricing each Terragrunt unit's resolved plan, produced by terragrunt plan with inheritance applied, yields a per-unit, per-environment cost. For a shared-input change, pricing all affected units and summing the delta shows the full cost blast radius on the pull request.

What to do next

Price DRY infrastructure through inheritance. C3X prices each resolved Terragrunt unit against a live catalog. Start with the quickstart.