Something every senior engineer learns the expensive way:

Terraform DAGs at scale: when the graph becomes the hazard

Terraform's dependency graph is elegant at small scale. At 500+ resources across a mono-repo, it becomes the most dangerous part of your infrastructure.

SAFE (small module):         DANGEROUS (at scale):
[vpc] ──▶ [subnet] ──▶ [ec2]   [shared-net] ──▶ [team-a-infra]
                                                   │
                                                [team-b-infra]
                                                   │
                                                [team-c-infra]
                                                   │
                                                [data-layer]
                              One change → fan-out destroy/create

Where it breaks

• Implicit ordering assumptions survive until a refactor exposes them - usually as an unplanned destroy chain in prod.
• Fan-out graphs make blast radius review near-impossible. 'What does this change affect?' has no fast answer.
• depends_on papering over bad module interfaces - it fixes the symptom and couples the modules permanently.

The rule I keep coming back to

• If a module needs depends_on to be safe, the module boundary is wrong. Redesign the interface - don't paper over it.

How I sanity-check it

• terraform graph | dot -Tsvg > graph.svg - visualize fan-out and cycles before every major refactor.
• Gate all applies with OPA/Conftest + mandatory human review on any planned destroy operations.

The difference between a senior engineer and a principal is knowing which guardrails to build before you need them.

Deep dive: https://neeraja-portfolio-v1.vercel.app/workflows/terraform-dags-at-scale-when-the-graph-becomes-the-hazard

Curious what guardrails you've built around this. Drop your pattern below.

terraform #iac #devops #sre

Terraform DAGs at scale: when the graph becomes the hazard

Terraform's dependency graph is elegant at small scale. At 500+ resources across a mono-repo, it becomes the most dangerous part of your infrastructure.

SAFE (small module):         DANGEROUS (at scale):
[vpc] ──▶ [subnet] ──▶ [ec2]   [shared-net] ──▶ [team-a-infra]
                                                   │
                                                [team-b-infra]
                                                   │
                                                [team-c-infra]
                                                   │
                                                [data-layer]
                              One change → fan-out destroy/create

Where it breaks

• Implicit ordering assumptions survive until a refactor exposes them - usually as an unplanned destroy chain in prod.
• Fan-out graphs make blast radius review near-impossible. 'What does this change affect?' has no fast answer.
• depends_on papering over bad module interfaces - it fixes the symptom and couples the modules permanently.

The rule I keep coming back to

• If a module needs depends_on to be safe, the module boundary is wrong. Redesign the interface - don't paper over it.

How I sanity-check it

• terraform graph | dot -Tsvg > graph.svg - visualize fan-out and cycles before every major refactor.
• Gate all applies with OPA/Conftest + mandatory human review on any planned destroy operations.

The difference between a senior engineer and a principal is knowing which guardrails to build before you need them.

Top comments (0)