Amazon CloudWatch OAM

目次

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

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 が解決する課題

課題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"
# }

# ソースアカウント（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"
# }
# }

# 監視アカウントで実行
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/月

コスト削減策：

  1. Metrics Retention 短縮 - 不要な古いメトリクスの削除
  2. Log Retention Policy - ログ保持期間を短縮（デフォルト：無制限）
  3. 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 を常に定義

# ❌ 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 統合度 ★★★★★ ★★★★ ★★★ ★★
学習曲線 低 中 高 中
カスタマイズ △ △ ✅ ✅

近年の動向

新機能・改善

  1. Application Signals SLO 拡張（2026年3月）

    • SLO Recommendations（30日自動分析）
    • Service-Level SLOs（全体的なサービス信頼性）
    • SLO Performance Report（カレンダー履歴）

  2. Database Insights クロスアカウント対応（2026年Q1）

    • RDS・Aurora・DynamoDB のパフォーマンス統合監視

  3. AI Operations 統合

    • 機械学習による異常検知
    • 予測的アラート

  4. Internet Monitor クロスアカウント

    • エッジロケーション単位でのトラフィック分析

  5. Unified Query Language

    • CloudWatch Metrics・Logs・Traces を同一クエリで検索

学習リソース

公式ドキュメント

AWS ブログ・事例

ハンズオン

実装例・チェックリスト

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

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

まとめ

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

主な価値提案：

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

適用判断：

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

今後の展開（2026 年）：

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

参考文献

  1. AWS CloudWatch OAM User Guide
  2. Observability Access Manager API Reference
  3. AWS Organizations Best Practices