![[アップデート] Amazon EC2のAMIで起動可能なインスタンスタイプを制限できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-bac3d29aa65f45576f73094798087ee5/039ad6f8a7d8f18da47986d21c447f48/amazon-ec2?w=3840&fm=webp)
[アップデート] Amazon EC2のAMIで起動可能なインスタンスタイプを制限できるようになりました
はじめに
皆様こんにちは、あかいけです。
EC2を間違って大きいインスタンスタイプで起動してしまい、想定外のコストが発生したことはありますか？私はあります…。
そしてそんな悲しい出来事を予防できそうなアップデートが先日ありました。
というわけで今回は、EC2のAMIで起動可能 / 起動不可なインスタンスタイプを指定できるようになったアップデートを紹介します。
アップデートの概要
今回のアップデートでAmazon EC2でAMI所有者がAMIと互換性のあるインスタンスタイプを明示的に指定できるようになりました。
指定方法として以下の3パターンがあります。
- サポート対象のインスタンスタイプを指定する
- 非対応のインスタンスタイプを指定する
- 両方を組み合わせて指定する
本機能は全リージョンで利用でき、追加料金もかかりません。
また明示的にAMIで設定しない限りは今までどおりすべてのインスタンスタイプで起動できるため、既存のAMIやワークフローへの影響はありません。
追加された属性
今回のアップデートで、AMIにInstanceTypeSpecificationという属性が追加されました。
この属性は次の2つのリストで構成されます。
SupportedInstanceTypes：このAMIが起動をサポートするインスタンスタイプUnsupportedInstanceTypes：このAMIが起動をサポートしないインスタンスタイプ
Amazon EC2は起動時に以下のロジックでインスタンスタイプの可否を判定します。
| 設定状態 | 起動時の挙動 |
|---|---|
InstanceTypeSpecificationが未設定(デフォルト) |
すべてのインスタンスタイプで起動可能 |
SupportedInstanceTypesのみ設定 |
指定したインスタンスタイプのみ起動可能。それ以外はブロック |
UnsupportedInstanceTypesのみ設定 |
指定したインスタンスタイプ以外はすべて起動可能 |
| 両方設定 | SupportedInstanceTypesに含まれ、かつUnsupportedInstanceTypesに含まれないインスタンスタイプのみ起動可能 |
ワイルドカードによる一括指定
SupportedInstanceTypesとUnsupportedInstanceTypesはどちらも*によるワイルドカード指定に対応しています。
そのためインスタンスファミリー単位やサイズ単位でまとめて指定できます。
| パターン | マッチするインスタンスタイプ |
|---|---|
t3.* |
t3ファミリーの全サイズ(t3.micro、t3.small、t3.largeなど) |
p4d.* |
p4dファミリーの全サイズ |
*xlarge |
全ファミリー横断でxlarge以上のサイズ |
*.12xlarge |
全ファミリー横断で12xlargeサイズ |
考慮事項
本設定は既存の起動済みインスタンスには影響せず、新規の起動リクエストにのみ適用されます。
またCopyImageでAMIをコピーした場合、InstanceTypeSpecificationはコピー先のAMIにも引き継がれます。
それ以外にもいくつか考慮事項があるので、詳しくはドキュメントをご確認ください。
どんなユースケースで使えそうか
使い道はいろいろありそうですが、パッと思いつくのは以下あたりでしょうか。
- 検証環境でのコスト節約のため、小さめのインスタンスタイプのみを許可する
- Marketplaceや社内共有しているAMIにて、動作保証外のインスタンスタイプの起動を禁止にする
- GPUドライバやCUDAを前提にビルドしたAMIを、GPUインスタンスファミリー以外で誤って起動されないようにする
- Graviton(arm64)向けにビルドしたAMIを、対応インスタンスタイプに限定する
- 特定ファミリーで不具合があるAMIについて、そのファミリーだけ利用禁止にする
試してみた
ここからは実際の挙動を確認するため、検証してみます。
1. 検証用AMIを準備する
まず検証用のインスタンスを起動し、そこからAMIを作成します。
# 検証用インスタンスを起動
INSTANCE_ID=$(aws ec2 run-instances \
--image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
--instance-type t3.micro \
--query 'Instances[0].InstanceId' \
--output text)
# インスタンスの起動完了を待つ
aws ec2 wait instance-running --instance-ids $INSTANCE_ID
# インスタンスからAMIを作成
AMI_ID=$(aws ec2 create-image \
--instance-id $INSTANCE_ID \
--name "verify-allowed-instance-types-$(date +%s)" \
--no-reboot \
--query 'ImageId' \
--output text)
# AMIが利用可能になるまで待つ
aws ec2 wait image-available --image-ids $AMI_ID
なおこの時点ではInstanceTypeSpecificationは未設定のため、パラメータとして存在しません。
aws ec2 describe-images \
--image-ids $AMI_ID
{
"Images": [
{
"PlatformDetails": "Linux/UNIX",
"UsageOperation": "RunInstances",
"BlockDeviceMappings": [
{
"Ebs": {
"DeleteOnTermination": true,
"Iops": 3000,
"SnapshotId": "snap-XXXXXXXXXXXXXXXXX",
"VolumeSize": 8,
"VolumeType": "gp3",
"Throughput": 125,
"Encrypted": false
},
"DeviceName": "/dev/xvda"
}
],
"EnaSupport": true,
"Hypervisor": "xen",
"Name": "verify-allowed-instance-types-1788611782",
"RootDeviceName": "/dev/xvda",
"RootDeviceType": "ebs",
"SriovNetSupport": "simple",
"VirtualizationType": "hvm",
"BootMode": "uefi-preferred",
"ImdsSupport": "v2.0",
"SourceInstanceId": "i-XXXXXXXXXXXXXXXXX",
"DeregistrationProtection": "disabled",
"SourceImageId": "ami-XXXXXXXXXXXXXXXXX",
"SourceImageRegion": "ap-northeast-1",
"FreeTierEligible": true,
"ImageId": "ami-XXXXXXXXXXXXXXXXX",
"ImageLocation": "XXXXXXXXXXXX/verify-allowed-instance-types-1788611782",
"State": "pending",
"OwnerId": "XXXXXXXXXXXX",
"CreationDate": "2026-09-05T12:36:23.000Z",
"Public": false,
"Architecture": "x86_64",
"ImageType": "machine"
}
]
}
2. 起動可能なインスタンスタイプを制限する
設定にはAWS CLIのreplace-image-instance-type-specificationコマンドを使います。
ここではt3ファミリーだけを許可するように設定してみます。
aws ec2 replace-image-instance-type-specification \
--image-id $AMI_ID \
--instance-type-specification '{"SupportedInstanceTypes": ["t3.*"]}'
{
"ReturnValue": true
}
なお、このコマンドは指定内容全体を置き換える仕様です。
インスタンスタイプを1つだけ追加・削除したい場合も、更新後の完全なリストを毎回渡す必要があります。
また--instance-type-specificationを指定せずに実行すると、設定済みの制約を解除してすべてのインスタンスタイプを起動可能な状態に戻せます。
3. 設定内容を確認してみる
describe-imagesの結果にInstanceTypeSpecificationが反映されていることを確認します。
aws ec2 describe-images \
--image-ids $AMI_ID \
--query 'Images[0].InstanceTypeSpecification'
{
"SupportedInstanceTypes": [
{
"InstanceType": "t3.*"
}
]
}
4. 許可されていないインスタンスタイプで起動してみる
t3ファミリー以外、たとえばm6.largeで起動を試みます。
aws ec2 run-instances \
--image-id $AMI_ID \
--instance-type m6i.large
許可されていないインスタンスタイプなので、InvalidParameterCombinationエラーで起動がブロックされます。
aws: [ERROR]: 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.
ちなみにマネジメントコンソールから起動する際に同じことをすると、そもそもサポートしないインスタンスタイプは選択できないようになっていました。
親切でいいですね。
5. 許可されたインスタンスタイプで起動してみる
もちろん指定したインスタンスタイプであれば、問題なく起動できます。
INSTANCE_ID_2=$(aws ec2 run-instances \
--image-id $AMI_ID \
--instance-type t3.small \
--query 'Instances[0].InstanceId' \
--output text)
さいごに
以上、Amazon EC2でAMIごとに起動可能なインスタンスタイプを制限できるようになったアップデートの紹介でした。
今まではAMIの利用者側で自由に指定できてしまう部分を、AMIの設定でブロックできるようになったのは嬉しいアップデートではないでしょうか。
特に社内向けにAMIを配布 / 管理している方や、Marketplaceで自作AMIを提供している企業などで使い道がある機能だと思います。
