1.13 : Terraform Data Sources — Query, Don’t Hardcode

🎯 Goal: Stop guessing AMI IDs or subnet IDs — query AWS dynamically and build portable, environment-agnostic configs.

✅ You’ll master:

✅ data "aws_ami" → Get latest AMIs (no more ami-0c7217cdde317cfec!)

✅ data "aws_vpc" + data "aws_subnet" → Reuse shared infrastructure

✅ Filtering with tags, name, cidr_block

✅ Safe, read-only discovery (no terraform apply side effects)

🧠 Why Data Sources Matter

❌ Without data sources:

Hardcoded ami = "ami-0c721..." → breaks when AMI rotates

Manual subnet_id = "subnet-abc123" → fails in staging/prod

Copy-paste VPC IDs across teams → configuration drift

✅ With data sources:

→ Infrastructure that self-discovers dependencies

→ Truly portable configs (dev → staging → prod)

→ Zero manual lookup — fully automated

💡 Golden Rule:

“If it already exists in AWS — data it. If you’re creating it — resource it.”

📦 Data Source Cheat Sheet (AWS)

Data Source	Use Case	Key Filter Attributes
`aws_ami`	Find OS images	`owners`, `name`, `virtualization_type`, `root_device_type`
`aws_vpc`	Reuse shared VPCs	`tags`, `cidr_block`, `default`
`aws_subnet`	Target specific subnets	`vpc_id`, `availability_zone`, `tags`, `cidr_block`
`aws_iam_role`	Attach to existing roles	`name`
`aws_ssm_parameter`	Read config from SSM	`name`

🎯 Critical:

data blocks are read-only — no side effects on apply

Values resolved during terraform plan → fully predictable

✏️ Hands-On: Data Sources in Action

🔹 Scenario: Deploy to Shared VPC & Subnets

✅ VPC: Name = "shared-prod-vpc" (already exists)
✅ Subnets: Name = "app-subnet-a", "app-subnet-b" (in us-east-1a, us-east-1b)
✅ OS: Latest Amazon Linux 2023 AMI