CloudWatch Logs 集中集約完全ガイド

🏢 全国チェーン店の報告書システムで理解する！

CloudWatch Logs の集中集約 = 全国の店舗から本社への報告システム

全国に100店舗あるレストランチェーン。各店舗で毎日発生する売上、在庫、トラブル情報...
これらを 本社で一元管理 したい！でも、全部は要らない。
重要な情報だけフィルタリング して、効率よく集めたい。

それが Subscription Filter & Destination の仕組みです✨

📝 各店舗の日報 = CloudWatch Logs
🔍 重要情報のみ選別 = Subscription Filter
📮 配送システム = Destination
🏛️ 本社の集約データベース = 中央ログアカウント

🎯 3つの重要コンポーネント

📝

CloudWatch Logs

各店舗の日報

各AWSアカウント/リージョンで発生するログ。アプリケーションログ、システムログ、セキュリティログなど、すべての活動記録。

🔍

Subscription Filter

重要情報の選別係

ログの中から特定のパターンにマッチするものだけを抽出。「ERROR」や「CRITICAL」など、重要なログのみを次へ送る。

📮

Destination

配送先の指定

フィルタされたログの送信先。Kinesis Data Streams、Lambda、別アカウントのCloudWatch Logsなどを指定可能。

🍽️ レストランチェーンの報告フロー

各店舗で日報を作成

東京店、大阪店、福岡店...それぞれの店舗で毎日の売上、在庫、顧客クレーム、設備トラブルなどを記録。

→ これが各AWSアカウントのCloudWatch Logs

🏪

重要な報告だけを選別

全ての情報を本社に送ると膨大すぎる！「売上が前日比20%以上減少」「設備故障」「食中毒リスク」など、重要な報告だけを抽出。

→ これがSubscription Filterのパターンマッチング

🔍

本社への配送システム

選別された重要報告を、専用の配送ルートで本社へ送信。各店舗から効率的にデータを集約。

→ これがDestination（Kinesis/Lambda経由）

📮

本社で一元管理

全国の店舗から集まった重要報告を本社のデータベースで一元管理。全体の傾向分析、異常検知、レポート作成が可能に。

→ これが中央ログアカウントでの集約・分析

🏛️

🏗️ アーキテクチャの全体像

🏪

各店舗（ソース）

アカウントA
CloudWatch Logs
/aws/lambda/app

→

🔍

フィルター

Subscription Filter
Pattern: [ERROR]
重要ログのみ抽出

⬇️

📮

配送システム

Destination
Kinesis Data Streams
または Lambda

→

🏛️

本社（集約先）

中央ログアカウント
CloudWatch Logs
全社統合分析

💡 ポイント：
• 複数のソースアカウントから1つの集約先へ送信可能
• 各ソースで異なるフィルターパターンを設定可能
• クロスアカウント/クロスリージョンに対応
• リアルタイムでログが転送される

⚙️ セットアップ手順（クロスアカウント）

集約先（本社）でDestinationを作成

🏛️ 中央ログアカウントで実施：

Kinesisストリームを作成し、CloudWatch Logs Destinationを設定。
他のアカウントからログを受け取る「受け皿」を準備。

# Kinesis Data Streamを作成 aws kinesis create-stream \ --stream-name central-log-stream \ --shard-count 2 # Destinationを作成 aws logs put-destination \ --destination-name CentralLogDestination \ --target-arn arn:aws:kinesis:region:account:stream/central-log-stream \ --role-arn arn:aws:iam::account:role/CloudWatchToKinesisRole

📝 やっていること：
• 全国の店舗からの報告を受け取る「本社の窓口」を開設
• 配送トラックが荷物を届けられる「集約センター」を建設

Destinationにアクセスポリシー設定

🔐 どのアカウントからの送信を許可するか定義：

Destinationに対して、ソースアカウントからのログ送信を許可するポリシーを設定。

# Destination Policyを設定 aws logs put-destination-policy \ --destination-name CentralLogDestination \ --access-policy '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": ["111111111111", "222222222222"] }, "Action": "logs:PutSubscriptionFilter", "Resource": "arn:aws:logs:region:account:destination:CentralLogDestination" }] }'

📝 やっていること：
• 「東京店」「大阪店」など、認証された店舗だけが報告を送信できるよう制限
• セキュリティゲートで身分証明を確認してから荷物を受け取る

各ソース（店舗）でSubscription Filterを作成

🏪 各店舗アカウントで実施：

ログストリームにSubscription Filterを設定し、重要なログだけを本社へ送信。

# Subscription Filterを作成 aws logs put-subscription-filter \ --log-group-name /aws/lambda/my-app \ --filter-name SendErrorsToCentral \ --filter-pattern "[ERROR]" \ --destination-arn arn:aws:logs:region:central-account:destination:CentralLogDestination

🔍 Filter Patternの例：
•


        [ERROR]

→ ERRORを含むログ
•


        [WARN]

→ 警告ログ
•


        [level=ERROR]

→ JSONの特定フィールド
•


        [..., status_code=5*]

→ 500番台エラー

📝 やっていること：
• 各店舗で「重大な問題」「緊急報告」だけを選別
• 日常業務の記録は店舗で保管、重要事項だけ本社へ送信

集約先でログを受信・保存

📊 中央アカウントで実施：

Kinesisから受け取ったログを、Lambda or Kinesis Firehose経由でCloudWatch LogsやS3に保存。

オプション1: Lambda → CloudWatch Logs

# Lambdaでログを受け取り、CloudWatch Logsへ def lambda_handler(event, context): for record in event['Records']: # Kinesisからデコード payload = base64.b64decode(record['kinesis']['data']) log_data = json.loads(payload) # CloudWatch Logsへ書き込み logs_client.put_log_events( logGroupName='/central/aggregated-logs', logStreamName=log_data['source_account'], logEvents=[{ 'timestamp': log_data['timestamp'], 'message': log_data['message'] }] )

オプション2: Kinesis Firehose → S3
長期保存やコスト削減にはS3へ直接保存も可能。

📝 やっていること：
• 本社で受け取った報告を、部門別・日付別にファイリング
• すぐに参照できる形で整理し、長期保存用にもアーカイブ

🔄 2つの集約パターン

🏢

同一アカウント内集約

📝 シナリオ： 1つのAWSアカウント内で、複数のリージョンやログストリームを1か所に集約したい。

🎯 ユースケース： • 東京リージョンと大阪リージョンのログを統合
• 複数のLambda関数のログを1つのログストリームに
• 開発環境と本番環境のログを分けて管理

✨ メリット： • セットアップが簡単（IAMポリシー設定が不要）
• クロスアカウントアクセスの管理不要
• コストが低い

⚙️ 設定： Destinationポリシー不要。
直接Subscription Filterを作成するだけ。

🌐

クロスアカウント集約

📝 シナリオ： 複数のAWSアカウントからログを1つの中央アカウントに集約したい。

🎯 ユースケース： • 開発・ステージング・本番アカウントを統合
• 部門ごとのアカウントからセキュリティチームへ
• 子会社の複数アカウントを親会社で一元管理

✨ メリット： • 組織全体のログを一元管理
• セキュリティ監視の集中化
• コンプライアンス対応が容易
• アカウント間の分析・比較が可能

⚙️ 設定： Destinationポリシーで
アクセス許可の設定が必要。
各ソースアカウントで個別設定。

💼 実際のユースケース

🔒

セキュリティ監視の集中化

課題：
全アカウントのセキュリティイベント（不正アクセス試行、権限変更など）をセキュリティチームが監視したい。

解決策：
• 各アカウントからCloudTrailログを抽出
• Filter:


         [userIdentity, eventName=DeleteUser]

• セキュリティアカウントに集約
• リアルタイムアラート設定

効果：
セキュリティインシデントを即座に検知し、全社的な対応が可能に。

🐛

マルチアカウントのエラー追跡

課題：
開発・ステージング・本番の3環境でアプリケーションエラーを統合的に追跡したい。

解決策：
• 各環境のアプリケーションログを収集
• Filter:


         [ERROR] [CRITICAL] [level=error]

• 運用アカウントに集約
• 環境ごとにタグ付けして分類

効果：
全環境のエラーを1つのダッシュボードで監視。環境間の問題の関連性も把握可能。

📊

コンプライアンス監査

課題：
全アカウントのログを7年間保存し、監査に対応できる体制を構築したい。

解決策：
• 全アカウントのログを中央アカウントに集約
• Kinesis Firehose → S3 Glacierへアーカイブ
• ライフサイクルポリシーで自動移行
• Athenaで過去ログを検索可能に

効果：
低コストで長期保存を実現。監査時に必要なログをすぐに取り出せる。

⚡

リアルタイムアラート統合

課題：
複数のアカウントで発生する重大エラーを、1つのSlackチャンネルに通知したい。

解決策：
• 各アカウントから重大ログを抽出
• 中央アカウントのLambdaで受信
• Lambda → SNS → Slack統合
• アカウント情報を含めて通知

効果：
どのアカウントで問題が起きても、1つのチャンネルで把握。対応漏れを防止。

✨ 集中集約の6大メリット

🎯

一元管理

全アカウント・全リージョンのログを1か所で管理。ログインし直す必要なし。

💰

コスト削減

重要なログのみを転送することで、ストレージコストとネットワークコストを最適化。

🔍

横断検索

複数のソースから集約されたログを、1回の検索で調査可能。

🚨

統合アラート

全社的な異常を1つのダッシュボードで監視。アラート設定も一元化。

🔒

セキュリティ強化

セキュリティログを専用アカウントで保護。改ざん防止と監査証跡の確保。

📈

トレンド分析

組織全体のログから傾向を分析。問題の予兆を早期発見。

💡 実装のベストプラクティス

1. フィルターパターンは慎重に設計：
• 広すぎるパターンは転送量が膨大に（コスト増）
• 狭すぎると重要なログを見逃す
• まずは ERROR と CRITICAL から始めて、徐々に調整

2. Kinesisのシャード数を適切に設定：
• 1シャードあたり 1MB/秒、1000レコード/秒
• ログの発生量に応じてスケールアップ
• Auto Scalingの活用を検討

3. ログの保持期間を設定：
• ソース側: 短期保持（1-7日）でコスト削減
• 集約先: 長期保持（30-365日以上）
• S3へのアーカイブも併用

4. メトリクスフィルターで監視：
• 集約先でメトリクスフィルターを設定
• エラー率、警告数などを可視化
• CloudWatch Alarmsで自動通知

5. タグとメタデータを活用：
• ログに送信元アカウント情報を追加
• 環境名（dev/stg/prod）をタグ付け
• 後からの検索・分析が容易に

6. 段階的にロールアウト：
• まず1つのテストアカウントで検証
• 問題なければ徐々に他のアカウントへ展開
• 各フェーズでコストと転送量を監視

7. バックアップと冗長性：
• 集約先は複数リージョンでバックアップ
• ソース側でも一定期間ログを保持
• Kinesis Firehose の障害対策を検討

🎓 まとめ

🏢 全国チェーン店の報告システム

CloudWatch Logs Subscription Filter & Destination は
全店舗から本社への効率的な報告システム と同じ！

重要な情報だけをフィルタリングして、
中央で一元管理することで、
組織全体の可視性とセキュリティが向上します✨

📝

Logs

各アカウントで
発生するログ

🔍

Filter

重要なログだけ
を抽出

📮

Destination

効率的な
配送システム

🏛️

Central

本社での
一元管理

🎯 すぐに始められる3ステップ：

1️⃣ 集約先アカウントで Destination を作成
2️⃣ 送信元アカウントで Subscription Filter を設定
3️⃣ 集約されたログを CloudWatch Insights で分析開始！

マルチアカウント環境でのログ管理は
最初の設計が重要 です。
フィルターパターンとアーキテクチャを慎重に設計して、
効率的で安全なログ基盤を構築しましょう！🎉

目次

📊 CloudWatch Logs 集中集約