LASSIC Media らしくメディア
AWS ECRのストレージコスト最適化を外注で進める手順
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Amazon ECRのストレージは保存容量に対して課金されるため、古いイメージや未タグイメージが積み重なると月額が膨らみます。ライフサイクルポリシーによる自動削除が基本の打ち手です。
- リージョン跨ぎレプリケーションは複製先リージョンごとに保存容量が増えること、拡張スキャンはAmazon Inspector経由の課金になることなど、ECR固有の費用ポイントを押さえる必要があります。
- CI/CDやマルチアーキ構成を理解した委託先にライフサイクルポリシー設計と運用を任せることで、開発を止めずに継続的なストレージ最適化を進めやすくなります。
目次
Amazon ECRのストレージ課金とは—保存容量とデータ転送の仕組み
Amazon ECR（Elastic Container Registry）は、Dockerコンテナイメージを保存・管理するAWSのフルマネージドなコンテナレジストリです。ECRのコストを考えるうえでまず押さえたいのは、課金が「保存しているイメージの容量」と「リージョンを跨ぐデータ転送」を軸にしている点です。
AWSの料金ページによると、プライベートリポジトリのストレージは保存容量1GBあたり月額0.10USDで課金されます*1（2026年6月時点）。また新規利用者向けには、プライベートリポジトリで月500MBのストレージが利用開始から1年間無料となる枠が用意されています*1。
データ転送については、ECRと同一リージョン内の他のAWSサービス（Amazon ECS・Amazon EKSなど）との間の転送は無料です*1。一方、異なるリージョンとの間で転送されるデータはインターネットデータ転送料金が適用されます*1。つまりECRのコストは「不要なイメージをいかに残さないか」と「リージョンを跨ぐ構成をどう設計するか」で大きく変わってきます。
ストレージが膨らむ原因—古いイメージと未タグイメージの蓄積
ECRのストレージコストが知らぬ間に増えていく背景には、コンテナ開発特有の事情があります。代表的な原因を整理します。
原因1：CI/CDで毎ビルドごとにイメージが積み上がる
継続的インテグレーション（CI）/継続的デリバリー（CD）のパイプラインでは、コミットやビルドのたびに新しいイメージがECRへプッシュされます。デプロイに使うのは通常最新の数世代だけですが、過去のビルド成果物を明示的に削除しないと、リポジトリには履歴が積み重なり続けます。
原因2：未タグ（untagged）イメージが残り続ける
同じタグ（例：latest）に新しいイメージをプッシュすると、以前そのタグが指していたイメージはタグを失い「未タグイメージ」として残ります。未タグイメージは一覧で目立ちにくく、手動では見落とされがちですが、保存容量としては課金対象になり続けます。
原因3：開発・検証用リポジトリの放置
検証目的で作成したリポジトリや、すでに終了したプロジェクトのイメージが削除されないまま残ることもあります。担当者の異動・退職で管理者が変わると、用途を把握している人がいなくなり、誰も触れないイメージが保存され続ける状況が生まれます。
ライフサイクルポリシーによる自動削除—ECRコスト最適化の中心
ECRのストレージ最適化で中心となるのが「ライフサイクルポリシー」です。これは、指定した条件に合致したイメージをECRが自動的に期限切れ（削除）させる仕組みで、ライフサイクルポリシー自体に追加の利用料金はかかりません。手作業での削除に頼らずに保存容量を一定範囲に保てる点が特徴です。
ライフサイクルポリシーの基本ルール
AWSのドキュメントによると、ライフサイクルポリシーは1つ以上のルールで構成され、各ルールが対象イメージと処理内容を定義します*2。ポリシーをリポジトリに適用すると、条件を満たしたイメージは原則として24時間以内に期限切れとして処理されます*2。代表的なルールパラメータは次の通りです。
| パラメータ | 意味 | 主な使いどころ |
|---|---|---|
tagStatus |
対象を未タグ（untagged）・タグ付き（tagged）・すべて（any）のいずれにするかを指定する | 未タグイメージだけを対象に絞って自動削除する |
countType = imageCountMoreThan |
プッシュ日時の新しい順に並べ、指定した世代数を超えたイメージを期限切れにする | 「最新N世代だけ残す」といった世代管理を行う |
countType = sinceImagePushed |
プッシュからの経過日数がcountNumberで指定した日数を超えたイメージを期限切れにする |
「90日より古いイメージを削除」など日数基準で整理する |
tagPrefixList / tagPatternList |
tagStatusがtaggedのときに、特定のタグ接頭辞やパターンに一致するイメージへ対象を限定する |
dev系タグだけを短いサイクルで削除し、本番タグは長く残す |
例えば「未タグイメージは早めに削除する」「dev接頭辞のイメージは最新数世代だけ残す」「本番タグは経過日数で長めに保持する」といったルールを組み合わせることで、開発に必要なイメージは残しながら不要分だけを継続的に圧縮できます。
適用前にプレビューで確認する
AWSのドキュメントでは、ポリシーをリポジトリへ本適用する前に「ライフサイクルポリシープレビュー」で、どのイメージが期限切れの対象になるかを確認することが推奨されています*2。デプロイ中のイメージや、まだ参照されているイメージを誤って削除しないよう、プレビュー結果をレビューしてから適用することが大切です。
レイヤー共有とマルチアーキ—重複排除でストレージを抑える考え方
コンテナイメージは複数の「レイヤー」を積み重ねた構造になっています。ベースイメージや共通ライブラリのレイヤーは、複数のイメージ間で同一であれば共有される設計になっており、この性質を意識すると保存容量の増え方を抑えやすくなります。
ベースイメージを揃えてレイヤーを共有する
アプリケーションごとにバラバラのベースイメージを使うより、組織内でベースイメージを標準化すると、共通レイヤーの重複が減りやすくなります。Dockerfileの記述順を工夫し、変更頻度の低いレイヤー（OSパッケージのインストールなど）を上位に、変更頻度の高いレイヤー（アプリコード）を下位に配置することで、ビルドごとに作り直されるレイヤーを限定し、ストレージとビルド時間の両面で効率化が期待できます。
マルチアーキイメージの扱い
Arm系（AWS Graviton）とx86系の両方に対応するため、マルチアーキ（複数アーキテクチャ対応）イメージを用意するケースが増えています。マルチアーキ構成ではアーキテクチャごとのイメージとそれらをまとめるマニフェストリストが保存されるため、対応アーキテクチャの数だけ保存容量が増える点を踏まえた設計が必要です。なお、ライフサイクルポリシーでは、マニフェストリストから参照されているイメージは、そのマニフェストリストが削除・アーカイブされない限り期限切れにならない仕様になっています*2。マルチアーキ環境では、どのアーキテクチャまで保持するかを運用ルールとして明確にしておくと、不要な保存容量を抑えやすくなります。
レプリケーション・プルスルーキャッシュ・スキャンの費用影響
ストレージ単価とライフサイクルポリシーに加えて、ECR固有の機能がコストに与える影響も押さえておきましょう。
リージョン跨ぎレプリケーションは複製先ごとに保存容量が増える
ECRには、リポジトリを別リージョンや別アカウントへ自動複製するレプリケーション機能があります*3。マルチリージョン構成での可用性向上やデプロイ高速化に有効ですが、複製されたイメージは複製先リージョンにも保存されます。ECRのストレージは保存しているリージョンごとに容量へ課金されるため、複製先が増えるほど保存容量の合計も増える点に注意が必要です。さらに前述の通り、リージョンを跨ぐデータ転送にはデータ転送料金が適用されます*1。「どのイメージを」「どのリージョンまで」複製するかを絞り込むことが、コストを抑える設計のポイントになります。なお、ライフサイクルポリシーは定義したリポジトリにのみ適用されるため、複製先リポジトリにも別途ポリシー設計が必要です*3。
プルスルーキャッシュはキャッシュしたイメージが保存容量になる
プルスルーキャッシュは、外部の公開レジストリのイメージをECRにキャッシュして利用できる機能です。外部レジストリへのアクセス頻度を抑えられる一方、キャッシュされたイメージはECRのプライベートリポジトリに保存されるため、保存容量として課金対象になります。キャッシュ対象が際限なく増えないよう、ここでもライフサイクルポリシーによる世代・日数管理を組み合わせる運用が有効です。
拡張スキャンはAmazon Inspector経由の課金になる
ECRのイメージスキャンには2種類あります。AWSのドキュメントによると、ベーシックスキャンはAWSネイティブの技術でOSの脆弱性を検出する方式です*4。拡張スキャン（Enhanced scanning）はAmazon Inspectorと統合し、OSとプログラミング言語パッケージの双方の脆弱性を継続的にスキャンする方式です*4。拡張スキャンを利用する場合はAmazon Inspector側の料金が発生するため、スキャン方式の選択も費用に影響します。脆弱性管理の要件とコストのバランスを踏まえて選定することが大切です。
ECRはコンテナ運用の一部であり、コンピュート側のコストとあわせて見直すと効果が高まります。クラスタ・ノードの最適化はKubernetes/コンテナのコスト最適化を外注する進め方、Amazon EKSに絞った最適化はAmazon EKSのコスト最適化を外注で進める手順で解説しています。
ECRストレージ最適化を外注する進め方—5ステップ
ECRのストレージ最適化を外注する場合は、いきなり削除を任せるのではなく、段階を踏むことで開発を止めずに進めやすくなります。
ステップ1：現状のリポジトリと保存容量を可視化する
まずリポジトリごとのイメージ数・保存容量・未タグイメージの割合を棚卸しします。どのリポジトリが容量の大半を占めているか、レプリケーションやプルスルーキャッシュがどのリージョンで稼働しているかを把握することで、効果の大きい対象から着手できます。
ステップ2：保持ルールを業務側と合意する
「本番タグは何日（何世代）保持するか」「未タグイメージは何日で削除するか」「dev・検証系はどこまで短縮するか」といった保持ルールを、開発・運用の関係者と合意します。デプロイのロールバック要件や監査上の保持義務がある場合は、それも踏まえて基準を決めます。
ステップ3：ライフサイクルポリシーを設計しプレビューで検証する
合意した保持ルールをライフサイクルポリシーのルールに落とし込み、本適用の前にプレビューで対象イメージを確認します*2。誤削除のリスクが高い箇所は、最初は対象を絞った緩やかなルールから始め、運用しながら段階的に調整する進め方が無難です。
ステップ4：レプリケーション・スキャン設定を見直す
複製先リージョンが本当に必要かを点検し、不要な複製先を整理します。スキャン方式についても、要件に対してベーシックスキャンで足りるか、拡張スキャンが必要かを確認し、過剰なコストが発生していないかを見直します*4。
ステップ5：定期点検の運用サイクルを回す
ライフサイクルポリシーは一度設定して終わりではありません。新しいリポジトリが増えればポリシー未設定のものが生まれるため、定期的に新規リポジトリの有無とポリシー適用状況を点検する運用を組み込みます。委託先には、この定期点検まで含めた継続支援を依頼すると効果が持続しやすくなります。
委託先の選び方と外注時の注意点
ECRストレージ最適化を委託する際は、コンテナ運用とCI/CDの実務に通じた委託先を選ぶことが成果につながります。評価したい観点を整理します。
観点1：CI/CDとコンテナ運用の理解
ライフサイクルポリシーの設計は、デプロイのロールバック要件やビルドパイプラインの構成と密接に関わります。ECRの単純な削除作業ではなく、Amazon ECS・Amazon EKSなどへのデプロイ全体を理解したうえでポリシーを設計できる委託先かどうかを確認しましょう。
観点2：誤削除を防ぐ運用設計力
本番で稼働中のイメージを削除すると、ロールバックや再デプロイに支障が出るおそれがあります。プレビューでの事前検証*2、対象を絞った段階適用、変更内容の記録といった、誤削除を防ぐ運用設計を提案できるかが重要な判断軸です。
観点3：元請（プライムベンダー）か再委託かの確認
委託した作業が再委託されると、AWS環境への権限付与に関する責任の所在が不明確になる場合があります。実際に作業するのが委託先自社のエンジニアか、外部へ流す形になるかを契約前に確認しておくと、権限管理やトラブル時の窓口を一本化しやすくなります。
まとめ—ECRストレージ最適化外注の要点
本稿では、Amazon ECRのストレージコストを最適化する観点と、それを外注で進める手順を整理しました。要点は次の3つです。
第一に、ECRのストレージは保存容量に課金されるため、CI/CDで積み上がる古いイメージや未タグイメージの蓄積が膨張の主因になります。中心の打ち手は、追加料金なしで使えるライフサイクルポリシーによる自動削除です*1*2。
第二に、レプリケーション・プルスルーキャッシュ・スキャンはECR固有の費用ポイントです。複製先リージョンごとに保存容量が増えること、リージョン跨ぎ転送に料金がかかること*1*3、拡張スキャンはAmazon Inspector経由の課金になること*4を踏まえた設計が求められます。
第三に、外注するならCI/CDとコンテナ運用を理解し、誤削除を防ぐ運用設計ができる委託先を選ぶことが大切です。現状可視化・保持ルール合意・プレビュー検証・定期点検まで含めて任せることで、開発を止めずに継続的なストレージ最適化を進めやすくなります。
よくある質問
Amazon ECRのストレージ料金はどのように決まりますか？
AWSの料金ページによると、プライベートリポジトリのストレージは保存容量1GBあたり月額0.10USDで課金されます*1（2026年6月時点）。新規利用者向けには、プライベートリポジトリで月500MBのストレージが利用開始から1年間無料となる枠もあります*1。実際の料金は保存しているイメージの合計容量に比例するため、不要なイメージを残さない運用がコストに直結します。最新の料金はAWS公式の料金ページでご確認ください。
ライフサイクルポリシーを使うと追加料金はかかりますか？
ライフサイクルポリシー機能そのものに追加の利用料金はかかりません。指定した条件に合致したイメージを自動的に期限切れ（削除）させることで、結果的にストレージの保存容量を抑える仕組みです。AWSのドキュメントによると、ポリシー適用後は条件を満たしたイメージが原則24時間以内に処理されるため*2、手作業の削除に頼らず保存容量を一定範囲に保ちやすくなります。
未タグ（untagged）イメージだけを自動で削除できますか？
できます。ライフサイクルポリシーのルールでtagStatusを未タグ（untagged）に指定すると、タグを持たないイメージのみを対象に自動削除を設定できます*2。同じタグへ新しいイメージをプッシュした際に発生する古い未タグイメージは見落とされやすいため、未タグ対象のルールを設けておくと保存容量の無駄を抑えやすくなります。本適用の前にプレビューで対象を確認することをお勧めします。
リージョン跨ぎのレプリケーションを使うとコストはどう変わりますか？
レプリケーションでは、複製されたイメージが複製先リージョンにも保存されます*3。ECRのストレージは保存しているリージョンごとに容量へ課金されるため、複製先が増えるほど保存容量の合計も増えます。加えて、リージョンを跨ぐデータ転送にはデータ転送料金が適用されます*1。可用性やデプロイ要件と照らし合わせ、複製対象のイメージと複製先リージョンを必要な範囲に絞ることがコスト面では有効です。
イメージスキャンを有効にすると費用は増えますか？
スキャン方式によって異なります。AWSのドキュメントによると、ベーシックスキャンはAWSネイティブの技術でOSの脆弱性を検出する方式、拡張スキャンはAmazon Inspectorと統合してOSとプログラミング言語パッケージの脆弱性を継続的にスキャンする方式です*4。拡張スキャンを利用する場合はAmazon Inspector側の料金が発生します。脆弱性管理の要件と費用のバランスを踏まえて方式を選定することが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ITアウトソーシング・クラウド運用のご相談はLASSICへ
元請（プライムベンダー）として、貴社のAmazon ECRストレージ最適化・コンテナ運用体制の構築をご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「Amazon ECR Pricing」（2026年6月時点）
- *2 出典：Amazon Web Services「Automate the cleanup of images by using lifecycle policies in Amazon ECR」（2026年6月時点）
- *3 出典：Amazon Web Services「Private image replication in Amazon ECR」（2026年6月時点）
- *4 出典：Amazon Web Services「Scan images for software vulnerabilities in Amazon ECR」（2026年6月時点）
