TerraformPilot

Troubleshooting

Fix Terraform Error - Data Source Returned No Results

Fix the Terraform data source no results error. Covers wrong region, filter typos, missing resources, AMI lookups, and debugging data source queries.

LLuca Berton2 min read

Quick Answer

#

Your data source filter didn't match any resources. Check that you're targeting the correct region/account, verify filter values for typos and case sensitivity, and confirm the resource actually exists using the cloud CLI.

The Error

#

When running terraform plan, you encounter:

Error: no matching EC2 AMI found
Error: no matching VPC found
Error: Your query returned no results. Please change your search
  criteria and try again.
Error: no matching subnet found for filter: ...

What Causes This Error

#

1. Wrong Region

#

The resource exists in us-east-1 but your provider is configured for eu-west-1:

provider "aws" {
  region = "eu-west-1"  # Resource is in us-east-1
}

2. Wrong AWS Account

#

You're authenticated to account A but the resource is in account B.

3. Typos in Filter Values

#

Tag names, AMI name patterns, and filter values are case-sensitive:

# BAD — wrong case
filter {
  name   = "tag:environment"  # Should be "tag:Environment"
  values = ["Production"]     # Actual tag value is "production"
}

4. Resource Doesn't Exist Yet

#

The data source queries a resource that hasn't been created — either it's in the same Terraform config or it was deleted.

5. AMI Not Shared or Not Available

#

For AMIs, the owner must share it with your account, or you need the correct owners filter.

6. Stale Name Pattern

#

AMI name patterns like ubuntu/images/hvm-ssd/ubuntu-focal-* may stop matching after Ubuntu releases a new version that changes the naming convention.

How to Fix It

#

Solution 1: Verify the Resource Exists with CLI

#

Before debugging Terraform, confirm the resource exists:

# Check AMIs
aws ec2 describe-images --filters "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-jammy*" \
  --owners 099720109477 --region us-east-1 --query 'Images[0].ImageId'
 
# Check VPCs
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=production-vpc" \
  --region us-east-1
 
# Check subnets
aws ec2 describe-subnets --filters "Name=tag:Name,Values=private-*" \
  --region us-east-1
 
# Check security groups
aws ec2 describe-security-groups --filters "Name=group-name,Values=web-sg" \
  --region us-east-1

Solution 2: Fix Region and Account

# 
provider "aws" {
  region  = "us-east-1"  # Match where the resource lives
  profile = "production"  # Match the correct account
}
 
# Or use a specific provider alias
provider "aws" {
  alias  = "virginia"
  region = "us-east-1"
}
 
data "aws_ami" "ubuntu" {
  provider    = aws.virginia
  most_recent = true
  owners      = ["099720109477"]
 
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
}

Solution 3: Use most_recent for AMI Lookups

# 
data "aws_ami" "ubuntu" {
  most_recent = true  # Always get the latest match
  owners      = ["099720109477"]  # Canonical
 
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
 
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
 
  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}
 
output "ami_id" {
  value = data.aws_ami.ubuntu.id
}

Common AMI owner IDs:

OSOwner ID
Ubuntu (Canonical)099720109477
Amazon Linuxamazon or 137112412989
Red Hat309956199498
Debian136693071363
CentOS125523088429
Windows Serveramazon or 801119661308

Solution 4: Debug by Relaxing Filters

#

Remove filters one by one to find the mismatch:

# Start broad — does anything match?
data "aws_vpcs" "all" {}
 
output "all_vpcs" {
  value = data.aws_vpcs.all.ids
}
 
# Then add filters back one at a time
data "aws_vpcs" "tagged" {
  filter {
    name   = "tag:Name"
    values = ["production-vpc"]
  }
}

Solution 5: Handle Optional Data Sources

#

Use try() or conditional logic for resources that may not exist:

# Use count to make the data source optional
variable "existing_vpc_name" {
  type    = string
  default = ""
}
 
data "aws_vpc" "existing" {
  count = var.existing_vpc_name != "" ? 1 : 0
 
  filter {
    name   = "tag:Name"
    values = [var.existing_vpc_name]
  }
}
 
locals {
  vpc_id = var.existing_vpc_name != "" ? data.aws_vpc.existing[0].id : aws_vpc.new[0].id
}

Solution 6: Fix Case Sensitivity

#

AWS tag names are case-sensitive. Verify exact casing:

# List all tags on VPCs
aws ec2 describe-vpcs --query 'Vpcs[].Tags[]' --output table
 
# Check exact tag key and value
aws ec2 describe-vpcs \
  --filters "Name=tag-key,Values=Name" \
  --query 'Vpcs[].{ID:VpcId,Tags:Tags}' --output json
# Match the exact case
data "aws_vpc" "main" {
  filter {
    name   = "tag:Name"       # Capital N
    values = ["Production"]   # Exact case match
  }
}

Common Data Source Patterns

# 
# Latest Amazon Linux 2023
data "aws_ami" "al2023" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}
 
# Default VPC
data "aws_vpc" "default" {
  default = true
}
 
# Subnets by tag
data "aws_subnets" "private" {
  filter {
    name   = "vpc-id"
    values = [var.vpc_id]
  }
  tags = {
    Tier = "Private"
  }
}
 
# Availability zones
data "aws_availability_zones" "available" {
  state = "available"
}

Troubleshooting Checklist

#
  1. ✅ Does the resource exist? Check with AWS CLI
  2. ✅ Are you in the correct region?
  3. ✅ Are you in the correct AWS account?
  4. ✅ Are filter values case-correct?
  5. ✅ For AMIs, is owners set correctly?
  6. ✅ For AMIs, is most_recent = true set?
  7. ✅ Does relaxing filters return results?

Prevention Tips

#
  • Always set most_recent = true for AMI data sources
  • Use owners to scope AMI searches — avoids matching community AMIs
  • Verify filters with CLI first — aws ec2 describe-* before using in Terraform
  • Add output blocks to inspect data source results during development
  • Use variables for region/account — makes it explicit which environment you're targeting
#

Conclusion

#

Data source "no results" errors mean your query didn't match anything. Verify the resource exists, check your region and account, fix filter typos and case sensitivity, and add most_recent = true for AMI lookups. Use the CLI to validate your filters before putting them in Terraform.

#data-source#query#filters

Share this article

Related articles