Terraform 0.13 Brings Powerful Meta-Arguments to Modular Workflows
The upcoming Terraform 0.13 release includes powerful new meta-arguments for modular workflows including count
, for_each
and depends_on
. These language features can simplify and streamline Terraform configurations at the resource-level, and they are now available for module-centric workflows.
In previous Terraform versions, the for_each
and count
features have allowed for systematically creating multiple resource instances from a single resource block based on data from elsewhere in the module:
variable "vpc_id" {
type = string
}
variable "subnets" {
type = map(object({
cidr_block = string
availability_zone = string
}))
}
resource "aws_subnet" "example" {
for_each = var.subnets
cidr_block = each.value.cidr_block
availability_zone = each.value.availability_zone
tags = {
Name = each.key
}
}
Terraform 0.13 introduces a similar capability for entire modules, allowing a single module block to produce multiple module instances systematically:
# Illustrative example only
locals {
resources = {
eks-prod = "prod-eks"
eks-qa = "qa-eks"
eks-dev = "dev-eks"
}
}
module "my-cluster" {
source = "terraform-aws-modules/eks/aws"
for_each = local.resources
cluster_name = each.value
cluster_version = "1.17"
...
worker_groups = [
{
name = each.key
instance_type = var.instance_type
asg_max_size = 5
}
]
}
In previous versions of Terraform, module instances have served only as separate namespaces, and have not been nodes in Terraform's dependency graph themselves. Terraform has always tracked dependencies via the input variables and output values of a module, but users have frequently requested a concise way to declare that all objects inside a module share a particular dependency in the calling module.
Terraform 0.13 introduces this capability by allowing depends_on
as a meta-argument inside module
blocks:
resource "aws_iam_policy_attachment" "example" {
name = "example"
roles = [aws_iam_role.example.name]
policy_arn = aws_iam_policy.example.arn
}
module "uses-role" {
# ...
depends_on = [aws_iam_policy_attachment.example]
}
While we are happy to have made depends_on
available for modular workflows, we recommend considering this a last resort and using data flow to imply dependencies wherever possible. Allowing Terraform to infer dependencies automatically will tend to make your configuration easier to maintain, and will allow Terraform to maximize concurrency when making many changes in a single operation.
We are very excited to be able to bring this first iteration of these in-demand features to our community of Terraform practitioners. Download Terraform 0.13 today, and try count
and for_each
by following our step-by-step tutorials. Learn more by reading the documentation, and draft upgrade guide, and join our community forum to tell us all about it.
Sign up for the latest HashiCorp news
More blog posts like this one

Build secure, AI-driven workflows with Terraform and Vault MCP servers
At AWS Summit New York, HashiCorp introduced new capabilities that bring Terraform, Vault, and Vault Radar into the age of AI agents — advancing secure, automated infrastructure through composable, agentic systems.

Terraform without writing code: How to build self-service with no-code modules
Terraform no-code modules are an advanced infrastructure as code best practice that helps everyone in the org use standard, approved modules, even if you don’t know Terraform.

Helvetia’s journey building an enterprise serverless product with Terraform
What started as a basic compliance challenge for one team at Helvetia Insurance evolved into a comprehensive enterprise solution for running self-managed installations like a cloud service, using Terraform to manage a serverless architecture.