AMI Lookup
What does zop.dev create for AMI Lookup?
zop.dev resolves machine images through its provisioner API's ami resource type: a lookup by owner and name pattern, such as owner 602401143452 with amazon-eks-node-al2023-x86_64-standard-1.34-* for EKS workers. Nothing is created and nothing bills; the resolved ID feeds image_id when EC2 instances are provisioned.
| Field | Value |
|---|---|
| Cloud | aws |
Choosing the right machine image is the first step of any EC2 workflow. zop.dev exposes AMI lookup as a resource so image selection is queryable rather than hardcoded.
AMI resolution through the ami resource type
AMI lookup via the provisioner API’s ami resource type; used to resolve image IDs for EC2 instance creation.
Lookup by owner and name pattern
Lookup by owner and name pattern (for example, the EKS worker default: owner 602401143452, name amazon-eks-node-al2023-x86_64-standard-1.34-*).Resolving images, never creating them
Read-oriented resource type. It resolves images, it does not create them.
A lookup that creates nothing
The ami resource type is read-oriented: it resolves an image ID and stops there. Nothing is
created in the account, nothing appears on the bill, and there is nothing to tear down. That
makes it unusual in this directory. Every other resource here leaves something behind, while
this one only answers a question.
The reason it exists as a resource at all is repeatability. Hardcoding an AMI ID into an instance definition works until the image is deprecated or the region changes. AMI IDs are per-region, so the same image carries a different ID in us-east-1 and eu-west-1. A lookup by owner and name pattern travels; a raw ID does not.
Wildcard patterns float to the newest image
The default EKS worker lookup (owner 602401143452, name
amazon-eks-node-al2023-x86_64-standard-1.34-*) ends in a wildcard. Each resolution returns
the newest matching image, so two lookups a month apart can return different AMIs as AWS
publishes patched builds. For node images that is usually the behaviour you want: security
patches arrive without anyone editing configuration.
It also means the result is not stable. When bit-for-bit reproducibility matters (a regulated build, or comparing two instances during an incident), resolve once and pin the returned ID rather than resolving fresh at every provision.
The answer becomes permanent at launch
Whatever the lookup returns is baked into the instance at creation. EC2 has no in-place image swap. Moving to a newer AMI means launching a replacement, and the zop.dev EC2 resource type has no update path anyway. The lookup is cheap and reversible right up until something is created from its result; after that, changing your mind is a rebuild.
The owner filter is also the trust boundary. Constraining lookups to a known account ID is what prevents a similarly-named community image from being resolved by accident. For EKS images that ID is Amazon’s 602401143452.