CloudWatch Logs の料金が想定外に高くなる理由 - 取り込み・保存・分析のコスト構造
CloudWatch Logs の取り込み料金が保存料金の 20 倍以上である料金構造、VPC フローログや Lambda ログが引き起こすコスト爆発、Infrequent Access クラスや S3 エクスポートによる最適化戦略を解説します。
取り込み料金が支配的なコスト構造
CloudWatch Logs の料金は 3 つの要素で構成されます。以下に挙げる単価はいずれも 2026 年 8 月時点・東京リージョン (ap-northeast-1) のものです。取り込み (Ingestion) 料金は、ログデータを CloudWatch Logs に送信する際に課金されます。1GB あたり 0.76 USD です。保存 (Storage) 料金は、保存されたログデータに対して月額で課金されます。1GB あたり月額 0.033 USD です。分析 (Logs Insights) 料金は、クエリでスキャンしたデータ量に対して課金されます。1GB あたり 0.0076 USD です。注目すべきは、取り込み料金が保存料金の約 23 倍であることです。1GB のログを取り込むと 0.76 USD かかりますが、そのログを 1 ヶ月保存するコストは 0.033 USD です。つまり、CloudWatch Logs のコストの大部分は取り込み料金です。ログの保存期間を短くしてもコスト削減効果は限定的で、取り込むログの量を減らすことが最も効果的なコスト削減策です。
コスト爆発を引き起こす 3 つのパターン
CloudWatch Logs のコストが想定外に高くなるパターンは 3 つあります。本節で挙げるログ量や倍率は本記事の目安で、公式に示された数値ではありません。単価は 2026 年 8 月時点・ap-northeast-1 です。第 1 に、VPC フローログです。VPC フローログを CloudWatch Logs に送信すると、ネットワークトラフィックの量に比例してログが生成されます。トラフィックの多い VPC では、1 日に数十 GB のフローログが生成されることがあります。月間 1TB のフローログを取り込むと、取り込み料金だけで 760 USD です。VPC フローログは CloudWatch Logs ではなく S3 へ直接送信する方が安く済みます。ただし料金がゼロになるわけではありません。VPC フローログのように AWS のサービスが出力するログ (vended logs) は、S3 へ配信する場合も配信料金が課金され、これに S3 のストレージ料金が加わります。CloudWatch Logs へ送る場合より配信の単価が低いので総額は下がる、という関係です。削減幅は配信先とリージョンで変わるため、実際の見積もりは CloudWatch と S3 の公式料金表で確認してください。第 2 に、Lambda 関数のログです。Lambda は実行ごとに START、END、REPORT のログを自動的に CloudWatch Logs に送信します。1 日に 100 万回実行される関数があると、これだけで相当量のログが生成されます。関数内で console.log を多用していると、さらにログ量が増加します。第 3 に、デバッグログの消し忘れです。開発中に DEBUG レベルのログを有効にしたまま本番環境にデプロイすると、ログ量が通常の 10〜100 倍になることがあります。
Infrequent Access クラス - 取り込み料金を半額にする
2023 年に導入された CloudWatch Logs の Infrequent Access (IA) クラスは (以下の単価は 2026 年 8 月時点・ap-northeast-1)、取り込み料金を約 50% 削減できるストレージクラスです。IA クラスの取り込み料金は 1GB あたり 0.38 USD (Standard の半額) で、保存料金は同じ 0.033 USD/GB です。IA クラスの制約は、使える機能が Standard と異なる点です。Logs Insights のクエリはほぼすべてのコマンドが利用できる一方、Live Tail によるライブ表示、GetLogEvents や FilterLogEvents でのログイベントの直接取得、メトリクスフィルター、サブスクリプションフィルターは利用できません。IA クラスのログを読むときは Logs Insights が主な手段になります。したがって、リアルタイム監視やメトリクス抽出、他サービスへの転送が必要なログは Standard クラス、蓄積が主目的で参照は Logs Insights で足りるログは IA クラス、という使い分けになります。ロググループの作成時にクラスを指定します。既存のロググループのクラスは変更できないため、IA クラスに移行するには新しいロググループを作成し、ログの送信先を変更する必要があります。Lambda のログは既定で /aws/lambda/関数名 というロググループに送信されますが、Lambda 側の設定で送信先ロググループを変更できるため、あらかじめ IA クラスで作成したロググループを指定できます。この場合も既存ロググループのクラスを変えるわけではなく、新規作成と送信先の切り替えが前提です。なお IA クラスは Lambda Insights のログ取り込みに対応していないため、Lambda Insights を使っている関数では Standard クラスを維持する必要があります。
S3 エクスポートと Firehose - 長期保存の最適解
ログの長期保存には、CloudWatch Logs よりも S3 の方が圧倒的に安価です。本節で挙げる単価はいずれも 2026 年 8 月時点・ap-northeast-1 のものです。CloudWatch Logs の保存料金は 0.033 USD/GB ですが、S3 Standard は 0.025 USD/GB、S3 Glacier Instant Retrieval は 0.005 USD/GB です。CloudWatch Logs から S3 にログをエクスポートする方法は 2 つあります。CreateExportTask API は、指定した期間のログを S3 にバッチエクスポートします。ただし、1 つのアカウントで同時に実行できるエクスポートタスクは RUNNING または PENDING のもの 1 つだけで、大量のロググループがある環境では時間がかかります。Amazon Data Firehose (2024 年 2 月に Kinesis Data Firehose から改名) を使用したサブスクリプションフィルターは、ログをリアルタイムで S3 に配信します。Firehose のデータ処理料金 (0.036 USD/GB) がかかりますが、CloudWatch Logs の取り込み料金 (0.76 USD/GB) と比較すれば安価です。最も効率的なアーキテクチャは、ログを CloudWatch Logs と S3 の両方に送信することです。CloudWatch Logs には短期間 (7〜30 日) だけ保存してリアルタイムの監視とアラームに使用し、S3 には長期間保存して Athena で分析します。
ログ量を減らす実践テクニック
コスト削減の最も効果的な方法は、取り込むログの量自体を減らすことです。第 1 に、ログレベルの適切な設定です。本番環境では INFO または WARN レベルに設定し、DEBUG レベルのログを出力しないようにします。環境変数でログレベルを制御すれば、デバッグが必要な場合だけ DEBUG に切り替えられます。第 2 に、サンプリングです。すべてのリクエストのログを記録する必要がない場合、一定割合のリクエストだけをログに記録します。たとえば、10% のリクエストだけをログに記録すれば、ログ量は 10 分の 1 になります。第 3 に、構造化ログの活用です。JSON 形式の構造化ログを使用し、必要なフィールドだけを含めることで、1 行あたりのデータ量を削減できます。スタックトレースの全文をログに含めるのではなく、エラーメッセージと最初の数行だけを記録する方法も有効です。第 4 に、メトリクスフィルターの活用です。ログからメトリクスを抽出し、CloudWatch メトリクスとして保存すれば、ログ自体の保存期間を短くできます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。