[アップデート] EC2 の AMI に対応インスタンスタイプを設定できるようになったので試してみた

EC2 の AMI に対応インスタンスタイプを指定できる新機能が追加されました。従来のアーキテクチャチェックに加え、特定のインスタンスタイプのみで起動を許可する細かい制御ができるようになったので、実際の動作を確認してみます。
2026.08.31
いわさです。
EC2 の AMI には、その AMI がどのアーキテクチャ（x86_64 や arm64）向けに作られているかといった情報が含まれています。
先日のアップデートで、AMI の所有者が「この AMI はこのインスタンスタイプでのみ起動できる」という対応インスタンスタイプを AMI 自体に定義できるようになりました。
https://github.com/aws/aws-cli/commit/fde0048d6f5e6cbd582133da3fce44358fc01c38
これまでも AMI のアーキテクチャと合わないインスタンスタイプでは起動できませんでしたが、それより細かい粒度で「特定のファミリーやサイズだけ許可する」といった制御ができるようになったみたいです。

特定のインスタンスタイプ向けにチューニング/前提とした AMI を作った時とかに使えそうです。
なお、本日時点でマネジメントコンソールから設定できなさそうで、API では新しく ReplaceImageInstanceTypeSpecification という API が追加されていて、AMI に対応・非対応のインスタンスタイプを設定できます。AWS CLI では 2.36.33 で使えるようになっています。
今回こちらを確認してみたので紹介します。
 実際に確認してみるAWS CLI で試してみます。
今回は東京リージョンで、Amazon Linux 2023 のインスタンスから作成した自前の AMI を使って検証します。作成済みの AMI がこちらです。
$ aws ec2 describe-images --image-ids ami-0dfffad9bb4a5a05d \
  --query 'Images[0].{ImageId:ImageId,Name:Name,InstanceTypeSpecification:InstanceTypeSpecification}' \
  --output json
{
    "ImageId": "ami-0dfffad9bb4a5a05d",
    "Name": "hoge-instance-type-spec-test",
    "InstanceTypeSpecification": null
}
設定前は InstanceTypeSpecification が null になっていますね。この状態だと従来どおり、アーキテクチャさえ合っていればどのインスタンスタイプでも起動できます。
 対応インスタンスタイプを設定するreplace-image-instance-type-specification を使って設定してみましょう。SupportedInstanceTypes に t3.*、UnsupportedInstanceTypes に t3.nano を指定してみます。t3 ファミリーは許可するけれど t3.nano だけは除外する、という設定です。
$ aws ec2 replace-image-instance-type-specification \
  --image-id ami-0dfffad9bb4a5a05d \
  --instance-type-specification 'SupportedInstanceTypes=["t3.*"],UnsupportedInstanceTypes=["t3.nano"]' \
  --output json
{
    "ReturnValue": true
}
SupportedInstanceTypes はインスタンスタイプ名をそのまま書くほか、t3.* のようにワイルドカードで指定できます。
きちんと設定できたか、describe-images で中身を見てみます。
$ aws ec2 describe-images --image-ids ami-0dfffad9bb4a5a05d \
  --query 'Images[0].InstanceTypeSpecification' --output json
{
    "SupportedInstanceTypes": [
        {
            "InstanceType": "t3.*"
        }
    ],
    "UnsupportedInstanceTypes": [
        {
            "InstanceType": "t3.nano"
        }
    ]
}
先ほど null だった箇所に、設定した内容が入っていますね。今回のアップデートで describe-images のレスポンスにこの InstanceTypeSpecification フィールドが追加されています。
サポートするインスタンスタイプと、サポートしないインスタンスタイプのどちらも設定できるわけですが、今回のように t3.* を許可しつつ t3.nano を除外した場合、t3.nano はどっちに転ぶんでしょうか。
これは公式ドキュメントに評価ロジックの記載がありました。何も設定していなければ全許可、UnsupportedInstanceTypes だけなら一致するもの以外は許可、SupportedInstanceTypes を設定した場合は supported に一致しかつ unsupported に一致しないものだけが許可される、とのことです。
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.
https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceImageInstanceTypeSpecification.html
unsupported が優先されるので、今回の設定だと t3.* は許可、ただし t3.nano は除外、という状態になりますね。
 実際に起動して挙動を確認するこの AMI で 3 パターンのインスタンスタイプを起動してみます。
まずは t3.micro から。supported の t3.* に一致し、unsupported にも一致しないので、これは起動できるはずですね。どうなるでしょうか。
$ aws ec2 run-instances --image-id ami-0dfffad9bb4a5a05d \
  --instance-type t3.micro --subnet-id subnet-xxxxxxxx --dry-run
An error occurred (DryRunOperation) when calling the RunInstances operation: Request would have succeeded, but DryRun flag is set.
DryRunOperation が返ってきました。起動できる状態ですね。想定どおりです。
次は t3.nano を試します。supported の t3.* には一致しますが、unsupported に明示しているので、今度は弾かれてほしいところです。
$ aws ec2 run-instances --image-id ami-0dfffad9bb4a5a05d \
  --instance-type t3.nano --subnet-id subnet-xxxxxxxx --dry-run
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.
狙いどおり InvalidParameterCombination でブロックされました。エラーメッセージでも「DescribeImages の InstanceTypeSpecification を確認してね」と案内してくれています。
最後に m5.large も試しておきます。supported の t3.* に一致しないので、こちらも弾かれるはずです。
$ aws ec2 run-instances --image-id ami-0dfffad9bb4a5a05d \
  --instance-type m5.large --subnet-id subnet-xxxxxxxx --dry-run
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.
同じく InvalidParameterCombination になりました。supported に載っていないタイプは弾かれることが確認できますね。
念のため実際に t3.micro で起動してみましたが、こちらは問題なくインスタンスが立ち上がりました。supported に含まれるタイプはこれまでどおり普通に起動できますね。
なお、設定できるのは AMI の所有者だけです。また、AWS Marketplace に出品されている AMI にはインスタンスタイプ指定を設定できず、逆に指定を設定した AMI は Marketplace に出品できないとのことです。
 マネジメントコンソールでの見え方ここまで CLI で確認してきましたが、マネジメントコンソールでどう見えるかも触っておきます。
AMI 一覧の表示列は、デフォルトだとインスタンスタイプ指定の列は出てきません。一覧右上の設定（歯車アイコン）を開くと、属性列に「サポートされるインスタンスタイプ」「サポートされていないインスタンスタイプ」が追加されていました。どちらも初期状態はオフなので、トグルをオンにします。
列を表示させると、指定を設定済みの AMI の行に「1 インスタンスタイプ」のように件数が表示されました。設定していない AMI は - です。
「1 インスタンスタイプ」がリンクになっていたので、詳細が見られるのかと思ってクリックしてみました。すると、遷移先は真っ白なページでした。うーむ...。
一覧に列と件数までは出るものの、詳細を開くところはまだ用意されていないみたいですね。コンソール側は追いついていない雰囲気を感じました。今のところ設定内容をきちんと確認するなら CLI や API を使うのが良さそうです。
一方で、起動時のブロック自体はコンソールからでもきちんと働きました。非対応のインスタンスタイプを選んで起動すると、起動ログの「起動の開始」で失敗し、CLI と同じエラーメッセージが表示されます。
インスタンスタイプを選んだ時点ではなく、起動処理に入ってからブロックされる挙動でした。
 さいごに本日は EC2 の AMI に対応インスタンスタイプを指定して、非対応タイプでの起動をブロックできるようになったので確認してみました。
これまでのアーキテクチャレベルの互換性チェックに加えてインスタンスタイプなどでも絞りたかった方はぜひ使ってみてください！

コンソールもそのうち対応しそうな雰囲気は感じます。