AWSオブザーバビリティOSS統合Vol1｜Managed Prometheus・Grafana

1. OSS可観測性の本番課題とAMP/AMGの全体像

現代のクラウドネイティブ環境において、システムの健全性を継続的に把握するオブザーバビリティは、信頼性の高いサービス運用に不可欠です。その中でも、メトリクス収集・蓄積・クエリの分野でPrometheus、可視化・ダッシュボードの分野でGrafanaは、OSSエコシステムのデファクトスタンダードとして広く採用されています。

しかし、本番環境でこれらのOSSツールを自前で運用するには、スケール・可用性・運用負荷という3つの大きな課題が立ちはだかります。Amazon Managed Service for Prometheus（AMP）とAmazon Managed Grafana（AMG）は、これらの課題をAWSマネージドサービスとして解決します。本記事ではAMP+AMGを組み合わせたOSS可観測性スタックの本番運用を体系的に解説します。

1-1. Prometheus/Grafanaがデファクトになった背景

Prometheusは2012年にSoundCloudで開発が始まり、2016年にCNCF（Cloud Native Computing Foundation）のホスティングプロジェクトとして採用されました。プル型のスクレイプモデル、強力なラベルベースのデータモデル、PromQLという表現力豊かなクエリ言語が特徴です。Kubernetesとの親和性が高く、EKSをはじめとするコンテナ環境での標準メトリクス基盤として定着しています。

Prometheusが幅広く採用されている主な理由は次のとおりです。

• kube-state-metrics、node-exporter、cAdvisorなど主要コンポーネントがPrometheus形式でメトリクスを公開しており、最小限の設定でKubernetesクラスターの監視を開始できます
• MySQL、PostgreSQL、Redis、Nginx、JVMなど数百のPrometheus exporterが公開されており、多様なシステムのメトリクス収集に対応できます
• PromQLのレート計算・集計関数・ラベルフィルタリングを組み合わせることで、SLOのバーンレートを含む高度なメトリクス分析が可能です
• CNCFのGraduatedプロジェクトとして大規模本番採用の実績があり、活発なコミュニティが運用ノウハウを共有しています

Grafanaは2014年にリリースされたオープンソースの可視化プラットフォームです。Prometheus、CloudWatch、Elasticsearch、InfluxDB、Loki、Tempoなど多数のデータソースへの接続をサポートし、豊富なダッシュボードテンプレート、柔軟なアラート機能、チームコラボレーション機能を提供します。Grafana Dashboardsのマーケットプレイスには数千のコミュニティ製テンプレートが公開されており、Kubernetes、Node、MySQLなど主要コンポーネントの監視ダッシュボードをすぐに取り込んで利用できます。

この2ツールの組み合わせにより、AWSに限らず複数クラウドやオンプレミスを横断したメトリクス監視基盤を標準的なOSSとして構築できます。既存のPrometheus/Grafana資産（ダッシュボード・アラートルール・PromQLクエリ）をそのまま活用できる点は、マルチクラウド・ハイブリッドクラウド戦略を採る組織にとって大きな強みです。

1-2. OSS自前運用における本番課題

PrometheusとGrafanaは機能面で優れていますが、本番環境での自前運用には次の課題が伴います。

課題1: スケールの限界

Prometheusは単一サーバー構成が基本です。アクティブシリーズ（収集中のメトリクス時系列）が数十万〜数百万規模になると、メモリ消費とクエリ性能が劣化します。EKSクラスターが増え、マイクロサービスが増加するにつれ、シリーズ数は急激に増大します。ThanosやCortexを使ったシャーディング・フェデレーション構成を組む方法もありますが、アーキテクチャの複雑性が増し、独自の運用ノウハウが必要になります。

課題2: 高可用性（HA）の確保

プレーンなPrometheusはステートフルなサービスです。HAペアを組むにはスクレイプの重複管理や、Thanosなどのオーバーレイコンポーネントが必要です。ストレージは通常ローカルディスクに保持されるため、ノード障害時のデータ損失リスクがあります。本番SLAを維持するにはレプリケーション設計が必須ですが、設計・運用コストは小さくありません。

課題3: 運用負荷の肥大化

Prometheusのバージョンアップ、scrape設定変更のCI/CD管理、ストレージキャパシティの継続監視、アラートルールのデプロイ管理、Grafanaのプラグインアップデートとセキュリティパッチ対応——これらを専任担当者が継続して行う必要があります。本来の価値創出である「何を監視すべきか」の設計やアラートルールのチューニングに使うべきリソースが、インフラ維持に消費されてしまいます。

課題4: セキュリティとアクセス制御

社外ネットワークからGrafanaへアクセスするにはVPN・リバースプロキシ・SSO統合が必要です。マルチチームで一つのGrafanaインスタンスを共有する場合、チームごとのダッシュボードやデータソースへのアクセス分離の設計が複雑になりがちです。エンタープライズ向け機能（チームパーミッション・データソース権限等）にはGrafana Enterpriseが必要なケースもあり、ライセンスコストの検討も求められます。

1-3. AMP+AMGによるマネージドサービスでの解決

AMPとAMGは、上記の課題をAWSマネージドサービスとして解決します。

Amazon Managed Service for Prometheus（AMP）は、Prometheus互換のメトリクス収集・保管・クエリサービスです。スケール問題はAWS側が透過的に対応し、ユーザーはPrometheusのremote_write設定でAMPのインジェストエンドポイントに書き込むだけで使い始められます。HA設計はAWSが保証しており、マネージドAlertmanagerによるアラート評価も標準で提供されます。スケール上限（アクティブシリーズ数等）はサービス仕様として公開されていますが変動する可能性があるため、公開時にAWS公式ドキュメントで最新情報を確認してください。

Amazon Managed Grafana（AMG）は、GrafanaをAWSマネージドで提供するサービスです。SAML 2.0またはAWS IAM Identity Center（旧AWS SSO）によるSSO認証が標準で組み込まれており、追加のネットワーク設定なしにAMPやCloudWatch、X-RayをデータソースとしてIAM認証付きで接続できます。プラグイン管理・セキュリティパッチ・スケールはAWS側が担当します。

両サービスの組み合わせにより、次のメリットが得られます。

• インフラ管理からの解放: PrometheusとGrafanaのサーバー管理・バージョンアップ・HA設計をAWSに委譲できます
• セキュリティの標準化: IAM認証・SAML SSO・VPC統合がサービス標準として提供され、セキュリティ設計の工数を削減できます
• 既存資産の継続利用: Prometheus互換APIとGrafana互換のダッシュボード・クエリ・アラートルールをそのまま活用できます
• スケールの透過的な提供: 組織の成長に合わせてシリーズ数・ワークスペース数を増やす際もAWS側が対応します

1-4. AMP+AMG全体アーキテクチャ概要

本シリーズで扱うアーキテクチャの全体像を整理します（fig01参照）。

メトリクスの取込経路（インジェスト）

各種メトリクスソース（EKS上のアプリケーション、ADOTコレクター、EC2上のPrometheus exporter、オンプレミスやマルチクラウドのPrometheusエージェント）がPrometheus remote_writeプロトコルを使ってAMPのインジェストエンドポイントへメトリクスを送信します。通信はSigV4署名により認証され、IAMポリシーで制御されます。

AMPワークスペース（メトリクス保管・クエリ）

AMPワークスペースはメトリクスの論理的な保管・クエリ単位です。ワークスペースごとに独立したアクティブシリーズ枠を持ち、Prometheus互換HTTP APIを通じてPromQLクエリが可能です。マネージドAlertmanagerがワークスペース内のアラートルールを評価し、SNS経由でPagerDuty/Slack/メール等へアラートを配信します。

AMGワークスペース（可視化・アラート）

AMGワークスペースはGrafana UIを提供します。SAML/IAM Identity Centerで認証されたユーザーが、AMPをはじめとする複数のデータソースを利用してダッシュボードを作成・共有します。サービスマネージド権限（CloudFormation StackSets）を利用すると、AWS Organizations配下の複数アカウントのAMPワークスペースやCloudWatchメトリクスをAMGデータソースとして一括登録できます。

1-5. 既存可観測性記事との棲み分け

本記事はAMP+AMGの専門的な深掘りに特化し、既存の可観測性関連記事と次の役割分担をしています。

1-6. 本記事（Vol1）の範囲と想定読者

本記事が扱う範囲

本記事はAMP+AMGによるOSS可観測性スタックのVol1として、基礎から本番運用までを体系的に解説します。

• §2: AMP — ワークスペース設計、リモートライト設定、PromQL、スケール管理とアクティブシリーズ制限
• §3: AMG — ダッシュボード構築、データソース設定、SAML/IAM Identity Center認証とアクセス権限設計
• §4: EKS/コンテナ監視 — ADOTコレクターによるAMPメトリクス連携（ログ・Container Insightsは既存EKS可観測性記事を参照）
• §5: アラート&SLO運用 — マネージドAlertmanager、アラートルール設計、バーンレートSLO
• §6: コスト・スケール・マルチアカウント運用
• §7: 既存可観測性スタックとの統合パターンと選定フロー
• §8: つまずきポイント・アンチパターン・まとめ

想定読者

• EKSやEC2でPrometheus/Grafanaを自前運用しており、マネージドサービスへの移行を検討している方
• オンプレミスやAWS以外のクラウドのPrometheus/Grafana基盤をAWSへ統合したい方
• マルチクラウド環境で統一の可観測性プラットフォームを構築したい方
• CloudWatchネイティブを使っているが、Prometheusエコシステムとの統合を検討している方
• Prometheusの基本操作は把握しており、AWSでのマネージド運用に特化した情報を求めている方

なお、Prometheus/PromQLやGrafanaの基本操作については本記事では扱いません。可観測性の基礎概念やCloudWatch・X-Rayの入門については「可観測性入門」記事を参照してください。

可観測性の基礎はこちら（オブザーバビリティ入門）

2. Amazon Managed Service for Prometheus(AMP)

AMPは、PrometheusのメトリクスをAWSフルマネージドで収集・保存・クエリできるサービスです。セルフホストのPrometheusでは避けられないHA設定・ストレージ管理・スケールアウトをAWSに委譲しつつ、PromQL・アラートルール・Grafanaダッシュボードの既存資産をそのまま活用できます。

本節では、AMPの中核概念であるワークスペース設計、リモートライトによるメトリクス取込、SigV4認証、アクティブシリーズ管理、ラベルベースのアクティブシリーズ制限（2025-04追加）、マネージドAlertmanager、CloudWatch使用量監視の順に解説します。

ワークスペース：メトリクスの論理分離単位

AMPの基本単位はワークスペース（Workspace）です。Prometheusインスタンスに相当する論理的なメトリクス保管・クエリ単位であり、AWSアカウント・リージョン内に複数作成できます。

ワークスペース設計の基本は環境分離（prod/staging/dev）と組織分離（チーム・BU）の2軸です。本番環境は専用ワークスペースに分離し、開発環境と混在させないことでコスト把握とアクティブシリーズ管理が容易になります。

# ワークスペース作成
aws amp create-workspace \
  --alias "prod-metrics" \
  --region ap-northeast-1

作成後に返されるworkspaceIdとprometheusEndpointを記録してください。インジェストエンドポイント（/api/v1/remote_write）とクエリエンドポイント（/api/v1/）は用途が異なるため、それぞれの用途に合わせたURLを使用します。

リモートライト：メトリクス取込の仕組み

AMPへのメトリクス送信にはremote_writeプロトコルを使用します。PrometheusサーバーまたはADOTコレクターが、スクレイプしたメトリクスをインジェストエンドポイントへHTTP POSTで送信します。

Prometheusサーバーからのremote_write設定例は以下のとおりです。

# prometheus.yaml
global:
  scrape_interval: 60s
  evaluation_interval: 60s

remote_write:
  - url: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api/v1/remote_write
 sigv4:
region: ap-northeast-1
 queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500

sigv4フィールドによりSigV4署名を自動処理します。queue_configはリトライ動作とバックプレッシャー耐性に直結するため、本番環境では必ずチューニングが必要です。max_shardsを上げすぎるとAMP側の取込レートを超えてスロットリングが発生します。初期値max_shards: 200を基準に、ThrottledSamples CloudWatchメトリクスを監視しながら調整してください。

SigV4認証：AWSネイティブなアクセス制御

AMPのインジェスト・クエリエンドポイントはすべてSigV4署名による認証が必須です。IAMポリシーで書き込み・読み取りを別個の権限として細かく制御できます。

インジェスト用IAMポリシーの最小権限例を示します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "aps:RemoteWrite",
  "aps:GetSeries",
  "aps:GetLabels",
  "aps:GetMetricMetadata"
],
"Resource": "arn:aws:aps:ap-northeast-1:123456789012:workspace/ws-xxxxxxxx"
 }
  ]
}

EKSからADOTでリモートライトする場合はIRSA（IAM Roles for Service Accounts）を使ってSigV4認証を設定します。IRSAの設定詳細は§4で解説します。

Prometheus互換HTTP APIとPromQL

AMPはPrometheus互換のHTTP APIを完全サポートしています。既存のPromQLクエリ、Grafanaダッシュボード、アラートルールをそのまま移行できます。

AMG（Amazon Managed Grafana）からAMPをデータソースとして追加する場合は、クエリエンドポイントURLをデータソース設定に指定するだけです。AMGのサービスマネージド権限を使用すれば、追加のIAM設定なしにAMPへアクセスできます。

PromQLの基礎構文（レート算出・集計関数・ヒストグラム活用など）は既存EKS可観測性記事に活用事例をまとめています。本節ではAMP固有のワークスペース設計・スケール運用に絞って解説します。

アクティブシリーズとスケール設計

AMPのスケール特性を理解することは、コスト管理と可用性設計の両面で不可欠です。

アクティブシリーズとは、直近の保持期間内（デフォルト150日）に書き込みがあったメトリクス系列（ラベルの組み合わせとメトリクス名）の数です。カーディナリティが高いラベル（PodのIPアドレス、リクエストIDなど）を含めると、シリーズ数が爆発的に増加します。

AMPのアクティブシリーズ上限は2025年7月に大幅拡張されました。

デフォルトの5,000万シリーズは多くのワークロードで十分ですが、大規模なマイクロサービス環境（数千サービス×多数のPodレプリカ）では上限引き上げ申請が必要になる場合があります。現在のアクティブシリーズ数はCloudWatchで確認できます。

# アクティブシリーズ数をCloudWatchで確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/Prometheus \
  --metric-name ActiveSeries \
  --dimensions Name=WorkspaceId,Value=ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --start-time 2025-01-01T00:00:00Z \
  --end-time 2025-01-02T00:00:00Z \
  --period 3600 \
  --statistics Maximum

上限の80%（4,000万シリーズ）に達した時点でアラートを発砲し、ラベル設計を見直して不要なメトリクスを削減することを推奨します。

ラベルベースのアクティブシリーズ制限（2025年4月）

2025年4月に導入されたラベルベースのアクティブシリーズ制限（Per-label-value Active Series Limit）は、特定のラベル値がシリーズ数を独占することを防ぐ機能です。

マイクロサービス環境でservice="payment-service"のラベルを持つシリーズが急増した場合でも、そのラベル値だけに制限が適用され、他のサービスのメトリクス取込には影響しません。チームやサービス単位のクォータ管理に特に有効な機能です。

チーム間のクォータ分離イメージ:

シナリオ: payment-serviceのPodが突発的に1,000個に増加

ラベルベース制限なし: ワークスペース全体のシリーズ上限を消費
  → 他サービスのメトリクスが取込拒否される

ラベルベース制限あり: payment-serviceラベルのシリーズにのみ制限が適用
  → 他サービスへの影響はゼロのまま継続

制限値の設定はAWS Supportへの申請が必要です。申請時には対象ラベル名・値・上限値を明確に指定してください。

マネージドAlertmanager

AMPにはPrometheus互換のマネージドAlertmanagerが内蔵されています。セルフホストのAlertmanagerインスタンスを別途管理する必要はなく、AMPワークスペース内で完結します。

Alertmanager設定はYAML形式で、AWS CLIでPut/Getできます。

# Alertmanager設定をBase64エンコードして登録
ALERTMANAGER_CONFIG=$(base64 < alertmanager.yaml)
aws amp put-alert-manager-definition \
  --workspace-id ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --data "$ALERTMANAGER_CONFIG" \
  --region ap-northeast-1

SNSを通知先とするAlertmanager設定の最小例を示します。

# alertmanager.yaml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'sns-alerts'
  routes:
 - match:
  severity: critical
receiver: 'sns-critical'
repeat_interval: 1h

receivers:
  - name: 'sns-alerts'
 sns_configs:
- api_url: https://sns.ap-northeast-1.amazonaws.com
  topic_arn: arn:aws:sns:ap-northeast-1:123456789012:ops-alerts
  sigv4:
 region: ap-northeast-1
  - name: 'sns-critical'
 sns_configs:
- api_url: https://sns.ap-northeast-1.amazonaws.com
  topic_arn: arn:aws:sns:ap-northeast-1:123456789012:ops-critical
  sigv4:
 region: ap-northeast-1

group_byで同一アラートをまとめることで通知件数を削減し、repeat_intervalで重複通知を抑制します。criticalとwarningで受信者を分けることが運用上の推奨です。

CloudWatch使用量メトリクスによる監視

AMPはAWS/Prometheus名前空間のCloudWatchメトリクスで使用量を監視できます。

ThrottledSamplesの値が0を超えている場合は、ラベル設計を見直すか、アクティブシリーズ上限の引き上げを検討してください。

# ThrottledSamplesのCloudWatchアラーム設定
aws cloudwatch put-metric-alarm \
  --alarm-name "AMP-ThrottledSamples-Alert" \
  --metric-name ThrottledSamples \
  --namespace AWS/Prometheus \
  --dimensions Name=WorkspaceId,Value=ws-xxxxxxxx \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alerts

3. Amazon Managed Grafana(AMG)

Amazon Managed Grafana(AMG)の概要

Amazon Managed Grafana(AMG)は、オープンソースのGrafanaをAWSがフルマネージドで提供するサービスです。サーバーのプロビジョニング・パッチ適用・スケーリングをAWSが担うため、運用チームはダッシュボード設計とアラート運用に集中できます。AMGはGrafana Enterprise機能を含み、SAML 2.0およびAWS IAM Identity Center経由の認証統合と、AMP・CloudWatch・X-Rayといった複数のAWSデータソースへの接続が最大の特徴です。

既存記事ではほぼ未カバーの空白エリアであるため、本節ではAWSマネージド固有の認証設計・権限モデル・データソース統合を中心に詳しく解説します。

ワークスペースの概念

AMGの基本単位はワークスペースです。ワークスペースは独立したGrafanaサーバーに相当し、データソース・ダッシュボード・ユーザー・権限を管理する論理的な境界を提供します。同一AWSアカウント内で複数のワークスペースを作成でき、環境ごと（本番/ステージング）や部署ごとに分離して運用できます。

ワークスペースを作成する際の主な設定項目は次のとおりです。

• 認証プロバイダー: SAML 2.0 / AWS IAM Identity Center / 両方のいずれかを選択
• 権限タイプ: サービスマネージド権限 / 顧客マネージド権限
• プラグイン管理: Enterprise Pluginsの有無（高度なデータソースやパネルプラグインが追加される）

ワークスペース単位で認証方式・権限スコープ・データソースを独立して管理するため、セキュリティ要件やチーム構造に応じた柔軟な分離が可能です。

認証方式①: SAML 2.0直接統合

AMGはSAML 2.0プロトコルを利用し、既存のIDプロバイダー(IdP)と直接統合できます。この方式の最大の特徴はIAMロールが不要な点で、AWSアカウントのIAMポリシーを編集せずにSSOを実現できます。AWSが動作確認済みのIdPは次のとおりです。

• Okta: Okta管理コンソールでAMGアプリを作成し、SAMLメタデータXMLをAMGに貼り付けて設定します
• Azure Active Directory: エンタープライズアプリとして追加し、SAMLシングルサインオン設定をエクスポートして利用します
• OneLogin: コネクタギャラリーからGrafanaを選択してSAML統合を設定します
• Ping Identity: PingFederateまたはPingOneでSAMLアダプターを設定します
• CyberArk Identity: SAMLベースのアプリケーションとして追加します

SAML設定の基本手順は次のとおりです。IdP側でAMGをSAMLアプリケーションとして登録し、SAMLメタデータURL（またはXMLファイル）を取得します。AMGワークスペースのSAML設定画面でメタデータをアップロードし、以下のアサーションマッピングを設定します。

• email: ユーザーのメールアドレス（必須）
• login: ログイン名（Grafanaのユーザー名として使用）
• name: 表示名
• role: GrafanaのAdmin/Editor/Viewerにマッピングするロール
• org: オーガナイゼーション（マルチOrg設定時に使用）

SAMLロールマッピングの具体例を示します。IdPのグループクレームをroleアサーションに含め、AMGのassertion_attribute_roleにロールマッピングルールを設定することで、Okta/Azure ADのグループメンバーシップが自動的にGrafanaの権限に変換されます。

resource "aws_grafana_workspace_saml_configuration" "example" {
  workspace_id = aws_grafana_workspace.main.id
  idp_metadata_url= "https://your-idp.example.com/saml/metadata"
  editor_role_values = ["grafana-editor"]
  admin_role_values  = ["grafana-admin"]
  email_assertion = "mail"
  login_assertion = "uid"
  name_assertion  = "displayName"
  role_assertion  = "role"
}

SAML方式を選択する判断基準は「既存のOkta/Azure ADなどのIdP資産がある場合」です。IAMの追加設定なしに既存のIDライフサイクル管理（入退社処理・グループ管理）をGrafanaに即時反映できます。クロスクラウドSSOが既にIdP側で構成されている場合、AMGへのアクセスも既存のSSOポータルに組み込めます。

認証方式②: AWS IAM Identity Center

AWS IAM Identity Center（旧AWS SSO）を利用した認証方式は、AWS Organizations配下の組織横断認証に適しています。IAM Identity CenterはワークフォースユーザーのフェデレーテッドIDを一元管理し、複数のAWSアカウントへのアクセスをポータルから提供します。AMGとIAM Identity Center統合の特徴は次のとおりです。

ユーザー/グループの同期: IAM Identity Center側でユーザーとグループを管理します。Active Directory ConnectorやSCIM自動プロビジョニングを利用すれば、社内のActive DirectoryをIAM Identity Centerへ同期し、AMGユーザー管理をAD側に集約できます。

AMGへのアクセス割り当て: IAM Identity Centerのアプリケーション一覧からAMGワークスペースを選択し、アクセス権を付与するユーザー・グループを指定します。ここで割り当てたグループがAMGのEditorやAdminにマッピングされます。グループベースのアクセス管理により、組織の異動・入退社に伴う権限変更をAD/IAM Identity Center側の一箇所で完結できます。

MFA統合: IAM Identity CenterがMFA（多要素認証）を担うため、AMG側で個別のMFA設定は不要です。組織のMFAポリシーをそのままAMGアクセスにも適用できます。

CloudTrail連携: IAM Identity Center経由のログインはCloudTrailに記録されます。AMGへのアクセスを含む一元的な監査ログが取得でき、セキュリティ監査要件を満たしやすくなります。

IAM Identity Center方式を選択する判断基準は「AWS Organizations配下でマルチアカウント運用しており、IAM Identity Centerが既に導入済みの場合」です。複数のAMGワークスペースへのアクセス制御を一箇所で管理できます。

SAMLとIAM Identity Centerの使い分け・両方選択

AMGワークスペースではSAML/IAM Identity Center/両方のいずれかを選択できます。「両方」を選択した場合、ユーザーはどちらの認証方式でもログインできます。例えば、AWS内部チームはIAM Identity Center経由で、外部パートナーやマルチクラウドチームはSAML直接統合経由でアクセスさせる構成が可能です。

データソースの追加と管理

AMGワークスペースには、Grafanaのデータソースとして複数のAWSサービスを追加できます。AMGとAWSサービスの接続は、後述の「権限タイプ」で制御します。主要なデータソースは次のとおりです。

Amazon Managed Service for Prometheus(AMP):
Grafanaの「Data Sources」からPrometheus互換データソースとして追加します。URLにはAMPワークスペースのクエリエンドポイントを指定し、SigV4認証を有効化します。AMGはIAMを介してAMPに接続するため、適切なIAMポリシー（aps:QueryMetrics・aps:GetLabels等）を付与する必要があります。PromQLのクエリをGrafanaのパネルやExploreビューから直接実行できます。

Amazon CloudWatch:
CloudWatchデータソースを追加するだけで、AMGワークスペースのIAMロールを使用して自動的に接続します。メトリクス・ログ・アノテーションを統一されたGrafanaダッシュボードで可視化できます。マルチリージョン/マルチアカウントのCloudWatchデータを単一ダッシュボードへ集約する場面で特に有用です。

AWS X-Ray:
X-Rayデータソースを追加することで、トレースデータをGrafanaのExploreビューでクエリ・可視化できます。AMP（メトリクス）・CloudWatch Logs（ログ）・X-Ray（トレース）の3種類を単一AMGダッシュボードに集約する統合パターンは§7で詳述します。

その他のデータソース: Grafana Enterprise Plugin対応のデータソース（PostgreSQL・Elasticsearch等）もEnterprise Pluginsを追加することで利用できます。

サービスマネージド権限 vs 顧客マネージド権限

AMGのデータソース接続権限の管理方式は2種類あります。

サービスマネージド権限（Service Managed Permissions）:
AMGがCloudFormation StackSetsを自動的にデプロイし、AWS Organizations配下の全アカウント（または選択したOUのアカウント）に、データソース読み取り用のIAMロールを作成します。この方式ではAMGが以下のIAMアクションを代行します。

• iam:CreateRole / iam:AttachRolePolicy: 各アカウントへのクロスアカウントロール作成
• cloudformation:CreateStackInstances: StackSetsによる一括デプロイ
• organizations:ListAccounts: 対象アカウント一覧の取得

設定はAMGコンソールでOrganizationとOUを選択するだけです。ただし、この方式を使うにはOrganizations管理アカウント（またはDelegated Administrator）でのAMG設定が必要です。自動作成されるIAMロールの権限スコープは固定されており、細粒度のカスタマイズはできません。

顧客マネージド権限（Customer Managed Permissions）:
IAMロールの作成と管理をすべて手動で行う方式です。AMGワークスペースのIAMロールに対し、接続するAWSサービス（AMP/CloudWatch/X-Ray等）の読み取り権限を個別に付与します。最小権限の原則で絞り込んだポリシーを適用できます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "aps:QueryMetrics",
  "aps:GetLabels",
  "aps:GetSeries",
  "aps:GetMetricMetadata"
],
"Resource": "arn:aws:aps:ap-northeast-1:123456789012:workspace/ws-example"
 },
 {
"Effect": "Allow",
"Action": [
  "cloudwatch:GetMetricData",
  "cloudwatch:ListMetrics"
],
"Resource": "*"
 }
  ]
}

顧客マネージド権限は、組織全体へのStackSets展開が難しい場合や、権限スコープを精細に制御したい場合に適しています。

Grafana OSSダッシュボード資産の流用

AMGはGrafana OSS（v8以降）と高い互換性を持ち、既存のGrafanaダッシュボードをそのまま流用できます。Grafana.comのダッシュボードギャラリーには多数のコミュニティダッシュボードが公開されており、IDを指定してAMGに直接インポートできます。

代表的なインポートダッシュボードの例を示します。

• Kubernetes Cluster Monitoring: kube-state-metricsとnode-exporterのメトリクスを網羅的に可視化するダッシュボード
• Node Exporter Full: Linux/Windowsホストのリソース監視（CPU・メモリ・ディスクI/O・ネットワーク）
• JVM Micrometer: Javaアプリケーション（Spring Boot等）のJVMメトリクス

既存のGrafana OSSで運用しているダッシュボードはJSONとしてエクスポートし、AMGにインポートするだけで移行できます。PromQLクエリやパネル設定はほぼそのまま引き継がれるため、Prometheusエコシステムの資産を捨てずにマネージドサービスへ移行できます。

ユーザー・グループ管理と権限

AMGのユーザー権限は3レベルで管理します。

SAMLまたはIAM Identity Center経由でログインしたユーザーは、設定済みのロールマッピングルールに従い自動的にAdmin/Editor/Viewerのいずれかに割り当てられます。

グループ管理については、GrafanaのOrganization（Org）機能を使い、チームやプロジェクト単位でダッシュボードのアクセス制御を行えます。SAMLアサーションのorgクレームによってユーザーを特定のOrgに自動配置できるため、マルチOrg運用の自動化が可能です。コスト観点では、Viewerライセンス（$5/月）とEditorライセンス（$9/月）は分けて管理し、実際に編集権限が必要なユーザーのみEditorを割り当てることで、AMGのライセンスコストを最適化できます。

4. EKS/コンテナ監視 — AMPへのメトリクス連携

4.1 EKSメトリクスとAMP連携の全体像

Amazon EKS上のコンテナワークロードから収集したメトリクスをAMPへ送信する際、推奨アーキテクチャはAWS Distro for OpenTelemetry（ADOT）コレクターを中心に構成します。ADOTコレクターはEKSクラスター内にDaemonSetまたはDeploymentとして稼働し、Prometheus receiverでクラスター内のエクスポーターをスクレイプして、remote_writeでAMPワークスペースへ転送します。

本節がカバーするのは「EKSメトリクスをAMPへ送るパイプライン」です。FluentBitによるログ収集やContainer Insightsの設定については、後掲のep-btnからEKS可観測性記事をご参照ください。本節ではAMP remote write連携に絞って解説します。

メトリクスパイプラインの構成要素

4.2 ADOTコレクターのデプロイ方式

EKSへのADOTコレクターのデプロイには主に2つの方式があります。プロジェクトの運用体制やGitOps環境に合わせて選択してください。

ADOT Operator（推奨）

ADOT OperatorはAWS提供のKubernetes Operatorです。OpenTelemetryCollectorカスタムリソース（CR）を定義するだけで、コレクターのPodライフサイクル・設定管理・スケーリングをOperatorが自動処理します。cert-managerが前提条件となります。

# cert-managerのインストール
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

# ADOT OperatorのCRDと権限設定
kubectl apply -f https://amazon-eks.s3.amazonaws.com/docs/addons-otel-permissions.yaml

# ADOT Operatorのデプロイ
kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

OpenTelemetryCollector CRの設定例（DaemonSetモード）:

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: adot-collector
  namespace: monitoring
spec:
  mode: daemonset
  serviceAccount: adot-collector-sa
  config: |
 receivers:
prometheus:
  config:
 scrape_configs:
- job_name: 'kubernetes-pods'
  scrape_interval: 60s
  kubernetes_sd_configs:
 - role: pod
  relabel_configs:
 - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
 exporters:
prometheusremotewrite:
  endpoint: "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/<WORKSPACE_ID>/api/v1/remote_write"
  auth:
 authenticator: sigv4auth
 extensions:
sigv4auth:
  region: "ap-northeast-1"
  service: "aps"
 service:
extensions: [sigv4auth]
pipelines:
  metrics:
 receivers: [prometheus]
 exporters: [prometheusremotewrite]

Helmチャートによるデプロイ

ADOT Operatorを使用しない場合、公式Helmチャートでコレクターを直接デプロイできます。設定ファイルはConfigMapで管理し、values.yamlでカスタマイズします。チームのGitOps運用体制に合わせてOperatorとHelmを選択してください。

helm repo add aws-otel https://aws-observability.github.io/aws-otel-helm-charts
helm install adot-collector aws-otel/adot-exporter-for-eks-on-ec2 \
  --namespace monitoring \
  --set clusterName=<YOUR_CLUSTER_NAME> \
  --set awsRegion=ap-northeast-1 \
  --set ampWorkspaceId=<YOUR_WORKSPACE_ID>

4.3 ADOTコレクター設定の要点

スクレイプ設定とscrape_interval

ADOTコレクターのPrometheus receiverは、Prometheusのscrape_configsと同じ書式で設定できます。EKSでは主に次の3つのスクレイプターゲットを設定します。

• kubernetes-pods: Podのアノテーション（prometheus.io/scrape: "true"）を検出して自動スクレイプ
• kubernetes-nodes: kubeletのメトリクスエンドポイント
• kubernetes-service-endpoints: ServiceのアノテーションベースでkSM等を検出

scrape_intervalはコスト最適化の重要パラメータです。デフォルトの60sを基本とし、SLOバーンレートのベースメトリクスなど高頻度が必要なターゲットだけ30sに短縮する設計が一般的です。スクレイプ間隔を短くするほどAMPのインジェストサンプル数（コスト）が増加します。

scrape_configs:
  - job_name: 'kube-state-metrics'
 scrape_interval: 60s
 static_configs:
- targets: ['kube-state-metrics.monitoring.svc.cluster.local:8080']
  - job_name: 'node-exporter'
 scrape_interval: 60s
 kubernetes_sd_configs:
- role: node
 relabel_configs:
- action: labelmap
  regex: __meta_kubernetes_node_label_(.+)

metric_relabel_configsによるメトリクスフィルタ

不要なメトリクスをAMPへ送らないよう、metric_relabel_configsでフィルタリングします。カーディナリティの高いメトリクスをドロップすることで、AMPのアクティブシリーズ消費を大幅に抑えられます。

metric_relabel_configs:
  - source_labels: [__name__]
 regex: 'go_.*|python_.*'
 action: drop
  - source_labels: [__name__]
 regex: 'kube_pod_.*|node_cpu_.*|node_memory_.*'
 action: keep

4.4 メトリクス源: kube-state-metrics と node-exporter

kube-state-metrics（kSM）

kSMはKubernetesコントロールプレーンのオブジェクト状態をPrometheusメトリクスとして公開するコンポーネントです。EKSクラスター内にDeploymentとして稼働し、ADOTコレクターからスクレイプされます。

主要なメトリクス群:

node-exporter

node-exporterはLinuxノードのOS・ハードウェアメトリクスを公開します。EKSのマネージドノードグループではDaemonSetとしてデプロイします。kSMがKubernetesオブジェクト視点、node-exporterがノードOS視点と役割が分かれます。

主要なメトリクス群:

どちらもHelm経由でデプロイするのが一般的です。kube-prometheus-stackチャートにはkSM・node-exporterが同梱されており、EKSクラスターへの一括デプロイが可能です。

4.5 IRSA（IAM Roles for Service Accounts）によるSigV4認証

EKSからAMPへのremote_write送信にはSigV4署名が必要です。EKSでのベストプラクティスはIRSA（IAM Roles for Service Accounts）です。IRSAはPod単位でIAMロールを割り当てる仕組みで、EC2インスタンスプロファイルを使わずに最小権限を実現します。

IRSA設定手順

Step 1: EKS OIDC プロバイダーの確認

aws eks describe-cluster --name <CLUSTER_NAME> \
  --query "cluster.identity.oidc.issuer" --output text

Step 2: IAMロールの作成

aws iam create-role \
  --role-name adot-collector-role \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name adot-collector-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess

trust-policy.json（OIDCフェデレーション設定）:

{
  "Version": "2012-10-17",
  "Statement": [{
 "Effect": "Allow",
 "Principal": {
"Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER>"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
"StringEquals": {
  "<OIDC_PROVIDER>:sub": "system:serviceaccount:monitoring:adot-collector-sa"
}
 }
  }]
}

Step 3: ServiceAccountへのアノテーション付与

apiVersion: v1
kind: ServiceAccount
metadata:
  name: adot-collector-sa
  namespace: monitoring
  annotations:
 eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/adot-collector-role

IRSAを設定すると、ADOTコレクターはSigV4認証の署名に必要なクレデンシャルをPodのServiceAccountトークン経由で自動取得します。sigv4authエクステンションがこれを処理するため、設定ファイルへのアクセスキー直書きは不要です。アクセスキーの直書きは認証情報漏洩リスクがあるため、EKS環境では必ずIRSAを使用してください。

4.6 マルチクラスターから単一AMPワークスペースへの集約

複数のEKSクラスター（本番・ステージング・リージョン別など）のメトリクスを1つのAMPワークスペースへ集約するパターンは、AMGで横断ダッシュボードを実現する上で有効です。

クラスター識別ラベルの付与

異なるクラスターのメトリクスを同一ワークスペースに集約する場合、クラスターを識別するexternal_labelsをremote_write段階で付与します。

exporters:
  prometheusremotewrite:
 endpoint: "https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/<WORKSPACE_ID>/api/v1/remote_write"
 external_labels:
cluster: "prod-ap-northeast-1"
environment: "production"
 auth:
authenticator: sigv4auth

各クラスターのADOTコレクターに異なるclusterラベルを設定することで、AMGのダッシュボードでクラスター別のフィルタリングが可能になります。PromQLの{cluster="prod-ap-northeast-1"}でクラスター別に絞り込めます。

ワークスペース分割 vs 集約の選択指針

単一AMPワークスペース集約の場合、AMGはデータソースとして1つのAMPエンドポイントを参照するだけで全クラスターのメトリクスにアクセスできます。AMGのデータソース設定で複数のAMPワークスペースを登録でき、ワークスペース分割でも横断可視化が実現できます。

4.7 コスト管理とスクレイプ最適化

アクティブシリーズとコストの関係

AMPのコストはインジェストサンプル数（1サンプル＝1タイムスタンプ×1時系列）と、クエリ処理量で決まります。kube-state-metricsとnode-exporterのメトリクス数はクラスター規模に比例して増加します。100ノードのEKSクラスターでフルメトリクスを収集すると、数十万〜数百万のアクティブシリーズになるケースもあります。

コスト最適化の主な施策:

1. scrape_intervalの適正化 — 基本は60s。SLOアラートに使うメトリクスは30sに短縮しても可。15sはよほどリアルタイム性が必要な場合に限定する
2. metric_relabel_configsでの不要メトリクス除外 — go_.*などランタイム内部メトリクスは監視不要なことが多い
3. kSMのメトリクスフィルタ — --metric-allowlistオプションで必要なメトリクスのみ有効化
4. AMPのラベルベース制限 — アクティブシリーズ制限でチーム/アプリ単位に上限設定し、急増ワークロードによるワークスペース全体への影響を隔離する

カーディナリティ増大への対策

Podが動的に入れ替わるEKSでは、ラベルの組み合わせ（カーディナリティ）が急増します。特に注意が必要なラベル:

• pod: Pod名は動的。リリースのたびに新しい時系列が生成されアクティブシリーズを消費
• container_id: コンテナIDを含むラベルは高カーディナリティの典型例
• namespace + deployment + versionの組み合わせ: バージョン情報の追加でカーディナリティが指数的に増加

relabel_configsでPod名をdeployment名に集約したり、バージョン情報をラベルから除外したりする設計が、AMPのアクティブシリーズ管理において重要です。

EKSログ/Container Insightsはこちら（EKS可観測性 — FluentBit/Container Insights/ADOT）

5. アラート&SLO運用

AMPとAMGのアラート機能は、単なる「しきい値超過通知」を超え、SLO(サービスレベル目標)に基づいたエラーバジェット管理と高度な通知ルーティングを実現します。本節では、AMPのマネージドAlertmanagerを中核に据えたアラート設計と、Grafana Alertingとの役割分担を解説します。

AMPのアラートルール — Recording RulesとAlerting Rules

AMPはPrometheus互換のルールエンジンを内蔵しており、ルールファイルをYAML形式でワークスペースに適用します。ルールにはRecording Rules（事前集計）とAlerting Rules（条件評価）の2種類があります。

Recording Rules はPromQLの計算結果を新しいメトリクス系列として保存します。複雑なクエリを事前に集計しておくことで、ダッシュボードのロード時間短縮とアラート評価の安定化に貢献します。

groups:
  - name: slo_recording_rules
 interval: 1m
 rules:
# 過去5分間のエラーレートを記録
- record: job:http_request_errors:rate5m
  expr: |
 sum(rate(http_requests_total{status=~"5.."}[5m])) by (job)
 /
 sum(rate(http_requests_total[5m])) by (job)

# 過去30日間の可用性を記録
- record: job:http_availability:ratio_30d
  expr: |
 1 - (
sum_over_time(job:http_request_errors:rate5m[30d])
/
count_over_time(job:http_request_errors:rate5m[30d])
 )

Alerting Rules は評価式がtrueになった時点でアラートを発火します。for フィールドで「X分間継続したら発火」と指定でき、一時的なスパイクによる誤報を防ぎます。

groups:
  - name: service_alerts
 rules:
- alert: HighErrorRate
  expr: job:http_request_errors:rate5m > 0.05
  for: 2m
  labels:
 severity: warning
 team: backend
  annotations:
 summary: "高エラーレート検出: {{ $labels.job }}"
 description: "エラーレート {{ $value | humanizePercentage }} が5%を超えています"
 runbook_url: "https://wiki.example.com/runbooks/high-error-rate"

AMP APIを通じてルールファイルを登録します。

# ルールファイルをbase64エンコードしてAMPへ登録
WORKSPACE_ID="ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
RULES_FILE="slo_rules.yaml"

aws amp put-rule-groups-namespace \
  --workspace-id ${WORKSPACE_ID} \
  --name slo-namespace \
  --data "$(base64 -i ${RULES_FILE})" \
  --region ap-northeast-1

マネージドAlertmanager — 設定と通知ルーティング

AMPのマネージドAlertmanagerは、Alertmanager OSS互換の設定をAMPワークスペースに適用するフルマネージドサービスです。自前でAlertmanagerをデプロイ・運用する必要はありません。

Alertmanager設定の中核となるのが ルーティングツリー です。ラベルに基づいてアラートを適切なレシーバーへ振り分けます。

global:
  resolve_timeout: 5m

route:
  # デフォルトレシーバー
  receiver: default-receiver
  group_by: ['alertname', 'job']
  group_wait: 30s# アラートをまとめる待機時間
  group_interval: 5m# 同グループの次回通知間隔
  repeat_interval: 3h  # 解決済みでない場合の再通知間隔

  routes:
 # severity=criticalはPagerDutyへ即時通知
 - match:
  severity: critical
receiver: pagerduty-critical
group_wait: 10s
repeat_interval: 1h

 # team=backendはSlackの#backend-alertsチャンネルへ
 - match:
  team: backend
receiver: slack-backend

 # SLOバーンレートアラートはオンコールへ
 - match_re:
  alertname: "SLOBurnRate.*"
receiver: oncall-pagerduty
group_wait: 15s

receivers:
  - name: default-receiver
 sns_configs:
- topic_arn: "arn:aws:sns:ap-northeast-1:123456789012:alerts-default"
  sigv4:
 region: ap-northeast-1
  attributes:
 severity: "{{ .CommonLabels.severity }}"

  - name: pagerduty-critical
 pagerduty_configs:
- routing_key: "<PagerDuty Integration Key>"
  severity: "{{ .CommonLabels.severity }}"
  description: "{{ .CommonAnnotations.summary }}"

  - name: slack-backend
 slack_configs:
- api_url: "<Slack Webhook URL>"
  channel: "#backend-alerts"
  title: "{{ .CommonAnnotations.summary }}"
  text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"

  - name: oncall-pagerduty
 pagerduty_configs:
- routing_key: "<PagerDuty On-Call Key>"
  severity: critical

Alertmanager設定もAMP APIで適用します。

aws amp put-alertmanager-definition \
  --workspace-id ${WORKSPACE_ID} \
  --data "$(base64 -i alertmanager.yaml)" \
  --region ap-northeast-1

SNS基本設定・通知統合はこちら（アプリ統合本番運用 Vol1 — SQS/SNS/EventBridge）

グルーピング・抑制(Inhibition)・サイレンス

グルーピングは複数のアラートを1つの通知にまとめる機能です。例えば、同じジョブで複数のアラートが同時発火した場合、group_by: ['alertname', 'job'] で1通にまとめ、通知の氾濫を防ぎます。group_wait で待機時間を設けることで、関連アラートの集約率が向上します。

抑制(Inhibition) は、上位のアラートが発火している間、下位のアラートを送信しない機能です。インフラ障害時の「連鎖通知」を遮断できます。

inhibit_rules:
  # ノード停止中はそのノード上のサービスアラートを抑制
  - source_match:
alertname: NodeDown
 target_match_re:
alertname: "ServiceDown|HighLatency"
 equal: ['instance']

  # criticalが発火中はwarningを抑制
  - source_match:
severity: critical
 target_match:
severity: warning
 equal: ['alertname', 'job']

サイレンスは、メンテナンス作業など既知の作業時間中にアラートを一時的に無効化します。AMG UIからもSilenceを設定できますが、Alertmanager API経由でCI/CDパイプラインから自動設定するパターンも有効です。

# メンテナンス中(9:00-10:00)のサイレンス設定例
curl -X POST http://<alertmanager-endpoint>/api/v2/silences \
  -H "Content-Type: application/json" \
  -d '{
 "matchers": [{"name": "job", "value": "payment-service", "isRegex": false}],
 "startsAt": "2026-06-08T09:00:00Z",
 "endsAt": "2026-06-08T10:00:00Z",
 "comment": "定期メンテナンス by CI/CD pipeline"
  }'

SLO設計 — エラーバジェットとバーンレートアラート

単純なしきい値アラート（例: エラーレート > 1%）は誤報が多く、重要な障害を埋もれさせるアラート疲れの原因になります。SLO(サービスレベル目標)とエラーバジェットに基づくアラート設計がこれを解決します。

エラーバジェットの概念

• SLO: 例「30日間でリクエストの99.9%が成功すること」
• エラーバジェット: SLOが許容するエラーの総量 = 30日 × 0.1% = 43.2分相当
• バーンレート: エラーバジェットを消費している速度の倍率（1.0 = SLO通りの消費速度）

バーンレートが高いほど、エラーバジェットが急速に枯渇しています。

マルチウィンドウ・マルチバーンレートアラート

単一のバーンレート閾値ではなく、短時間の高バーンレートと長時間の低バーンレートを組み合わせることで、緊急性と低速な劣化の両方を検知します。

groups:
  - name: slo_burn_rate
 rules:
# SLO: 99.9%(30日間)を想定
# エラーバジェット = 0.1%

# Page worthy: 高速バーンレート(1時間で14.4倍消費→2h以内にバジェット枯渇)
- alert: SLOBurnRateFast
  expr: |
 (
job:http_request_errors:rate1h > (14.4 * 0.001)
and
job:http_request_errors:rate5m > (14.4 * 0.001)
 )
  for: 2m
  labels:
 severity: critical
 slo_window: fast
  annotations:
 summary: "SLO緊急: 高速バーンレート検出 ({{ $labels.job }})"
 description: "現在のバーンレートが14.4倍。エラーバジェットが2時間以内に枯渇します"

# Ticket worthy: 低速バーンレート(6時間で6倍消費→1日以内にバジェット枯渇)
- alert: SLOBurnRateSlow
  expr: |
 (
job:http_request_errors:rate6h > (6 * 0.001)
and
job:http_request_errors:rate30m > (6 * 0.001)
 )
  for: 15m
  labels:
 severity: warning
 slo_window: slow
  annotations:
 summary: "SLO警告: 持続的なバーンレート検出 ({{ $labels.job }})"
 description: "6時間ウィンドウでバーンレートが6倍。今日中にエラーバジェットが枯渇します"

このマルチウィンドウアプローチにより、2分間の高速劣化（ページング）と数時間かけてじわじわ悪化するケース（チケット）を分けて対応できます。

AMP Alertmanager と Grafana Alerting の使い分け

AMPとAMGは、それぞれ独立したアラートエンジンを持っています。役割を明確に分けることが重要です。

閾値設計のアンチパターンとアラート疲れ対策

アラート設計で最も避けるべきは「アラート疲れ」です。過剰な通知により担当者がアラートを無視するようになると、本当の障害を見逃すリスクが生じます。

AMGダッシュボードでのSLO可視化

アラートは「何かが壊れた」を知らせるものですが、SLOダッシュボードは「今どれだけ健全か」をチームが常時把握できるようにします。

AMGでSLOを可視化する際の典型的なパネル構成は以下の通りです。

• エラーバジェット残量 (Gauge): 残余エラーバジェット(%)をリアルタイム表示。月初から月末にかけての消費推移をグラフで可視化
• バーンレート推移 (Time Series): 1h/6h/24hのバーンレートを重ねて表示。上昇傾向を早期検知
• SLO遵守状況 (Stat Panel): 過去30日間の可用性(%)をパーセント表示。赤/緑で一目判断
• アラート発火履歴 (Logs Panel): AlterManagerへの通知履歴をタイムライン表示

AMGのダッシュボードJSONは既存のGrafana OSS資産をそのままインポートできます。Prometheus Communityが公開している「SLO dashboard」テンプレートを流用し、データソースをAMPに差し替えるだけで即座に運用を始められます。

6. コスト・スケール・マルチアカウント運用

AMP+AMGは強力なOSS可観測性プラットフォームです。ただし、適切なコスト設計なしには予想外の請求額になるケースがあります。本節では、AMPとAMGのコスト体系を詳細に解説し、コスト最適化の手法、スケール設計、マルチアカウント運用のアーキテクチャを説明します。なお、料金は変動する可能性があるため、本番導入前にAWS公式の料金ページで最新情報を確認してください。

6-1. AMPのコスト体系

AMPの料金は主に3要素で構成されています。

取込サンプル課金（Ingestion）

AMPの主要コスト要素が取込サンプル課金です。Prometheusのremote_writeによってAMPに書き込まれたサンプル（メトリクス値）の数に応じて課金されます。参考値として2025年時点の米国東部リージョン（us-east-1）では、最初の20億サンプルが$0.90/100万サンプルとなっており、段階的に単価が下がります。詳細な料金区分はAWS公式の料金ページを確認してください。

取込サンプル数を左右する主な因子は次のとおりです。

• scrape_interval: Prometheusがexporterからメトリクスを収集する間隔です。デフォルトは15秒ですが、15秒間隔と60秒間隔では1分あたりのサンプル数が4倍異なります。監視の必要精度に応じてscrape_intervalを適切に設定することが、コスト管理の基本になります
• アクティブシリーズ数: scrapeターゲットが公開するメトリクスの時系列数（ラベルの組み合わせ数）です。高カーディナリティなラベル（pod名、リクエストID等）をそのまま使用するとシリーズ数が爆発し、取込コストが急増します
• remote_writeの対象メトリクス: write_relabelでAMPに送信するメトリクスをフィルタリングしないと、exporter全メトリクスが全量送信されます

ストレージ課金（Storage）

AMPに保存されたメトリクスデータのストレージ容量に対して課金されます。参考値（2025年時点）として$0.03/GB-月ですが、詳細はAWS料金ページを確認してください。保存期間のデフォルト設定はワークスペース作成時に指定でき、不要データの早期削除がコスト最適化につながります。

クエリサンプル処理課金（Query）

PromQLクエリの実行時に処理したサンプル数に対して課金されます。料金は段階的な構造で、参考値（2025年時点）では段階課金が適用されます。大量データをスキャンする重いPromQLクエリや、高頻度のダッシュボード自動更新は課金額に影響します。

6-2. AMGのコスト体系

AMGの料金はアクティブユーザー課金モデルです。

アクティブユーザーの定義

AMGでは「アクティブユーザー」を、当月中に1回以上GrafanaワークスペースへのログインまたはAPIアクセスを行ったユーザーと定義しています。月初にログインしてその後一切アクセスしなかったユーザーも、その月はアクティブユーザーとして1ヶ月分の課金対象となります。

ユーザーロール別料金（参考値、2025年時点）

• 編集者（Editor）・管理者（Admin）: $9/月・ユーザー
• 閲覧者（Viewer）: $5/月・ユーザー
• Enterprise Pluginsアドオン: +$45/月・ユーザー（Datadog、ServiceNow等のEnterprise Plugin利用時）

ワークスペース単位で課金され、複数ワークスペースを利用するユーザーはワークスペースごとに別々のアクティブユーザーとしてカウントされます。また、AMGには無料枠があります（詳細はAWS料金ページを確認してください）。

Enterprise Pluginsの適用範囲

AMGには標準で利用可能なプラグイン（Prometheus、CloudWatch、Athena等）と、Enterprise Plugin（Datadog、Splunk、ServiceNow、New Relic等）があります。Enterprise Pluginsを利用するユーザーにはEnterprise Pluginsのアドオン料金が発生します。標準プラグインのみ利用するユーザーには不要です。

6-3. コスト最適化の実践

AMP側のコスト最適化

（1）scrape_intervalの見直し

監視の要件によって適切なscrape_intervalを設定します。インフラメトリクス（CPU、メモリ、ネットワーク等）は60秒間隔でも十分なケースが多く、アラートの精度要件が高いメトリクスのみ15〜30秒にする差別化が効果的です。

（2）メトリクスフィルタリング（write_relabelの活用）

Prometheus remote_writeのwrite_relabelを設定し、AMPに送信するメトリクスを必要なものだけに絞ります。exporterが公開する全メトリクスを無差別に送信することは避けましょう。

（3）高カーディナリティラベルの排除

Podのランダムなサフィックス、リクエストID、ユーザーIDなど、高カーディナリティなラベル値はシリーズ数を急増させます。relabel_configsのlabledropや、アプリケーション側でのラベル設計の見直しが重要です。

（4）不要シリーズの削減

不使用になったexporterやscrapeターゲットを適切に除去します。Kubernetesの場合、削除済みPodのメトリクスがscrapeターゲットに残存するケースがあります。

（5）Recording Rulesの活用

Recording Rulesで事前集計したメトリクスをダッシュボードやアラートルールで参照することで、同じデータへの重複クエリを削減しクエリ処理課金を抑えられます。

AMG側のコスト最適化

（1）閲覧者ライセンスの活用

ダッシュボードの参照のみのユーザーは閲覧者（Viewer）ロールに設定することで、$9から$5へ削減できます。月次レポート参照程度のユーザーをEditorのままにしておくと不必要なコストが発生します。

（2）非アクティブユーザーの棚卸し

月次でアクティブユーザーのアクセスログを確認し、長期間ログインしていないユーザーを無効化・削除します。組織変更や退職などによる「幽霊ユーザー」が蓄積するとAMGコストが増大します。

（3）ワークスペース統合

チームごとに別々のAMGワークスペースを作成している場合、組織としてのユーザー課金が分散します。アクセス制御をフォルダー/データソース権限で管理することで、ワークスペース数を最適化できます。

6-4. スケール設計とアクティブシリーズ管理

アクティブシリーズの上限

AMPのアクティブシリーズ数にはワークスペース単位での上限があります。2025年時点では既定50M/ワークスペースで、最大10億シリーズまでリクエスト上限引き上げが可能です。上限値はサービス改定により変動することがあるため、公開時にAWS公式ドキュメントで確認してください。

ラベルベースのアクティブシリーズ制限（2025-04〜）

2025年4月からAMPで提供が始まったラベルベースのアクティブシリーズ制限により、特定のラベルセット（例: service=”payment-service”）に対するシリーズ数を個別に制限できるようになりました。これにより、急増するマイクロサービスが全体のシリーズ枠を圧迫する問題を防ぎ、マルチテナント環境でのテナント間の公平なリソース分配が可能になります。

スケール設計のポイント

• 大規模環境ではワークスペースの論理分割（環境別・リージョン別・チーム別）を検討します
• 取込サンプルレートとアクティブシリーズ数をCloudWatchのAMPメトリクスで継続監視し、上限への接近を早期に検知します
• AMGのデータソースで複数AMPワークスペースをクロスクエリできるため、ワークスペース分割してもGrafanaで統合表示できます

6-5. マルチアカウント運用

AMGのサービスマネージド権限とStackSets

AMGワークスペースで「サービスマネージド権限」を有効にすると、CloudFormation StackSetsを使ってAWS Organizations配下の複数アカウントへIAMロールが自動プロビジョニングされます。これにより、各アカウントのAMPワークスペース・CloudWatchメトリクス・X-Rayトレースを、AMGデータソースとして一括登録・集約閲覧できます。

セットアップには次の権限が必要です。

• Organizations管理アカウントでStackSetsの信頼関係設定
• AMGサービスロールへのiam:CreateRole等の権限付与

マルチAMPワークスペースの集約

複数アカウント・複数リージョンにAMPワークスペースを分散させ、AMGで集約表示するパターンが本番でよく使われます。各開発チームが独立したAMPワークスペースでメトリクスを管理しつつ、SREチームが全ワークスペースを一つのAMGから横断監視する構成です。

使用量監視とアラート

AMPの使用量（取込サンプルレート・アクティブシリーズ数）はCloudWatch usage metricsでモニタリングできます。次のCloudWatchアラームを設定することで、上限への接近を早期に検知できます。

• AWS/Usage メトリクス: ResourceType=WorkspaceId、Type=Resource でAMPリソース使用量を取得します
• アクティブシリーズ数が上限の80%を超えた場合にSNS通知を設定します
• 取込レートの週次トレンドを確認し、急増パターンを早期検知します

6-6. コスト見積もりとコスト配分タグ

コスト見積もりの考え方

AMP+AMGの月次コストを事前に見積もるには、以下の情報が必要です。

• AMPワークスペースのアクティブシリーズ数の推計（既存Prometheus構成から概算可能）
• scrape_intervalの設定（サンプル/分 = シリーズ数 × 60/scrape_interval）
• 月次の推定取込サンプル数 = サンプル/分 × 60 × 24 × 30
• AMGのアクティブユーザー見込み数とロール内訳（Editor/Viewerの比率）

AWS Pricing Calculatorを使うと、これらのパラメータを入力してAMP+AMGの月次コストを試算できます。

コスト配分タグの活用

AWSコスト配分タグをAMPワークスペースとAMGワークスペースに付与することで、チーム・プロジェクト・環境ごとにコストを分解してAWS Cost Explorerで確認できます。マルチチーム・マルチプロジェクトの組織では、どのチームがどれだけAMP/AMGコストを消費しているかの可視化と配賦が重要です。コスト配分タグを有効活用することで、FinOps観点からのオブザーバビリティコスト管理が実現します。

7. 実戦統合パターン — 既存可観測性との使い分け・統合

統合パターン①: AMGで横断可視化（単一ダッシュボード統合）

最も強力な統合パターンは、AMGのデータソースにAMP・CloudWatch・X-Rayをすべて追加し、単一のGrafanaダッシュボードで横断的に可視化する構成です。

[メトリクス] AMP──┐
[ログ] CloudWatch Logs──┤→ AMG単一ダッシュボード（統合可視化）
[トレース]AWS X-Ray──┤
[メトリクス] CloudWatch  ──┘

単一ダッシュボードへの集約により得られるメリットは次のとおりです。

コンテキストスイッチの排除: インシデント発生時に複数コンソール間を行き来せず、1つのダッシュボードでメトリクス・ログ・トレースを関連付けて調査できます。例えば、AMPのHTTPエラーレートスパイクを検知した後、同じダッシュボードのパネルでCloudWatch Logsのエラーログを確認し、X-Rayのトレースで原因サービスを特定するという一連の作業がシームレスに行えます。

Grafana Variables活用: Grafanaのダッシュボード変数（Variables）を使い、$env（production/staging）や$serviceでフィルタリングすることで、単一ダッシュボードで複数環境・サービスを切り替えられます。AMP側では{env="$env"}のPromQLラベルフィルタ、CloudWatch側ではディメンションフィルタとして同じ変数を参照します。

Grafana Unified Alert: AMG上でGrafana Unified Alertingを設定すると、AMP・CloudWatch・X-Rayのデータを横断してアラート条件を評価できます。例えば「AMPのエラーレートが5%超 かつ CloudWatchのP99レイテンシが2秒超」という複合条件のアラートをGrafana上で定義できます。

時系列の相関表示: Grafanaのアノテーション機能を使うと、Alertmanagerのアラート発火タイミングをTimeSeriesパネルに重ねて表示できます。「この時間帯に何が起きていたか」を複数データソースにまたがって俯瞰できます。

AMGへの複数データソース追加手順

AMGワークスペースへのデータソース追加はワークスペース設定の「Data sources」から行います。AMP・CloudWatch・X-Rayを順番に追加してください。

Configuration → Data Sources → Add data source
→ Amazon Managed Service for Prometheus（URLにAMPクエリエンドポイント・SigV4有効）
→ Amazon CloudWatch（デフォルトリージョン設定のみ）
→ AWS X-Ray（デフォルトリージョン設定のみ）

各データソースの接続テストを「Save & Test」ボタンで実施し、全データソースが「Data source is working」を返すことを確認してください。

統合パターン②: メトリクス/ログ/トレースの役割分担

AMP・CloudWatch・X-Rayをシグナル種別で役割分担する構成は、既存のAWSモニタリング基盤を段階的にPrometheusエコシステムへ移行する際の典型的なアーキテクチャです。

この役割分担の設計判断根拠は次のとおりです。

メトリクスにAMPを選ぶ理由: Kubernetes/EKSの監視でkube-state-metrics・Prometheus exportersを既に使用している場合、AMPへのremote_write移行は設定変更のみで完了します。PromQLの豊富な集計関数（rate/histogram_quantile/topk等）は、カスタムメトリクスの高度な分析に強みがあります。一方、CloudWatch Metricsで十分なAWSサービスメトリクスはCloudWatchのままにすることで、二重課金を避けられます。

ログにCloudWatch Logsを選ぶ理由: Lambda・ECS・EKS（Fluent Bit）等のAWSサービスはデフォルトでCloudWatch Logsへ送信します。CloudWatch Logs Insightsの構造化ログクエリ・S3へのエクスポート・サブスクリプションフィルターはAWSネイティブの利点です。Prometheusはメトリクスのストアであり、ログは守備範囲外です。

トレースにX-Ray/ADOTを選ぶ理由: AWS SDKとのネイティブ統合・Service Map・Insights機能はX-Ray固有です。ADOTコレクターはOpenTelemetryトレースをX-Ray形式に変換するため、計装コードの変更なしにOpenTelemetry標準のトレースをX-Rayに送信できます。

CloudWatch Logs詳細はこちら（オブザーバビリティ Vol2）

統合パターン③: 専門監視系との連携と境界設計

AMP+AMGスタックは「メトリクス+可視化」に特化しており、他の専門監視系と適切に境界を引くことが重要です。

ネットワーク可観測性との連携:
VPC Flow Logs・AWS Network Reachability Analyzer・Traffic Mirroringといったネットワーク監視は、専門のネットワーク可観測性スタックが担います。AMP+AMGはアプリケーション/インフラメトリクスに集中し、ネットワーク系の詳細はネットワーク可観測性シリーズのスタック（CloudWatch・Network Flow Monitor等）に委ねます。

AMGのデータソースとしてCloudWatch Logs（VPC Flow Logs保存先）を追加することで、ネットワークメトリクスの概要をAMGダッシュボードに表示しつつ、詳細分析は専門ツールに誘導するハイブリッド構成も可能です。

AI可観測性(LLMOps)との連携:
LLM推論ワークロード（Amazon Bedrock/SageMaker等）の監視は、通常のインフラメトリクスとは異なる指標（トークン処理数・推論レイテンシ・コストパートークン等）を要します。AMPにPrometheusフォーマットのLLMメトリクスをリモートライトで送信すれば、AMGダッシュボードでLLMOpsメトリクスを可視化できます。ただし、LLM固有の評価指標（RAG精度・Hallucination率等）は別のMLOpsスタックに委ねられることが多く、AMPはインフラ層のメトリクスに集中させる設計が合理的です。

可観測性スタック選定フロー

実際の現場でAMP+AMGかCloudWatchネイティブかを選択する際は、次のフローで判断します。

flowchart TD
 A[可観測性スタック選定] --> B{監視対象の主体は？}
 B -->|AWSサービスのみ| C{Prometheusエコシステムの\n資産はあるか？}
 B -->|EKS/コンテナ/マルチクラウド| D[AMP+AMG]
 C -->|なし| E[CloudWatchネイティブ]
 C -->|あり| F{既存OSSダッシュボード\nやPromQLクエリ資産}
 F -->|多数あり| D
 F -->|ほぼなし| E
 D --> G{CloudWatchも\n使い続けるか？}
 G -->|はい| H[ハイブリッド:\nAMGにAMP+CW両データソース]
 G -->|いいえ| I[AMP+AMG専用スタック]
 E --> J[CloudWatchネイティブ:\nメトリクス+Logs+X-Ray]

このフローの要点をまとめます。

CloudWatchネイティブを選ぶ場合:

• 監視対象がAWSサービス中心（EC2/RDS/ALB等）でPrometheus exporterのカスタムインストールが不要
• チームにPrometheus/PromQLの習熟者がいない
• 追加のエージェントやコレクターを管理したくない
• シンプルなAWS統合を優先する

AMP+AMGを選ぶ場合:

• EKS/コンテナワークロードでkube-state-metrics・Prometheus exporterを既に運用中
• オンプレミス・他クラウドのメトリクスをAMPへ集約してマルチクラウド統合監視を実現したい
• 既存のGrafanaダッシュボード・PromQLアラートルール資産を再利用したい
• CloudWatchメトリクスの高カーディナリティな用途でコスト効率をPrometheusで最適化したい

ハイブリッドを選ぶ場合:
最も現実的な構成は「CloudWatchとAMP+AMGを並存させ、AMGで統合表示する」ハイブリッドです。AWSサービスのメトリクスはCloudWatch、EKSやカスタムアプリのメトリクスはAMP、そしてAMGのデータソースにその両方を登録して単一ダッシュボードで可視化します。

段階移行も容易です。まずCloudWatchで始め、EKS導入を機にAMPを追加し、AMGダッシュボードにCloudWatchデータソースも並べる、というステップを踏めます。
既存投資を無駄にせずPrometheusエコシステムへ段階的に移行できる点が、ハイブリッド構成の最大の利点です。

既存可観測性記事群との連携全体像

本記事の位置づけをシリーズ全体の中で整理します。

入門記事（オブザーバビリティ基礎）:
CloudWatchメトリクス・X-Ray・AWS Distro for OpenTelemetry（ADOT）の基礎概念を解説しています。本記事は入門知識を前提とし、AMP+AMGのAWS固有設定に特化しています。AMP/AMGを初めて触れる方は入門記事からご参照ください。

オブザーバビリティ基礎はこちら（可観測性入門）

CloudWatch Logsシリーズ（Vol2）:
ログの集約・管理・分析に特化した記事シリーズです。本記事の統合パターン②でログをCloudWatch Logsに委ねる設計の詳細はCloudWatch Logsシリーズをご参照ください。AMGダッシュボードでログパネルを追加する際も、CloudWatch Logsのロググループ・フィルタパターンの設計は同シリーズに依拠します。

App Signals/SLOシリーズ（Vol3）:
AWS Application Signalsは、APM（アプリケーションパフォーマンス監視）をAWSネイティブに実現するサービスです。SLOの設定・サービスマップ・CodeGuru Profilerとの連携を解説しています。本記事§5のAlertmanager/SLO運用と補完関係にあり、AMP+AMGスタックのSLO設計はAlertmanagerベース、Application SignalsのSLOはAWSネイティブという棲み分けです。

X-Rayシリーズ:
分散トレーシングの詳細（セグメント・サブセグメント・サービスマップ・サンプリングルール）を解説しています。本記事では「AMGのデータソースにX-Rayを追加して可視化する」にとどめ、X-Rayの詳細設定はX-Rayシリーズに委ねます。

ネットワーク可観測性シリーズ（Vol1）:
VPC Reachability Analyzer・VPC Flow Logs・Traffic Mirroringを解説しています。本節の統合パターン③で「ネットワーク監視は専門記事参照」と案内している詳細がここにあります。

ネットワーク可観測性はこちら（ネットワーク可観測性 Vol1）

Application Signals/SLOはこちら（オブザーバビリティ Vol3）

8. つまずきポイント・アンチパターン・まとめ

AMP+AMGの構築・運用で頻出するつまずきポイントをまとめます。各項目には症状・原因・対処法を記載しているため、本番環境での設計・運用改善にご活用ください。AMP固有の制限事項と、AMG特有の認証・ライセンス管理の注意点を中心に整理します。

つまずきポイント

1. 高カーディナリティラベルによるアクティブシリーズ上限超過

症状: ThrottledSamples CloudWatchメトリクスが増加し始め、一部メトリクスの取込が拒否される。AMGダッシュボードに特定サービスのデータが表示されなくなる。

原因: pod_ip、request_id、UUID等の一意性の高い値をラベルに含めると、Podが100個いれば100シリーズ×メトリクス数だけシリーズが生成されます。マイクロサービスが数百種類あると、アクティブシリーズ上限（既定5,000万）に到達します。動的に生成されるPod名もカーディナリティ増大の原因です。

対処法:
– 高カーディナリティラベルの特定: aps:GetSeries APIやAMGのExploreビューで上位シリーズ数のラベルを可視化する
– relabel_configsで不要ラベルをドロップするか、値を集約する
– ラベルベースのアクティブシリーズ制限（2025-04追加）でテナント分離し、特定サービスの急増が他に波及しないよう設計する
– CloudWatchのActiveSeriesが上限の80%に近づいたらアラームを設定し、早期に対処する

2. scrape_interval過短による取込コスト爆発

症状: AMPの月額コストが予算の数倍になる。コスト管理ダッシュボードでIngestedSamplesが急増している。

原因: AMPは取込サンプル数に応じた課金（$0.90/100万サンプル）です。scrape_interval: 10sで1,000万シリーズを収集すると1分間で6,000万サンプルが発生し、月間コストが急増します。デフォルト値を確認しないまま運用しているケースが多くあります。

対処法:
– 多くのユースケースではscrape_interval: 60sが適切な出発点です
– SLOアラートのベースメトリクスなど高頻度が必要なターゲットのみ30sに設定し、それ以外は60s以上を維持する
– Recording Rulesで頻繁に使用するPromQLクエリを事前集計し、クエリサンプル処理コストも削減する
– metric_relabel_configsで使用していないメトリクス（go_.*等ランタイム内部指標）をドロップして取込量を削減する

3. AMG閲覧者ライセンスの想定外課金

症状: 月次請求で「Amazon Managed Grafana」の行が予算超過している。閲覧専用ユーザーが多数いる。

原因: AMGはアクティブユーザー（月1回以上ログインまたはAPI利用）単位で課金されます（Viewer $5/月・Editor/Admin $9/月・ワークスペース単位）。閲覧のみのユーザーでも月1回ログインすれば課金対象です。退職者アカウントや利用頻度の低いユーザーを放置すると、意図せず課金が膨らみます。

対処法:
– 毎月末にアクティブユーザーリストをAMGコンソールで確認し、不要アカウントを削除する
– ダッシュボードの閲覧のみが目的のユーザーには、AMGへの直接アクセスではなく共有リンクによるアクセスを検討する
– Enterprise Plugins（+$45/ユーザー）は実際に使用するプラグインが必要な場合のみ有効化する
– AWS Budgetsで月額上限アラートを設定し、想定外の課金増を早期検知する

4. SAMLとIAM Identity Centerの混同による認証設定ミス

症状: AMGワークスペースに「Authentication required」エラーが出てログインできない。またはユーザーを追加できない。

原因: AMGの認証方式は①SAML 2.0直接統合（IdP証明書とアサーションURLを設定）と②AWS IAM Identity Center（ワークフォースID経由）の2種類です。ワークスペース作成後の方式変更は容易でないため、両方の設定を同時に試みて競合を招くケースが多くみられます。

対処法:
– 認証方式は組織のIdP状況で決定してから変更しないことが原則です。既存のOkta/Azure AD/OneLogin等があればSAML直接統合、AWSワークフォースIDで統一するならIAM Identity Centerを選択します
– SAMLの場合はIdP側でAMG用のSAMLアプリを作成し、メタデータXMLをAMGへ正確にインポートします
– ユーザーが両方の方式で登録されている場合、優先順位は設定によって異なるため混乱の元になります。方式を1つに統一してください
– ワークスペース作成前に認証方式を決定し、後から変更が必要な場合は新規ワークスペースの作成を検討してください

5. IRSA未設定によるEKS→AMP認証失敗

症状: EKSのADOTコレクターPodがCrashLoopBackOffになる。ログにfailed to sign request: NoCredentialProvidersが出る。

原因: EKS上のアプリケーションがAMPにリモートライトする際はSigV4署名が必須です。IRSA（IAM Roles for Service Accounts）でServiceAccountにIAMロールを紐付けていないと、PodはAWSクレデンシャルを取得できません。EC2インスタンスプロファイルによる認証はセキュリティ的に非推奨です。

対処法:
– EKSのOIDCプロバイダーを有効化し、IRSA設定を完了させます
– ServiceAccountのannotationにeks.amazonaws.com/role-arnを追加します
– IAMロールにaps:RemoteWrite権限を付与します
– aws sts get-caller-identityをPod内から実行して、IRSAが正しく機能しているか確認します
– ADOTコレクターのsigv4authエクステンション設定でregionとserviceを正確に指定します

6. Alertmanagerルーティング設定漏れによる通知未着

症状: AMPのアラートルールは「FIRING」になっているが、SNSやPagerDutyに通知が届かない。

原因: マネージドAlertmanagerにおいて、ルーティング設定（routeセクション）の未設定またはreceiver名の不一致が発生している場合、アラートはFIRINGになっても通知は送出されません。YAML書式エラーはAMPへの設定登録時に拒否されることがありますが、ルーティングの論理ミスは登録が成功しても機能しません。

対処法:
– Alertmanager設定を登録前にAlertmanager公式のルーティングツリーエディタで検証します
– receiver名はroute側とreceivers配列の名前が完全一致することを確認します
– AMPのAlertmanager APIでアラート状態（/api/v2/alerts相当）を確認し、ルーティング先を検証します
– SNSトピックへのIAM権限（sns:Publish）がAlertmanager実行ロールに付与されているか確認します

7. CloudWatchで十分な場面でのAMP/AMG過剰導入

症状: 運用工数が増えた割にCloudWatchとAMP/AMGで可観測性が分散してしまい、どちらを見ればよいか分からなくなる。

原因: 既存のAWSサービス監視（EC2/ECS/Lambda等）はCloudWatchネイティブメトリクスで十分カバーできることが多いです。Prometheusエコシステムの既存資産がない、またはマルチクラウド要件がないにもかかわらずAMP/AMGを導入すると、ツールが二重になり運用コストが増加します。

対処法:
– §7の使い分けフローチャートを参照し、AMP/AMGが本当に必要か確認します
– 既存のPrometheusダッシュボード・アラートルール資産がある、またはEKS/セルフマネージドKubernetesのメトリクス基盤が必要な場合にAMP/AMGを採用します
– AWSサービス中心の監視はCloudWatchに留め、AMGのデータソースにCloudWatchを追加して統合表示だけをAMGで行うハイブリッド構成も有効です
– 投資対効果の観点から、既存のGrafana OSSダッシュボード資産が10枚以上ある場合にAMGへの移行を検討するのが現実的な基準です

8. scrape_config未設定でAMPにメトリクスが届かない

症状: ADOTコレクターを設置したがAMPにメトリクスが届かない。AMGのダッシュボードが空になる。

原因: ADOTコレクターのOpenTelemetry設定ファイルでPrometheus receiverのscrape_configsが未記述、またはターゲットのポートが間違っています。Prometheusレシーバーはscrape_configs構文でターゲットサービスを明示的に指定する必要があります。

対処法:
– ADOTのConfigMapでscrape_configsにターゲットサービスとポートを明示します
– EKSのサービスディスカバリー（kubernetes_sd_configs）を使用すれば手動ターゲット管理が不要になります
– コレクターPodのログにscrape errorが出ていないか確認します
– AMPのIngestedSamplesが0のままであれば、パイプラインのreceivers/exporters設定を再確認してください

9. マネージドAlertmanagerへのAlerting Rules未登録

症状: AMPのルール設定をput-rule-groups-namespaceで登録したつもりだが、アラートが一切発火しない。

原因: AMPのルール設定とAlertmanager設定は別個のAPIエンドポイントで管理されます。Recording Rules/Alerting Rulesはput-rule-groups-namespaceで、AlertmanagerのルーティングとレシーバーはAMPのput-alertmanager-definitionで別々に登録する必要があります。どちらか一方だけ設定しても機能しません。

対処法:
– aws amp list-rule-groups-namespacesでルールが登録されているか確認します
– aws amp describe-alertmanager-definitionでAlertmanager設定が存在するか確認します
– ルール登録後にaws amp list-ingested-data等でルール評価が開始されているか確認します
– stagingワークスペースで両方の設定をセットとして検証してから本番に適用する手順を標準化します

10. AMGのデータソースにAMPを追加後、クエリが空になる

症状: AMGでAMPをデータソースとして追加したが、Exploreでクエリを実行しても結果が空になる。

原因: AMGのサービスマネージド権限（Service Managed Policies）が有効になっていない、またはAMGワークスペースにAMPワークスペースへのアクセス権限が付与されていない場合に発生します。AMGとAMPが異なるAWSアカウントに存在する場合、クロスアカウントの権限設定が必要です。

対処法:
– AMGコンソールでData sourcesの設定を確認し、AMPワークスペースが「Connected」になっているか確認します
– サービスマネージド権限が有効になっている場合、AMGのサービスロールにaps:QueryMetrics等の権限が自動付与されます
– 手動設定（顧客マネージド権限）の場合、AMGのサービスロールにaps:QueryMetrics、aps:GetSeries、aps:GetLabels等の権限を明示的に付与します
– クロスアカウントの場合、AMPワークスペースのリソースベースポリシーでAMGのサービスロールからのアクセスを許可します

アンチパターンと正解

AMP+AMGの導入・運用で繰り返し見られるアンチパターンを整理します。

まとめ：AMP+AMGで実現するOSS可観測性スタックの全体像

本記事では、AMPとAMGを中心にOSS標準の可観測性スタックをAWSフルマネージドで運用する方法を解説しました。

AMP（§2）は、ワークスペース単位のメトリクス保管・クエリ分離、remote_writeによるスケーラブルなメトリクス取込、SigV4認証によるセキュアなアクセス制御が主要なポイントです。2025年7月の更新で既定5,000万シリーズへのスケールアップが実現し、大規模マイクロサービス環境でも安定して運用できます。ラベルベースのアクティブシリーズ制限（2025-04）により、マルチテナント環境でのクォータ管理が容易になりました。AMPを正しく活用するには、ワークスペース設計・ラベルカーディナリティ管理・scrape_interval最適化の3点が特に重要です。

AMG（§3）は、SAML直接統合とIAM Identity Centerによる2方式の認証、サービスマネージド権限による組織横断データソース接続が特徴です。既存のGrafanaダッシュボード資産をそのまま移行でき、AMGがAMP・CloudWatch・X-Rayを単一の視点で統合表示します。認証方式はワークスペース作成前に確定し、後から変更しないことが運用安定性の鍵です。

EKS/コンテナ環境（§4）は、ADOTコレクターのPrometheus receiverとremote_writeでAMPへメトリクスを集約します。IRSA設定さえ正確に行えばSigV4認証は自動処理されます。マルチクラスター構成でも単一ワークスペースに集約でき、AMGで横断ダッシュボードを実現できます。

アラート・SLO（§5）は、マネージドAlertmanager+SNSで通知を送信し、マルチウィンドウ・マルチバーンレートアラートでSLO違反の予兆を早期検知できます。AMPのAlertmanagerとAMGのGrafana Alertingは役割を明確に分けて使うことが重要です。単純なしきい値アラートからSLOベースのエラーバジェット管理へ段階的に移行することを推奨します。

コスト・スケール（§6）では取込サンプル削減（interval調整・recording rules・relabel）とAMGのアクティブユーザー管理がコスト最適化の要です。AMPのコストは取込サンプル数・ストレージ・クエリの3軸で発生するため、それぞれに対応した最適化施策を組み合わせて実施してください。

CloudWatchネイティブとの使い分け（§7）は、Prometheusエコシステムの既存資産・マルチクラウド要件がある場合にAMP+AMGを採用し、AWSサービス中心ならCloudWatchを使うというフローで判断できます。AMGはその両方をデータソースとして統合する「統合ビューア」としても機能します。

本番運用チェックリスト

AMP+AMGを本番環境で安定運用するための確認事項をまとめます。

設計フェーズ:
– [ ] ワークスペース分割方針を決定した（環境別/チーム別）
– [ ] AMGの認証方式を選定した（SAML直接統合 or IAM Identity Center）
– [ ] CloudWatchとAMPの収集対象を明確に分離した
– [ ] IRSAの設計を完了した（EKS使用の場合）
– [ ] アクティブシリーズ上限の見積もりと上限引き上げ申請の要否を判断した

実装フェーズ:
– [ ] AMPワークスペースを環境別に作成し、IAMポリシーで最小権限を設定した
– [ ] remote_writeのqueue_configをチューニングした
– [ ] metric_relabel_configsで不要なメトリクスをドロップした
– [ ] scrape_intervalをメトリクス種別ごとに設定した（デフォルト60s）
– [ ] Alertmanager設定をルーティングツリーエディタで検証後にApplyした
– [ ] SLOのRecording Rulesを定義し、バーンレートアラートを設定した

運用フェーズ:
– [ ] CloudWatch ActiveSeriesアラームを設定した（上限の80%でアラート）
– [ ] CloudWatch ThrottledSamplesアラームを設定した（0超えで即時アラート）
– [ ] AMGのアクティブユーザーを月次で棚卸しする運用ルールを定めた
– [ ] AMGワークスペースのバックアップ方針（ダッシュボードJSONのgit管理）を定めた
– [ ] Alertmanagerルーティング設定の変更をstagingで必ず検証するフローを整備した

関連記事・シリーズ構成

本記事と合わせて読むことで、AWS可観測性スタックの全体像を把握できます。