本記事では、AWS CloudWatch Logs を Terraform で管理する実践的な方法について解説します。
Log Group の作成、ログ保持期間（Retention）の設定、Metric Filter の定義までを一通りカバーし、運用でそのまま使える構成を紹介します。
CloudWatch Logs をコンソール操作に頼らず、IaC（Infrastructure as Code）として安全・再現可能に管理したい方向けの記事です。
🎯 対象読者
- CloudWatch Logs を手動で設定している方
- ログ保持期間や課金が気になり始めた方
- Terraform で監視・運用系リソースも管理したいエンジニア
🧩 なぜ Terraform で CloudWatch Logs を管理するのか
CloudWatch Logs をコンソールで管理していると、以下の課題が発生しがちです。
- Log Group が自動生成され、設定が統一されない
- Retention 未設定でログが無期限保存される
- Metric Filter の設定内容がブラックボックス化する
Terraform を使うことで、
- ✅ ログ設定をコードで明示
- ✅ 保持期間を強制しコストを最適化
- ✅ 監視ルールのレビュー・再利用が可能
になります。
🛠 今回構築する構成
- CloudWatch Log Group
- Retention（ログ保持期間）
- Metric Filter（ログ → メトリクス変換）
ディレクトリ構成例
cloudwatch/
├─ main.tf
├─ variables.tf
├─ outputs.tf
📁 CloudWatch Log Group を Terraform で作成
resource "aws_cloudwatch_log_group" "app" {
name = "/aws/app/example"
retention_in_days = 14
tags = {
Environment = "dev"
Service = "example-app"
}
}
📌 ポイント
-
retention_in_daysを必ず指定 - 未指定だとログは無期限保存（＝コスト増）
⏳ Retention 設計の考え方
よく使われる目安：
| 用途 | Retention |
|---|---|
| 開発環境 | 7〜14 日 |
| 検証環境 | 14〜30 日 |
| 本番環境 | 30〜90 日 |
👉 要件・監査ポリシーに応じて調整しましょう。
📊 Metric Filter を設定する
例：ERROR ログをメトリクス化
resource "aws_cloudwatch_log_metric_filter" "error_count" {
name = "error-count"
log_group_name = aws_cloudwatch_log_group.app.name
pattern = "ERROR"
metric_transformation {
name = "ErrorCount"
namespace = "ExampleApp"
value = "1"
}
}
この設定により：
- ログ内の
ERRORを検知 - CloudWatch メトリクスとしてカウント
- Alarm と連携可能
🔔 （補足）Alarm との連携イメージ
Metric Filter は、以下と組み合わせることで真価を発揮します。
- CloudWatch Alarm
- SNS 通知
- Ops / 障害検知フロー
※ Alarm 設定は別記事で解説するとよいでしょう。
🚨 実務での注意点
1️⃣ 自動生成 Log Group との競合
- Lambda / ECS などは Log Group を自動作成する
- 事前に Terraform で作成するのがおすすめ
2️⃣ 名前規則を統一する
/aws/{service}/{application}
命名ルールを決めることで運用が楽になります。
📦 運用を楽にする工夫
- Retention を変数化して環境別制御
- Metric Filter を module 化
- CI で
terraform planをレビュー
✅ まとめ
Terraform を使って CloudWatch Logs を管理すると、
- 📄 ログ設定の可視化
- 💰 不要なログ保存コスト削減
- 🔁 再現性の高い監視構成
が実現できます。
ログ・監視系こそ IaC 化の効果が高い領域です。
ぜひ Terraform 管理に取り入れてみてください。