Amazon EC2 の新機能 AMI Watermarks で承認済みAMIの利用を強制してみた
はじめに
2026年6月24日、Amazon EC2にAMI Watermarks機能が追加されました。
従来、AMIの来歴を追跡するには命名規則やタグに頼るしかなく、コピーや派生を経ると元のAMIとの関係を把握しにくい課題がありました。AMI Watermarksはこの課題を解決する機能です。プライベートAMIに構造化された識別子を埋め込み、コピーや派生時に自動で引き継ぎます。
機能の要点をまとめます。
| 項目 | 内容 |
|---|---|
| WatermarkKey の形式 | アカウントID:ウォーターマーク名(アカウントID は自動付与) |
| 伝播 | CopyImage, CreateImage で自動的に引き継がれる |
| 上限 | 1 AMI あたり最大5個 |
| 対象 | プライベートAMI のみ(パブリックAMI には付与不可) |
| 料金 | 追加料金なし |
| リージョン | 全リージョン(中国・GovCloud 含む) |
ウォーターマークの基本操作
検証環境は以下の通りです。
- リージョン: ap-northeast-1
- CLI: aws-cli/2.35.11
付与
ウォーターマークはプライベートAMIにのみ付与可能なため、まずパブリックAMIをコピーしてプライベートAMIを作成します。
aws ec2 copy-image \
--source-image-id ami-0bc1ef7af11bba977 \
--source-region ap-northeast-1 \
--region ap-northeast-1 \
--name "watermark-test"
{
"ImageId": "ami-0496605161386a315"
}
AMIがavailableになった後、ウォーターマークを付与します。
aws ec2 attach-image-watermark \
--image-id ami-0496605161386a315 \
--watermark-name "my-approved-ami" \
--region ap-northeast-1
{
"WatermarkKey": "123456789012:my-approved-ami"
}
WatermarkKey はアカウントIDが自動付与された形式で生成されます。
確認
describe-images の ImageWatermarks フィールドで確認できます。
aws ec2 describe-images --image-ids ami-0496605161386a315 --region ap-northeast-1
"ImageWatermarks": [
{
"WatermarkKey": "123456789012:my-approved-ami",
"SourceImageRegion": "ap-northeast-1",
"SourceImageId": "ami-0496605161386a315",
"SourceImageCreationTime": "2026-06-24T23:22:04.976000+00:00",
"WatermarkCreationTime": "2026-06-24T23:23:15.914000+00:00"
}
]
削除
detach-image-watermark でウォーターマークを削除できます。先ほどのAMIは後続の検証で使用するため、別のテスト用AMIで確認しました。
aws ec2 detach-image-watermark \
--image-id ami-094676932a70ae1b1 \
--watermark-key "123456789012:my-approved-ami" \
--region ap-northeast-1
{
"Return": true
}
削除後、describe-images で ImageWatermarks フィールドは空になりました。なお、ドキュメントによると既に派生AMIに伝播済みのウォーターマークは元AMIから削除しても影響を受けません。
フィルタ
image-watermark-key フィルタで特定のウォーターマークを持つAMIを横断検索できます。
aws ec2 describe-images \
--filters "Name=image-watermark-key,Values=123456789012:my-approved-ami" \
--region ap-northeast-1
派生AMIへの伝播確認
ウォーターマーク付きAMIからインスタンスを起動し、そのインスタンスから create-image で新しいAMIを作成しました。
# インスタンス起動
aws ec2 run-instances \
--image-id ami-094676932a70ae1b1 \
--instance-type t4g.nano \
--subnet-id subnet-0123456789abcdef0 \
--no-associate-public-ip-address \
--region ap-northeast-1
# AMI作成
aws ec2 create-image \
--instance-id i-0abc1234def567890 \
--name "watermark-derived-test" \
--no-reboot \
--region ap-northeast-1
派生AMI(ami-03df64fb303906bfb)のウォーターマークを確認したところ、元AMIに付いていた5つのウォーターマークが全て引き継がれていました。各ウォーターマークの SourceImageId は元AMI(ami-094676932a70ae1b1)を指しており、タイムスタンプも元のまま保持されています。CreateImage による派生でウォーターマークが確実に伝播することを確認できました。
:::details全5件の出力(クリックで展開)
[
{
"WatermarkKey": "123456789012:test-wm-1",
"SourceImageRegion": "ap-northeast-1",
"SourceImageId": "ami-094676932a70ae1b1",
"SourceImageCreationTime": "2026-06-24T23:30:43.576000+00:00",
"WatermarkCreationTime": "2026-06-24T23:33:26.234000+00:00"
},
{
"WatermarkKey": "123456789012:test-wm-2",
"SourceImageRegion": "ap-northeast-1",
"SourceImageId": "ami-094676932a70ae1b1",
"SourceImageCreationTime": "2026-06-24T23:30:43.576000+00:00",
"WatermarkCreationTime": "2026-06-24T23:33:26.875000+00:00"
},
{
"WatermarkKey": "123456789012:test-wm-3",
"SourceImageRegion": "ap-northeast-1",
"SourceImageId": "ami-094676932a70ae1b1",
"SourceImageCreationTime": "2026-06-24T23:30:43.576000+00:00",
"WatermarkCreationTime": "2026-06-24T23:33:27.649000+00:00"
},
{
"WatermarkKey": "123456789012:test-wm-4",
"SourceImageRegion": "ap-northeast-1",
"SourceImageId": "ami-094676932a70ae1b1",
"SourceImageCreationTime": "2026-06-24T23:30:43.576000+00:00",
"WatermarkCreationTime": "2026-06-24T23:33:28.434000+00:00"
},
{
"WatermarkKey": "123456789012:test-wm-5",
"SourceImageRegion": "ap-northeast-1",
"SourceImageId": "ami-094676932a70ae1b1",
"SourceImageCreationTime": "2026-06-24T23:30:43.576000+00:00",
"WatermarkCreationTime": "2026-06-24T23:33:29.139000+00:00"
}
]
:::
上限テスト
1つのAMIに対して連続でウォーターマークを付与し、上限を確認しました。
for i in 1 2 3 4 5 6; do
echo "--- Attach watermark-$i ---"
aws ec2 attach-image-watermark \
--image-id ami-094676932a70ae1b1 \
--watermark-name "test-wm-$i" \
--region ap-northeast-1
done
1〜5個目は正常に付与されましたが、6個目で以下のエラーが発生しました。
An error occurred (ResourceLimitExceeded) when calling the AttachImageWatermark operation:
Can't attach the watermark because the image already has the maximum number of watermarks (5).
Detach unused watermarks, and try again.
ドキュメント通り、1 AMIあたりの上限は5個です。
なりすまし不可の確認
ウォーターマーク名にコロン(:)を含む別アカウントID風の文字列を指定して付与を試みました。
aws ec2 attach-image-watermark \
--image-id ami-0b685cdf524897143 \
--watermark-name "999999999999:prod-baseline" \
--region ap-northeast-1
An error occurred (InvalidParameter) when calling the AttachImageWatermark operation:
The watermark name isn't valid. The name must be 3-128 characters and can contain only
letters (A-Z, a-z), numbers (0-9), spaces, and the following characters: () [] . / - ' @ _.
コロンは許可文字ではないためエラーになりました。正常な名前を指定すると、WatermarkKeyのプレフィックスとしてサーバー側で自アカウントIDが自動付与されます。
aws ec2 attach-image-watermark \
--image-id ami-0b685cdf524897143 \
--watermark-name "prod-baseline" \
--region ap-northeast-1
{
"WatermarkKey": "123456789012:prod-baseline"
}
WatermarkKey のアカウントID部分はユーザーが指定できないため、別アカウントIDを名乗るウォーターマークを新規に付与することはできません。
Allowed AMIs との連携によるガバナンス強制
audit mode での確認
まずaudit modeでImageWatermarks条件を設定し、AMIの許可状態を確認しました。
# audit mode を有効化
aws ec2 enable-allowed-images-settings \
--allowed-images-settings-state audit-mode \
--region ap-northeast-1
# ウォーターマーク条件を設定
aws ec2 replace-image-criteria-in-allowed-images-settings \
--image-criteria '[{"ImageWatermarks":[{"WatermarkKey":"123456789012:my-approved-ami"}]}]' \
--region ap-northeast-1
{
"State": "audit-mode",
"ImageCriteria": [
{
"ImageWatermarks": [
{
"WatermarkKey": "123456789012:my-approved-ami"
}
]
}
],
"ManagedBy": "account"
}
audit modeではAMIに ImageAllowed フラグが付きますが、起動制限はかかりません。
# ウォーターマーク付きAMI
aws ec2 describe-images --image-ids ami-0496605161386a315 \
--query 'Images[0].ImageAllowed' --output text
# → true
# ウォーターマーク無しAMI(パブリック)
aws ec2 describe-images --image-ids ami-0bc1ef7af11bba977 \
--query 'Images[0].ImageAllowed' --output text
# → false
enabled での起動制限テスト
enabledに切り替え、実際の起動可否を確認しました。
aws ec2 enable-allowed-images-settings \
--allowed-images-settings-state enabled \
--region ap-northeast-1
ウォーターマーク無しAMI で起動を試みた結果:
aws ec2 run-instances \
--image-id ami-0bc1ef7af11bba977 \
--instance-type t4g.nano \
--subnet-id subnet-0123456789abcdef0 \
--region ap-northeast-1
An error occurred (InvalidAMIID.NotFound) when calling the RunInstances operation:
The image id '[ami-0bc1ef7af11bba977]' does not exist
許可されていないAMIは、RunInstances 時に InvalidAMIID.NotFound(存在しないAMIと同じエラー)が返り、起動が拒否されました。
ウォーターマーク付きAMI で起動した結果:
aws ec2 run-instances \
--image-id ami-0496605161386a315 \
--instance-type t4g.nano \
--subnet-id subnet-0123456789abcdef0 \
--region ap-northeast-1
{
"InstanceId": "i-0def4567abc890123",
"State": "pending"
}
ウォーターマーク付きAMIからは正常に起動できました。
検証後、Allowed AMIsをdisabledに戻しています。
ワイルドカード対応
ドキュメントによると、Allowed AMIsの ImageWatermarks 条件で指定する WatermarkKey はワイルドカード(*, ?)に対応しています。
{
"ImageWatermarks": [
{
"WatermarkKey": "111122223333:prod-*",
"MaximumDaysSinceWatermarkCreated": 90
}
]
}
この設定では、アカウント 111122223333 が付与した prod- で始まるウォーターマークを持つAMIのみが許可されます。さらに WatermarkCreationTime から90日以内という条件も加わるため、古いAMIの利用を自動的に制限できます。命名規約を組織で統一しておくことで柔軟なフィルタリングが可能です。
運用設計パターン
ここまでの検証結果を踏まえ、AMI Watermarksを組織のガバナンスに組み込む構成を整理します。
┌─────────────────────────────────────────────────────┐
│ AMIビルドアカウント (111122223333) │
│ - EC2 Image Builder で AMI 作成 │
│ - 作成後にウォーターマーク付与 │
│ - IAM/SCP で DetachImageWatermark を Deny │
└──────────────────────┬──────────────────────────────┘
│ AMI共有 or コピー
▼
┌─────────────────────────────────────────────────────┐
│ ワークロードアカウント │
│ Allowed AMIs (enabled): │
│ WatermarkKey: "111122223333:golden-*" │
│ → このウォーターマーク付きAMIからのみ起動可能 │
└─────────────────────────────────────────────────────┘
なりすまし防止: WatermarkKey のアカウントID部分はサーバー側で自動付与されるため、ビルドアカウント以外がそのアカウントIDを含むウォーターマークを作成することはできません。Allowed AMIs側でアカウントID込みのフルキーを条件にすることで、承認済みアカウントが付与したウォーターマークを持つAMIのみに制限できます。
削除防止: AMIオーナーはウォーターマークを削除できますが、削除するとAllowed AMIsの条件を満たさなくなりインスタンスを起動できなくなります。ビルドアカウント内ではSCPで ec2:DetachImageWatermark をDenyにしておくことで、誤操作や内部脅威による削除も防止できます。
単独アカウントでも利用可能: Allowed AMIsは各アカウントで直接設定できます。さらにDeclarative Policiesを使えばOrganizations配下の全アカウントに一括適用でき、アカウント側での設定変更を禁止することも可能です。
まとめ
AMI Watermarksは、AMIのコピーや派生を経ても来歴情報が自動的に引き継がれる仕組みです。Allowed AMIsと組み合わせることで、組織として承認したウォーターマークを持つAMIからのみインスタンス起動を許可するガバナンスを実装できます。アカウントIDがサーバー側で自動付与される設計により、別アカウントIDを名乗るウォーターマークの新規付与はできません。追加料金もかからないため、AMIガバナンスの基盤として導入しやすい機能です。









