amazon-ami data source: add sort_by="name" option to select AMIs by lexicographic order instead of creation date #650
Description
Description
The amazon-ami data source currently only supports selecting the "most recent" AMI by creation date (most_recent = true). This is unreliable when multiple AMI families with semantic versioning
coexist in AWS — a patch release for an older version can have a newer creation date than a more recent major/minor version, causing the wrong AMI to be selected.
A sort_by option (e.g. sort_by = "name") would allow users to select AMIs based on lexicographic name order, which correctly reflects semantic versioning in AMI naming conventions.
Use Case(s)
SUSE Linux Enterprise Server (SLES) publishes AMIs following this naming pattern:
suse-sles-15-sp7-v20241105-hvm-ssd-x86_64
suse-sles-15-sp6-v20250210-hvm-ssd-x86_64 ← newer creation date, older SP version
SUSE maintains multiple Service Packs simultaneously, publishing security patches for SP6 even after SP7 is released. With most_recent = true and a wildcard filter like
suse-sles-15-sp*-v202*-hvm-ssd-x86_64, Packer may select SP6 (newer creation date) over SP7 (older creation date but higher version), causing runtime failures due to kernel/package version
mismatches.
Sorting by name would correctly select sp7 over sp6 since sp7 > sp6 lexicographically, regardless of creation dates.
The same issue applies to any AMI family where vendors publish patches for multiple versions in parallel (e.g. Talos Linux, Ubuntu LTS releases, etc.).
Potential configuration
data "amazon-ami" "source_os" {
filters = {
name = "suse-sles-15-sp*-v202*-hvm-ssd-x86_64"
root-device-type = "ebs"
virtualization-type = "hvm"
}
most_recent = true
sort_by = "name" # sort by AMI name instead of creation date
owners = ["013907871322"]
region = var.aws_region
}
Potential References
- AWS DescribeImages API supports returning results but does not natively sort by name — this sorting would need to be implemented in the plugin after fetching results.
- Terraform's aws_ami data source has the same limitation, and users work around it with multi-step data "aws_ami_ids" + locals semantic version parsing — a workaround not available in Packer
HCL due to the absence of for_each on data sources.