CloudWatchクロスアカウントモニタリングで実現するログ一元管理の実践ガイド

## 概要
複数のAWSアカウント間でCloudWatchを使用してログを一元管理する方法を解説します。モニタリングアカウントとソースアカウントのリンク設定から、オブザーバビリティの基本概念まで、実践的な手順とベストプラクティスを紹介します。

## 目次
1. [はじめに - なぜクロスアカウントモニタリングが必要なのか](#はじめに---なぜクロスアカウントモニタリングが必要なのか)
2. [オブザーバビリティとテレメトリの基礎知識](#オブザーバビリティとテレメトリの基礎知識)
3. [CloudWatchクロスアカウント機能の概要](#cloudwatchクロスアカウント機能の概要)
4. [モニタリングアカウントとソースアカウントの設定手順](#モニタリングアカウントとソースアカウントの設定手順)
5. [ログ転送の設定と動作確認](#ログ転送の設定と動作確認)
6. [運用時の注意点とベストプラクティス](#運用時の注意点とベストプラクティス)
7. [料金とコスト最適化のポイント](#料金とコスト最適化のポイント)
8. [終わりに](#終わりに)

## はじめに - なぜクロスアカウントモニタリングが必要なのか

企業のAWS環境が拡大すると、開発環境、ステージング環境、本番環境を異なるAWSアカウントで分離することが一般的になります。これは「マルチアカウント戦略」と呼ばれ、セキュリティとガバナンスの観点から推奨されるベストプラクティスです。

しかし、複数のアカウントにまたがるシステムでは、ログやメトリクスが分散してしまい、障害発生時の原因特定や全体的なシステム監視が困難になります。これを解決するのがCloudWatchのクロスアカウントモニタリング機能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4071751/49924c12-477f-4507-bdff-1765eef56048.png)


例えば、ECサイトを運営している企業では以下のような課題が発生します：
- 開発アカウント：アプリケーションのテストログ
- 本番アカウント：実際の顧客トランザクションログ
- 共通サービスアカウント：認証サービスのログ

これらのログが別々に管理されていると、顧客からの問い合わせに対して複数のコンソールを確認する必要があり、対応時間が長くなってしまいます。

## オブザーバビリティとテレメトリの基礎知識

クロスアカウントモニタリングを理解する前に、現代のシステム運用で重要な概念である「オブザーバビリティ」と「テレメトリ」について説明します。

### オブザーバビリティとは

オブザーバビリティ（Observability）は、システムの内部状態を外部からの出力によって推測できる能力のことです。簡単に言えば「システムの中で何が起こっているかを理解できる状態」を指します。

従来の監視（Monitoring）が「予め決められた問題を検出する」ことに重点を置いているのに対し、オブザーバビリティは「未知の問題も含めて原因を特定できる」ことを目指します。

AWS公式ドキュメント ( https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/observability-best-practices.html ) によると、オブザーバビリティは以下の3つの柱で構成されます：

| 要素 | 説明 | AWSサービス例 |
|------|------|---------------|
| ログ（Logs） | システムやアプリケーションのイベント記録 | CloudWatch Logs |
| メトリクス（Metrics） | 時系列で測定可能な数値データ | CloudWatch Metrics |
| トレース（Traces） | リクエストの処理経路と処理時間 | AWS X-Ray |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4071751/81ada224-0d4e-4c83-8723-26256481c89b.png)

### テレメトリとは

テレメトリ（Telemetry）は、遠隔地から自動的にデータを収集・送信する技術や、そのデータ自体を指します。クラウド環境では、各サービスから自動的に収集される運用データのことを意味します。

AWSでは、EC2インスタンスのCPU使用率、RDSの接続数、Lambda関数の実行時間など、様々なテレメトリデータが自動的に収集されています。

## CloudWatchクロスアカウント機能の概要

CloudWatchのクロスアカウント機能を使用すると、複数のAWSアカウントのログとメトリクスを一つのアカウント（モニタリングアカウント）に集約できます。この機能は2022年に発表され、企業のマルチアカウント環境での運用を大幅に改善しました。

### 主要コンポーネント

| コンポーネント | 役割 | 設定場所 |
|----------------|------|----------|
| モニタリングアカウント | ログとメトリクスの受信・表示 | 中央管理アカウント |
| ソースアカウント | ログとメトリクスの送信元 | 各環境アカウント |
| アカウントリンク | アカウント間の接続設定 | 両アカウント |

AWS公式ドキュメント ( https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html ) によると、この機能により最大5つのリージョンから最大300のソースアカウントを1つのモニタリングアカウントにリンクできます。

## モニタリングアカウントとソースアカウントの設定手順

実際の設定手順を、AWS CLIを使用して解説します。この例では、アカウントID「111111111111」をモニタリングアカウント、「222222222222」をソースアカウントとして設定します。

### ステップ1: モニタリングアカウントでの初期設定

まず、モニタリングアカウントでCloudWatchの統合機能を有効化します：

```bash
# モニタリングアカウントでの実行
aws logs put-account-policy \
    --policy-name CrossAccountPolicy \
    --policy-type ACCOUNT_POLICY \
    --policy-document '{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::222222222222:root"
                },
                "Action": [
                    "logs:CreateLogStream",
                    "logs:PutLogEvents"
                ],
                "Resource": "*"
            }
        ]
    }'
```

### ステップ2: ソースアカウントでのリンク作成

次に、ソースアカウントからモニタリングアカウントへのリンクを作成します：

```bash
# ソースアカウントでの実行
aws oam create-link \
    --sink-identifier arn:aws:oam:us-east-1:111111111111:sink/sink-id \
    --resource-types "AWS::Logs::LogGroup" "AWS::CloudWatch::Metric" \
    --link-configuration '{
        "logGroupConfiguration": {
            "filter": "ERROR"
        }
    }'
```

### ステップ3: モニタリングアカウントでのSink作成

モニタリングアカウント側でデータを受信するSinkを作成します：

```bash
# モニタリングアカウントでの実行
aws oam create-sink \
    --name production-monitoring-sink \
    --tags Key=Environment,Value=Production
```

### ステップ4: リンクの確認

設定が正常に完了したかを確認します：

```bash
# リンク一覧の確認
aws oam list-links

# Sink一覧の確認
aws oam list-sinks
```

## ログ転送の設定と動作確認

基本的なリンクが確立された後、具体的なログ転送の設定を行います。

### CloudWatch Logsの転送設定

特定のロググループを転送対象に設定します：

```bash
# ソースアカウントでロググループにタグを追加
aws logs tag-log-group \
    --log-group-name /aws/lambda/my-function \
    --tags CrossAccountMonitoring=enabled

# 転送設定の確認
aws logs describe-log-groups \
    --log-group-name-prefix /aws/lambda/
```

### カスタムメトリクスの転送

アプリケーション固有のメトリクスも転送できます：

```bash
# カスタムメトリクスの送信例
aws cloudwatch put-metric-data \
    --namespace "MyApplication/Orders" \
    --metric-data MetricName=OrderCount,Value=10,Unit=Count
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4071751/a5a487ae-7388-44e7-ac5b-5dbcaf249fa4.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4071751/f739238f-d19e-4125-89d4-89aed3e58126.png)


### 動作確認の方法

設定が正しく動作しているかを確認する手順：

1. **ソースアカウントでテストログを生成**
```bash
aws logs put-log-events \
    --log-group-name /test/crossaccount \
    --log-stream-name test-stream \
    --log-events timestamp=$(date +%s000),message="Test cross-account log"
```

2. **モニタリングアカウントでログを検索**
```bash
aws logs filter-log-events \
    --log-group-name /test/crossaccount \
    --start-time $(date -d "1 hour ago" +%s)000
```

AWS公式ドキュメント ( https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html ) によると、ログの転送には通常1-2分の遅延が発生することが正常です。

## 運用時の注意点とベストプラクティス

### セキュリティ面での注意点

クロスアカウントでのデータ共有では、以下のセキュリティ原則を遵守してください：

- **最小権限の原則**：必要最小限のリソースのみを共有対象とする
- **定期的な権限確認**：四半期ごとにアクセス権限を見直す
- **ログの暗号化**：転送時と保存時の両方で暗号化を有効化

```bash
# ロググループの暗号化設定例
aws logs create-log-group \
    --log-group-name /secure/application \
    --kms-key-id arn:aws:kms:us-east-1:111111111111:key/12345678-1234-1234-1234-123456789012
```

### パフォーマンス最適化

大量のログを転送する場合のパフォーマンス対策：

| 対策 | 効果 | 実装方法 |
|------|------|----------|
| ログフィルタリング | 転送量削減 | フィルターパターンの設定 |
| バッチ処理 | スループット向上 | ログの一括送信 |
| 圧縮 | 帯域幅節約 | gzip圧縮の有効化 |

### 障害時の対応手順

クロスアカウントリンクに問題が発生した場合の診断手順：

```bash
# リンクの状態確認
aws oam get-link --identifier link-12345678

# エラーログの確認
aws logs describe-metric-filters \
    --log-group-name /aws/oam/errors
```

## 料金とコスト最適化のポイント

CloudWatchクロスアカウント機能の利用には、通常のCloudWatch料金に加えて以下のコストが発生します。

### 主な料金体系

AWS公式価格表 ( https://aws.amazon.com/cloudwatch/pricing/ ) によると、以下の料金が適用されます：

| 項目 | 料金 | 備考 |
|------|------|------|
| ログ取り込み | $0.50/GB | 初回取り込み時 |
| ログ保存 | $0.03/GB/月 | 標準ストレージ |
| クロスアカウント転送 | $0.01/GB | 転送時の追加料金 |

### コスト最適化の戦略

1. **ログフィルタリングの活用**
```bash
# ERRORレベルのログのみを転送
aws logs put-metric-filter \
    --log-group-name /aws/lambda/my-function \
    --filter-name ErrorsOnly \
    --filter-pattern "[timestamp, request_id, level=ERROR, ...]"
```

2. **保存期間の最適化**
```bash
# ログの保存期間を30日に設定
aws logs put-retention-policy \
    --log-group-name /aws/lambda/my-function \
    --retention-in-days 30
```

3. **不要なメトリクスの削除**
定期的に使用されていないカスタムメトリクスを確認し、削除することで月額料金を削減できます。

## 終わりに

CloudWatchのクロスアカウントモニタリング機能により、複数のAWSアカウントにまたがるシステムの可視性を大幅に向上させることができます。特に、マルチアカウント戦略を採用している企業では、運用効率の向上と障害対応時間の短縮という大きなメリットを得られます。

重要なポイントをまとめると：
- オブザーバビリティの3つの柱（ログ、メトリクス、トレース）を理解し、適切に活用する
- セキュリティと最小権限の原則を守りながらアカウント間連携を設定する
- コスト最適化を意識してログフィルタリングや保存期間を適切に設定する

次のステップとして、X-Rayトレーシングとの連携や、AWS Configを使用したコンプライアンス監視の統合を検討することをお勧めします。また、CloudWatch Insightsを活用した高度なログ分析手法の習得も、より効果的な運用につながります。

## 参考文献・参考サイト

- 「Amazon CloudWatch Cross-Account Observability」AWS Documentation, https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html
- 「Working with log groups and log streams」AWS Documentation, https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html
- 「Implementing logging and monitoring in Amazon CloudWatch」AWS Documentation, https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/observability-best-practices.html
- 「Amazon CloudWatch Pricing」AWS, https://aws.amazon.com/cloudwatch/pricing/
- 「Cross-account log data sharing with subscription filters」AWS Documentation, https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html
- Adrian Cockcroft「Observability at Scale」O'Reilly Media, 2023
- 「AWS Well-Architected Framework - Operational Excellence Pillar」AWS Documentation, https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html