Terraform's documentation calls depends_on a last resort. What does adding one actually cost you compared with an ordinary attribute reference?

## Two edges that look the same and are not Both an attribute reference and a `depends_on` entry create an edge in Terraform's graph, and both guarantee ordering. The difference is what else Terraform learns. When you write `subnet_id = aws_subnet.app.id`, Terraform records a *typed* dependency: this argument, of this resource, takes this attribute of that object. It can reason about the single value. If the subnet already exists unchanged, the value is known and the downstream plan is fully concrete. If the subnet is being created, exactly one attribute is unknown and everything else about the instance still plans normally. When you write `depends_on = [aws_subnet.app]`, Terraform records only "after". It has no idea which part of the subnet the instance cares about — for all it knows, the answer is "all of it". ## Cost one: conservative plans and unknown values Because the edge is untyped, Terraform must assume the worst. If the upstream object has changes pending, the downstream node's plan becomes less certain, and more of its attributes render as `(known after apply)` than would with a precise reference. The Terraform documentation makes exactly this point when it recommends `depends_on` as a last resort: it produces a more conservative plan than necessary because the tool is uncertain what will change. The practical consequence lands on review. A plan you can read is one where the interesting lines stand out; a plan where fifty attributes are `(known after apply)` because a `depends_on` sits upstream of half the graph is one that reviewers scroll past and approve on faith. You have not made the apply riskier so much as you have made the *review* worthless, which amounts to the same thing. ## Cost two: concurrency and the critical path Terraform walks the graph, starting any node whose predecessors have finished and running several at a time (ten concurrent operations by default). The graph's shape sets the floor on wall-clock time: independent resources fan out, dependent ones queue. Every edge you add is a queue. A `depends_on` on a module block is the loud version of this — every resource inside now waits for the whole upstream object, even the ones that had nothing to do with it — but the effect exists at resource level too. Ten resources that each `depends_on` the previous one apply in strict sequence, and if each takes ninety seconds you have built a fifteen-minute apply out of work that could have finished in ninety seconds. ## Cost three: it is static, and it rots `depends_on` accepts a fixed list of addresses. You cannot compute it, cannot make it conditional on a variable, cannot generate it. That rigidity is deliberate — the graph is built before expressions are evaluated — but it means the entry survives every refactor unchanged. When the resource it names is renamed, you get an error and fix it; when the *reason* for the dependency disappears, nothing tells you, and the edge stays for years. ## Cost four: the code stops explaining itself A reference documents itself on the line where the value is used. An explicit edge is a bare address at the bottom of a block, and six months later nobody knows whether it encodes a real provider constraint or a superstition left over from a bad afternoon. Anyone considering removing it has to test in production to find out, so nobody does. The mitigation is cheap and almost always skipped: a one-line comment saying what the invisible dependency is. ```hcl resource "aws_instance" "app" { # The boot script writes to S3; without the role policy attached # first, the instance comes up and immediately 403s. depends_on = [aws_iam_role_policy.app] } ``` ## When the cost is worth paying None of this makes `depends_on` wrong. A genuine hidden dependency — permissions that must exist before software boots, an API activation, an ordering the provider schema simply does not model — is worth a coarse edge and a conservative plan, because the alternative is an intermittent first-run failure. The discipline is only this: ask whether an attribute reference could express the same thing, prefer it when it can, and when it cannot, write down why.