こんにちは！ウォンテッドリーでインフラエンジニアをしている加藤 健です。

先日、Amazon ECR のライフサイクルポリシーを見直しました。

この記事では、ポリシーの選び方と日数の決め方についてまとめています。ECR のコストに悩んでいる方の参考になれば幸いです。

なぜ見直したのか

一番の理由はコスト削減です。ECR の費用の内訳を見ると、そのほとんどがイメージの保存料でした。

さらに調べてみると、保存料の約 8 割は半年以上使われていないイメージのものでした。ライフサイクルポリシーは「9,000 個まで残す」という設定になっていましたが、9,000 個に達するリポジトリはほとんどなく、古いイメージがほぼ削除されていない状態でした。

どのポリシーを選ぶか

ECR のライフサイクルポリシーは、条件に合ったイメージを自動で削除 (またはアーカイブ) してくれる仕組みです。一番気をつけたいのは、いま本番で動いているイメージを消さないこと。設定できるポリシーは以下のとおりです。

以上から、本番のイメージを消すリスクが最も低い「最後の pull から N 日」を採用しました。

何日で削除するか

「最後の pull から N 日」にも落とし穴があります。同じノードでコンテナが再起動するだけなら、ノードに残っているイメージが使われるので ECR からは pull されません。

一方で、EKS のアップグレードではすべてのノードが入れ替わるため、動いているイメージは必ず pull されます。つまり、アップグレードの間隔より長い日数にしておけば、動いているイメージがアーカイブされることはありません。そこで、過去のアップグレードの間隔を調べました。

90 日だと多くの回で間隔のほうが長く、180 日を超えたのは 211 日の 1 回だけでした。そこで、以下の設定にしました。

• 最後の pull から 180 日経過したイメージをアーカイブする
• アーカイブから 90 日経過したイメージを削除する

アーカイブ中は復元できるので、最後の pull から 270 日まではイメージが失われません。

AWS に Feature Request を出しました

本当に欲しかったのは「最後に pull された順に N 個残す」というポリシーです。これがあれば、ノードの入れ替え間隔を気にせずに設定できます。

AWS の containers-roadmap に Issue を立てたので、同じことで困っている方はぜひ 👍 をお願いします！

• https://github.com/aws/containers-roadmap/issues/2885

（2026/11/12 追記）上の表の「最後の pull 日時 × 日数で指定」は、現在はアーカイブだけでなく削除もできます。https://github.com/aws/containers-roadmap/issues/2728

まとめ

• ECR のコストの約 8 割は、半年以上使われていないイメージの保存料だった
• 本番のイメージを消さないために、「最後の pull から N 日」を基準にした
• 日数は EKS アップグレードの間隔から決め、180 日でアーカイブ、さらに 90 日で削除にした

ライフサイクルポリシーは一見シンプルですが、「動いているイメージを消さない」という条件を加えると、意外と選択肢が限られることが分かりました。

最後まで読んでいただき、ありがとうございました！