Estimate how long terraform apply will take based on resource count and parallelism.
Terraform executes independent resource operations concurrently up to the -parallelism limit (default 10), so apply time is closer to total_work / parallelism than the sum of every operation's duration — bounded by the slowest single operation, since apply can't finish faster than its longest-running resource. Formula: serial_time = creates×create_time + modifies×modify_time + destroys×destroy_time; parallel_time ≈ max(longest_op, serial_time / min(parallelism, total_resources)).
Serial time
serial_time = creates × avg_create_time + modifies × avg_modify_time + destroys × avg_destroy_time
Parallel apply time
parallel_time = max(longest_op, serial_time / min(parallelism, total_resources))
Terraform's dependency graph means some resources must wait on others, and even with unlimited parallelism, the critical path through dependent resources (e.g. a VPC before its subnets) sets a floor on total apply time — a single slow resource (like an RDS instance taking 10+ minutes) often dominates regardless of parallelism.
Only up to the number of independent (non-dependent) resources ready to apply at once, and up to API rate limits from your cloud provider — beyond that point, more parallelism just means more concurrent operations queueing on the same rate limit.
Some resources (IAM roles, S3 buckets) are near-instant API calls, while others (RDS instances, EKS clusters, ACM certificate validation) involve provisioning infrastructure that takes minutes — use per-resource-type historical timing from your own applies for the most accurate average.
Not necessarily — some resources have slow deletion (e.g. RDS instances with final snapshots, load balancers with dependent ENIs). If your destroys are known to be slower, model them separately rather than reusing the modify-time average.