# 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. Source: https://zop.dev/integrations/provision/aws/ami-lookup Updated: 2026-08-19 --- 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 ```text 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.