developersIO
CloudWatchの新機能「Metrics Centralization」で、Organizations内のメトリクスの集約を試してみた

CloudWatchの新機能「Metrics Centralization」で、Organizations内のメトリクスの集約を試してみた

AWS Organizations環境でCloudWatchの新機能「Metrics Centralization」（コンソールの「一元化ルール管理」）を設定し、メトリクスとログをクロスアカウントで集約する手順を検証しました。OTelパスではPromQLアラームを作成でき、Vended Metric Enrichmentとの連携ではタグベースの絞り込みも確認できます
Amazon CloudWatchAWS OrganizationsCloudWatch MetricsObservabilityAWS
2026.06.30

はじめに

2026年6月、CloudWatchに Metrics Centralization が追加されました。Organizations内のメトリクスを集約先アカウントに物理コピーし、集約先からローカルにアラーム・ダッシュボード・クエリを実行できる機能です。

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-cross-account-metrics-centralization/

従来から利用できるOAM（Cross-Account Observability）と位置付けが異なるため、比較表で整理します。

OAM（Cross-Account Observability） Metrics Centralization
仕組み モニタリングアカウントからソースのテレメトリを横断参照 メトリクスを集約先アカウントに物理コピー
データの所在 ソースアカウントに残る 集約先に複製される
アラーム作成 モニタリングアカウントから可能（クロスアカウント参照） 集約先でローカルメトリクスとして作成
ソース識別 Account ID による絞り込み Classic: :@aws.account ディメンション、OTel: @aws.account 属性が自動付与
設定主体 ソースアカウントが sink への接続を承認 管理アカウントが Centralization Rule で一括指定
Organizations 必須 不要（個別アカウント間で設定可能） 必須
対象 メトリクス / ログ / トレース メトリクス + ログ
過去データ ソース側の既存データを参照可能 ルール作成後の新規データのみ
コスト（メトリクス） 通常の CloudWatch API / 機能利用料金の範囲 最初のメトリクスコピーは無料

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Cross-Account-Methods.html

Centralization の仕組み

管理アカウントからCentralization Ruleを作成して対象アカウント・リージョンを指定します。集約されたメトリクスには以下のようにソース識別情報が付与されます。

  • PutMetricData 経由のカスタムメトリクス（Classic パス）: :@aws.account / :@aws.region ディメンションが自動付与
  • OTLP endpoint 経由の OTel メトリクス（OTel パス）: @aws.account / @aws.region 属性が自動付与

ログについても同一のCentralization Ruleで集約を設定できます。SourceLogsConfiguration を追加することで、指定したアカウント・リージョンのロググループが集約先に転送されます。

制約

  • ルール作成後の新規データのみが対象（過去データは転送されない）
  • 選択的フィルタリング（特定メトリクスのみ集約）は現時点で未対応

検証環境と前提条件

アカウント 役割 アカウント ID
管理アカウント Centralization Rule 作成、Trusted access 有効化 111111111111
監視対象アカウント EC2 + CWAgent（Classic + OTel 並行）+ Enrichment 有効化 222222222222
集約先アカウント メトリクス参照・アラーム・ダッシュボード構築 333333333333
  • リージョン： ap-northeast-1（東京）
  • EC2: t4g.small (arm64) / Amazon Linux 2023
  • CloudWatch Agent: v1.300069.0

信頼されたアクセスの有効化と Centralization Rule の作成

信頼されたアクセスの有効化

Metrics Centralizationを利用するには、管理アカウントでCloudWatchの信頼されたアクセス（Trusted access）を有効化する必要があります。

CloudWatchコンソールのSettings画面、Organizationタブから有効化しました。

信頼されたアクセスをオン

信頼されたアクセスをオン2

信頼されたアクセスオン3

Centralization Rule の作成（メトリクス + ログ）

管理アカウントから observabilityadmin CLIでルールを作成します。

aws observabilityadmin create-centralization-rule-for-organization \
  --rule-name metrics-centralization-202606 \
  --rule '{
    "Source": {
      "Regions": ["ap-northeast-1"],
      "Scope": "AccountId = '\''222222222222'\''",
      "SourceMetricsConfiguration": {},
      "SourceLogsConfiguration": {
        "LogGroupSelectionCriteria": "*",
        "EncryptedLogGroupStrategy": "SKIP"
      }
    },
    "Destination": {
      "Region": "ap-northeast-1",
      "Account": "333333333333"
    }
  }' \
  --region ap-northeast-1

{
    "RuleArn": "arn:aws:observabilityadmin:ap-northeast-1:111111111111:organization-centralization-rule/metrics-centralization-202606"
}

設定のポイント：

  • SourceMetricsConfiguration: {} は空オブジェクトでも明示指定が必要です。省略すると ValidationException になります
  • Scope の構文： AccountId = '<account-id>' で単一アカウント指定、OrganizationUnitId IN (...) でOU指定、* で全アカウント指定が可能です
  • LogGroupSelectionCriteria: "*" で全ロググループを対象にしています
  • EncryptedLogGroupStrategy: "SKIP" でCMK暗号化されたロググループをスキップします

メトリクス集約の確認

集約結果の概要です。

パス 確認方法 ソース識別キー 到達時間
Classic（PutMetricData） ListMetrics + GetMetricData（Metrics Insights SQL） :@aws.account / :@aws.region（ディメンション） 約5分
OTel（OTLP） PromQL API（awscurl） @aws.account / @aws.region（属性） 約5分

Classic パス（Metrics Insights）

集約先アカウントで list-metrics を実行すると、ソースアカウントの8メトリクスが :@aws.account / :@aws.region ディメンション付きで確認できました。

aws cloudwatch list-metrics --namespace CWAgent --recently-active PT3H --region ap-northeast-1
メトリクス :@aws.account :@aws.region
cpu_usage_idle 222222222222 ap-northeast-1
mem_used_percent 222222222222 ap-northeast-1
netstat_tcp_established 222222222222 ap-northeast-1
disk_used_percent 222222222222 ap-northeast-1
... (計8メトリクス)

GetMetricData で実データも取得できることを確認します。

aws cloudwatch get-metric-data \
  --metric-data-queries '[{
    "Id": "cpu_idle",
    "Expression": "SELECT AVG(\"cpu_usage_idle\") FROM \"CWAgent\" WHERE \":@aws.account\" = '\''222222222222'\''",
    "Period": 60
  }]' \
  --start-time 2026-06-29T09:50:00Z \
  --end-time 2026-06-29T10:10:00Z \
  --region ap-northeast-1

{
  "Values": [98.43, 99.19, 98.87],
  "Timestamps": ["2026-06-29T19:06:00+09:00", "2026-06-29T19:02:00+09:00", "2026-06-29T19:01:00+09:00"]
}

ルール作成から約5分でデータポイントが到着しました。

OTel パス（PromQL）

監視対象アカウントのCWAgentでは、Classic設定に加えて append-config でOTel YAMLを追加適用し、OTLP endpointへのメトリクス送信を並行動作させています。

OTel YAML（CWAgent append-config）
receivers:
  hostmetrics/cwagent:
    collection_interval: 60s
    scrapers:
      cpu: {}
      memory: {}
      disk: {}
      filesystem: {}

processors:
  batch/cwagent: {}
  resource/cwagent:
    attributes:
      - key: service.name
        value: "ec2-metrics-source"
        action: upsert

exporters:
  otlphttp/cwagent:
    metrics_endpoint: https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics
    auth:
      authenticator: sigv4auth/cwagent

extensions:
  sigv4auth/cwagent:
    region: "ap-northeast-1"
    service: "monitoring"

service:
  extensions: [sigv4auth/cwagent]
  pipelines:
    metrics/cwagent:
      receivers: [hostmetrics/cwagent]
      processors: [resource/cwagent, batch/cwagent]
      exporters: [otlphttp/cwagent]

同じEC2上のCloudWatch Agentから、従来のCloudWatchメトリクス送信（PutMetricData、Classicパス）とOTLP送信（OTelパス）を並行させています。コンポーネント名に /cwagent サフィックスを付けて既存設定との衝突を回避し、sigv4auth extensionでインスタンスプロファイルの認証情報を使用しています。

OTelパスのメトリクスはPromQLで確認します。CloudWatchのPromQL APIはAWS CLIに専用サブコマンドがないため、awscurl で直接呼び出します。

awscurl --service monitoring --region ap-northeast-1 \
  -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d 'query={"__name__"="system.cpu.time", "@aws.account"="222222222222"}' \
  "https://monitoring.ap-northeast-1.amazonaws.com/api/v1/query"

レスポンスから、@aws.account / @aws.region が付与されていることを確認できました。resource attributeの @resource.service.name も集約先に伝搬しています。

{
  "metric": {
    "@aws.account": "222222222222",
    "@aws.region": "ap-northeast-1",
    "@resource.service.name": "ec2-metrics-source",
    "__name__": "system.cpu.time",
    "__type__": "Sum",
    "cpu": "cpu0",
    "state": "idle"
  },
  "value": [1782727830.413, "5327538.25"]
}

CloudWatchのPromQLで @aws.account や @resource.service.name のようなラベルを指定する場合は、ラベル名をダブルクォートで囲みます。

{"__name__"="system.cpu.time", "@aws.account"="222222222222", "state"="idle"}

Vended Metric Enrichment との連携

今回の検証では、EC2のCPUUtilization等のAWS vended metricsはEnrichmentなしの状態では集約先から確認できませんでした。ただし、Vended Metric Enrichmentを有効化するとOTelメトリクス（ExponentialHistogram型）として生成され、Centralizationの対象になります。

前セクションで確認したCWAgentのhostmetrics（system.cpu.time 等）は明示的にOTLP送信したものです。ここで扱うEnrichmentメトリクスはAWSが自動生成するもので、EC2タグやARNが属性として付与される点が異なります。

Enrichment メトリクスの Centralization 伝搬

検証では、監視対象アカウントと集約先アカウントの両方でVended Metric Enrichmentを有効化しました。

集約先アカウントでPromQLを実行すると、Enrichmentが生成した CPUUtilization メトリクスに対してタグベースの絞り込みができました。@aws.tag.Name で特定のEC2インスタンスを指定しています。

awscurl --service monitoring --region ap-northeast-1 \
  -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d 'query=histogram_avg({"CPUUtilization", "@aws.account"="222222222222", "@aws.tag.Name"="ec2-instance-name"})' \
  "https://monitoring.ap-northeast-1.amazonaws.com/api/v1/query"

EnrichmentによりExponentialHistogramとして扱えるメトリクスには histogram_avg() や histogram_quantile() を適用できます。ClassicのPutMetricDataメトリクスでは同じhistogram関数は使えません。

ログ集約の確認

ロググループの到着とストリーム命名規則

Centralization Ruleでログ集約を有効にすると、ソースアカウントのロググループと同名のロググループが集約先に自動作成されます。

aws logs describe-log-streams \
  --log-group-name "/aws/ec2/ec2-instance/system" \
  --region ap-northeast-1

[
    {
        "name": "i-0123456789abcdef0/messages-222222222222-ap-northeast-1",
        "lastEvent": 1782733095809
    }
]

ストリーム名には -{ソースアカウントID}-{ソースリージョン} サフィックスが自動付与されます。この命名規則から、複数ソースアカウントの同名ロググループが集約された場合でもストリーム名でソースを識別できる設計と読み取れます（今回は単一ソースアカウントでの確認です）。

filter-log-events による検索

集約されたログに対して filter-log-events のフィルタパターン検索が正常動作することを確認しました。

aws logs filter-log-events \
  --log-group-name "/aws/vendedlogs/states/resource-monitor" \
  --filter-pattern "ExecutionSucceeded" \
  --region ap-northeast-1 \
  --limit 1

{
    "logStreamName": "states/resource-monitor/2026-06-29-11-40/00000000-222222222222-ap-northeast-1",
    "message": "{\"type\":\"ExecutionSucceeded\",\"details\":{\"output\":\"{\\\"totalChecks\\\":9,\\\"criticalCount\\\":0,...}\"}}"
}

Step Functionsの実行ログも集約先に到着しており、フィルタパターンで検索できました。

Logs Insights

Logs Insightsも集約ログに対して正常動作しました。ただし集約直後はクエリ結果に反映されるまで約15〜20分のタイムラグがありました。

aws logs start-query \
  --log-group-name "/aws/ec2/ec2-instance/system" \
  --start-time $(date -d '1 hour ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message, @logStream | sort @timestamp desc | limit 5' \
  --region ap-northeast-1

@logStream フィールドにストリーム名（サフィックス付き）が表示されるため、Logs Insightsのクエリ結果からもソースアカウントを識別できます。

アラームの設定

Classic アラーム（MetricStat）

:@aws.account ディメンションでソースアカウントを絞り込み、TCP接続数に閾値を設定しました。

aws cloudwatch put-metric-alarm \
  --alarm-name "centralized-tcp-connections-classic" \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --metric-name netstat_tcp_established \
  --namespace CWAgent \
  --period 60 \
  --statistic Average \
  --threshold 3 \
  --treat-missing-data missing \
  --dimensions '[
    {"Name":"InstanceId","Value":"i-0123456789abcdef0"},
    {"Name":":@aws.account","Value":"222222222222"},
    {"Name":":@aws.region","Value":"ap-northeast-1"}
  ]' \
  --region ap-northeast-1

約1分でALARMに遷移しました。

centralized-tcp-connections-classic

PromQL アラーム（EvaluationCriteria）

OTelパスのメトリクスにはPromQLベースのアラームを使用します。EvaluationCriteria.PromQLCriteria で設定するため、--cli-input-json でJSONを渡す必要があります。

aws cloudwatch put-metric-alarm \
  --cli-input-json '{
    "AlarmName": "centralized-cpu-idle-promql",
    "EvaluationCriteria": {
      "PromQLCriteria": {
        "Query": "avg(rate({\"__name__\"=\"system.cpu.time\", \"@aws.account\"=\"222222222222\", \"state\"=\"idle\"}[5m])) * 100 > 90",
        "PendingPeriod": 60,
        "RecoveryPeriod": 60
      }
    },
    "EvaluationInterval": 60
  }' \
  --region ap-northeast-1

このアラームは検証しやすいようにCPU idle（idle状態のrate × 100）の値が90を超えたらALARMになるよう設定しています。実運用でCPU使用率を監視する場合は、stateの絞り込みや集約方法の設計が必要です。

PromQLアラームの構文ポイント：

  • 閾値条件はクエリ内に含めます（> 90）。従来の --threshold / --comparison-operator は指定できません
  • PendingPeriod: ALARMに遷移するまでの秒数
  • RecoveryPeriod: OKに戻るまでの秒数
  • 初期状態はOKです（ClassicのINSUFFICIENT_DATAとは異なります）

約3分でALARMに遷移しました。遷移時間は PendingPeriod、評価間隔、メトリクス到着遅延、PromQLのレンジ指定に依存します。

centralized-cpu-idle-promql

ダッシュボードの構築

ダッシュボード定義

aws cloudwatch put-dashboard \
  --dashboard-name "centralized-ec2-otel" \
  --dashboard-body '{
    "widgets": [
      {
        "type": "chart",
        "x": 0, "y": 0, "width": 6, "height": 6,
        "properties": {
          "view": "line",
          "title": "CPU Utilization (Vended Metric / タグ絞り込み)",
          "region": "ap-northeast-1",
          "data": {
            "queries": [{
              "id": "A",
              "type": "cloudwatch-metrics",
              "language": "PromQL",
              "query": "histogram_avg({\"CPUUtilization\", \"@aws.account\"=\"222222222222\", \"@aws.tag.Name\"=\"ec2-instance-name\"})"
            }]
          },
          "plotOptions": {
            "legend": {"position": "bottom", "show": true},
            "xAxis": {"type": "datetime"},
            "yAxis": [{"type": "linear"}],
            "style": {
              "label": {"position": "top", "show": false},
              "lineOptions": {"filled": false, "pattern": "solid", "spline": false, "stacked": false, "width": 2}
            }
          }
        }
      },
      {
        "type": "chart",
        "x": 6, "y": 0, "width": 6, "height": 6,
        "properties": {
          "view": "line",
          "title": "Memory Usage % (OTel hostmetrics)",
          "region": "ap-northeast-1",
          "data": {
            "queries": [{
              "id": "A",
              "type": "cloudwatch-metrics",
              "language": "PromQL",
              "query": "sum({\"__name__\"=\"system.memory.usage\", \"@aws.account\"=\"222222222222\", \"state\"=\"used\"}) / sum({\"__name__\"=\"system.memory.usage\", \"@aws.account\"=\"222222222222\"}) * 100"
            }]
          },
          "plotOptions": {
            "legend": {"position": "bottom", "show": true},
            "xAxis": {"type": "datetime"},
            "yAxis": [{"type": "linear"}],
            "style": {
              "label": {"position": "top", "show": false},
              "lineOptions": {"filled": false, "pattern": "solid", "spline": false, "stacked": false, "width": 2}
            }
          }
        }
      }
    ]
  }' \
  --region ap-northeast-1

集約ダッシュボードサンプル

PromQLダッシュボードの注意点：

  • ウィジェットタイプは "chart" を使用します。従来の "metric" はMetric Math / Metrics Insights SQL用です
  • 今回の chart ウィジェット定義では plotOptions が必要でした。省略するとコンソールで "Something went wrong" エラーになりました
  • CLIから作成した chart ウィジェットがエラーになる場合、コンソールのQuery Studioからウィジェットを追加 → ダッシュボードにピン留めする方法も有効でした

コスト

公式Pricingページに「最初の集約先への転送は無料（The first copy of centralized metrics is free）」と記載されており、メトリクスコピーに関しては最初の集約先で追加の転送コストが発生しません。ログ集約やクエリ実行、アラーム等には通常のCloudWatch料金が別途適用されます。

https://aws.amazon.com/cloudwatch/pricing/

まとめ

CloudWatch Metrics Centralizationを利用することで、AWS Organizations内のメトリクスとログを集約先アカウントに集約し、集約先からアラーム・ダッシュボード・クエリを実行できることを確認しました。

今回の検証では、CWAgentのClassicパス（PutMetricData）のメトリクスは :@aws.account / :@aws.region ディメンション付きで集約され、Metrics Insightsや通常のCloudWatchアラームから利用できました。一方、OTelパスのメトリクスは @aws.account / @aws.region 属性付きで集約され、PromQL APIやPromQLアラームから参照できました。

また、Vended Metric Enrichmentと組み合わせることで、EC2の CPUUtilization をPromQLで扱い、EC2タグによる絞り込みやExponentialHistogramに対する histogram_avg() の利用も確認できました。EnrichmentによりタグやARNなどの属性が付与されるため、Classicメトリクスだけでは難しい属性ベースの分析にも活用できそうです。

ログについても、同じCentralization Ruleで集約でき、集約先に同名ロググループが作成されること、ログストリーム名にソースアカウントIDとリージョンのサフィックスが付与されることを確認しました。filter-log-events やLogs Insightsからも集約ログを検索できます。

OAMのようにソースアカウントのテレメトリを横断参照する方式とは異なり、Metrics Centralizationは集約先にコピーされたデータをローカルリソースとして扱える点が特徴です。Organizations配下の監視データを集約先アカウントでまとめて扱いたい場合に、有力な選択肢になりそうです。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatchMetrics_Centralization.html

そのマルチアカウント運用、気合いで支えていませんか

Organizations や Control Tower で土台は作れても、アカウントもポリシーも増えるほど、運用は「詳しい一人」に寄りかかっていく。属人化が限界を迎える前に、組織として回す仕組み＝CCoEへ。5,600社の支援から得た立ち上げの型を、無料資料にまとめました。

CCoE総合支援

組織で回す仕組みの資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

CloudWatch クロスアカウントオブザーバビリティ機能により AWS Organizations メンバーアカウントのメトリクス情報を集約する
yhana
2025.06.05
Amazon CloudWatch が OpenTelemetry メトリクスをネイティブサポート（GA）— OTLP 直接送信と PromQL を試してみた
suzuki.ryo
2026.06.17
OTel Vended Metric Enrichment を有効化して既存AWSメトリクスをPromQLで参照してみた
suzuki.ryo
2026.06.17
CloudWatch が OpenTelemetry メトリクスをサポートし、OTLP エンドポイント経由でのメトリクス送信や PromQL を利用したクエリやアラーム設定が可能になりました (Public Preview)
枡川 健太郎
2026.04.06