Image and catalogue actions
Objective
Section titled “Objective”Four read actions that describe what is available to launch, and where.
Three of them are not paginated, and that is a contract rather than an oversight — see below.
Permissions
Section titled “Permissions”All four require "Resource": "*". Describe actions in EC2 are not
resource-scoped.
Instructions
Section titled “Instructions”DescribeImages
Section titled “DescribeImages”| Parameter | Type | Notes |
|---|---|---|
ImageId.N | list | Specific images |
Filter.N | list | name, architecture, state, tag:<key> |
MaxResults | integer | 5 to 1000 |
NextToken | string |
Paginated.
Response: for each image — imageId, name, description,
architecture, imageState, creationDate, rootDeviceType,
blockDeviceMapping.
The description states the login user for that image. It is set by the
distribution, not by us, and using the wrong one produces a permission denied
that looks like a key problem.
There are no public or shared images from other accounts. Every image returned is one we published.
Image names roll. A name points at the newest build we have imported; when
we import a newer one, the name moves and the id changes. Pin by imageId for
a build that cannot change beneath you.
DescribeInstanceTypes
Section titled “DescribeInstanceTypes”| Parameter | Type | Notes |
|---|---|---|
InstanceType.N | list | |
Filter.N | list | vcpu-info.default-vcpus, memory-info.size-in-mib |
MaxResults | integer | 5 to 100 |
NextToken | string |
Paginated.
Response: instanceType, vCpuInfo.defaultVCpus, memoryInfo.sizeInMiB,
instanceStorageSupported, hypervisor, currentGeneration.
[!primary]
Aliases do not appear in this response. The Amazon EC2 model has no field for them, and an SDK discards elements its model does not declare — so an alias returned here would be invisible to the very command a customer runs to look for it.
The alias table is published in Instance types instead. Each alias is also accepted in
InstanceType.Non this call, so a lookup by alias works even though the response names our own type.
DescribeRegions
Section titled “DescribeRegions”| Parameter | Type | Notes |
|---|---|---|
RegionName.N | list | |
Filter.N | list | region-name, endpoint |
Not paginated. Never returns a NextToken.
Response: regionName, regionEndpoint, optInStatus.
DescribeAvailabilityZones
Section titled “DescribeAvailabilityZones”| Parameter | Type | Notes |
|---|---|---|
ZoneName.N | list | |
Filter.N | list | zone-name, state, region-name |
Not paginated. Never returns a NextToken.
Response: zoneName, zoneId, regionName, zoneState.
Each of our regions returns exactly one zone. Ask for it rather than constructing the name, and store what you are given: a caller that assumes one zone forever will need changing when there are two, and a caller that reads this call will not.
Why three of these must not paginate
Section titled “Why three of these must not paginate”DescribeRegions, DescribeAvailabilityZones and DescribeAccountAttributes
are modelled as unpaginated in the Amazon EC2 service definition. Every AWS SDK
therefore builds no paginator for them and discards any NextToken we might
return.
A caller would then receive a truncated list — half the zones, half the regions — with no error and no indication that anything was missing. Silent truncation of a location list is worse than an error, because the code proceeds confidently on a partial answer.
So these actions return every result in one response, always.