Amazon CloudWatch OAM 完全ガイド 2026

マルチアカウント・オブザーバビリティの一元化と統合監視基盤

Amazon CloudWatch Observability Access Manager（OAM） は、複数の AWS アカウントのメトリクス・ログ・トレース・Application Insights を中央監視アカウントから統一的に閲覧・管理できるサービス です。マルチアカウント環境での観測可能性（Observability）を実現し、Organizations 傘下の多数のアカウントをシンク・リンク機構で一括管理することで、クロスアカウント監視基盤を構築します。本ドキュメントは、CloudWatch OAM の本質・アーキテクチャ・設定・運用・ベストプラクティスを包括的に解説するガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： マルチアカウント監視とは何か、OAM が解決する課題を理解したい方
セキュリティ・運用者向け： Sink・Link・Trust Policy の設定と運用
アーキテクト向け： Organizations との統合・Central Logging の設計
SRE 向け： クロスアカウント Observability ダッシュボード・Alarms 構築
意思決定者向け： 既存 CloudWatch・Datadog・New Relic との比較

2026 年の CloudWatch OAM エコシステム

Application Signals SLO 拡張：SLO Recommendations・Service-Level SLOs・SLO Performance Report
EKS Observability デフォルト化：CloudWatch EKS add-on の automatic enable
AI Operations 統合：機械学習による異常検知・予測的アラート
Database Insights クロスアカウント対応：RDS・Aurora・DynamoDB のパフォーマンス統合監視
Internet Monitor クロスアカウント：エッジロケーション単位でのトラフィック分析
GenAI Observability：LLM API コスト追跡・トークン使用量監視
Unified Cross-Region Query：複数リージョンのログ・メトリクス統一検索

概要

初心者向けメモ： CloudWatch OAM は「複数の AWS アカウントの監視データを 1 つの中央アカウントから見える化するサービス」です。従来は各アカウントの CloudWatch を個別に確認する必要があり、50 アカウント環境では 50 回のコンソール切り替えが必要でした。OAM でリンクを張ると、中央アカウントから全アカウントのメトリクス・ログを統一ダッシュボードで監視できます。

CloudWatch OAM は AWS が提供する マルチアカウント Observability 基盤 です。各ソースアカウントが中央監視アカウントのシンク（Sink）にリンク（Link）を張ることで、メトリクス・ログ・トレース・Application Insights・Internet Monitor を安全に共有します。Fine-grained Access Control により、「メトリクスのみ読み取り」「ログ Insights クエリは許可」など、アクセス権限を細かく制御可能です。

CloudWatch OAM の位置づけ

graph TB
    subgraph MonitoringAccount["中央監視アカウント<br/>（Monitoring Account）"]
        Sink["🔗 Sink<br/>（OAM Sink）"]
        Dashboard["CloudWatch Dashboard<br/>全アカウント統合"]
        Logs_Insights["Logs Insights<br/>クロスアカウント検索"]
        Alarms["CloudWatch Alarms<br/>統合監視"]
    end
    
    subgraph SourceAccounts["ソースアカウント"]
        Account1["Account 1<br/>Production"]
        Account2["Account 2<br/>Staging"]
        Account3["Account 3<br/>Development"]
    end
    
    Account1 -->|リンク: メトリクス・ログ| Sink
    Account2 -->|リンク: メトリクス・ログ| Sink
    Account3 -->|リンク: メトリクス・ログ| Sink
    
    Sink --> Dashboard
    Sink --> Logs_Insights
    Sink --> Alarms
    
    style Sink fill:#FF9900
    style MonitoringAccount fill:#E8F4F8

定義

AWS 公式による定義：

“Amazon CloudWatch cross-account observability helps you monitor and troubleshoot applications that span multiple AWS accounts within a Region, by viewing and interacting with observability data from multiple source accounts.”

Sink・Link・Trust Policy を通じた安全でスケーラブルなマルチアカウント監視基盤を提供します。

概要
OAM が解決する課題
主な特徴
アーキテクチャ
コアコンポーネント
セットアップ・ステップバイステップ
Organizations との統合
主要ユースケース
ダッシュボード・クエリ実例
アクセス制御・セキュリティ
クロスアカウント Logs Insights
Application Signals 統合
CloudWatch Alarms
トラブルシューティング
パフォーマンス・スケーリング
コスト管理
ベストプラクティス
既存ツールとの比較
2025-2026 最新動向
学習リソース
実装例・チェックリスト
まとめ
参考文献

OAM が解決する課題

課題1: マルチアカウント環境での監視の複雑性

従来の課題： 50 アカウント・200 リソースを監視する場合、各アカウントのコンソールを個別に切り替えて確認する必要があり、運用負荷が極めて大きい。SRE チームが全社の health を把握するのに数時間を要する。

OAM での解決： 中央監視アカウント（Monitoring Account）を設置し、全ソースアカウントのメトリクス・ログをシンク経由でリンク。中央アカウントから一画面ですべてのメトリクス・ログを統合監視可能。

課題2: クロスアカウントアクセス権限管理の複雑性

従来の課題： 従来の IAM クロスアカウントロールでは、「ロールを全体的に許可・禁止」という粗粒度の制御になりやすく、「メトリクスのみ読み取り、ログエクスポートは禁止」といった細かい制御が難しい。

OAM での解決： OAM の Resource Policy により「メトリクスのみ共有」「Application Signals のみ共有」など、データタイプごとの細かい制御が可能。ソースアカウント側で共有するデータタイプを明示的に選択できるため、セキュリティ境界が明確。

課題3: コスト最適化と監視スケーリングの両立

従来の課題： 全アカウントの CloudWatch ダッシュボードを個別に構築・運用すると、ダッシュボード作成・変更・削除の手作業が増殖。アカウント数増加に伴い、運用コストが増加。

OAM での解決： Organizations と統合すれば、新規アカウント作成時に自動的に OAM リンクが張られ、中央監視アカウントに自動追加。追加コストなしにスケーリング可能。

主な特徴

┌────────────────────────────────────────────────────────┐
│      CloudWatch OAM の主な特徴（v2026）               │
├────────────────────────────────────────────────────────┤
│                                                        │
│  ✅ マルチアカウント統合監視                            │
│     • Sink（監視アカウント）× Link（ソース）の構造     │
│     • 100,000 アカウントまでスケール可能                │
│                                                        │
│  ✅ 細粒度のアクセス制御                                │
│     • メトリクス・ログ・トレース単位でのアクセス制御    │
│     • Resource Policy による明示的な権限定義           │
│                                                        │
│  ✅ Organizations との自動統合                         │
│     • 新規アカウント自動リンク                         │
│     • OU（Organizational Unit）単位での一括設定       │
│                                                        │
│  ✅ 複数データタイプのサポート                          │
│     • CloudWatch Metrics（メトリクス）                │
│     • CloudWatch Logs（ログ）                        │
│     • AWS X-Ray（トレース）                           │
│     • Application Signals（APM）                      │
│     • Application Insights（アプリケーション監視）     │
│     • Internet Monitor（エッジ監視）                  │
│                                                        │
│  ✅ クロスアカウント Logs Insights                     │
│     • 複数アカウントのログを一度に検索                  │
│     • SQL 風クエリで複雑な分析実施                     │
│                                                        │
│  ✅ 無料で提供                                         │
│     • Sink・Link 作成・管理は追加費用なし             │
│     • CloudWatch 本体の課金のみ                        │
│                                                        │
│  ✅ セキュリティ重視                                   │
│     • 各ソース・監視アカウント間で明示的な許可必須      │
│     • CloudTrail で全操作を監査                        │
│                                                        │
└────────────────────────────────────────────────────────┘

アーキテクチャ

監視アカウント（Monitoring Account）              ソースアカウント（Source Accounts）
┌──────────────────────────────────────┐  ┌────────────────────────────────────────┐
│ AWS Account ID: 111111111111         │  │ AWS Account ID: 222222222222           │
│                                      │  │                                        │
│  ┌──────────────────────────────┐   │  │  EC2・Lambda・RDS・ECS                │
│  │ CloudWatch OAM Sink          │   │  │  ↓                                     │
│  │ (Observability Access Mgr)   │───┼──┼──CloudWatch Metrics / Logs            │
│  │                              │   │  │  ↓                                     │
│  │ Resource Policy:             │   │  │  OAM Link (リンク)                     │
│  │ ├─ Metrics: Allow           │   │  │  └─ Trust Policy で監視アカウントを信頼 │
│  │ ├─ Logs: Allow              │   │  │                                        │
│  │ ├─ Traces: Allow            │   │  │                                        │
│  │ └─ App Signals: Allow        │   │  │                                        │
│  └──────────────────────────────┘   │  │                                        │
│           ↑                          │  │                                        │
│  ┌──────────────────────────────┐   │  │  ┌────────────────────────────────┐  │
│  │ Unified Dashboard            │   │  │  │ AWS Account ID: 333333333333   │  │
│  │ ├─ All Metrics (3 accounts)  │   │  │  │                               │  │
│  │ ├─ All Logs (3 accounts)     │   │  │  │ OAM Link (リンク)             │  │
│  │ └─ Cross-Account Alarms      │   │  │  │ └─ Trust Policy OK            │  │
│  └──────────────────────────────┘   │  │  │                               │  │
│           ↑                          │  │  └────────────────────────────────┘  │
│  ┌──────────────────────────────┐   │  │                                        │
│  │ Logs Insights                │   │  │  ┌────────────────────────────────┐  │
│  │ (クロスアカウント検索)        │   │  │  │ AWS Account ID: 444444444444   │  │
│  │ fields @timestamp, @message  │   │  │  │                               │  │
│  │ | stats count() by @log_name │   │  │  │ OAM Link (リンク)             │  │
│  └──────────────────────────────┘   │  │  │ └─ Trust Policy OK            │  │
│                                      │  │  │                               │  │
└──────────────────────────────────────┘  │  └────────────────────────────────┘  │
                                          │                                        │
                                          └────────────────────────────────────────┘

コアコンポーネント

コンポーネント	役割	管理
Sink	監視アカウント内のリンク受付ポイント	監視アカウント
Link	ソースアカウント → Sink への接続	ソースアカウント
Resource Policy	Sink へのアクセス権定義	監視アカウント
Trust Policy	ソースが監視アカウントを信頼	ソースアカウント
Observability Data	共有されるメトリクス・ログ・トレース	ソースアカウント

コアコンポーネント

1. Sink（シンク）

監視アカウント内に作成される「リンク受付ポイント」。ソースアカウント側から Link を張るターゲット。

# Sink の作成（監視アカウント）
aws oam create-sink \
  --name "central-monitoring-sink" \
  --region us-east-1 \
  --tags Environment=production,Team=platform

# Sink 詳細取得
aws oam describe-sink \
  --identifier "arn:aws:oam:us-east-1:111111111111:sink/central-monitoring-sink"

特徴：

リージョンごとに 1 つの Sink を作成
ARN で一意に識別
Resource Policy で共有権限を明示

2. Link（リンク）

ソースアカウント側から Sink へ張るリンク。共有するデータタイプを明示。

# Link の作成（ソースアカウント）
aws oam create-link \
  --label-template "prod-account-001" \
  --resource-types AWS::CloudWatch::Metric AWS::Logs::LogGroup AWS::XRay::Trace \
  --sink-identifier "arn:aws:oam:us-east-1:111111111111:sink/central-monitoring-sink" \
  --region us-east-1

# Link 一覧取得（ソースアカウント）
aws oam list-links --region us-east-1

ポイント：

resource-types で共有するデータタイプを指定
label-template でアカウント識別情報を付与
Link 作成後、Sink 側で承認待ち状態

3. Resource Policy（リソースポリシー）

Sink へのアクセス権を定義。どのアカウント・ARN がアクセス可能か明示。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSourceAccountsMetrics",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::222222222222:root",
          "arn:aws:iam::333333333333:root",
          "arn:aws:iam::444444444444:root"
        ]
      },
      "Action": "oam:CreateLink",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "oam:ResourceTypes": [
            "AWS::CloudWatch::Metric",
            "AWS::Logs::LogGroup"
          ]
        }
      }
    }
  ]
}

4. Trust Policy（信頼ポリシー）

ソースアカウント側が監視アカウントを信頼することを明示。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "oam:*",
      "Resource": "*"
    }
  ]
}

セットアップ・ステップバイステップ

ステップ 1: 監視アカウントで Sink を作成

# 監視アカウント（Account ID: 111111111111）で実行
aws oam create-sink \
  --name "production-monitoring-sink" \
  --region us-east-1

# 出力：
# {
#   "Arn": "arn:aws:oam:us-east-1:111111111111:sink/production-monitoring-sink"
# }

ステップ 2: ソースアカウントで Link を作成

# ソースアカウント（Account ID: 222222222222）で実行
aws oam create-link \
  --label-template "prod-app-server" \
  --resource-types \
    AWS::CloudWatch::Metric \
    AWS::Logs::LogGroup \
    AWS::XRay::Trace \
  --sink-identifier "arn:aws:oam:us-east-1:111111111111:sink/production-monitoring-sink" \
  --region us-east-1

# 出力：
# {
#   "Link": {
#     "Arn": "arn:aws:oam:us-east-1:222222222222:link/1234abcd"
#   }
# }

ステップ 3: 監視アカウントで Link を承認

# 監視アカウントで実行
aws oam list-sink-links \
  --identifier "arn:aws:oam:us-east-1:111111111111:sink/production-monitoring-sink" \
  --region us-east-1

# Link の承認
aws oam update-sink-permission \
  --identifier "arn:aws:oam:us-east-1:111111111111:sink/production-monitoring-sink" \
  --principals "arn:aws:iam::222222222222:root" \
  --action-verbs "oam:*" \
  --region us-east-1

ステップ 4: CloudFormation による自動化

# 監視アカウント側
Resources:
  MonitoringSink:
    Type: AWS::OAM::Sink
    Properties:
      Name: central-monitoring-sink
      SinkPolicy:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - 'arn:aws:iam::222222222222:root'
                - 'arn:aws:iam::333333333333:root'
            Action: 'oam:CreateLink'
            Resource: '*'
            Condition:
              StringEquals:
                'oam:ResourceTypes':
                  - 'AWS::CloudWatch::Metric'
                  - 'AWS::Logs::LogGroup'

  Tags:
    Environment: production
    ManagedBy: CloudFormation

# ソースアカウント側
Resources:
  MonitoringLink:
    Type: AWS::OAM::Link
    Properties:
      LabelTemplate: !Sub '${AWS::StackName}-account'
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: 'arn:aws:oam:us-east-1:111111111111:sink/central-monitoring-sink'

Organizations との統合

Organizations 一括設定

# 組織単位での一括リンク設定（監視アカウント）
aws oam create-sink \
  --name "org-wide-monitoring-sink" \
  --region us-east-1

# Organizations で全アカウントに CloudFormation StackSet を配布
aws cloudformation create-stack-set \
  --stack-set-name OAMLink \
  --template-body file://oam-link-template.yaml \
  --auto-deployment Enabled=true,Retain=false \
  --call-as DELEGATED_ADMIN

# StackSet Target の設定
aws cloudformation create-stack-instances \
  --stack-set-name OAMLink \
  --accounts 222222222222 333333333333 444444444444 \
  --regions us-east-1

メリット：

新規アカウント作成時に自動的に Link 生成
Organizations 全体でのコンプライアンス監視・セキュリティ監視を一元化
OU 単位での細かい制御も可能

主要ユースケース

1. エンタープライズ全社の統合監視（50+ アカウント）

複数部門・複数環境（本番・ステージング・開発）を 1 つの中央ダッシュボードで監視。SRE チームが全社の health を 1 画面で把握可能。

構成：

Organizations
├─ Production OU
│  ├─ Account 1 (App)
│  ├─ Account 2 (DB)
│  └─ Account 3 (Cache)
├─ Staging OU
│  └─ Account 4
└─ Development OU
   └─ Account 5

Central Monitoring Account
├─ CloudWatch OAM Sink
├─ Unified Dashboard (All Metrics)
├─ Logs Insights (Cross-account search)
└─ Alarms (Aggregate health)

2. セキュリティ・ガバナンス一元化（Compliance Monitoring）

SecurityOps チームが全アカウントのセキュリティイベント・アクセスログを一元監視。GuardDuty・AWS Config・CloudTrail ログを集約。

Central Security Account
├─ CloudWatch OAM Sink
├─ Logs Insights Query
│  └─ fields @timestamp, eventName, sourceIPAddress, userAgent
│     | stats count() by eventName, sourceIPAddress
│     | filter eventName like /Delete|Remove|Modify/
├─ CloudWatch Alarms
│  └─ UnauthorizedOperation count > 5 in 5min → SNS Alert

3. マルチリージョン監視

各リージョンで運用しているアプリケーションスタック（us-east-1, eu-west-1, ap-northeast-1）の統合監視。

Central Monitoring Account
├─ Sink in us-east-1
│  ├─ Link: us-east-1 Apps (Account 222)
│  ├─ Link: us-east-1 DB (Account 223)
├─ Sink in eu-west-1
│  ├─ Link: eu-west-1 Apps (Account 224)
└─ Sink in ap-northeast-1
   └─ Link: ap-northeast-1 Apps (Account 225)

Unified Dashboard
├─ Global Metrics (all regions)
├─ Global Logs (cross-region Insights)
└─ Global Alarms (aggregate)

4. 顧客テナントの独立監視（SaaS マルチテナント）

SaaS プラットフォームで複数顧客（テナント）を運用。顧客ごとに AWS アカウントを分離し、各顧客の監視データを顧客独自の監視アカウントで管理。

Customer A Monitoring Account
├─ Sink: customer-a-monitoring
└─ Links: customer-a-prod, customer-a-staging

Customer B Monitoring Account
├─ Sink: customer-b-monitoring
└─ Links: customer-b-prod, customer-b-staging

Platform Operations Account (Central Oversight)
├─ Sink: platform-wide-monitoring
└─ Links: All Customer Accounts

5. パフォーマンス・コスト最適化（FinOps）

FinOps チームが全アカウントの EC2・RDS・Lambda の利用パターンを監視。コスト最適化の機会を自動検出。

FinOps Monitoring Account
├─ OAM Sink
├─ Logs Insights Query
│  └─ fields @timestamp, resourceType, @billedDuration
│     | stats sum(@billedDuration) as totalDuration by resourceType
│     | filter resourceType like /Lambda|EC2|RDS/
└─ Custom Metrics
   └─ DailyRunningCost by Account

ダッシュボード・クエリ実例

Unified Dashboard（複数アカウント統合）

[ Dashboard: Organization-Wide Health ]

┌─────────────────────────────────────────────┐
│ Prod Account - CPU Utilization              │
│ ┌──────────────────┐ (0-100%)                │
│ │ ▓▓▓▓▓▓░░░░░░░░░  │ Average: 42%          │
│ └──────────────────┘                         │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ Staging Account - Memory Utilization        │
│ ┌──────────────────┐ (0-100%)                │
│ │ ▓▓▓▓░░░░░░░░░░░░ │ Average: 28%          │
│ └──────────────────┘                         │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ Development Account - Errors                │
│ ┌──────────────────┐ (0-100)                 │
│ │ ▓░░░░░░░░░░░░░░░ │ Count: 5 (last 5min)  │
│ └──────────────────┘                         │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ Cross-Account Error Rate (Last 1 hour)     │
│                                             │
│ Prod:      3.2% ████░░░░░░░░░░░░░░░░      │
│ Staging:   0.8% ██░░░░░░░░░░░░░░░░░░░░    │
│ Dev:       1.1% ██░░░░░░░░░░░░░░░░░░░░    │
└─────────────────────────────────────────────┘

Logs Insights クロスアカウント検索

-- 全アカウントから ERROR レベルのログを検索
fields @timestamp, @message, @logStream, accountId
| filter @message like /ERROR|FATAL/
| stats count() as error_count by accountId, @logStream
| sort error_count desc

-- 結果例：
# accountId          @logStream              error_count
# 222222222222       /aws/lambda/checkout    145
# 333333333333       /aws/ecs/api-service    89
# 222222222222       /aws/rds/mysql-primary  34

Application Insights 統合クエリ

-- 全アカウントの Application Insights から Application Health を確認
fields @timestamp, Account, ApplicationName, HealthStatus
| filter HealthStatus = "RED"
| stats count() as red_applications by Account

アクセス制御・セキュリティ

細粒度の権限制御

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowMetricsOnlyFromSourceAccounts",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::222222222222:root",
          "arn:aws:iam::333333333333:root"
        ]
      },
      "Action": "oam:CreateLink",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "oam:ResourceTypes": [
            "AWS::CloudWatch::Metric"
          ]
        }
      }
    },
    {
      "Sid": "AllowLogsAndTracesFromSecurityTeam",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444444444444:root"
      },
      "Action": "oam:CreateLink",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "oam:ResourceTypes": [
            "AWS::Logs::LogGroup",
            "AWS::XRay::Trace"
          ]
        }
      }
    }
  ]
}

セキュリティ層別対策：

層	対策	実装方法
Network	VPC Endpoint（Planning）	計画中
Identity	IAM × OAM Policy	Principal + Condition
Resource	OAM Resource Policy	Sink Policy
Data	CloudTrail Logging	全操作を監査
Application	Data Classification	ソース側で管理

クロスアカウント Logs Insights

マルチアカウント統合検索

# CloudWatch Logs Insights コンソール →「Account: All accounts」を選択

# クエリ例 1: エラーログの統計
fields @timestamp, @message, @logStream, accountId
| filter @message like /ERROR|EXCEPTION/
| stats count() as error_count, pct(@duration, 99) as p99_duration by accountId
| sort error_count desc

# クエリ例 2: パフォーマンス分析（複数ログストリーム）
fields @timestamp, @duration, @memoryUsed, @logStream
| filter @duration > 1000  # 1 秒以上
| stats avg(@duration) as avg_duration, max(@memoryUsed) as max_memory by @logStream

Live Tail（リアルタイム監視）

# CloudWatch Logs Insights で Live Tail を有効化
# → 複数アカウントのログがリアルタイムで流れる
# → ホットキー：Ctrl+Shift+L

# 例：本番環境全体のエラーをリアルタイム監視
fields @timestamp, @message, accountId, @logStream
| filter @message like /ERROR/ and accountId in [222222222222, 333333333333]

Application Signals 統合

統合 Service Map

Central Monitoring Account
├─ Unified Service Map
│  ├─ Prod Account Services
│  │  ├─ API Service (Latency: 45ms, Error Rate: 0.2%)
│  │  ├─ Payment Service (Latency: 230ms, Error Rate: 0.05%)
│  │  └─ Cache Service (Latency: 2ms, Error Rate: 0%)
│  ├─ Staging Account Services
│  │  ├─ API Service (Latency: 50ms)
│  │  └─ Payment Service (Latency: 250ms)

SLO Management

# 統合 SLO の設定（複数アカウント対象）
SLOs:
  APIAvailability:
    Service:
      - prod-api-account
      - staging-api-account
    Objective: 99.9%
    Window: 30 days
    
  PaymentLatency:
    Service:
      - prod-payment-account
    Objective: P95 < 200ms
    Window: 7 days

CloudWatch Alarms

クロスアカウント Composite Alarms

# 複数アカウントのメトリクスを組み合わせたアラーム
aws cloudwatch put-composite-alarm \
  --alarm-name "Production-Health" \
  --alarm-rule "ALARM(prod-account-cpu-alarm) OR ALARM(staging-account-error-alarm)" \
  --alarm-description "Alert if any production/staging metric exceeds threshold" \
  --actions-enabled \
  --alarm-actions "arn:aws:sns:us-east-1:111111111111:ops-team"

集約アラーム設定例

{
  "AlarmName": "Multi-Account-High-Error-Rate",
  "AlarmRule": "ALARM(arn:aws:cloudwatch:us-east-1:222222222222:alarm:api-errors) OR ALARM(arn:aws:cloudwatch:us-east-1:333333333333:alarm:api-errors) OR ALARM(arn:aws:cloudwatch:us-east-1:444444444444:alarm:api-errors)",
  "ActionsEnabled": true,
  "AlarmActions": [
    "arn:aws:sns:us-east-1:111111111111:critical-alerts",
    "arn:aws:lambda:us-east-1:111111111111:function:trigger-incident-response"
  ]
}

トラブルシューティング

症状	原因	対策
Link が “Pending” のまま	Sink 側の承認待ち	Sink Owner が Update Sink Permission を実行
ソースアカウントのメトリクスが見えない	Resource Type 権限不足	OAM Link で `AWS::CloudWatch::Metric` を追加
Logs Insights で “Account: All” が表示されない	Link 未作成	ソースアカウントで Link 作成確認
CloudTrail で OAM 操作ログが記録されない	CloudTrail 無効	Source Account で CloudTrail を有効化
クロスアカウント Alarms が機能しない	メトリクス ARN 誤り	ARN 形式確認：`arn:aws:cloudwatch:region:account:metric:...`

パフォーマンス・スケーリング

スケーラビリティ項目        制限値           注釈
────────────────────────────────────────────
監視アカウント1つあたり     100,000 リンク    ソースアカウント数上限
ソースアカウントからの       5 監視アカウント  1 つのソースが複数の監視へ
リンク数

Logs Insights               数百 GB           複数月のログクエリ対応
クエリレート               1000 req/min      Quota 増加申請可

メトリクス共有            数万メトリクス     全名前空間対応

CloudTrail ログ          500,000 event/h    1 時間あたりのイベント数

コスト管理

コスト構成
═══════════════════════════════════════════════
OAM Sink・Link         : 無料
CloudWatch Metrics     : $0.30/メトリクス-月
CloudWatch Logs        : $0.50/GB ingested
Logs Insights クエリ   : $0.005/GB scanned
──────────────────────────────────────────────

例：小規模環境（5 アカウント）
  Metrics:  100 × $0.30 = $30/月
  Logs:     100 GB × $0.50 = $50/月
  合計 ≈ $80/月

例：大規模環境（50 アカウント）
  Metrics:  5,000 × $0.30 = $1,500/月
  Logs:     5,000 GB × $0.50 = $2,500/月
  Queries:  1,000 GB × $0.005 = $5/月
  合計 ≈ $4,005/月

コスト削減策：

Metrics Retention 短縮 - 不要な古いメトリクスの削除
Log Retention Policy - ログ保持期間を短縮（デフォルト：無制限）
Selective Sharing - すべてのデータタイプではなく必要なもののみ共有

ベストプラクティス

✅ Do: 推奨プラクティス

1. Organizations と OAM を統合

# StackSet で全アカウントに OAM Link を自動配置
aws cloudformation create-stack-set \
  --stack-set-name OAMLinkAutomation \
  --template-body file://oam-link-template.yaml \
  --auto-deployment Enabled=true

理由： 新規アカウント作成時に自動的にリンクされ、スケーリングが容易

2. 最小権限の原則（Least Privilege）を適用

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
    "Action": "oam:CreateLink",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "oam:ResourceTypes": ["AWS::CloudWatch::Metric"]
      }
    }
  }]
}

理由： リソースタイプごとの細かい制御でセキュリティ境界を明確化

3. CloudTrail で全操作を監査

# CloudTrail Configuration
aws cloudtrail put-trail-config \
  --trail-name oam-audit-trail \
  --enable-log-file-validation

理由： OAM Link・Sink の作成・削除などすべての操作を監査可能

4. 定期的なアクセス権限レビュー

# 月 1 回の権限確認スクリプト
aws oam list-sink-links \
  --identifier $SINK_ARN \
  | jq '.SinkLinks[] | {Label, Arn, ResourceTypes}'

❌ Don’t: アンチパターン

1. すべてのリソースタイプを許可（過権限）

// ❌ 危険：全権限を与えている
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "*" },
    "Action": "oam:*",
    "Resource": "*"
  }]
}

// ✅ 正解：必要なリソースタイプのみ
{
  "Condition": {
    "StringEquals": {
      "oam:ResourceTypes": ["AWS::CloudWatch::Metric"]
    }
  }
}

2. Sink を無防備に公開

# ❌ 誰でも Link を張れる状態にしない
# → Resource Policy を常に定義

3. Link を定期確認しない

# ❌ Link が無効・古いまま放置
# ✅ 月 1 回は Link のヘルスチェック実施

既存ツールとの比較

観点	CloudWatch OAM	Organizations Logging	Datadog Multi-Account	New Relic Sub-accounts
マルチアカウント	✅（100K accounts）	✅（Organizations）	✅	✅
セットアップ	簡単（5分）	複雑（30分）	複雑（API Key）	中程度
コスト	無料＋CW料金	無料＋CW料金	$$（高）	$（中）
Logs Insights	✅（強力）	△	✅	△
AWS 統合度	★★★★★	★★★★	★★★	★★
学習曲線	低	中	高	中
カスタマイズ	△	△	✅	✅

2025-2026 最新動向

新機能・改善

Application Signals SLO 拡張（2026年3月）
- SLO Recommendations（30日自動分析）
- Service-Level SLOs（全体的なサービス信頼性）
- SLO Performance Report（カレンダー履歴）
Database Insights クロスアカウント対応（2026年Q1）
- RDS・Aurora・DynamoDB のパフォーマンス統合監視
AI Operations 統合
- 機械学習による異常検知
- 予測的アラート
Internet Monitor クロスアカウント
- エッジロケーション単位でのトラフィック分析
Unified Query Language
- CloudWatch Metrics・Logs・Traces を同一クエリで検索

学習リソース

公式ドキュメント

AWS ブログ・事例

ハンズオン

AWS Workshops - Multi-Account Observability

実装例・チェックリスト

本番環境デプロイチェック

[ ] 監視アカウントで Sink を作成
[ ] Resource Policy で共有権限を定義
[ ] CloudFormation StackSet で全ソースアカウントに Link を配置
[ ] CloudTrail で OAM 操作監査を有効化
[ ] Logs Insights クエリをテスト実行
[ ] Composite Alarms でクロスアカウント監視を設定
[ ] 月 1 回の Link ヘルスチェックをスケジュール設定

まとめ

Amazon CloudWatch OAM は、「複数 AWS アカウントの監視データを中央アカウントから統一的に管理できるマルチアカウント Observability 基盤」 です。

主な価値提案：

運用効率化 - 50+ アカウント環境で 1 つのダッシュボード・Alarms 管理
セキュリティ強化 - Fine-grained Resource Policy でアクセス制御
スケーラビリティ - Organizations と統合で新規アカウント自動リンク
コスト効率 - Sink・Link 機能は無料（CloudWatch 本体料金のみ）
AWS 中心 - CloudWatch・Application Signals・X-Ray と深く統合

適用判断：

✅ 5+ AWS アカウント運用
✅ マルチアカウント統合監視必須
✅ Organizations を使用している
❌ 単一アカウント → CloudWatch で十分

今後の展開（2026 年）：

Application Signals SLO の自動化
Database Insights クロスアカウント
AI による異常検知・予測

参考文献

最終更新：2026-04-26 バージョン：v2.0

目次

Amazon CloudWatch OAM 完全ガイド 2026

マルチアカウント・オブザーバビリティの一元化と統合監視基盤

ドキュメントの目的

2026 年の CloudWatch OAM エコシステム

概要

CloudWatch OAM の位置づけ

定義

目次

OAM が解決する課題

課題1: マルチアカウント環境での監視の複雑性

課題2: クロスアカウントアクセス権限管理の複雑性

課題3: コスト最適化と監視スケーリングの両立

主な特徴

アーキテクチャ

コアコンポーネント

コアコンポーネント

1. Sink（シンク）

2. Link（リンク）

3. Resource Policy（リソースポリシー）

4. Trust Policy（信頼ポリシー）

セットアップ・ステップバイステップ

ステップ 1: 監視アカウントで Sink を作成

ステップ 2: ソースアカウントで Link を作成

ステップ 3: 監視アカウントで Link を承認

ステップ 4: CloudFormation による自動化

Organizations との統合

Organizations 一括設定

主要ユースケース

1. エンタープライズ全社の統合監視（50+ アカウント）

2. セキュリティ・ガバナンス一元化（Compliance Monitoring）

3. マルチリージョン監視

4. 顧客テナントの独立監視（SaaS マルチテナント）

5. パフォーマンス・コスト最適化（FinOps）

ダッシュボード・クエリ実例

Unified Dashboard（複数アカウント統合）

Logs Insights クロスアカウント検索

Application Insights 統合クエリ

アクセス制御・セキュリティ

細粒度の権限制御

クロスアカウント Logs Insights

マルチアカウント統合検索

Live Tail（リアルタイム監視）

Application Signals 統合

統合 Service Map

SLO Management

CloudWatch Alarms

クロスアカウント Composite Alarms

集約アラーム設定例

トラブルシューティング

パフォーマンス・スケーリング

コスト管理

ベストプラクティス

✅ Do: 推奨プラクティス

1. Organizations と OAM を統合

2. 最小権限の原則（Least Privilege）を適用

3. CloudTrail で全操作を監査

4. 定期的なアクセス権限レビュー

❌ Don’t: アンチパターン

1. すべてのリソースタイプを許可（過権限）

2. Sink を無防備に公開

3. Link を定期確認しない

既存ツールとの比較

2025-2026 最新動向

新機能・改善

学習リソース

公式ドキュメント

AWS ブログ・事例

ハンズオン

実装例・チェックリスト

本番環境デプロイチェック

まとめ

参考文献