CloudWatch Logs の料金が想定外に高くなる理由 - 取り込み・保存・分析のコスト構造
CloudWatch Logs の取り込み料金が保存料金の 20 倍以上である料金構造、VPC フローログや Lambda ログが引き起こすコスト爆発、Infrequent Access クラスや S3 エクスポートによる最適化戦略を解説します。
取り込み料金が支配的なコスト構造
CloudWatch Logs の料金は 3 つの要素で構成されます。取り込み (Ingestion) 料金は、ログデータを CloudWatch Logs に送信する際に課金されます。ap-northeast-1 では 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 つあります。第 1 に、VPC フローログです。VPC フローログを CloudWatch Logs に送信すると、ネットワークトラフィックの量に比例してログが生成されます。トラフィックの多い VPC では、1 日に数十 GB のフローログが生成されることがあります。月間 1TB のフローログを取り込むと、取り込み料金だけで 760 USD です。VPC フローログは S3 に直接送信する方が安価です。S3 への送信は取り込み料金が不要で、S3 のストレージ料金 (0.025 USD/GB) のみです。第 2 に、Lambda 関数のログです。Lambda は実行ごとに START、END、REPORT のログを自動的に CloudWatch Logs に送信します。1 日に 100 万回実行される関数があると、これだけで相当量のログが生成されます。関数内で console.log を多用していると、さらにログ量が増加します。第 3 に、デバッグログの消し忘れです。開発中に DEBUG レベルのログを有効にしたまま本番環境にデプロイすると、ログ量が通常の 10〜100 倍になることがあります。
Infrequent Access クラス - 取り込み料金を半額にする
2023 年に導入された CloudWatch Logs の Infrequent Access (IA) クラスは、取り込み料金を約 50% 削減できるストレージクラスです。IA クラスの取り込み料金は 1GB あたり 0.38 USD (Standard の半額) で、保存料金は同じ 0.033 USD/GB です。IA クラスの制約は、Logs Insights によるクエリができないことです。ログの検索には Live Tail またはフィルターパターンを使用する必要があります。頻繁にクエリで分析するログは Standard クラス、保存が主目的で分析頻度が低いログは IA クラス、という使い分けが推奨されます。ロググループの作成時にクラスを指定します。既存のロググループのクラスは変更できないため、IA クラスに移行するには新しいロググループを作成し、ログの送信先を変更する必要があります。Lambda のログは自動的に /aws/lambda/関数名 というロググループに送信されますが、Lambda の設定でロググループを変更できるため、IA クラスのロググループに切り替えることが可能です。
S3 エクスポートと Firehose - 長期保存の最適解
ログの長期保存には、CloudWatch Logs よりも S3 の方が圧倒的に安価です。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 つのエクスポートタスクしか実行できず、大量のロググループがある環境では時間がかかります。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 メトリクスとして保存すれば、ログ自体の保存期間を短くできます。ログ管理のコスト最適化を体系的に学ぶには、専門書籍 (Amazon)が参考になります。