Skip to content
hannctl.
PDF ↓
← All work
04 / PF-04 · AWS · Terragrunt IaC automation

AWS Terragrunt DRY IaC.

Sixteen Terraform modules behind one root config, with Terragrunt running them in order from their dependency graph.

PERIOD
Personal project · released Nov 2026
MY ROLE
Design and implementation
TOOLS & CONTEXT
Terragrunt · Terraform · AWS — 16 modules · 16 units · 4 dependency levels
iam_custom_policyiam_useriam_custom_roleiam_groupvpcelastic_ipebsinternet_gatewaysecurity_groupvpc_endpointvpc_peeringelasticache_subnet_groupnat_gatewayroute_tableinstance_profileec2_instance
01 / CONTEXT

Problem

Each Terraform root repeated its backend and provider blocks, and the order between roots lived in people's heads.

02 / DECISIONS

Approach

Modules stay plain Terraform and Terragrunt wraps them. The backend, provider, and common inputs are generated once from live/root.hcl. _envcommon holds module sources and dependencies, and each unit states only its inputs. dependency blocks build the graph, and mock_outputs let the whole stack validate without a cloud account.

03 / ENGINEERING

Implementation

  • Terragrunt
  • Terraform
  • AWS

Scale · 16 modules · 16 units · 4 dependency levels

live/root.hclbackend · provider · common inputslive/dev/account.hclPer-account values<region>/region.hclPer-region values_envcommon/<module>.hclsource · dependency · mock_outputs<resource>/terragrunt.hclStates only its own inputsbackend.tfprovider.tf1 root config replaces 16 copies
Terragrunt generates backend.tf and provider.tf. One root config replaces 16 copies.
04 / VERIFICATION

Result

This repository groups 16 modules and 16 units into four dependency levels and validates them without cloud credentials. The 40% shorter deployment time came from moving a live production estate to this pattern.

16
Terraform modules and units
1
Root config replacing 16 copies
-40%
Deployment time (production result)

MEASUREMENT Lower is better

Before 100
After 60
Condition
Deployment time (production result)
Scope
Relative value, before the change = 100
05 / REFLECTION

What I learned

The key point was that Terragrunt does not replace Terraform; it decides where code lives. Modules stay plain Terraform while the backend, provider, and common inputs are generated from one root, so a structure that copied the same settings 16 times became one where a single edit reaches everything. Writing run order as dependency blocks moves it from people's memory into a graph, and mock_outputs let the whole stack validate without cloud credentials. The demo keeps state local, but where several people share an environment, where state lives has to be settled first, and I now treat that as part of the design from day one.

OUTCOME

4 dependency levels — 16 units, run in order with run-all

Public repo: pf-04-aws-terragrunt-dry-iac ↗

Related field notes

NEXT / PF-05 · Multi-cloud · Python Multi-cloud asset and audit automation

Search the site

Quick links ↑ ↓ move · Enter open · Esc close

Choose a theme

Click a badge to switch to that theme on the same content. Dragging only swings it.

Back to the front page →