はじめに
前回 ECR ライフサイクルルール についての記事を投稿しました。
今回は一歩踏み込んで、「複数のルールが存在する場合、どのルールが優先されるのか？」という優先度のメカニズムについて具体例を交えて解説します。
ライフサイクルルールの基本原則
ECRのルール評価には、以下の鉄則があります。
- 優先度の数値が小さい順（1, 2, 3...）に適用される
- 最初にマッチしたルールのアクションが適用され、そのイメージの判定はそこで終了する
- すべてのルールは、優先度に関係なく同時に評価される
重要： 「いずれかのルールに合致したら削除（OR条件）」ではなく「早い者勝ちで適用されるルールが決まる」という仕組みです。
判定シミュレーション
以下のイメージ群とルール群がある場合、どのような結果になるか追ってみましょう。
□保持しているイメージ群
| イメージタグ | 作成時刻 | |
|---|---|---|
| a | - | 2026/10/10 |
| b | develop-25.11 | 2026/11/10 |
| c | prod-1.0.0 | 2026/11/20 |
| d | develop-25.12 | 2026/12/10 |
| e | prod-1.1.0 | 2026/12/20 |
| f | develop-26.01 | 2026/01/10 |
| g | prod-1.1.1, latest | 2026/01/20 |
| h | develop-26.02, latest | 2026/02/10 |
□設定するライフサイクルルール
| 優先度 | タグステータス | 一致条件 | アクション |
|---|---|---|---|
| 1 | prod-*, latest | イメージ数 > 100 | アーカイブ |
| 2 | prod-* | イメージ数 > 2 | 失効 |
| 3 | develop-* | イメージ数 > 2 | 失効 |
| 4 | * | 経過日数 > 60 | 失効 |
判定の流れイメージ
実施日を 『2026/02/20』 とします。
この時、60日前となる日付は 『2025/12/22』 です。
Step1. まず最初にすべてのルールを評価
| イメージタグ | 作成時刻 | ルール1判定 | ルール2判定 | ルール3判定 | ルール4判定 | |
|---|---|---|---|---|---|---|
| a | - | 2026/10/10 | - | - | - | ○ |
| b | develop-25.11 | 2026/11/10 | - | - | ○ | ○ |
| c | prod-1.0.0 | 2026/11/20 | - | ○ | - | ○ |
| d | develop-25.12 | 2026/12/10 | - | - | ○ | ○ |
| e | prod-1.1.0 | 2026/12/20 | - | × | - | ○ |
| f | develop-26.01 | 2026/01/10 | - | - | × | × |
| g | prod-1.1.1, latest |
2026/01/20 | × | × | - | × |
| h | develop-26.02, latest |
2026/02/10 | - | - | × | × |
○ : タグ条件、一致条件いずれも合致したのでアクション対象
× : タグ条件に合致したが一致条件に合致しない(現状維持対象)
- : タグ条件に合致しない
Step2. ルール１(prod-*, latest)の適用
対象は g のみですがアクション対象ではありませんでした
Step3. ルール２(prod-*)の適用
この時点での判定対象は g を除いた すべてとなります。
g はルール１で判定結果が下されているのでここでは判定されません。
| イメージタグ | 作成時刻 | ルール1判定 | ルール2判定 | ルール3判定 | ルール4判定 | |
|---|---|---|---|---|---|---|
| a | - | 2026/10/10 | - | - | - | ○ |
| b | develop-25.11 | 2026/11/10 | - | - | ○ | ○ |
| c | prod-1.0.0 | 2026/11/20 | - | ○ | - | ○ |
| d | develop-25.12 | 2026/12/10 | - | - | ○ | ○ |
| e | prod-1.1.0 | 2026/12/20 | - | × | - | ○ |
| f | develop-26.01 | 2026/01/10 | - | - | × | × |
| h | develop-26.02, latest | 2026/02/10 | - | - | × | × |
対象は c e。
c のみが失効します。
Step4. ルール３(develop-*)の適用
上記同様、この時点での判定対象は c e g を除いた すべてとなります。
| イメージタグ | 作成時刻 | ルール1判定 | ルール2判定 | ルール3判定 | ルール4判定 | |
|---|---|---|---|---|---|---|
| a | - | 2026/10/10 | - | - | - | ○ |
| b | develop-25.11 | 2026/11/10 | - | - | ○ | ○ |
| d | develop-25.12 | 2026/12/10 | - | - | ○ | ○ |
| f | develop-26.01 | 2026/01/10 | - | - | × | × |
| h | develop-26.02, latest | 2026/02/10 | - | - | × | × |
対象は b d f h。
b d が失効します。
Step5. ルール４(all)の適用
上記同様、この時点での判定対象は b c d e f g h を除いた すべてとなります。
| イメージタグ | 作成時刻 | ルール1判定 | ルール2判定 | ルール3判定 | ルール4判定 | |
|---|---|---|---|---|---|---|
| a | - | 2026/10/10 | - | - | - | ○ |
対象は a。
a が失効します。
最終的なアクション結果
| イメージ | 適用されたルール | 結果 | 理由 |
|---|---|---|---|
| a | ルール４ | 失効 | 60日以上経過した |
| b | ルール３ | 失効 | develop系で3番目以降に古い |
| c | ルール２ | 失効 | prod系で3番目以降に古い |
| d | ルール３ | 失効 | develop系で3番目以降に古い |
| e | ルール２ | 保持 | prod系の最新2件以内 |
| f | ルール３ | 保持 | develop系の最新2件以内 |
| g | ルール１ | 保持 | ルール１で「100個以内」として保護された |
| h | ルール３ | 保持 | develop系の最新2件以内 |
ポイント：なぜ e は消えなかったのか？
イメージ e は、ルール4（60日経過）の条件にも当てはまっています。しかし、優先度2のルールで「保持」という判定が下されたため、そこで評価が終了し、ルール4で削除されるのを免れました。
このように「残したいものほど優先度を高く設定する」のが鉄則です。
まとめ
-
「残すべきイメージ」の判定を優先度高く設定する
- 優先度の高いルールで「保持」と決まれば、その後の削除ルールに引っかかることはありません
-
範囲の狭い条件（特定のタグ）から順に判定させる
- 特定のタグ（
prod-*など）から順に判定させ、最後に広い条件（ワイルドカード*やタグなしuntagged）を置くのが定石です
- 特定のタグ（
-
or条件はルールを分割して優先度をつける- 単一ルールで複雑な条件は組めないため、ルールを分けて優先順位で制御しましょう
-
最後には必ず「掃除用」のルールを入れる
- コスト最適化のため、最低優先度で「60日経過したら削除」といった、すべてのイメージを拾えるルールを置いておくのがおすすめです
作成する際は「プレビュー」から
AWSマネジメントコンソールには「ルールプレビュー」という、実際にどのイメージが消えるか試せる機能があります。
プレビュー結果をそのまま適用することも可能なので、基本的にはそちらから作成することをお勧めします。