> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Controlling Resource Order with Explicit Dependencies
> Explains using Terraform depends_on to enforce explicit resource creation order, prevent race conditions, and when to prefer implicit dependencies
`depends_on` is a Terraform meta-argument that creates explicit ordering between resources. Terraform usually determines ordering automatically via implicit dependencies when one resource references another's attributes. For example, a subnet that references a VPC ID creates an implicit dependency and Terraform ensures the VPC is created first.
But when Terraform cannot infer the relationship from resource attributes — for instance, when one resource must be fully ready before another starts — you should use `depends_on` to enforce ordering and prevent race conditions.
Key benefits of `depends_on`:
* Forces a specific creation order in Terraform plans and applies.
* Prevents race conditions when resources must be fully provisioned before others start.
* Ensures downstream resources that perform startup actions (migrations, initializations) have their upstream dependencies available.
* Use sparingly — prefer implicit dependencies where possible to retain parallelism and faster provisioning.
Example: RDS database and EC2 web server
* Without `depends_on`, Terraform may create both resources in parallel. If the web server expects the database to be available and initialized at startup (beyond just knowing its ID), you should enforce order with `depends_on`.
```terraform theme={null}
resource "aws_db_instance" "db" {
identifier = "mydb"
engine = "mysql"
instance_class = "db.t3.micro"
allocated_storage = 20
username = "admin"
password = "SuperSecurePassword123!"
skip_final_snapshot = true
}
resource "aws_instance" "app_server" {
ami = "ami-0abcdef1234567890"
instance_type = "t2.micro"
# Ensure the EC2 instance is created only after the DB instance exists.
depends_on = [aws_db_instance.db]
}
```
This `depends_on` prevents Terraform from creating the EC2 instance until the database resource has been created. Use this pattern when the application will try to connect or run migrations at startup and requires the database to be fully provisioned.
Prefer implicit dependencies (resource attribute references) when possible. Overusing `depends_on` serializes execution and reduces Terraform's ability to parallelize resource creation.
Implicit vs explicit dependencies — clarification and examples
* Implicit dependency: Terraform infers ordering from attribute references between resources.
* Explicit dependency: You use `depends_on` when no attribute reference exists that would create the dependency automatically, but you still require a specific order.
Implicit dependency example (security group referenced by EC2 instance)
```terraform theme={null}
resource "aws_security_group" "web" {
name = "web-sg"
}
resource "aws_instance" "app" {
ami = "ami-12345"
instance_type = "t2.micro"
vpc_security_group_ids = [aws_security_group.web.id] # Implicit dependency on aws_security_group.web
}
```
In this example, Terraform automatically orders creation so the security group exists before the instance.
Explicit dependency example (Lambda function depending on a policy attachment that isn't referenced)
```terraform theme={null}
resource "aws_iam_role" "lambda" {
name = "lambda-role"
# role configuration...
}
# Assume this resource exists elsewhere in your configuration and attaches a policy to the role.
resource "aws_lambda_function" "app" {
function_name = "my-function"
role = aws_iam_role.lambda.arn
# The function needs the policy attachment to exist first, but we do not reference its attributes here.
depends_on = [aws_iam_role_policy_attachment.lambda_logs]
}
```
Here, because the Lambda function does not reference attributes from the policy attachment resource, Terraform would not infer the dependency. `depends_on` explicitly enforces the order.
Only use `depends_on` when necessary. If an attribute reference already expresses the dependency, prefer that implicit dependency. Misusing `depends_on` can hide configuration issues and slow down apply operations.
When to use `depends_on` — quick reference table
| Use case | Best practice |
| - | - |
| Resource attributes reference other resources (e.g., `vpc_security_group_ids = [aws_security_group.web.id]`) | Use implicit dependency; no `depends_on` needed |
| A resource must be fully ready before another starts but no attribute reference exists | Use `depends_on` to enforce ordering (e.g., DB ready before app server performing migrations) |
| Resource relationship exists but is represented outside Terraform or via side-effects | Use `depends_on` combined with proper provisioning checks or external data sources |
Related links and references
* [Terraform Meta-Arguments: depends\_on (docs)](https://www.terraform.io/language/meta-arguments/depends_on)
* [Terraform Concepts: Resource Dependencies](https://www.terraform.io/language/dependencies)
* [AWS Provider Documentation](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)
Summary
* `depends_on` gives you explicit control over resource ordering when Terraform cannot infer dependencies from configuration.
* Use it to avoid race conditions and to ensure resources that rely on completed provisioning are created in the correct order.
* Favor implicit dependencies where possible; reserve `depends_on` for cases where explicit ordering is truly required.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.