CloudWatch Logs のコスト削減 — 保存ではなく取り込みが本体です

インフラ AWS コスト
読了 6分

CloudWatch の料金が大きくなったとき、犯人はほぼ常に Logs で、Logs の中でも取り込み(ingestion)です。結論を先に書くと、取り込み料金が GB あたり約 $0.50 で保存料金(GB 月あたり約 $0.03)の 17 倍なので、削減は古いログの削除ではなく、入ってくる量を減らすことから生まれます。 保持期間をどれだけ縮めても、すでに取り込んだ GB の $0.50 は戻ってきません。ログレベルの調整、Infrequent Access クラス、送り先の変更が実際にお金になる順序です。料金が急に増えた場合の全体点検はよくある原因 10 個で扱いました。料金は us-east-1 基準です。

一目でわかる料金構造 #

項目単価備考
取り込み(Standard)約 $0.50/GB月 5GB 無料、ボリューム段階別引き下げ(10TB 超から $0.25 以下)
取り込み(Infrequent Access)約 $0.25/GBStandard の半額、リアルタイム機能に制約
保存約 $0.03/GB 月圧縮後のサイズ基準
Logs Insights クエリ約 $0.005/スキャン GBスキャン範囲に比例
S3 エクスポート・サブスクリプション配信別途の配信料金大量保管は S3 側が安い

取り込みが本体である理由 #

1 日 10GB を取り込むサービスで計算すると構造がすぐ見えます。月間の取り込み 300GB で約 $150、保存は 3 か月分を積んでも月 $27 程度です。保持期間を 1 年から 1 か月に縮めても保存料金は数ドル単位でしか減りませんが、ログレベルを調整して取り込み量を 30% 減らせば毎月 $45 が消えます。削減の対象は蓄積分ではなく流入量です。

それでも保持期間の設定はそれとして必要です。ロググループのデフォルト保持は無期限なので、放置されたロググループは保存料金が静かに右肩上がりになります。アカウント全体のロググループに保持期間(本番 30〜90 日、監査ログは要件どおり)を一括設定するのは、常時点検リストに入れておく基本です。長期保管の要件があるなら CloudWatch に積まず、S3 にエクスポートしてアーカイブクラスに下げるほうが桁違いに安くなります。

取り込み量の大きい組織にはボリューム段階別の引き下げが適用されます。Standard 基準で月 10TB までは $0.50、次の 20TB は $0.25、その先の段階は $0.10、$0.05 まで下がります。月数十 TB を入れる規模なら実効単価が半分以下に落ちるため、単価交渉なしでも請求書の傾きは緩やかになります。

Infrequent Access とインテリジェントティアリング #

ログクラスを Infrequent Access(IA)にすると取り込み単価が半額($0.25/GB)になります。対価はリアルタイム機能です。IA のロググループは Live Tail、メトリクスフィルター、サブスクリプションフィルター、アラーム連携といったリアルタイム処理が使えず、Logs Insights での照会はできます。つまりアラームの根拠になるログは Standard、問題が起きたときに検索する用途のログは IA という分け方が基準です。デバッグログ、アクセスログ、バッチ処理のログが IA の典型的な対象です。

2026 年 7 月にはインテリジェントティアリングが追加され、アクセスパターンに応じて Standard、Infrequent Access、Archive Instant Access の 3 階層に自動分類されます。ロググループごとにクラスを手動で決めるのが難しい規模なら、この機能が分類作業そのものを代わりにやってくれます。新しい機能なので、要件(対象ロググループ、階層の条件)は適用前にドキュメントで確認します。

Lambda には選択肢がもう 1 つあります。2025 年から Lambda のログに段階別引き下げ料金が適用され、ログの送り先を CloudWatch 以外に S3 や Data Firehose へ直接指定できます。呼び出しの多い関数のログを分析パイプライン(S3 + Athena など)に直送すれば、CloudWatch の取り込み料金を通りません。CloudWatch でログを見る理由がない関数から移すのが手順です。

取り込み量自体を減らす基本 #

  • ログレベル: 本番で DEBUG を常時オンにしておくのが最大の無駄パターンです。平常時は INFO、調査時だけレベルを下げる運用に変えるだけで、数十 % 減ることが多いです。
  • 構造化と重複除去: JSON の構造化ログで 1 イベントを 1 行に収め、スタックトレースの重複出力やリクエスト本文全体のログのような大容量パターンを取り除きます。
  • サンプリング: 全リクエストのログが要らないトラフィックの多いエンドポイント(ヘルスチェック、静的アセット)は除外またはサンプリングします。ALB や VPC Flow Logs のようなインフラのログも、必要なフィールドと対象だけ残す設定ができます。
  • Insights クエリの習慣: クエリ料金はスキャン GB に比例するため、時間範囲を絞りロググループを特定する習慣が照会コストを抑えます。

削減の手順 #

  1. どのロググループがどれだけ入れているかを先に見ます: Cost Explorer とロググループ別の IncomingBytes メトリクスで取り込み量の上位を探します。上位の数個が大部分を占める分布が普通です。
  2. 保持期間を一括設定します: 無期限保持をなくします。保存料金は大きくありませんが、放置すると増え続けます。長期保管は S3 にエクスポートします。
  3. 取り込み上位のレベル・重複・サンプリングを整理します: 流入を減らすことが、単価構造の上で最も大きい削減です。
  4. リアルタイム機能の要らないログを IA に下げます: アラームやメトリクスフィルターへの依存を確認してから、検索用のログを半額の単価に移します。規模が大きければインテリジェントティアリングで自動化します。
  5. Lambda の大量ログは送り先を変えます: CloudWatch を経由する理由がない関数のログは S3・Firehose 直送で、取り込み料金自体を回避します。

まとめ #

  • CloudWatch Logs の本体は取り込み料金(GB あたり約 $0.50)です。保存(GB 月約 $0.03)の 17 倍なので、削減は流入量の圧縮から生まれます。
  • 保持期間のデフォルトが無期限である点は別の落とし穴です。全ロググループに保持期間を設定し、長期保管は S3 に下げます。
  • IA クラスは取り込み単価が半額です。アラームの根拠になるログは Standard、検索用は IA に分け、規模が大きければ 2026 年導入のインテリジェントティアリングで自動分類します。
  • Lambda のログは S3・Firehose 直送ができるようになり、CloudWatch の取り込み料金を回避できます。呼び出しの多い関数から検討します。
  • DEBUG の常時出力、スタックトレースの重複、ヘルスチェックの全量ログが 3 大無駄パターンです。取り込み量上位のロググループから取り除きます。
X