DEV Community

Cover image for Day 13: Data Sources — Stop Hardcoding, Start Automating
Brian Mengo
Brian Mengo

Posted on

Day 13: Data Sources — Stop Hardcoding, Start Automating

Understanding Terraform Data Sources and Why They Matter
Terraform data sources provide a way to query and reference existing resources in your AWS environment (or any provider) without creating new ones.
This is essential for automation and avoiding manual hardcoding, especially when resource IDs change frequently or you want to ensure you always use the latest available versions.

Unlike resources:
❌ Data sources do not create anything,
✅ They only read pre-provisioned AWS infrastructure without hardcoding.

In this article, we’ll deploy an EC2 instance into an already existing VPC and subnet — without recreating or managing the network itself.

Deploying EC2 in an Existing VPC

  1. A shared VPC and subnet already exist
  2. Create two EC2 instances in subnet one, and two in subnet two
  3. Instead of creating new resource, reference those existing
  4. Use data sources to fetch:
  5. VPC ID by filtering on the VPC name tag (e.g., default).
  6. Subnet ID by filtering subnet name under the VPC.
  7. Latest Amazon Linux 2 AMI ID matching owner and virtualization type

Architecture(Text Diagram)

AWS Account
│
├── Shared Network (Managed Separately)
│   ├── VPC: shared-network-vpc
│   │
│   └── Subnet: shared-primary-subnet
│
└── Application Terraform (Day 13)
    ├── data.aws_vpc.shared
    ├── data.aws_subnet.shared
    ├── data.aws_ami.amazon_linux_2
    │
    └── aws_instance.day13_instance
            └── Uses existing subnet & AMI
Enter fullscreen mode Exit fullscreen mode

Implementation Using Terraform

Step 1: Provider Setup
We start by telling Terraform to use AWS.

provider "aws" {
  region = "ap-south-1"
}
Enter fullscreen mode Exit fullscreen mode

Step 2: Data Source for VPC

data "aws_vpc" "selected" {
  filter {
    name   = "tag:Name"
    values = ["default"]
  }
}
Enter fullscreen mode Exit fullscreen mode

This selects the existing default VPC in the AWS environment.

Step 3: Data Source for Subnet

data "aws_subnet" "shared" {
  filter {
    name   = "tag:Name"
    values = ["Subneta"]
  }

  vpc_id = data.aws_vpc.selected.id
}
Enter fullscreen mode Exit fullscreen mode

Provide vpc_id to restrict search to the selected VPC.

Step 4: Data Source for AMI Image

Use data "aws_ami" "linux2".
Set most_recent = true to pick latest AMI.

data "aws_ami" "Linux2" {
  most_recent = true

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  filter {
    name = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["amazon"]
 }
Enter fullscreen mode Exit fullscreen mode

Step 5: Using Data Sources in EC2 Resource:

Reference AMI ID, as data.aws_ami.Linux2.id.
Reference subnet ID as data.aws_subnet.shared.id.

resource "aws_instance" "example"{
  ami       = data.aws_ami.Linux2.id
  instance_type = "t2.micro"
  subnet_id = data.aws_subnet.shared.id

}
Enter fullscreen mode Exit fullscreen mode

Conclusion
Automation: Using data sources prevents manual hardcoding of AMI, VPC, and subnet IDs.
Reliability: Always uses the latest Amazon Linux 2 AMI available.
Reuse: Leverages existing network resources shared by multiple teams.
Scalability: Making it simple to scale instances with consistent configurations.

Top comments (0)