Data Sources

A data source reads information about infrastructure Terraform does not manage — an existing AMI, the default VPC, the AWS account ID you are running in — so your configuration can reference real values without baking them in as constants. Where a resource creates and owns an object, a data block only looks one up. It never creates, changes, or destroys anything.

The payoff is a configuration that adapts to its environment instead of carrying brittle hardcoded IDs. The same code, run in a different account or region, resolves a different account ID and a different latest AMI on its own — no edit required.

Resource vs Data Source

A resource block manages a lifecycle: Terraform creates the object, tracks it in state, updates it when the config changes, and destroys it on terraform destroy. A data block does none of that. It performs a read against the provider's API and exposes the result as attributes you can reference. Removing a data block from your config removes the lookup; it never touches a real object, because the data source never owned one in the first place.

Common AWS Data Sources

A handful of data sources show up in almost every AWS configuration. aws_ami finds an image by filter — usually the latest one matching a name pattern. aws_availability_zones lists the AZs available in the current region. aws_caller_identity returns the account ID and ARN you are authenticated as. aws_region gives the active region, and aws_vpc looks up an existing VPC by tag or ID. The block below resolves the most recent Amazon Linux 2023 image owned by Amazon and feeds its ID straight into an instance.

data "aws_ami" "al2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.al2023.id
  instance_type = "t3.micro"
}

Read the address carefully: a data source is referenced as data.<type>.<name>.<attribute> — here data.aws_ami.al2023.id — with the data. prefix that distinguishes it from a managed resource. That prefix is the only thing separating a lookup from a thing you own.

Filtering and Selecting

A data source that matches more than one object is a problem, because most expect exactly one result. For aws_ami, most_recent = true resolves the ambiguity by taking the newest match; owners restricts the search to a trusted publisher so you do not accidentally pick up a community image with a colliding name. The filter blocks narrow by attribute, and tags pin down a specific object. Without most_recent, a filter that matches several images either fails or returns a non-deterministic result that changes between runs.

When Data Sources Read

Most data sources read at plan time, so their values are available to the plan and you see real IDs in the diff. The exception is a data source whose arguments depend on a resource that does not exist yet — its read is deferred until apply, after the resource is created. When you have a genuine ordering requirement that Terraform cannot see, add depends_on to the data block so it reads only after the managed resource exists; otherwise the data source may try to read too early and the plan errors.

Outputs from Other Configurations

The terraform_remote_state data source reads another configuration's outputs — a way to consume a network stack's VPC ID in an application stack. It works, but it couples the two configurations tightly: the consumer breaks if the producer's state moves, its outputs change shape, or its backend is reorganized. For cross-stack values, publishing to SSM Parameter Store and reading it back with the aws_ssm_parameter data source keeps the coupling loose — the consumer depends on a stable parameter name, not on another stack's internal state layout.