ECR lifecycle 未設定

ルール ID: aws.ecr.repo.lifecycle-missing ・ カテゴリ: hygiene ・ 必要な読み取り: インベントリのみ(初回スキャンで検出) 計画中

古いイメージを自動整理する仕組みがないまま、イメージが溜まり続けている ECR リポジトリを見つけます。lifecycle policy を 1 つ設定するだけで、以後の蓄積を止められます。

このページは判定規範に従う予定仕様です。閾値・観測窓の根拠(出典)は実装時に付記します。

何を無駄とみなすか

lifecycle policy が設定されておらず、CI/CD が push するたびに古いイメージが際限なく蓄積しているリポジトリ。放置するとストレージ課金が単調に増え続けます。

判定条件

次の両方を満たす場合に候補とします:

• リポジトリに lifecycle policy が設定されていない
• イメージの蓄積が過多である

インベントリのみで判定できるため、初回スキャンから検出できます。

必須 facts

• lifecycle policy の設定有無
• イメージ数・リポジトリの合計サイズ
• 取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

誤検知・危険になり得る条件

• 過去の全バージョンを保持する必要があるリポジトリ(監査要件・長期サポート製品の配布用など)
• タグの付け方が世代管理と対応していないリポジトリ(タグ基準のルールが意図しないイメージを削除対象にし得る)
• ロールバック先として古いイメージを稼働環境が参照し続ける運用

実行前の確認

• 保持が必要な世代数・タグ体系(release タグ・latest 運用など)をオーナーと確認する
• 稼働中のワークロードが古いタグ・ダイジェストを直接参照していないか確認する
• IaC(Terraform / CloudFormation 等)でリポジトリを管理している場合、policy もコード側に追加する

非破壊テストとロールバック

Safety Tier: low(提案するのは lifecycle policy の追加という設定変更)— ただし有効化後はポリシーに一致したイメージが自動削除され、削除されたイメージは元に戻りません。設定変更を「無害な追加」と誤認しないでください。だからこそプレビューでの対象確認を必須手順とします:

1. まず lifecycle policy のプレビュー(dry-run)で、削除対象になるイメージの一覧を確認する
2. 意図しないイメージが含まれていれば、保持世代数・タグ条件を調整して再プレビューする
3. 問題がなければ policy を適用する

ロールバック: policy 自体の削除・緩和はいつでもできます。ただし policy によって削除済みのイメージは戻らないため、初回は保守的な保持条件から始めます。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。効果は policy 適用後の整理が進むにつれて現れます。