はじめに
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%削減できました。
「うちも似たような設定になっているかも」と思った方は、
ぜひ参考にしてみてください！