はじめに

AWSを使っていると、EC2やRDSのコストは気にするのに、

CloudWatchって「監視ツールだから仕方ない」と、
なんとなくスルーしてしまいがちじゃないですか？

実際に私も、運用フェーズに入った後の案件で、コストを見直してみたところ…
「なにこれ！？CloudWatchの利用料...EC2とほぼ同額ってどういうこと！？」
と、思わず二度見してしまいました。

そこから本格的にコストを見直し、施策を打った結果、

🎉 CloudWatchの月額料金を約41%削減することができました

今日は実際にやった3つの施策を紹介したいと思います。
「うちも似たような状況かも…」と思ったら、ぜひ参考にしてみてください。

まず：CloudWatchのどこでお金が出てるか

削減する前に「どこが高いのか」を把握することが大事です。
Cost Explorerでコストの内訳を確認し、今回の案件でCloudWatchの主な課金項目はこちらです。

課金項目	東京リージョン単価	今回の案件での状況
カスタムログ収集	$0.76 / GB	全ログを垂れ流していた
Vended Logs収集（WAFログ・VPCフローログなど）	$0.76 / GB	CloudWatchに送っていた
Logs ストレージ	$0.033 / GB / 月	長期間溜まり続けていた

では、実際案件で試した3つの施策を見ていきます。

施策① AWSへ転送のログを「WARNING」以上に絞る

私たちの案件では、EC2上のAPPログはローカルにも保存されており、
logrotateによるローテーション設定も行っています。

CloudWatchへ全ログレベルを転送する必要はないと再検討した結果、
WARNING・ERROR以上のみに絞ることにしました。

具体的な対策：CloudWatch Agent の filters を使う

CloudWatch Agentの設定ファイルに filters を追加して、
WARNING・ERRORのみを転送するよう変更しました。

{
  "file_path": "/実際のAPP_LOG.logのパス",
  "log_group_name": "amazon-CloudWatch-agent.log/application-log/実際のcloudwatch Log名",
  "log_stream_name": "{instance_id}",
  "retention_in_days": 30,
  "filters": [
    {
      "type": "include",
      "expression": "\\s{3}[WE]\\s{3}"
    }
  ]
}

この正規表現の意味

\\s{3}[WE]\\s{3}
  │         │
  │    └─ W（Warning）または E（Error）の1文字
  └──────── 前後にスペース3つ

私たちのアプリのログフォーマットは以下のような形式でした。

# フォーマット：日時   ログレベル1文字   メッセージ

2024-01-01 12:00:00   I   処理情報          → ❌ 除外（Info）
2024-01-01 12:00:02   W   タイムアウト発生   → ✅ 転送（Warning）
2024-01-01 12:00:03   E   DB接続失敗        → ✅ 転送（Error）

ログレベルの前後にスペース3つというフォーマットに合わせた正規表現です。

結果

一台のEC2の削減結果：

	Before	After	削減率
1日あたりの転送量	4 GB	250 MB	▼ 約94%
1ヶ月あたりの転送量	120 GB	7.5 GB	▼ 112.5 GB
インジェストコスト / 月	$91.2	$5.7	▼ 約$85 / 月

設定ファイルに数行追加するだけで、転送量を94%削減できました。

施策② Log Groupの保存期間の見直し

AWSのLog Groupはデフォルトで保存期間が「無期限」です。
私たちの案件では当初の設計で半年〜1年に設定していましたが、
改めて見直してみると、そこまでLog Groupで長期保管が必要なログは多くありませんでした。

「障害調査に2ヶ月あれば十分」という判断で、60日に統一しました。

施策③ VPCフローログはS3へ出力

VPCフローログは全リクエストが記録されるため、
トラフィックが多いシステムでは相当な量になります。

ここで一度立ち止まって、ログの用途を考えてみました。

用途	実態
リアルタイムでアラートしたい	→ VPCフローログは向いていない
障害時に遡って確認する	→ これが主な用途

障害時に遡って見るだけなら、CloudWatchに置く必要はありません。

CloudWatch vs S3 コスト比較

	CloudWatch Logs	S3
取り込みコスト	$0.76 / GB	$0（無料）
ストレージ	$0.033 / GB / 月	$0.025 / GB / 月
検索方法	Logs Insights（課金）	Athena（スキャン量課金・安い）
向いている用途	リアルタイム監視・アラート	保管・遡り調査

出力先を変えるだけで、取り込みコストがゼロになり、
保存料金も安くなりました。

その他： Cost Anomaly Detectionで監視する

施策①〜③でコストを削減しても、
「気づかず設定が元に戻っていた」「障害でログが急増していた」
という事態は十分起こりえます。

「削減して終わり」ではなく、「削減 → 監視」のセットで初めて完成だと考えています。

そこで使うのが AWS Cost Anomaly Detection です。
AWSが機械学習でコストの異常を自動検知してくれる、しかも完全無料のサービスです。

設定手順（約5分で完了）

Step 1. AWS Cost Explorer を開く

Step 2. 左メニュー「Cost Anomaly Detection」を選択

Step 3. 「モニター作成」
        → モニタータイプ：AWSのサービス
        → サービス：Amazon CloudWatch を選択

Step 4. 「アラートサブスクリプション作成」
        → しきい値：$20以上 or 前週比20%以上（環境に合わせて設定）
        → 通知先：SNS → Slack / メール

通知イメージ

⚠️ [AWS] CloudWatchのコストに異常を検知しました
─────────────────────────────────────────
サービス    : Amazon CloudWatch
検知期間    : 2026/xx/xx 〜 xx/xx
先週のコスト: $32
今週のコスト: $46（+45%）
─────────────────────────────────────────
→ 通知を受けてすぐ原因調査できる！

まとめ

設定ファイルに数行追加するだけ、出力先を変えるだけ——
大きな変更工数なしに、月額コストを41%削減できました。

「うちも似たような設定になっているかも」と思った方は、
ぜひ参考にしてみてください！

参考リンク