Amazon Managed Grafana

解決する課題

メトリクスやログは、CloudWatch、Prometheus、各種データベース、外部SaaSなど複数の場所に散らばりがちです。これらを一枚のダッシュボードに束ねて可視化したいときの定番がオープンソースのGrafanaですが、自前で立てるとサーバーの構築・冗長化・バージョンアップ・プラグイン管理・認証連携といった運用が重荷になります。Amazon Managed Grafanaは：

• Grafanaのサーバー運用をAWSが肩代わりし、利用者は可視化に集中できる
• 閲覧者やダッシュボードが増えても基盤側がスケールと可用性を担う
• 認証や暗号化、ネットワーク接続といった運用の作り込みをマネージドで提供する

複数システムの状態を一画面で俯瞰したい運用ダッシュボード、Prometheusで集めたコンテナ／Kubernetesの指標の可視化、部門横断のモニタリング共有などに向きます。可視化（Grafana）の部分を担うサービスであり、メトリクスやログを生み出す監視そのものはCloudWatchなどのデータソース側が担います。

主要概念と用語

• ワークスペース: Grafanaの論理的な単位。1つのワークスペースが1つのGrafana環境に相当し、独自のURLを持つ
• データソース: ダッシュボードが参照する元データの接続先。CloudWatch、Amazon Managed Service for Prometheus、OpenSearch、各種データベース、外部サービスなどを登録する
• ダッシュボード: グラフやパネルを並べた可視化の成果物。複数のデータソースを混在させられる
• パネル: 折れ線・棒グラフ・ゲージ・表など、ダッシュボード内の個々の可視化要素
• アラート（Grafanaアラート）: パネルのしきい値を監視し、通知先へ知らせる仕組み
• ロール（AdminとEditorとViewer）: 管理・編集・閲覧の権限区分。利用者やグループに割り当てる
• IAM Identity Center連携: 利用者の認証とロール割り当てを一元管理するためのシングルサインオン連携

仕様・制限・クォータ

• Grafanaのワークスペース単位で環境を分離して運用する
• 認証はIAM Identity Centerやサードパーティのシングルサインオン（SAML連携）と統合できる
• データソースはCloudWatchやマネージドPrometheus、OpenSearchなどAWSサービスに加え、外部の多様なソースに対応する
• 1ワークスペースに登録できるデータソース数や、ダッシュボード数、APIキー数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• 利用できるGrafanaのメジャーバージョンはAWS側が提供する範囲に従い、アップグレードもマネージドで行える

内部の仕組み

利用者はワークスペースを作成すると、AWSが管理するGrafanaサーバー群が裏側で割り当てられます。サーバーの構築・パッチ・スケール・可用性確保はマネージドで行われ、利用者はダッシュボードとデータソースの設定に集中します。

ダッシュボードを開くと、Grafanaは登録済みのデータソースに対してその場で問い合わせを行い、返ってきた時系列データやログをパネルに描画します。Grafana自身は基本的にデータを保持せず、各データソースが真実の情報源になります。そのため表示の鮮度や応答速度は、接続先データソースの性能と保持状況に依存します。

AWSサービスのデータソースに接続する際は、ワークスペースに割り当てたIAMの権限を用いてアクセスします。VPC内のデータソースへは、プライベートなネットワーク接続を構成して到達させることもできます。

設計パターン / ベストプラクティス

• データソースの集約: CloudWatchやマネージドPrometheusなど複数ソースを1ワークスペースに登録し、システム全体を1画面で俯瞰する
• ロール分担: 管理者はAdmin、ダッシュボード作成者はEditor、見るだけの利用者はViewerに分け、最小権限で運用する
• シングルサインオン連携: IAM Identity Centerや既存のIDプロバイダと連携し、利用者ごとに個別パスワードを持たせない
• アラートの活用: 重要パネルにGrafanaアラートを設定し、しきい値超えを通知先へ自動連携する
• 環境分離: 本番と検証など用途ごとにワークスペースを分け、誤操作や情報の混在を防ぐ
• ダッシュボードのコード管理: ダッシュボード定義を再利用・バージョン管理し、環境間で一貫した可視化を保つ

運用・監視

• ワークスペースやデータソース接続の状態を確認し、接続失敗時に検知・是正できるようにする
• 利用者・グループへのロール割り当てを定期的に棚卸しし、不要な権限を整理する
• Grafanaのバージョンアップはマネージドで行えるため、提供範囲に追従して計画的に適用する
• API操作はCloudTrailで監査でき、誰がワークスペースやデータソースを変更したかを追跡できる
• ダッシュボードやデータソースはAPIで管理でき、開発・本番間の構成移行を仕組み化できる

コスト

• 課金は主にアクティブな利用者（編集者・閲覧者）の人数を単位とする考え方で、利用ロールによって扱いが異なる
• ダッシュボードや基盤サーバーを自前で常時稼働させる場合と異なり、サーバーの待機コストを意識せずに済む
• データソース側（CloudWatchのAPI呼び出しやマネージドPrometheusのクエリなど）に別途の料金が発生する点に注意する
• 使わない利用者や不要なワークスペースを整理することが、基本の節約策になる

セキュリティ

• 利用者の認証はIAM Identity Centerやサードパーティのシングルサインオンと統合でき、個別認証情報の乱立を避けられる
• アクセス制御はAdminとEditorとViewerのロールで行い、利用者やグループに最小権限を割り当てる
• AWSサービスのデータソースへのアクセスは、ワークスペースに紐づくIAM権限の範囲に制限される
• 通信はTLSで保護され、保存されるデータは暗号化される構成がある
• VPC内のデータソースへは、プライベート接続を構成して公開せずに到達できる
• API操作はCloudTrailで記録され、監査に利用できる

Well-Architected の観点

• 運用上の優秀性: 可視化基盤の構築・冗長化・バージョンアップをマネージド化し、運用者はダッシュボードと観測性の設計に集中できる
• セキュリティ: シングルサインオン連携と最小権限ロール、IAMによるデータソースアクセス制限、監査ログの活用
• 信頼性: 基盤の可用性とスケールをAWSが担い、利用者やダッシュボード増加に追従する
• コスト最適化: サーバー待機コストを持たず、利用者と接続先クエリの両面を見直して支出を抑えられる

試験で問われるポイント

関連サービス・比較

同じ監視カテゴリの Amazon CloudWatch とよく対比されます。CloudWatchはメトリクス・ログ・アラームを生み出し蓄積する監視の中核で、Managed Grafanaはそれらを含む複数ソースを束ねて可視化する層です。両者は対立せず、CloudWatchをデータソースにManaged Grafanaで見せる、という形で連携するのが一般的です。

ハンズオン / CLI例

# Grafanaワークスペースを作成する（認証はIAM Identity Centerを指定）
aws grafana create-workspace \
  --workspace-name central-observability \
  --account-access-type CURRENT_ACCOUNT \
  --authentication-providers AWS_SSO \
  --permission-type SERVICE_MANAGED \
  --workspace-data-sources CLOUDWATCH PROMETHEUS

# 作成したワークスペースの状態とエンドポイントを確認する
aws grafana describe-workspace \
  --workspace-id g-0123456789 \
  --query "workspace.{Status:status,Endpoint:endpoint,Version:grafanaVersion}"

# アカウント内のワークスペース一覧を取得する
aws grafana list-workspaces \
  --query "workspaces[].{Name:name,Id:id,Status:status}"