LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

CloudWatch Logsのコストが膨らむ理由：取り込み・保存・分析の3軸と無期限保管の落とし穴

CloudWatch Logsのコスト削減とは、ログの取り込み（ingestion）・保存（storage）・分析（Logs Insights）という3つの課金軸を正確に把握し、用途別の保管期間設定・S3/Glacierへのアーカイブ移行・不要ログの出力削減によって費用を適正化する取り組みです。AWS公式の料金情報^*1によると、東京リージョンでの目安として取り込みは約0.76USD/GB、保存は約0.03USD/GBとされており（AWS公表の目安であり変動します。為替換算による円額は断定できません）、システム規模の拡大に伴いログ量が増えると費用が急増しやすい構造になっています。

コスト膨張の主な原因の一つは、ロググループの保管期間（retention）がデフォルトで「無期限」に設定されていることです。新規に作成したロググループは明示的に設定を変更しない限り、ログが削除されずに蓄積し続けます。システムの稼働年数が長くなるほど保存量が増え、気づいたときには削減の優先順位が立てにくくなっているケースがあります。

もう一つの原因は、取り込み量の管理が後回しになりやすい点です。開発環境や検証環境でDEBUGレベルのログを本番と同じように出力し続けると、取り込み費用が予想以上に積み上がります。ログの出力量と保存量の両方を把握しなければ、削減策の優先順位を決めることができません。

課金3軸の仕組み：ingestion・storage・Logs Insightsを理解する

AWS公式の料金情報^*1によると、CloudWatch Logsの課金は主に3つの軸で構成されています。それぞれの仕組みを正確に把握することが、どの削減策を優先するかの判断につながります。

第1軸：データ取り込み（ingestion）コスト

ロググループにログを送信する際に発生する費用です。AWS公式によると、東京リージョンでの目安は約0.76USD/GBとされています（変動あり）。EC2インスタンス・Lambda関数・ECSコンテナ・アプリケーションがCloudWatch Logsエージェント（CloudWatch Logs Agent）やSDKを通じてログを送信するたびに課金対象になります。

取り込みコストはログの出力量に直接比例します。不要なDEBUGログや冗長なスタックトレースを出力し続けると、ログが増えるほど費用が増加します。アプリケーション側の出力制御が最も根本的な削減手段になります。

第2軸：データ保存（storage）コスト

ロググループに保存されているログデータの量に応じて月次で発生する費用です。AWS公式によると、東京リージョンでの目安は約0.03USD/GBとされています（変動あり）。保存コストは取り込みコストと比べて単価は低いものの、保管期間が無期限のまま放置すると年単位でログが積み上がり、保存量の増加に伴って費用が継続的に発生します。

S3の標準ストレージの保存単価は約0.025USD/GBとされており（AWS公式情報・変動あり）^*2、長期保管についてはS3やGlacier（グレイシャー）を活用した方が費用を抑えられる場合があります。アクティブに参照しなくなったログをCloudWatch Logsに残し続けることは、費用対効果の観点から見直しの余地があります。

第3軸：データ分析（CloudWatch Logs Insights）コスト

CloudWatch Logs Insights（ログインサイト）は、ロググループに対してクエリを実行してログを検索・集計・可視化できる機能です。課金はクエリでスキャンしたデータ量に応じて発生します。クエリの対象ロググループが広い・時間範囲が長いほど、スキャン量が増えて費用が積み上がります。

ログ障害調査や定期的なサービス分析でLogs Insightsを使う頻度が高い環境では、スキャン量の管理が重要になります。対象ロググループを絞り込み、クエリの時間範囲を必要最小限にすることがコスト抑制の基本です。

削減策：retention設定・S3アーカイブ・取り込み量の抑制・メトリクス整理

CloudWatch Logsのコスト削減には、3つの課金軸に対してそれぞれ対応策があります。削減効果の高い順に優先度を付けて取り組むことが大切です。

削減策1：retention（保管期間）を用途別に設定する

ロググループのretentionを無期限から有限に変更することは、保存コスト削減の起点になります。AWS公式ドキュメント^*3によると、CloudWatch Logsでは1日・3日・5日・1週間から10年まで保管期間を設定できます。保管期間を超えたログは自動的に削除されるため、保存量の増加を抑えられます。

設定の考え方は用途によって異なります。開発・検証環境のデバッグログは数日〜1週間程度で十分な場合があります。本番アプリケーションのアクセスログやエラーログは、インシデント対応の観点から1〜3か月程度が目安になります。一方、コンプライアンス要件（例：金融系のシステム監査ログ）では法令・社内規程に従って3年・5年などを設定する必要があります。

AWSマネジメントコンソール・AWS CLI・AWS CloudFormation（クラウドフォーメーション）のいずれからでも設定でき、既存のロググループに対して一括変更することも可能です。多数のロググループが存在する場合は、AWS CLIスクリプトや Infrastructure as Code（IaC）を使った一括設定が効率的です。

削減策2：古いログをS3・Glacierへアーカイブする

リアルタイム監視が不要になった古いログは、CloudWatch Logsに保存し続けるよりS3やGlacier（グレイシャー）にエクスポートすることで、保存コストを抑えられます。AWS公式によるとS3 Standardの保存単価は約0.025USD/GB（目安・変動あり）^*2であり、長期アーカイブ向けのGlacier Deep Archive（ディープアーカイブ）はさらに低い保存単価で設定されています。

エクスポートの方法は主に2種類あります。1つ目は手動エクスポートです。コンソールまたはAWS CLIでエクスポートタスクを作成し、対象ロググループの時間範囲と出力先S3バケットを指定してログを書き出せます。過去ログのバックアップや一時的なアーカイブに向いています。

2つ目はサブスクリプションフィルター（Subscription Filter）を使ったリアルタイム転送です。Kinesis Data Firehose（キネシス・データ・ファイアホース）やLambdaを経由してS3へ継続的に転送する構成を組むことで、CloudWatch Logsへの長期保存を最小化しながら、S3にログを蓄積できます。継続的なアーカイブ運用を自動化したい場合に向いた方法です。

削減策3：取り込み量（ingestion）を抑制する

取り込み費用はログの出力量に直接連動するため、アプリケーション側でのログ出力制御が費用削減に直結します。本番環境でDEBUGレベルのログを出力している場合、INFOやWARNに切り替えるだけで取り込み量を削減できます。

また、CloudWatch Logsへ送るログパターンを絞り込むためにメトリクスフィルター（Metrics Filter）やサブスクリプションフィルターを活用する方法もあります。全量のログをCloudWatch Logsに送りつつ、重要なパターンだけをメトリクス化・転送する設計にすることで、分析コストと保存コストの両方を抑えられます。

削減策4：不要なメトリクスとアラームを整理する

CloudWatch Logsで作成したメトリクスフィルターに基づくカスタムメトリクス（Custom Metrics）やアラームも費用に影響します。使われなくなったアラームやメトリクスが残り続けているケースでは、棚卸しによって整理できます。AWS Cost Explorerでメトリクス・アラームに関連する費用を確認し、不要なものを削除または統合することが大切です。

削減を進める流れ：現状把握→保管方針設計→設定・実装→継続モニタリング

CloudWatch Logsのコスト削減を体系的に進めるには、現状の費用構造を把握してから設定変更に取り組む順序が重要です。見通しのないまま設定を変更すると、業務上必要なログを誤って削除してしまうリスクがあります。

ステップ1：現状把握——費用の内訳とログの実態を確認する

AWS Cost ExplorerでCloudWatchの費用内訳を確認し、取り込み・保存・Logs Insightsのどの軸が費用の主因かを特定します。続いてAWSマネジメントコンソールのCloudWatch画面でロググループの一覧を開き、各ロググループの保管期間設定（無期限になっているもの）・ストレージ量・直近のログ取り込みアクティビティを確認します。

AWS CLIを使うと全ロググループのretention設定を一覧取得してCSVに出力できるため、数十以上のロググループがある環境では効率的に棚卸しができます。費用の上位を占めるロググループを中心に、削減の優先順位を整理します。

ステップ2：保管方針を設計する——用途別のretentionとアーカイブ先を決める

ロググループを「用途（開発/本番/監査）」と「参照頻度（リアルタイム/低頻度/長期保存）」の2軸で分類し、それぞれの保管期間とアーカイブ先を設計します。コンプライアンス要件がある場合は、法令・社内規程に照らして最低保存期間を確認してから設定値を決めます。

S3へのアーカイブを組み込む場合は、S3バケットのライフサイクルルール（Lifecycle Rule）も合わせて設計します。例えば「S3 Standardに転送後90日でGlacier Flexible Retrievalへ移行し、5年後に削除する」といったルールを設定することで、S3側の保存コストも継続的に最適化できます。

ステップ3：retention設定・エクスポート構成を実装する

設計に基づいてロググループごとのretentionを変更します。多数のロググループに対して一括設定する場合は、AWS CLIコマンドをスクリプト化するか、AWS CloudFormationやTerraform（テラフォーム）を使ってIaCで管理することが設定ミスの防止につながります。

継続的なS3転送を構成する場合は、サブスクリプションフィルターとKinesis Data Firehoseの組み合わせを設定します。転送先S3バケットには適切なバケットポリシーが必要です。設定後はCloudWatch LogsのメトリクスとS3の受信量を確認し、想定どおりに転送されているかを検証します。

ステップ4：継続モニタリングで費用増加を早期検知する

retention設定とアーカイブ構成を一度行った後も、アプリケーションの追加・変更に伴って新しいロググループが作成されることがあります。新規ロググループが無期限のまま放置されないよう、定期的にロググループの棚卸しを行う運用ルールを設けることが大切です。

AWS Cost ExplorerやCloudWatchのアラームを使って、CloudWatch Logs費用が一定水準を超えた際に通知を受け取る設定をしておくと、費用急増を早期に検知できます。月次のコスト確認をチームの運用フローに組み込むことで、継続的な費用管理が可能になります。

外注の使いどころ：コスト診断・ログ基盤設計・アーカイブ実装の委託判断軸

CloudWatch Logsのコスト削減を内製で進めることは技術的には可能ですが、ロググループ数が多い環境や、S3アーカイブ・Kinesis Data Firehoseを組み合わせた構成の設計・実装には専門的な知識と工数が必要です。外注を検討する際の判断軸と委託先の選び方を整理します。

外注が有効な3つの場面

1つ目はコスト診断フェーズです。どのロググループが費用の主因か、取り込み・保存・Logs Insightsのどの軸が課題かを特定できていない場合、AWS Cost ExplorerとCloudWatchの使用状況を横断して診断できる外部の専門家に委ねることが有効です。

2つ目はログ基盤設計フェーズです。用途別のretention設計・S3転送構成の設計・Logs Insightsの利用ポリシー設計には、業務要件・コンプライアンス要件とAWSの課金構造の両方を理解した設計が必要です。設計ミスは「コンプライアンス上必要なログを削除してしまった」「転送構成が二重課金になっていた」といったリスクに直結するため、経験のあるパートナーに委ねることでリスクを抑えられます。

3つ目は継続運用・モニタリングフェーズです。社内にCloudWatchコスト管理の担当リソースがない場合、月次の棚卸し・費用確認・ルール更新を外注することで、新規ロググループの管理漏れや費用急増の見落としを防げます。

内製対応に必要なスキルと工数の目安

内製でCloudWatch Logsの最適化に取り組む場合、必要な知識の範囲は広くなります。CloudWatch Logsの課金構造とretentionの仕組み、AWS CLIを使ったロググループ棚卸しとretention一括設定、サブスクリプションフィルターとKinesis Data Firehoseの構成、S3バケットポリシーとライフサイクルルールの設計、IaC（CloudFormation/Terraform）を用いた設定管理、といった知識が求められます。

ロググループ数が数十以上ある環境を体系的に最適化する場合、担当者1〜2名が数週間程度を集中させる工数が目安になります（実際の工数はロググループ数・アーカイブ構成の複雑さ・業務要件によって異なります）。設計の誤りによりコンプライアンス上必要なログが失われた場合の対処コストも考慮すると、外注の費用対効果が見合うケースは多くなります。

委託先の選び方：AWS実績・設計力・コンプライアンス理解で判断する

CloudWatch Logsのコスト最適化を外注する際の選定ポイントを整理します。まず、CloudWatch Logsのretention設計・S3転送構成・Logs Insightsの利用ポリシー設計といった具体的な実績があるかを確認します。提案段階でロググループの用途別分類方針や設計思想を説明できるかが見極めのポイントです。

次に、コンプライアンス要件（ログの最低保存期間・保存先の要件）を業務・法令の観点から確認できる体制があるかどうかです。技術的な設定変更だけでなく、業務要件・監査要件を踏まえた設計ができるかを見極めることが大切です。

長期的な関係を前提にする場合は、設定方針・運用手順のドキュメント化や、社内担当者へのナレッジ移転の意向があるかどうかも確認します。最終的に内製化できる道筋を示せるパートナーが、長期的な費用対効果につながります。

表中の費用レンジは市場参考値であり、一次資料に基づく数値ではありません。実際の費用は複数社への見積もりで確認することをお勧めします。費用対効果の評価には、AWS Cost ExplorerでCloudWatch費用の削減前後を比較することが基本になります。

まとめ：CloudWatch Logsコスト削減を進める3つの判断軸

本稿では、CloudWatch Logsの課金が膨らむ原因から始まり、取り込み・保存・Logs Insightsという3つの課金軸の仕組み、retention設定・S3アーカイブ・取り込み量削減・メトリクス整理という具体的な削減策、現状把握から継続モニタリングまでの実施フロー、そして外注の使いどころと委託先の選び方を整理しました。要点を3つに集約します。

第一に、CloudWatch Logsのコスト削減の起点はretention設定の見直しです。デフォルトの無期限保管を用途別に有限に変更することが、保存コスト抑制の最初の一手になります。コンプライアンス要件がある場合は、設定変更の前に保存義務の範囲を確認することが不可欠です。

第二に、古いログのS3/Glacierへのアーカイブと取り込み量の抑制は、削減効果を持続させるための施策です。サブスクリプションフィルターを使った自動転送構成と、アプリケーション側のログレベル最適化を組み合わせることで、継続的なコスト管理が可能になります。

第三に、外注の有効性はロググループ数・担当リソースの有無・コンプライアンス要件の複雑さによって変わります。外注先はCloudWatch Logs設計実績・コンプライアンス要件への対応力・ナレッジ移転の姿勢を軸に選ぶことが長期的な費用対効果につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Amazon CloudWatch 料金」 — https://aws.amazon.com/jp/cloudwatch/pricing/（2024年）
2. *2　出典：Amazon Web Services「Amazon S3 料金」 — https://aws.amazon.com/jp/s3/pricing/（2024年）
3. *3　出典：Amazon Web Services「Amazon CloudWatch Logs ユーザーガイド：ロググループの保存期間の変更」 — https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html（2024年）

Tweet