![[アップデート] EC2 Image Builder ライフサイクルポリシーでワイルドカードによるレシピ指定がサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9a77dea1d7bd5c93a0746301f6ee63e2/e9c4b3d42f7df740ded6031194d290e5/ec2-image-builder?w=3840&fm=webp)
[アップデート] EC2 Image Builder ライフサイクルポリシーでワイルドカードによるレシピ指定がサポートされました
どうも、ちゃだいん（@chazuke4649）です。
EC2 Image Builder のライフサイクルポリシーにおいて、ワイルドカードパターンによるレシピバージョン指定がサポートされました。
EC2 Image Builder enhances lifecycle policies with wildcard support and simplified IAM - AWS
以前、Image Builder リソース自体の自動バージョニングについて記事を書きましたが、今回はライフサイクルポリシー側でのワイルドカード対応です。
先に結論
- ライフサイクルポリシーのリソースセレクションで
x.x.x、1.x.x、1.0.xのワイルドカードパターンが使えるようになり、単一ポリシーで複数レシピバージョンをまとめて管理できるようになった - ワイルドカードは実行時に解決されるため、ポリシー作成後に追加されたレシピバージョンも自動的に対象になる
- 前回記事で紹介したレシピ・コンポーネントの自動バージョニングと組み合わせることで、バージョン管理の運用負荷をさらに軽減できる
アップデート概要
従来、ライフサイクルポリシーでレシピを指定する際は、1.0.0 のように特定のバージョンを指定する必要がありました。新しいレシピバージョンを作成するたびに、ポリシーの更新が必要でした。
今回のアップデートにより、セマンティックバージョニングのワイルドカード x を使用して、複数のバージョンをまとめて指定できるようになりました。
| パターン | マッチ対象 | 例 |
|---|---|---|
x.x.x |
すべてのバージョン | 1.0.0, 2.5.3 など全て |
1.x.x |
メジャーバージョン 1 の全バージョン | 1.0.0, 1.5.2 など |
1.0.x |
バージョン 1.0 の全パッチバージョン | 1.0.0, 1.0.5 など |
ワイルドカードパターンは実行時に解決されます。つまり、ポリシー設定後に新しく作成されたレシピバージョンも、次回のポリシー実行時に自動的に対象に含まれます。
なお、ワイルドカードの記法は前回記事で紹介したレシピ・コンポーネントのバージョン指定と同じ x 形式です（* ではありません）。
やってみた
AWS CLI を使って、ワイルドカードパターンを指定したライフサイクルポリシーの作成・確認を行いました。
ワイルドカードパターンでライフサイクルポリシーを作成
semanticVersion に x.x.x を指定してライフサイクルポリシーを作成します。ライフサイクル実行用の IAM ロールとレシピは事前に作成済みとします。
aws imagebuilder create-lifecycle-policy \
--name "lifecycle-test-wildcard-policy" \
--description "Lifecycle policy with wildcard pattern" \
--execution-role "arn:aws:iam::123456789012:role/ImageBuilderLifecycleRole" \
--resource-type "AMI_IMAGE" \
--status "DISABLED" \
--policy-details '[
{
"action": {
"type": "DELETE",
"includeResources": {
"amis": true,
"snapshots": true
}
},
"filter": {
"type": "AGE",
"value": 180,
"unit": "DAYS",
"retainAtLeast": 1
}
}
]' \
--resource-selection '{
"recipes": [
{
"name": "lifecycle-test-recipe",
"semanticVersion": "x.x.x"
}
]
}'
{
"lifecyclePolicyArn": "arn:aws:imagebuilder:ap-northeast-1:123456789012:lifecycle-policy/lifecycle-test-wildcard-policy"
}
正常に作成されました。ポリシーの詳細を確認してみます。
aws imagebuilder get-lifecycle-policy \
--lifecycle-policy-arn "arn:aws:imagebuilder:ap-northeast-1:123456789012:lifecycle-policy/lifecycle-test-wildcard-policy"
{
"lifecyclePolicy": {
"arn": "arn:aws:imagebuilder:ap-northeast-1:123456789012:lifecycle-policy/lifecycle-test-wildcard-policy",
"name": "lifecycle-test-wildcard-policy",
"description": "Lifecycle policy with wildcard pattern",
"status": "DISABLED",
"executionRole": "arn:aws:iam::123456789012:role/ImageBuilderLifecycleRole",
"resourceType": "AMI_IMAGE",
"policyDetails": [
{
"action": {
"type": "DELETE",
"includeResources": {
"amis": true,
"snapshots": true
}
},
"filter": {
"type": "AGE",
"value": 180,
"unit": "DAYS",
"retainAtLeast": 1
}
}
],
"resourceSelection": {
"recipes": [
{
"name": "lifecycle-test-recipe",
"semanticVersion": "x.x.x"
}
]
},
"dateCreated": "2026-03-31T09:59:27.646000+09:00"
}
}
resourceSelection.recipes[].semanticVersion に x.x.x が設定されていることが確認できます。これにより、lifecycle-test-recipe のすべてのバージョン（現在の 1.0.0 だけでなく、将来作成される 2.0.0 や 1.1.0 など）が自動的にこのライフサイクルポリシーの対象になります。
メジャーバージョン指定（1.x.x）でも確認
1.x.x パターンでもポリシーを作成してみます。
aws imagebuilder create-lifecycle-policy \
--name "lifecycle-test-major-wildcard" \
--description "Lifecycle policy with major version wildcard (1.x.x)" \
--execution-role "arn:aws:iam::123456789012:role/ImageBuilderLifecycleRole" \
--resource-type "AMI_IMAGE" \
--status "DISABLED" \
--policy-details '[
{
"action": {
"type": "DEPRECATE",
"includeResources": {
"amis": true
}
},
"filter": {
"type": "AGE",
"value": 90,
"unit": "DAYS"
}
}
]' \
--resource-selection '{
"recipes": [
{
"name": "lifecycle-test-recipe",
"semanticVersion": "1.x.x"
}
]
}'
{
"lifecyclePolicyArn": "arn:aws:imagebuilder:ap-northeast-1:123456789012:lifecycle-policy/lifecycle-test-major-wildcard"
}
こちらも問題なく作成できました。1.x.x の場合、メジャーバージョン 1 系のレシピのみが対象となり、将来 2.0.0 が作成されても対象外となります。用途に応じて使い分けが可能です。
Terraform での記述例
Terraform で同等のライフサイクルポリシーを作成する場合は、aws_imagebuilder_lifecycle_policy リソースを使用します。
resource "aws_imagebuilder_lifecycle_policy" "example" {
name = "my-lifecycle-policy"
description = "Delete AMIs older than 180 days"
execution_role = aws_iam_role.imagebuilder_lifecycle.arn
resource_type = "AMI_IMAGE"
policy_detail {
action {
type = "DELETE"
include_resources {
amis = true
snapshots = true
}
}
filter {
type = "AGE"
value = 180
unit = "DAYS"
retain_at_least = 1
}
}
resource_selection {
recipe {
name = "my-recipe"
semantic_version = "x.x.x"
}
}
depends_on = [aws_iam_role_policy_attachment.imagebuilder_lifecycle]
}
semantic_version に "x.x.x" を指定することで、AWS CLI と同様にワイルドカードパターンが利用できます。
前回記事で紹介したレシピ側の lifecycle { ignore_changes = [version] } と組み合わせれば、レシピのバージョン自動インクリメントとライフサイクルポリシーの自動追従を一貫して管理できます。
注意点
- ワイルドカードパターンは
x.x.x、1.x.x、1.0.xの 3 種類のみ対応しています。1.x.0のような任意の位置へのワイルドカード指定はできません - ワイルドカードはポリシー実行時に解決されるため、ポリシー作成後に追加されたレシピバージョンは次回実行時から反映されます。逆に言えば、作成直後の実行では反映されない場合があります
まとめ
EC2 Image Builder のライフサイクルポリシーでワイルドカードパターンがサポートされたことで、レシピバージョンが増えてもポリシーの更新が不要になりました。前回記事で紹介したレシピ・コンポーネントの自動バージョニングと合わせて活用すると、Image Builder のバージョン管理全体の運用負荷を大きく軽減できると思います。
それでは今日はこの辺で。ちゃだいん（@chazuke4649）でした。
参考
