It’s 3 a.m., your infrastructure pipeline just ran, and somehow a security group tried to attach to a subnet that doesn’t exist yet.
Welcome to the world of Terraform dependencies — a concept that looks simple until it isn’t. Most developers learn the hard way that Terraform has two ways of understanding what needs to happen first: implicit dependencies (inferred from your code) and explicit ones (what you tell it directly). Get this wrong, and your infrastructure becomes a game of infrastructure roulette.
Why Dependencies Matter (Even If You Don’t Think They Do)
Terraform doesn’t just apply your configuration in the order you write it. Instead, it builds a directed acyclic graph (DAG) — a map of everything you’re creating and what depends on what. Resources that have no dependency on each other can be created in parallel. That’s why Terraform is fast. But parallelization is also where things fall apart if you’re not paying attention.
Here’s the thing: Terraform can infer dependencies automatically when you reference another resource’s attribute. When you write vpc_id = aws_vpc.main.id, you’re creating an implicit dependency. Terraform sees that line and thinks, “Oh, I need to create the VPC before the subnet.” No magic words required.
But there’s a catch. Implicit dependencies only work when you’re directly referencing an attribute. What happens when a resource depends on another resource existing, but you never actually reference its output? That’s when implicit dependencies fail catastrophically — and that’s when you need depends_on.
Implicit Dependencies: The Short Version
Look at this snippet from the lab configuration:
vpc_id = aws_vpc.main.id # ✅ IMPLICIT DEPENDENCY
That reference? That’s an implicit dependency. Terraform parses your HCL, sees aws_vpc.main.id, and automatically creates an ordering constraint. The VPC must exist before the subnet. The EC2 instance must exist before you reference its security group.
Implicit dependencies are beautiful because they’re automatic. You don’t have to think about them. They’re also dangerous for exactly that reason — they feel magical until the day you need something to happen in a specific order and Terraform can’t see why it matters.
The security group in the example (aws_security_group.sg) references aws_vpc.main.id, so Terraform knows the VPC has to exist first. The EC2 instance references the subnet and security group, so those are implicit dependencies too. Everything chains together like a logical sequence. Terraform’s DAG can visualize this — you can even run terraform graph | dot -Tpng > graph.png and stare at the dependency arrows until it makes sense.
When Implicit Dependencies Aren’t Enough
Now here’s where explicit dependencies enter the chat.
The lab includes a null_resource with a local provisioner that runs after the EC2 instance is created. The provisioner just echoes a message — not important. What is important is the depends_on block:
depends_on = [aws_instance.ec2] # ✅ EXPLICIT DEPENDENCY
Why is this explicit dependency needed? Because the provisioner doesn’t reference any attribute of the EC2 instance. It just needs the instance to exist first. If you removed that depends_on line, Terraform might try to run the provisioner before the EC2 instance even exists. The DAG would have no idea there was a connection.
Explicit dependencies are for situations where the dependency is invisible to Terraform’s static analysis. You’re essentially saying, “Trust me — this needs to happen after that.” Provisioners, external data sources, or even custom logic that isn’t represented in your code all require depends_on.
The Real Problem With Dependencies
Here’s what nobody talks about: the more you rely on depends_on, the slower your infrastructure provisioning becomes. Explicit dependencies force serialization. When you chain 10 resources together with explicit dependencies, you lose parallelization. Your apply time goes from seconds to minutes.
This is why implicit dependencies are the preferred path — they let Terraform parallelize safely. The subnet creation, security group, and EC2 instance in the lab can all theoretically happen in parallel (modulo the actual AWS API constraints) because their dependencies are direct references.
But over-relying on implicit dependencies leads to coupling. You end up with a tangled mess of resource references. Change one output, and suddenly three other resources break. Good infrastructure code should be modular. That means sometimes you do need depends_on to decouple the dependency graph from the reference graph.
A Practical Lesson
Run the lab configuration locally. Watch terraform plan show you the execution order. Then run terraform graph and look at what Terraform actually sees. You’ll notice something: the null_resource sits at the end of the chain because of depends_on. Everything else chains together via references. The security group might not appear between the subnet and the instance because there’s no direct reference relationship — but it does depend on the VPC indirectly.
This is Terraform’s brain at work. It’s not magic. It’s just a dependency solver, like any package manager. And like any package manager, it can get confused if you don’t tell it the truth.
Mistakes to Avoid
Don’t assume depends_on is a substitute for careful architecture. Don’t create unnecessary explicit dependencies just because you’re nervous about ordering. Don’t ignore the graph output — it’s literally Terraform telling you how it understands your code.
And don’t write configurations where dependencies are ambiguous. If something might need to happen before something else, make it explicit. Future you — the one debugging at 3 a.m. — will be grateful.
The difference between implicit and explicit dependencies isn’t academic. It’s the difference between infrastructure that scales and infrastructure that becomes a brittle hall of mirrors. Master this, and your Terraform code will actually be maintainable.
🧬 Related Insights
- Read more: The ‘I Built’ Post Industrial Complex: Why Standardizing Developer Narratives Backfires
- Read more: Fashion’s Docker Moment: How Textile Giants Are Stealing Tech Stack Playbooks
Frequently Asked Questions
What is an implicit dependency in Terraform?
An implicit dependency occurs when one resource references an attribute of another resource (e.g., vpc_id = aws_vpc.main.id). Terraform automatically infers the ordering without requiring a depends_on block.
When should I use depends_on in Terraform?
Use depends_on when a resource logically depends on another resource but doesn’t reference its attributes directly — typically with provisioners, data sources, or side effects that Terraform can’t detect from static code analysis.
Does using depends_on slow down Terraform apply?
Yes. Explicit dependencies force serialization, preventing parallelization. Prefer implicit dependencies (direct references) when possible, and use depends_on only when necessary to avoid unnecessary performance degradation.
