AMI Allowed Instance Types and Launch Governance on Amazon EC2 - What the Image Owner Declares, What Accounts and Organizations Add, and What a Launch-Time Check Leaves Untouched

First Published: 2026-09-24
Last Updated: 2026-10-01

The infrastructure team created an AMI that includes GPU drivers and inference libraries, and they are sharing it with multiple accounts within the organization. One day, the team using the AMI launched it on a generic, small instance type. The launch was successful, but the application could not detect the GPU and failed to function. The infrastructure team had documented in the README that this AMI could only be used with instance types that have a GPU. However, that specific line in the README was not being considered during the launch process.

On September 4, 2026, Amazon EC2 introduced the "AMI allowed instance types" feature. Now, the owner of an AMI can declare, as an AMI attribute, which instance types are allowed and which are not allowed for launching the AMI. If a launch attempt uses an instance type that doesn't match the declared settings, Amazon EC2 will prevent the launch. The previously mentioned line in the README can now be replaced with a declaration that is evaluated at the time of the launch request.

However, the decision on whether a launch is allowed isn't solely based on this one declaration. The consuming account can also have its own "Allowed AMIs" setting, which defines which AMIs it is permitted to discover and use. The organization can distribute this setting to individual accounts through AWS Organizations EC2 policies, and an SCP with the condition key ec2:InstanceType can be used to limit the instance types that can be launched. Therefore, a single launch request is subject to declarations from the AMI owner, the consuming account, and the organization. What does each declaration define, who can remove it, and when is it evaluated? And what can none of them stop?

This article aims to answer these questions. It is not a guide on how to create AMIs or choose instance types. Instead, it will present four declarations, located in three different places, through five key questions. These questions address where the declarations are located, who can change or remove them, when they are evaluated, what enforces them, and what they do not cover. Finally, it will describe what a blocked launch looks like and provide methods for verifying the current status of each declaration. The intended audience includes infrastructure teams that create and distribute AMIs to other accounts and organizations, as well as platform engineers who use those distributed AMIs. Specifically, it targets readers who want to design their systems while avoiding confusion between the similar-sounding "Allowed AMIs" and "AMI allowed instance types."

Three limits on scope come first. This article does not cover the public release of AMIs. Block public access for AMIs, which decides whether an AMI can be made public, is covered in What Can Be Made Public on AWS. This article also does not address the evaluation logic for SCPs. What SCPs reach and do not reach is covered in AWS Organization Guardrails. Furthermore, this article does not discuss the selection of instance types. The lineage of EC2 instance families is documented in Amazon EC2 Instance Types History and Timeline.

All specifications included in this article have been verified against official AWS documentation. The verification date was September 23, 2026. AMI allowed instance types is a recently added feature, introduced on September 4, 2026, so the user guide descriptions may be subject to revision. Any information not explicitly stated in the primary sources is clearly indicated as such. Discrepancies between different primary sources have been left as is in Chapter 8.

Whether an Instance Can Launch Is Not Declared in One Place
The Anatomy of a Declaration - Five Questions Asked of Four Declarations
What the Image Owner Declares - The InstanceTypeSpecification Attribute
How Far the Declaration Travels
What the Consuming Account Declares - Allowed AMIs
What the Organization Declares
What None of the Declarations Covers
How a Blocked Launch Appears and Where to Confirm Each Declaration
Failure Modes and Anti-Patterns
Frequently Asked Questions
Summary
References

1. Whether an Instance Can Launch Is Not Declared in One Place

Whether an instance can be launched isn't determined solely by the permissions of the person making the launch request. Instead, multiple factors come into play: declarations associated with the AMI itself, the settings for the account initiating the launch, and organizational policies. These factors each pose separate questions regarding the request. This chapter will first outline the questions this article addresses and clarify the relationship between these four declarations.

1.1 Shared AMI Launched with Unexpected Instance Types

Incidents like the example described above are more likely to occur when the team creating the AMI and the team using it are separate. The team that created the AMI understands the specific hardware it's designed for. However, the team launching the AMI simply uses the instance types specified in their launch templates or automation configurations. The underlying assumptions were only documented or existed within the knowledge of the creation team.

The "AMI allowed instance types" user guide provides an example of an AMI designed for GPU instances, illustrating the feature's intended use.

For example, if your AMI requires GPU hardware, you can restrict it to GPU instance types
only. If your AMI is incompatible with a specific instance family, you can exclude that family
from the allowed instance types.

The source is the Amazon EC2 User Guide's section on AMI allowed instance types. According to the "What's New" announcement dated September 4, 2026, this feature provides AMI owners with a built-in mechanism.

AMI owners now have a built-in way to prevent launches on instances that are not compatible with their AMIs.

According to "What's New," this feature is available in all AWS Regions. By default, AMIs do not have this declaration, and any instance type can be launched until the owner explicitly adds it.

1.2 Three Places, Four Declarations

The declarations that determine whether an instance can be launched are divided into three places. Each place addresses a different question.

The image owner places declarations within the AMI's InstanceTypeSpecification attribute. The feature name is "AMI allowed instance types." The question it answers is: "With which instance types can this AMI be launched?"

The consuming account places declarations within the account's "Allowed AMIs" settings. The question it answers is: "Which AMIs can this account discover and use?" The instance type is not a factor.

The organization can place two types of declarations. One is through AWS Organizations' EC2 policy, which distributes the "Allowed AMIs" settings from the organization to each account. This addresses the same question as the account's declaration. The other is through the SCP condition key ec2:InstanceType, which limits the instance types that can be launched. This does not consider the AMI.

There are three places for declarations, but there are four declarations in total. These four declarations address three different questions: "This AMI on which types?", "Which AMIs?", "Which types?". Only the owner's declaration answers based on a combination of image and instance type.

Three Places, Four Declarations - What Each One Decides Before an EC2 Launch

Regarding the names, one point needs to be clarified upfront. "Allowed AMIs" and "AMI allowed instance types" have similar names, but they are distinct features. The entities making the declarations are different, and so are the targets being restricted. "Allowed AMIs" restricts the AMI that the consuming account can use. "AMI allowed instance types" restricts the instance types to those that the AMI owner allows. This article will refer to both of these using their full, formal names, and will not use any shortened versions.

1.3 Scope of this Article and Topics Handled in Previous Publications

This article focuses on the launching of Amazon EC2 instances. It addresses five questions regarding each of four declarations: where they are located, who can change or remove them, when they are evaluated, what enforces them, and what they do not cover. These five questions are summarized in a table in Chapter 2, and then explored in detail for each place in Chapters 3 through 6. Chapter 7 outlines what none of the declarations covers, while Chapter 8 discusses how a blocked launch appears and the methods for verifying each declaration.

The following topics are not covered in this article:

AMI publication and settings for preventing publication. What Can Be Made Public on AWS Section 4.2 (Block Storage and Machine Images - EBS Snapshots and AMIs) contains this information. The history of changes to the default setting for blocking public access to AMIs is detailed in AWS Security Defaults History Section 9.2 (The Three Dates Behind Block Public Access for AMIs).
The logic behind SCP evaluations and the entities that do not receive SCPs. AWS Organization Guardrails Section 3.1 (What SCPs do and do not reach) provides this information. An example of an SCP that uses ec2:InstanceType to deny RunInstances can be found in AWS Multi-Account Operational Patterns Section 4.4 (Restrict Expensive EC2 Instance Types).
Designing template constraints in AWS Service Catalog to limit the selection of instance types. Internal Developer Platforms on AWS Section 4.3 (What a Template Constraint Narrows Is the Parameters) contains this information.
AMI end-of-life dates and product support lifecycles. Amazon Linux History and Timeline provides this information.
How to choose instance types. Amazon EC2 Instance Types History and Timeline provides this information.
Settings for sellers on AWS Marketplace. This article only references a primary source description stating that an instance type specification cannot be set on an AMI listed in AWS Marketplace, as described in Section 3.6.
Pricing. This article does not discuss pricing.

2. The Anatomy of a Declaration - Five Questions Asked of Four Declarations

All four declarations follow a similar pattern: a user declares a condition, and AWS enforces that condition at the time of the request. While the structure is the same, the specifics – where the declaration is made, who can remove it, when it is evaluated, what enforces it, and what it does not cover – vary from declaration to declaration. This chapter presents these five aspects in a single table. A similar table can be found in the article Object Lock, Legal Holds, and Event Holds in Amazon S3, which applies these same five questions to Amazon S3 protection.

2.1 Five Questions to Apply to Any Declaration

The rows in the table will contain the following five questions. The row names stay fixed.

Where it is declared — Where is the declaration located? (AMI, account, or organization?)
Who can change or remove it — Who can change or remove it?
When it is evaluated — When is it evaluated? Upon which request?
What enforces it — What enforces it?
What it does not cover — What does it not cover?

The fifth question is the most important. The answers to the other four questions will not reveal what a launch that you intended to govern is actually not protected from.

2.2 Anatomy Table

The table consists of four columns. The first column represents declarations made by the image owner, while the remaining three columns pertain to either accounts or organizations. The second and third columns both reflect the "Allowed AMIs" setting, differing only in which entity holds that setting.

Question	AMI allowed instance types	Allowed AMIs	EC2 policy (Allowed Images Settings)	SCP (`ec2:InstanceType`)
Where it is declared	AMI attribute `InstanceTypeSpecification`. One per AMI.	Account settings. One per Region.	AWS Organizations EC2 policy. Applied to organizations, OUs, or accounts, becoming the Allowed AMIs setting of each account.	AWS Organizations SCP. Applied to organizations, OUs, or accounts.
Who can change or remove it	Only the AMI owner. Sharing recipients cannot make changes. However, if a sharing recipient copies the AMI, they become the owner of the copy.	Entities within an account that have permission to modify the Allowed AMIs settings. Cannot be changed within the account while an EC2 policy holds the setting.	The management account of an organization. Includes member accounts that have been delegated policy management responsibilities.	Same as the EC2 policy column.
When it is evaluated	At the time of a launch request (`RunInstances`). Applies only to new launches.	At the time of requests to find and use AMIs (e.g., describe, copy, launch). In audit mode, it is evaluated but does not prevent the action.	Same as the Allowed AMIs column.	At the time of API requests targeted by the SCP.
What enforces it	Amazon EC2. Prevents launch requests with an `InvalidParameterCombination` error.	Amazon EC2. Makes non-compliant AMIs invisible and prevents them from being used for launch.	Amazon EC2. Enforcement of the declaration occurs within the service's control plane.	IAM authorization. SCP defines the upper limit of permissions available to an entity.
What it does not cover	Existing instances. AMIs copied by sharing recipients and for which they are now the owner. The primary sources do not state whether it applies to type changes of stopped instances, replacement of the root volume using an AMI, or images created with `CreateImage`.	AMIs owned by the account (including copied AMIs). Instance types. The impact on existing instances when enabled is not explicitly stated in the primary sources.	Same as the Allowed AMIs column. It does apply to the management account.	AMIs (the `ec2:InstanceType` condition does not evaluate AMIs). The management account. Service-linked roles. API requests not targeted by the SCP.

The verification date is September 23, 2026. The basis for each cell in the table is provided in the relevant sections from Chapter 3 through Chapter 8, along with supporting primary sources.

2.3 Reading the Table

Reading the table vertically reveals three key points.

First, in the "Where" row, declarations associated with a specific image are only present in the first column. The remaining three columns relate to accounts or organizations, and remain associated with the account that launches the instance. The owner declaration also applies to copies of the AMI (see Section 4.2). Conversely, who can remove the declaration after it travels with a copy depends on whether the copying account becomes the owner (see Section 4.3).

Second, in the "When" row, all four columns are the time of a request. In the "What enforces" row, Amazon EC2 enforces three of the columns, while IAM authorization enforces the fourth. What the primary sources give as the point of evaluation is, for all four, some request, not the running instance itself.

Third, the "What it does not cover" row shows a misalignment in the positions across the four columns. Allowed AMIs does not consider instance types. The SCP ec2:InstanceType condition does not consider AMIs. While the owner declaration applies to copies created by other accounts, those copies allow the creating account to modify the specification. Furthermore, the primary sources only explicitly mention the owner declaration in relation to existing instances. Simply layering these four declarations does not fill in the gaps. Which gaps each declaration closes, and which gaps remain, is discussed in Chapters 4 and 7.

3. What the Image Owner Declares - The InstanceTypeSpecification Attribute

The "AMI allowed instance types" feature allows the image owner to specify two lists within the AMI's InstanceTypeSpecification attribute. This chapter will detail the meaning of these two lists, the four evaluation cases, the constraints on acceptable values, the procedures for configuration and verification, and who is authorized to make changes.

3.1 Two Lists

InstanceTypeSpecification contains two lists. According to the user guide's definition:

SupportedInstanceTypes – The instance types that the AMI supports. Only these instance types can launch with the AMI.
UnsupportedInstanceTypes – The instance types that the AMI does not support. All other
instance types can launch with the AMI.

SupportedInstanceTypes lists the instance types that can be launched with this AMI. UnsupportedInstanceTypes lists the instance types that cannot be launched with this AMI. The former serves as an approved list, while the latter serves as an exclusion list.

3.2 Four Evaluation Cases

The user guide describes the evaluation of two lists in four cases.

If InstanceTypeSpecification is not set, Amazon EC2 allows all instance types. This is the default behavior.
If only SupportedInstanceTypes is set, only the specified instance types are allowed. Amazon
EC2 blocks all other instance types.
If only UnsupportedInstanceTypes is set, Amazon EC2 allows all instance types except those specified.
If both lists are set, the instance type must be in SupportedInstanceTypes and must not be in UnsupportedInstanceTypes.

Each of the four cases works as follows:

Neither list is present. The instance can be launched on all instance types. This is the default setting.
Only SupportedInstanceTypes is present. The instance can only be launched on instance types listed in this list. All other instance types are blocked.
Only UnsupportedInstanceTypes is present. Only the instance types listed in this list are blocked. All other instance types can be launched.
Both lists are present. To launch the instance, the instance type must be included in the SupportedInstanceTypes list and not included in the UnsupportedInstanceTypes list.

In the fourth case, the UnsupportedInstanceTypes list serves to exclude exceptions from the range permitted by the SupportedInstanceTypes list. One of the user guide's CLI examples allows all sizes of t3 and a2 instance types, but excludes only t3.micro (see Section 3.5).

Four Cases of InstanceTypeSpecification - How the Two Lists Decide a Launch

The API Reference for the same functionality describes the evaluation logic in three lines. The second and fourth cases from the user guide are combined into a single line, treating SupportedInstanceTypes as present, and the content is consistent with the user guide.

No specification set – all instance types are allowed.
Only UnsupportedInstanceTypes set – All instance types are allowed except those that match the unsupported list.
SupportedInstanceTypes set – The instance type must match the supported list and must not match the unsupported list.

The source is the Amazon EC2 API Reference's ReplaceImageInstanceTypeSpecification.

3.3 Wildcard

Both lists accept wildcards using the * character. The user guide provides examples of five patterns:

Pattern	User Guide Description
`t3.*`	All sizes within the `t3` family (for example, `t3.micro`, `t3.small`, `t3.large`).
`p4d.*`	All sizes within the `p4d` family.
`g5.*`	All sizes within the `g5` family.
`*xlarge`	Instance types that are xlarge or larger, across all families.
`*.12xlarge`	Instance types that are 12xlarge, across all families.

If you need to determine which families are included or excluded, the format t3.* is straightforward. Patterns that filter by size require careful consideration. While the user guide describes *xlarge as referring to instance types that are xlarge or larger, it doesn't clarify how this pattern handles sizes whose names do not end with "xlarge." If you have a clear understanding of which sizes you want to include or exclude, it is more reliable to specify the instance type names directly, rather than relying on patterns. After specifying the types, review the specification using describe-images and test launching instances in a test environment before sharing.

3.4 Constraints on Values in Lists

The InstanceTypeSpecificationRequest in the API Reference places the following constraints on each of the two lists:

Constraints: Maximum 100 entries. Each entry must be 1-24 characters and match the pattern
^[A-Za-z0-9_.*-]+$. Consecutive wildcard characters (**) are not allowed. Entries must be
unique within each list and across both lists; duplicate entries cause the request to fail.

The following three points are relevant to the design:

Each list can contain a maximum of 100 values. It's more efficient to use family wildcards rather than listing individual types, as this leaves more room within the limit.
You cannot use two consecutive * characters.
You cannot duplicate values, either within a single list or across both lists. If there are any duplicates, the request will fail. For example, you cannot specify t3.micro in SupportedInstanceTypes and also specify t3.micro in UnsupportedInstanceTypes.

3.5 Apply, read, remove

As of the verification date, this specification is not included in the parameters of the CreateImage and RegisterImage APIs. It is applied using ReplaceImageInstanceTypeSpecification after the AMI is created. In the console, you can apply it through the AMI's Actions menu, under "Manage instance type specification."

The CLI example in the user guide allows all t3 and a2 types except t3.micro.

aws ec2 replace-image-instance-type-specification \
    --image-id ami-1234567890abcdef0 \
    --instance-type-specification '{"SupportedInstanceTypes": ["t3.*", "a2.*"], "UnsupportedInstanceTypes": ["t3.micro"]}'

The applied specification can be read from the response of describe-images. In the response, each element of the lists is an object with a field called InstanceType.

{
    "Images": [
        {
            "ImageId": "ami-1234567890abcdef0",
            ...
            "InstanceTypeSpecification": {
                "SupportedInstanceTypes": [
                    {
                        "InstanceType": "t3.*"
                    },
                    {
                        "InstanceType": "a2.*"
                    }
                ],
                "UnsupportedInstanceTypes": [
                    {
                        "InstanceType": "t3.micro"
                    }
                ]
            }
        }
    ]
}

To remove the specification, execute the same command without the --instance-type-specification parameter. After removing it, the AMI will be able to launch with all instance types.

aws ec2 replace-image-instance-type-specification \
    --image-id ami-1234567890abcdef0

This operation replaces the entire specification. The user guide explicitly states this.

The ReplaceImageInstanceTypeSpecification action replaces the entire specification. To add or
remove individual instance types, you must include the complete updated specification in the
request.

Even if you only want to add a single instance type, you need to read the current specification using describe-images, add the desired value, and then pass the entire updated specification. If you only pass the single desired value, all previous values will be lost. When using this operation in an automated process, it's recommended to combine reading, adding, and writing into a single step, and after writing, read the specification again to verify the changes.

3.6 Only the Owner Can Make Changes

The Considerations section of the user guide specifies that only one entity can set and modify the specification.

Only the AMI owner can set or change the instance type specification.

Accounts that have received shared access cannot modify the specification of the shared AMI. Within the owner's account, IAM policies will determine which IAM entities are permitted to perform this operation. However, as of September 23, 2026, an entry for ReplaceImageInstanceTypeSpecification could not be found on the Amazon EC2 page in the Service Authorization Reference. There are entries for the four operations related to Allowed AMIs. If you intend to explicitly grant or deny this operation using IAM action names, verify the current information in the Service Authorization Reference before doing so.

The API Reference also documents another limitation that is not found in the user guide's features section: its relationship with AWS Marketplace.

To set the instance type specification, you must be the AMI owner. You cannot set an instance
type specification on an AMI that is listed in AWS Marketplace, and you cannot list an AMI in
AWS Marketplace if it has an instance type specification set.

You cannot apply this specification to AMIs listed on AWS Marketplace. If an AMI has this specification applied, it cannot be listed on AWS Marketplace. The seller's configuration, which falls outside the scope of this article, determines the instance types accepted by AMIs on AWS Marketplace.

4. How Far the Declaration Travels

The declaration is associated with the AMI. The AMI is shared, copied, and referenced from launch templates and Auto Scaling groups. This chapter will describe how the declaration is handled along each of these paths. It's important to note that how far the declaration travels, and who has the authority to remove it at its destination, are separate questions.

4.1 Accounts that receive shared access cannot modify the specification

The user guide states that if an AMI has a specification, the response from describe-images will include InstanceTypeSpecification. The error message displayed when a launch fails also advises the account attempting the launch to verify the specification using DescribeImages (see Section 8.1).

However, as described in Section 3.6, only the owner can modify the specification. Accounts that have received a shared AMI do not have the means to change the specification. As long as the AMI is used in its shared state, the account launching the instance can only select an instance type that is compatible with the specification.

4.2 CopyImage Inherits the Specification

When you copy an AMI, the new AMI will also inherit the same specification. The following considerations are outlined in the user guide:

When you copy an AMI using CopyImage, Amazon EC2 preserves the instance type specification in the new AMI.

When the owner copies its AMI to a different Region, there is no need to reapply the specification.

4.3 Copying it changes the owner

The account that received the share can copy shared AMIs. When an AMI is copied, the account that performed the copy becomes the new owner. The user guide, in the section describing how AMI copying works, states:

If you copy an AMI that is shared with your account, you are the owner of the target AMI in your account.

Here are the three points mentioned above side by side. Only the owner can modify the specification (Section 3.6). Copies inherit the specification (Section 4.2). When a shared AMI is copied, the account that performed the copy becomes the owner. Combining these points, the account that received the share can replace the specification of the copied AMI. A single sentence that explicitly states this conclusion could not be found in the primary sources, so it is presented here as a logical consequence derived from these three points.

Furthermore, Allowed AMIs does not restrict the AMIs owned by your account (Section 5.5). The copied AMI is an AMI owned by the account that performed the copy. Therefore, that AMI is also no longer subject to the criteria of the copying account's Allowed AMIs.

How a Copy Moves an AMI Out of Its Owner's Declaration

If you want to close this path, there are two places where you can place declarations.

First, on the owner's side. To copy a shared AMI, you need not only permission to access the AMI itself, but also permission to read the underlying storage. The user guide states:

To copy an AMI that was shared with you from another account, the owner of the source AMI must
grant you read permissions for the storage that backs the AMI, not just for the AMI itself.

The owner can decide whether or not to allow copying by granting or denying this permission.

Second, on the consuming account's side. When Allowed AMIs is enabled, operations involving AMIs that do not meet the criteria, including copying, will be restricted (Section 5.1). However, AMIs created by copying an AMI that does meet the criteria are owned by the account that performed the copy, and therefore are no longer subject to the criteria afterward. Allowed AMIs only restricts access at the point of copying.

The owner's declaration checks launches from AMIs that carry the specification. If you want to continue this same check on the shared side, you also need to decide whether or not to allow copying.

4.4 Images Created from Instances

When you run CreateImage on an instance launched from an AMI that has an instance type specification, a new AMI is created. However, the primary sources do not state whether this new AMI will inherit that specification. The user guide explicitly mentions inheritance only in the case of CopyImage.

In contrast, the "What's New" section for AMI watermarks, dated June 24, 2026, explicitly states that watermarks are inherited whether the image is copied or created from an instance.

Once applied, a watermark automatically carries forward to every AMI derived from the
original, whether you copy it across regions or create a new AMI from a running instance.

Similar documentation regarding instance type specifications could not be found in the primary sources reviewed. If the AMI created from an instance requires the same specification, you should apply it manually after creation and then verify it by reading it back using describe-images. Furthermore, the owner of an AMI created from an instance is the account that created it, and that AMI will not be subject to the Allowed AMIs criteria for that account (see Section 5.5).

4.5 Launch templates and Auto Scaling groups

The specification also applies to instances launched through launch templates or Auto Scaling groups. The user guide notes that these launches may fail and recommends verifying compatibility before applying a specification to a shared AMI.

Launch templates and Auto Scaling groups that reference an AMI with an instance type
specification can fail if the configured instance type is not allowed. We recommend verifying
compatibility before setting a specification on shared AMIs.

When combined with the statement that the specification does not apply to existing instances (Section 7.1), a clearer picture of potential failures emerges. Even if the owner applies a specification to a shared AMI, any instances already running will not be affected. If a user has configured an instance type that is incompatible with the specification, the failure first occurs when the Auto Scaling group attempts to launch a new instance. Whether it's a scale-out launch or a replacement launch for an instance deemed unhealthy, both are considered new launches. When application status checks are associated with the instances, Amazon EC2 Auto Scaling also replaces an instance whose overall application status reports impaired. How that status is decided is covered in the article Amazon EC2 Application Status Checks. The time between applying the specification and the emergence of failures can vary, and the failures will occur within the consuming account.

The way failures manifest within an Auto Scaling group is described in Section 8.2.

From the owner's perspective, a crucial preparatory step is to understand which accounts are referencing this AMI. Amazon EC2 AMI usage reports provide information on the accounts referencing the AMI, as well as the number of resources per account and resource type.

For each report, you can see the AWS accounts that are using the AMI, and for each account, a
count of the resources referencing the AMI by resource type.

The reports described in the user guide only provide information on accounts and counts. Details on the instance types being configured by users are not part of that description. The user guide also notes that recent changes to launch templates may not immediately appear in the reports. Before applying a specification, it is advisable to confirm the instance types being used by contacting the administrators of the accounts identified in the reports.

5. What the Consuming Account Declares - Allowed AMIs

Allowed AMIs is a setting that allows an account to define the criteria for AMIs that the account can discover and use. It existed prior to the owner's declaration and was introduced in the "What's New" release dated December 1, 2024. This chapter will describe what this setting restricts, how it can be configured, how to enable it, and what it does not restrict.

5.1 The restriction applies to AMIs, not instance types

The user guide lists three effects when Allowed AMIs is enabled.

The ImageCriteria are applied.
Only allowed AMIs are discoverable in the EC2 console and by APIs that use images (for
example, that describe, copy, store, or perform other actions that use images).
Instances can only be launched using allowed AMIs.

The restriction applies to the AMIs that can be found and the AMIs that can be used for launching instances. The instance type used for launching is not reflected in the criteria of Allowed AMIs in any way. If an AMI meets the criteria, Allowed AMIs will not prevent it from being launched, regardless of the instance type. The owner's declaration or the organization's SCP restricts the instance type.

The configuration unit is a combination of account and Region. The user guide states that it needs to be configured for each Region you want to control.

These settings must be configured in each AWS Region where you want to control AMI usage.

5.2 Criteria Are Built in Three Levels

The criteria for Allowed AMIs are structured in three tiers.

Tier	Content	Matching Method
Parameter Values	Values listed under `ImageProviders`, `ImageNames`, `MarketplaceProductCodes`, and `ImageWatermarks`.	OR. Any one of these values must match.
`ImageCriterion`	A combination of multiple parameters (six in total, including the four above, plus `CreationDateCondition` and `DeprecationTimeCondition`).	AND. All parameters within the `ImageCriterion` must match.
`ImageCriteria`	A collection of multiple `ImageCriterion` entries.	OR. Any one of the `ImageCriterion` entries must match.

The values that can be entered under ImageProviders are AWS-defined aliases and account IDs. amazon refers to AMIs created by Amazon or verified providers; aws-marketplace refers to AMIs created by verified providers on the AWS Marketplace; and aws-backup-vault refers to AMIs from backups stored in an AWS Backup logically air-gapped vault within a specific account. none is a value that limits usage to only AMIs created within your own account and cannot be used in conjunction with other criteria.

The limits are as follows: up to 10 ImageCriterion entries within an ImageCriteria, up to 200 ImageProviders within a single ImageCriterion, and up to 50 entries each for ImageNames, MarketplaceProductCodes, and ImageWatermarks. The user guide recommends using ImageNames in conjunction with ImageProviders to ensure that the AMI is uniquely identified, as using ImageNames alone may not always be sufficient.

5.3 Enabling and defining criteria are separate operations

For Allowed AMIs, the operation to change the status and the operation to define criteria are distinct. Enabling is done using enable-allowed-images-settings.

aws ec2 enable-allowed-images-settings --allowed-images-settings-state enabled

Defining criteria is performed using replace-image-criteria-in-allowed-images-settings, which requires passing a JSON file.

aws ec2 replace-image-criteria-in-allowed-images-settings --cli-input-json file://file_name.json

Disabling is done using disable-allowed-images-settings. While the console allows you to configure both the status and criteria on the same screen, the API and CLI require separate operations. IAM permissions are also divided into four: GetAllowedImagesSettings, EnableAllowedImagesSettings, DisableAllowedImagesSettings, and ReplaceImageCriteriaInAllowedImagesSettings.

Enabling does not mean defining criteria. Conversely, defining criteria will not apply any filtering if the status is still disabled. To verify, read both the status and criteria using get-allowed-images-settings (see Section 8.4).

5.4 Audit Mode - Evaluating Without Restricting

Allowed AMIs can have a status in addition to enabled and disabled: audit-mode. According to the user guide, it functions as follows:

The ImageCriteria are applied, but no restrictions are placed on AMI discoverability or usage.

In audit mode, the AMI is not restricted. Instead, the response from describe-images includes an "ImageAllowed": true or "ImageAllowed": false field, indicating whether the AMI would be usable if enabled. In the console, the AMI details will display an "Allowed image" field, and in the AMI Catalog, AMIs that do not meet the criteria will be marked as "Not allowed."

The user guide recommends starting with Allowed AMIs in audit mode. This allows users to verify which AMIs would be excluded based on the criteria, without preventing users from launching instances. The methods for verification are summarized in a table in Section 8.4.

The descriptions of audit mode differ between the user guide and the API Reference. This discrepancy is addressed in Section 8.6.

5.5 AMIs Owned by the Account Are Not Restricted

There are AMIs that the criteria cannot reach, regardless of how those criteria are defined. The user guide states:

The Allowed AMIs feature only controls the discovery and use of public AMIs or AMIs shared
with your account. It does not restrict the AMIs owned by your account. Regardless of the
criteria you set, the AMIs created by your account are always discoverable and usable by users
in your account.

Allowed AMIs only restricts publicly available AMIs and shared AMIs. AMIs created within your own account can be used without regard to any criteria. As mentioned in Sections 4.3 and 4.4, AMIs created by copying shared AMIs, or AMIs created from instances, are also considered AMIs owned by that account.

Therefore, it is most accurate to interpret Allowed AMIs as a declaration that restricts the entry points for AMIs originating from outside the account. If you wish to control AMIs created within your account, you must design the necessary IAM permissions, specifically the ability to create and copy AMIs. This design falls outside the scope of this article. Building AMIs inside an account with EC2 Image Builder is a separate subject: EC2 Image Builder - Recipes, Workflows, Distribution, and Lifecycle Policies, and What the Image Resource Records About How an AMI Was Built covers it, including which account owns each copy that Image Builder distributes.

5.6 AWS services that launch instances

The criteria for Allowed AMIs also apply to instances launched by AWS services within your account. The user guide's best practices recommend the following:

When using AWS managed services, such as Amazon ECS, Amazon EKS, or AWS Lambda Managed
Instances, we recommend specifying the amazon alias to allow AMIs created by AWS. These
services depend on Amazon-published AMIs to launch instances.

The same section also notes that overly restrictive CreationDateCondition settings may result in launch failures if the provider fails to update the AMI within the specified timeframe. After defining your criteria, it is important to verify that the launch of services using those criteria is successful, considering the results of an audit mode assessment.

6. What the Organization Declares

Organizations can define two types of declarations. One is an EC2 policy that holds the Allowed AMIs setting of accounts. The other is an SCP that limits the instance types. This chapter will describe these two mechanisms. The evaluation logic for SCPs themselves is covered in a separate publication.

6.1 Distributing Allowed AMIs via EC2 Policy

AWS Organizations' EC2 policy is one type of declarative policy. The Organizations user guide lists seven attributes that EC2 policies can manage, including Allowed Images Settings. The Amazon EC2 user guide also states that Allowed AMIs settings can be configured either directly within an account or through a declarative policy.

You specify the Allowed AMIs settings at the account level, either directly in the account or
by using a declarative policy. These settings must be configured in each AWS Region where you
want to control AMI usage. Using a declarative policy allows you to apply the settings across
multiple Regions simultaneously, as well as across multiple accounts simultaneously. When a
declarative policy is in use, you can't modify the settings directly within an account.

While an EC2 policy holds the setting, you cannot modify the Allowed AMIs settings within the account. You can determine who is managing the settings by examining the response from get-allowed-images-settings, specifically the ManagedBy field. The value will be either account or declarative-policy. The management account within Organizations is responsible for creating and applying these policies. According to the Organizations user guide, the management account can also delegate policy management to specific member accounts.

The Organizations user guide explains the difference between declarative policies and SCPs based on where they are enforced.

Declarative policies are enforced in the service's control plane, which is an important
distinction from authorization policies such as service control policies (SCPs) and resource
control policies (RCPs).

On the same page, a comparison table lists Allowed Images Settings as an example of a declarative policy. The row indicating whether it applies to service-linked roles shows "No" for both SCPs and RCPs, but "Yes" for declarative policies. In a table listing policy types, the column indicating whether it applies to the management account shows "No" for both SCPs and RCPs, but "Yes" for declarative policies. Based on these two tables, if an organization distributes Allowed AMIs using an EC2 policy, the same criteria will apply to both the management account and operations performed by AWS services using service-linked roles. The recommendation in Section 5.6 to include the amazon alias becomes particularly relevant when defining criteria at the organization layer.

One pitfall to watch for when writing EC2 policies: the spelling of certain values differs from the EC2 API. In the allowed_images_settings section of an EC2 policy, the state is written as enabled, disabled, and audit_mode, using underscores as separators. However, the EC2 API and CLI use hyphens, writing it as audit-mode. Similarly, the aliases for ImageProviders are aws_marketplace and aws_backup_vault in the EC2 policy, but aws-marketplace and aws-backup-vault in the API. When migrating criteria tested on an account to an organization's policy, you'll need to adjust the spelling accordingly.

The default message displayed when an EC2 policy denies access is described in Section 8.3. Section 7.3 ("What Declarative Policies Do Not Reach") of What Can Be Made Public on AWS outlines the overall scope of declarative policies that include EC2 policies, as well as the range of services that declarative policies do not cover.

6.2 SCPs and `ec2:InstanceType`: Limiting Instance Types

To restrict the types of instances that can be launched, an SCP can use the condition key ec2:InstanceType. The Service Authorization Reference describes this as "Filters access by the type of instance." An example of an SCP that denies requests for instance types not included in the allowed list is provided in Section 4.4 of AWS Multi-Account Operational Patterns. This article does not reproduce that example. The Organizations user guide describes SCPs as policies that control, at the API level, the maximum permissions an entity can have. Therefore, an SCP only affects requests for the specific APIs defined within the SCP itself. The example in that published article targets the RunInstances API.

There are two key points to understand. First, the ec2:InstanceType condition restricts instance types without considering the AMI being used. Defining a policy that restricts AMIs designed for GPUs to GPU instance types cannot be achieved using this condition key alone. Second, SCPs are evaluated as part of the IAM authorization process, and do not apply to all entities. They do not apply to entities within the management account or to service-linked roles. The document AWS Organization Guardrails, Section 3.1, details which entities are subject to SCPs and which are not.

6.3 Places where you can declare images and instance types as a pair

Looking at the RunInstances entry in the Service Authorization Reference, you can see how the condition keys are structured. ec2:InstanceType is associated with the instance resource, while ec2:ImageID and ec2:Owner are associated with the image resource.

Resource	Selected Condition Keys (Excerpt)
`image`	`ec2:ImageID`, `ec2:ImageType`, `ec2:Owner`, `ec2:Public`, `ec2:RootDeviceType`
`instance`	`ec2:InstanceType`, `ec2:Tenancy`, `ec2:EbsOptimized`, etc.

Similarly, SCP can be used to filter AMIs using condition keys associated with the image resource, such as ec2:Owner. However, this addresses the same question as Allowed AMIs: which AMIs are permitted. From IAM's perspective, the question of "which AMI" and the question of "which type" are directed toward different resources. This article does not investigate whether these two elements can be combined into a single unit within an IAM policy. What is certain is that, outside AWS Marketplace listings (Section 3.6), the only place the primary sources indicate for declaring a combination of "this AMI with this type" is the AMI's InstanceTypeSpecification attribute.

6.4 Layers That Limit User Choices

In addition to preventing launch requests, there are also layers that restrict the values users can choose. AWS Service Catalog template constraints allow you to limit the instance types that can be selected as parameters within a product's CloudFormation template. The nature and limitations of this layer are discussed in Section 4.3 of Internal Developer Platforms on AWS. That same section notes that whether users can directly launch large instances without going through the catalog is not related to template constraints, but rather determined by IAM permissions. Amazon EC2 itself applies the AMI owner declaration and the "Allowed AMIs" setting, in relation to the launch request. Neither layer replaces the other.

7. What None of the Declarations Covers

The four declarations outlined so far are all evaluated at the time of the request. This chapter will distinguish between the areas where the declarations do not apply, as explicitly stated in the primary sources, and those areas that are not addressed in the primary sources, leaving it unclear whether they apply or not. Areas that are not addressed in the primary sources are not counted here as areas the declarations do not cover.

7.1 Existing Instances

Regarding owner declarations, the user guide's Considerations state:

The specification does not affect existing instances. It applies only to new launches.

The specification does not affect existing instances; it only applies to new launches. Instances that are already running and do not meet the specification at the time the specification is applied will not be stopped or terminated. Applying a specification does not mean that existing instances will be automatically updated to comply with that specification. If you want to ensure compliance, the consuming side must identify existing instances and replace them. The methods for finding these instances are described in Section 8.5.

7.2 Operations not described in the primary sources

The sentence above promises two things: the specification does not affect existing instances, and it applies to new launches. However, there are certain operations performed on existing instances that the primary sources do not explicitly address regarding whether this specification applies. This article has examined three such cases:

Operation	Conditions Listed in the Primary Documentation	Reference to Instance Type Specification
Changing the instance type of a stopped instance (`ModifyInstanceAttribute`)	The compatibility chapter lists seven factors: virtualization type, architecture, network adapter, enhanced networking, NVMe, the number of volumes that can be attached, and NitroTPM.	None. Not mentioned in the API Reference either.
Replacing the root volume using an AMI	The AMI must have the same product code, billing information, architecture type, and virtualization type as the instance (ENA, sriov-net, NitroTPM, and boot mode support are also conditions).	None.
Creating an AMI from an instance using `CreateImage`	Inheritance is explicitly stated only for `CopyImage` (see Section 4.4).	None.

For these three cases, this article states neither that the specification applies nor that it does not. While changing the instance type does not constitute a new launch, the primary sources do not allow one to definitively conclude that the specification is being ignored, nor that it is included in the compatibility checks. If operations rely on this boundary, test it with a trial account. Stop an instance launched from an AMI that carries the specification, then attempt to change it to a type not covered by the specification, and verify the results before incorporating this into your design.

7.3 Existing Instances When Allowed AMIs Is Enabled

The user guide states that enabling Allowed AMIs affects the AMIs that can be found and the AMIs that can be launched (Section 5.1). Its methods for identifying existing instances launched from AMIs that do not meet the criteria include describe-instance-image-metadata and the AWS Config rule ec2-instance-launched-with-allowed-ami. This rule evaluates both running and stopped instances.

Checks if running or stopped EC2 instances were launched with Amazon Machine Images (AMIs)
that meet your Allowed AMIs criteria.

This rule designates instances launched from AMIs that do not meet the criteria as NON_COMPLIANT when Allowed AMIs is not in the disabled state. However, no explicit statement that describes the impact on existing instances when Allowed AMIs is enabled could be found in the user guide, API Reference, or What's New documentation. The fact that a rule is provided to evaluate instances even when Allowed AMIs is in an enabled state indicates that instances not meeting the criteria may still exist after Allowed AMIs is enabled. However, the primary sources do not clarify whether such instances can be stopped and restarted. This article does not treat Allowed AMIs as a declaration that leaves existing instances unaffected. This is because, unlike an owner's declaration, no such statement could be found in the primary sources.

7.4 Order of Evaluation

No primary source was found that specifies which is evaluated first when a launch request is simultaneously subject to an owner's declaration, Allowed AMIs, and SCP. This article does not describe the order of evaluation. When a launch is blocked, do not look only at the first error returned and conclude that other declarations are not involved. It is possible that a different declaration may block a launch even after one declaration has been corrected. The reason for the launch failure should be determined by examining the status of each declaration using the methods described in Section 8.4.

8. How a Blocked Launch Appears and Where to Confirm Each Declaration

Declarations only become visible when they block something. This chapter describes, for each declaration, how a blocked launch appears, and outlines methods for verifying their current state. Finally, it lists the places where the primary sources disagree.

8.1 When the Owner's Declaration Blocks a Launch

If you attempt to launch an instance type that doesn't meet the specification, Amazon EC2 will halt the launch and return an InvalidParameterCombination error. The user guide refers to this as a "hard block." Examples of requests and resulting errors are shown below:

aws ec2 run-instances \
    --image-id ami-1234567890abcdef0 \
    --instance-type t3.micro

An error occurred (InvalidParameterCombination) when calling the RunInstances operation: This AMI does not support the specified instance type. Check DescribeImages for InstanceTypeSpecification, and try again.

To resolve this, select an instance type that the specification allows. As the message indicates, you can determine which instance types are permitted by reviewing the specification using describe-images. You cannot modify the specification itself (see Section 4.1).

All calls to the Amazon EC2 API are logged in AWS CloudTrail.

CloudTrail captures all Amazon EC2 API calls as events.

If, from the owner's perspective, you need to track who changed the specification and when, search CloudTrail for calls to ReplaceImageInstanceTypeSpecification.

8.2 When Blocked Within an Auto Scaling Group

When an Auto Scaling group attempts to launch an instance and the launch is blocked, the first thing users check is the scaling activity. The description for describe-scaling-activities is as follows:

If an attempt to launch instances failed, the StatusCode value is Failed or Cancelled and the
StatusMessage element in the response indicates the cause of the failure.

As mentioned in Section 4.5, the date the owner applied the specification and the date the Auto Scaling group's instance launch fails may not coincide. If the cause of the scaling activity failure is determined to be the AMI's specification, you have two options: either review the launch template type or request the owner to modify the specification. The choice depends on whether the AMI is truly designed to operate with that particular type. The individuals with the necessary knowledge to make that determination are those who created the AMI.

8.3 When Caused by Allowed AMIs and EC2 Policies

The wording of the error message, which appears when attempting to launch an instance using an AMI that doesn't meet the "Allowed AMIs" criteria, could not be verified in the primary sources. What the user guide states is only the effect: an AMI that doesn't meet the criteria is no longer visible and cannot be used for launching instances. This article does not include that error message wording.

The default message returned when an action is denied due to an EC2 policy is documented in the AWS Organizations user guide.

This action is denied due to an organizational policy in effect.

The organization can customize this message using the exception_message setting within the EC2 policy. Including a link to internal documentation, for example, can help users who are blocked find the appropriate contact for assistance. However, the AWS Organizations user guide advises against including personally identifiable information or confidential data in this message.

8.4 Reading the Current Status of Each Declaration

The methods for reading each declaration are summarized in the following table.

What You Want to Know	Where to Read
Instance type specification associated with an AMI	`describe-images` response, specifically the `InstanceTypeSpecification`. In the console, check the Details tab of the AMI.
Status and criteria for Allowed AMIs in the account, and who has the configuration	`get-allowed-images-settings` response, specifically the `State`, `ImageCriteria`, and `ManagedBy` fields.
Whether individual AMIs meet the Allowed AMIs criteria	`describe-images` response in audit mode, specifically the `ImageAllowed` field. You can filter using the `image-allowed` filter.
Existing instances launched from AMIs that do not meet the criteria	`describe-instance-image-metadata` using the `image-allowed` filter. Also, check the AWS Config rule `ec2-instance-launched-with-allowed-ami`.
Types of existing instances	AWS Config rule `desired-instance-type` (marks instances not in the specified list as NON_COMPLIANT).
Status of attributes managed by the EC2 policy for each account within the organization	AWS Organizations account status report.
Who changed specifications or settings, and when	AWS CloudTrail (all Amazon EC2 API calls are recorded as management events).
Reasons for Auto Scaling group launch failures	`describe-scaling-activities`, specifically the `StatusCode` and `StatusMessage` fields.

An example of searching for existing instances launched from AMIs that do not meet the criteria using the CLI is shown in the user guide as follows:

aws ec2 describe-instance-image-metadata \
    --filters "Name=image-allowed,Values=false" \
    --query "InstanceImageMetadata[*].[InstanceId,ImageMetadata.ImageId]" \
    --output table

describe-instance-image-metadata returns AMIs that were used to launch instances, even if the AMI has been deprecated, deregistered, or made private. The API Reference provides the following explanation:

Describes the AMI that was used to launch an instance, even if the AMI is deprecated,
deregistered, made private (no longer public or shared with your account), or not allowed.

8.5 Verify existing instances against the owner's declaration

Reading the descriptions of the two AWS Config rules listed in Section 8.4, ec2-instance-launched-with-allowed-ami checks against the criteria for Allowed AMIs, while desired-instance-type verifies against the list of instance types specified in the rule's parameters. The instance type specification on the AMI side does not appear in either rule's description. To correlate existing instances with owner declarations, you need to combine two separate data retrievals.

The first retrieval involves obtaining the instance type and AMI used to launch each instance. The response from describe-instance-image-metadata contains both the instance type and AMI information. The API Reference notes that without specifying an instance ID or filter, the command will target all instances, potentially impacting performance. Therefore, in accounts with a large number of instances, it's recommended to use filters to narrow the scope.

aws ec2 describe-instance-image-metadata \
    --query "InstanceImageMetadata[*].[InstanceId,InstanceType,ImageMetadata.ImageId]" \
    --output table

The second retrieval involves obtaining the specification of each AMI.

aws ec2 describe-images \
    --image-ids ami-1234567890abcdef0 \
    --query "Images[].InstanceTypeSpecification"

By cross-referencing these two sets of data, you can identify instances running with instance types that are not permitted according to the AMI's specification. The user will need to determine wildcard matches. As mentioned in Section 3.3, the patterns on the size side can be subject to interpretation, so it is important to visually verify the results of the cross-referencing.

8.6 Areas where the primary sources conflict

As of the verification date, there were four places where the descriptions in the primary sources did not align. This article does not attempt to determine which source is correct.

Description of Audit Mode. The user guide states that in audit mode, criteria are applied (The ImageCriteria are applied, but no restrictions are placed on AMI discoverability or usage.). The API Reference, however, states that criteria are not applied in audit mode (The image criteria in your Allowed AMIs settings are not applied.). Both sources agree that there are no restrictions placed on AMI discovery and usage.
Exclusion of AWS Marketplace. The API Reference mentions that specifications cannot be applied to AMIs offered through the AWS Marketplace, while this information is not found on the user guide's features page (Section 3.6).
Number of Lines Describing Evaluation Logic. The user guide describes this in four lines, while the API Reference uses three. The content itself is consistent (Section 3.2).
Spelling of Values. The same conditions and aliases are written as audit-mode, aws-marketplace, and aws-backup-vault in the EC2 API, but as audit_mode, aws_marketplace, and aws_backup_vault in EC2 policies (Section 6.1). This is more of a formatting difference than a discrepancy, but it can be a source of errors when migrating.

9. Failure Modes and Anti-Patterns

Here's a breakdown of common failure modes and anti-patterns. All of these scenarios involve either a launch going through although a declaration was supposed to block it, or a launch being blocked although no one meant to block it.

9.1 Assuming that enabling Allowed AMIs also prevents launches using incompatible types

Allowed AMIs defines a restricted set of AMIs, and instance types are not a factor (see Section 5.1). If an AMI meets the Allowed AMIs criteria, Allowed AMIs will not prevent launches on any instance type. To restrict AMI usage to specific instance types, have the AMI owner set an instance type specification.

9.2 Assuming that setting the specification updates existing instances to a compatible type

The specification only applies to new launches and does not affect existing instances (see Section 7.1). Existing instances should be identified using the procedure outlined in Section 8.5, and then replaced by the consuming side.

9.3 Passing only the value you want to add to the list

ReplaceImageInstanceTypeSpecification replaces the entire specification (see Section 3.5). If you pass only the value you want to add, any previous values will be overwritten. Review the current specification, assemble the entire structure, submit it, and then retrieve it after it has been written.

9.4 Adding a specification to a shared AMI without verifying its usage

When you apply a specification, nothing happens to existing instances. If the instance type configured by the consuming side doesn't match the specification, the failure will occur within the consuming account when the launch template or Auto Scaling group next launches an instance (see Section 4.5). Before applying a specification, identify the accounts referencing the AMI with AMI usage reports, and verify the instance types they are configured to use.

9.5 Assuming that the specification will also be maintained by those who use a shared AMI

Once an account receives a shared resource, copying it creates a new AMI, and the owner of that copied AMI becomes the account that performed the copy (see Section 4.3). That account can then modify the specification, and the AMI falls outside the Allowed AMIs criteria. The owner determines whether copying is permitted, based on the storage read permissions.

9.6 Assuming that the SCP's `ec2:InstanceType` represents the constraints for each AMI

The SCP condition key ec2:InstanceType is used to filter instance types without regard to the AMI being used (see Section 6.2). This condition key alone does not restrict a specific AMI to a particular instance type. Instance type constraints for individual AMIs should be placed within the AMI owner's declaration.

9.7 Leaving the `amazon` alias out of the organization's criteria

Amazon ECS, Amazon EKS, and AWS Lambda Managed Instances launch instances using AMIs published by Amazon (see Section 5.6). The criteria applied through EC2 policies also apply to operations on service-linked roles and to the management account (see Section 6.1). Before applying the criteria, verify in audit mode that the services' launches are not excluded.

9.8 Deciding on a single blocking declaration from the first error returned

While no primary source outlining the order in which owner declarations, Allowed AMIs, and SCPs are evaluated could be found (see Section 7.4), after correcting one declaration, another declaration can still block the launch. Therefore, it is necessary to check the status of each declaration to identify all potential blocking declarations.

10. Frequently Asked Questions

This chapter presents key points in a question and answer format.

10.1 Are "AMI allowed instance types" and "Allowed AMIs" the same feature?

No. The entities declaring and the targets being restricted are reversed. "AMI allowed instance types" allows the AMI owner to declare, as an AMI attribute, the instance types that are permitted to launch the AMI. "Allowed AMIs" allows an account to declare, as an account setting, the AMIs that the account is allowed to find and use (as described in Section 1.2).

10.2 Will applying an instance type specification to an AMI stop running instances?

No. The user guide clearly states that the specification does not affect existing instances, but only applies to new launches (Section 7.1).

10.3 Can stopped instances be changed to a different instance type that is not in the specification?

The primary sources do not address this point. Neither the section on compatibility when changing types, nor the ModifyInstanceAttribute API Reference, mentions instance type specifications (see Section 7.2). Verify this with a test account before relying on it.

10.4 Can the shared AMI's specification be modified using the account that received the share?

No. Only the owner can modify the specification. However, if an account that received the shared access creates a copy of the AMI, that account becomes the owner of the copied AMI (see Section 4.3).

10.5 Can Allowed AMIs also restrict the AMIs created within my own account?

No. Allowed AMIs only applies to publicly available AMIs and shared AMIs. AMIs created within your own account can be used regardless of any criteria (see Section 5.5).

10.6 Can specifications be added to AMIs listed on the AWS Marketplace?

No. The API Reference states that specifications cannot be added to AMIs that you list, and that AMIs with specifications cannot be listed (see Section 3.6).

10.7 In what order are the declarations in the three places evaluated?

No primary sources were found that specify the order of evaluation. This article does not describe that order (see Section 7.4).

10.8 What is the process for adding just one type to a list in the specification?

To add a single type to the existing specification list, read the entire current specification and pass the complete, updated specification to ReplaceImageInstanceTypeSpecification. This operation replaces the entire specification, so if you only pass the new value, any previous values will be lost (see Section 3.5).

11. Summary

This article outlines four declarations that determine whether an instance can be launched on Amazon EC2, examining them through five questions (where the declaration is placed, who can change or remove it, when it is evaluated, what enforces it, and what it does not cover). It also addresses how a blocked launch appears and how to verify each declaration.

There are three places, four types of declarations, and three categories of questions being addressed. The AMI owner declares the instance types in which this AMI can be launched. The consuming account declares which AMIs it is allowed to use. Organizations can hold the Allowed AMIs setting through EC2 policies and can restrict the instance types allowed using SCPs (ec2:InstanceType). Only the owner's declaration specifies the combination of AMI and instance type.

Allowed AMIs and AMI allowed instance types are separate features. They have reversed roles: the subject making the declaration is different, and the target being restricted is also different.

All four declarations are evaluated at the time of the request. The owner's declaration is explicitly stated not to apply to existing instances. Regarding Allowed AMIs, such a statement could not be confirmed. The primary sources do not describe the relationship with changing instance types while stopped, replacing the root volume using an AMI, or inheritance by an image created from an instance.

The owner's declaration is inherited when an AMI is copied. However, if the account receiving the AMI makes a copy, the ownership transfers to that account, and, as derived in Section 4.3, that account can then modify the specification. The AMI also falls outside that account's Allowed AMIs criteria. The owner's storage read permissions determine whether copying is permitted.

The date the specification is applied and the date of failure may not coincide. If a specification is applied to a shared AMI, and the consuming account has an instance type configured that does not match the specification, the consuming account experiences a failure when its Auto Scaling group next launches an instance. Before applying the specification, verify the accounts referencing the AMI and the instance type configured in those accounts.

When a launch is blocked, the status can be checked for each declaration. The owner's declaration results in an InvalidParameterCombination error and can be viewed using describe-images. Allowed AMIs can be viewed using get-allowed-images-settings, specifically the State and ManagedBy fields. The order in which these evaluations occur is not specified in the primary sources, so do not rely solely on the first error encountered.

This article presents descriptions from primary sources as of September 23, 2026. The "AMI allowed instance types" feature was recently added on September 4, 2026, and the user guide may be revised in the future, including the discrepancies between the primary sources mentioned in Chapter 8. When reading this, verify that the sources listed alongside each section accurately reflect the information presented.

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi