Amazon Managed Grafanaとは？料金・対応バージョン・作成手順とGrafana Cloudとの違い

Amazon Managed Grafanaは、オープンソースの可視化ツールGrafanaを、AWSがサーバーごと運用するマネージドサービスです。利用者は「ワークスペース」と呼ばれるGrafanaの環境を作り、認証・アクセス権限とデータソースを設定することで、CloudWatchやAmazon Managed Service for Prometheusのメトリクス、ログ、トレースを1つのダッシュボードで見られます。

この記事では、誤解の多い料金（ワークスペースごとのアクティブユーザー課金）の計算方法、2026年10月時点で選べるGrafanaのバージョンと更新時の注意、ワークスペースをAWS CLIとTerraformで作る手順を、AWSの公式ドキュメントに沿って説明します。読み方は「グラファナ」です。

まとめ：Amazon Managed Grafanaの要点

• 何か：AWSがGrafanaサーバーの構築・パッチ適用・スケーリングを引き受けるサービス。2021年8月31日に一般提供を開始し、Grafana Labsと共同で開発された。
• 料金：ワークスペースごと・月ごとのアクティブユーザー課金。Editor／Administratorは月9ドル、Viewerは月5ドル。誰もログインしない月も、ワークスペースごとに最低1 Editor分（9ドル）がかかる。
• 見落としやすい課金：サービスアカウントも1ユーザーとして数える（Editor権限なら9ドル）。CloudWatchメトリクスの取得には GetMetricData の料金が、ログの検索にはCloudWatch Logs Insightsのクエリ料金などが別にかかる。
• バージョン：作成時に選べるのは9.4・10.4・12.4・13.2。バージョン8は2026年10月1日にサポートを終えた。更新は元に戻せず、12以降ではAPIキーとAngularプラグインが動かない。
• リージョン：東京（ap-northeast-1）では使えるが、大阪（ap-northeast-3）では提供されていない。ワークスペースは1リージョンあたり既定5個まで。
• 向き不向き：監視対象の大半がAWSにあり、Grafanaの運用を手放したい組織に向く。Grafanaアラートのインスタンス数が1ワークスペースあたり100件を超える運用には向かない。

Amazon Managed Grafanaとは｜AWSが運用するGrafanaのワークスペース

Grafanaは、複数のデータソースに問い合わせた結果を、グラフや表、ゲージを並べたダッシュボードに表示するオープンソースの可視化ツールです。データを自分では貯めず、PrometheusやCloudWatchなどの保存先へその都度クエリを投げて描画します。

Amazon Managed Grafanaは、このGrafanaをAWSが動かすサービスです。AWSのユーザーガイドでは、ワークスペースを「論理的に分離されたGrafanaサーバー」と説明しており、そのプロビジョニング、設定、スケーリング、保守をAWSが担います。利用者が用意するのは、ログインさせるユーザーと、データソースを読むためのIAMロールです。

2020年12月のプレビュー発表時の名称はAmazon Managed Service for Grafanaでした。2021年8月31日の一般提供の発表以降、公式ドキュメントの表記はAmazon Managed Grafanaです。AWS料金計算ツールの項目名などに旧称が残っていますが、指しているサービスは同じです。

セルフホストのGrafana・Grafana Cloudとの違い

同じGrafanaでも、誰がサーバーを運用し、何に対して課金されるかで3つに分かれます。

大きな違いは、Amazon Managed Grafanaが可視化だけを担い、データの保存先を持たないことです。メトリクスはPrometheusでの監視構築と同様にどこかへ貯める必要があり、AWSではAmazon Managed Service for PrometheusやCloudWatchがその役を担います。Grafana Cloudはメトリクス、ログ、トレースの保存基盤まで一体で提供するため、比べるときは保存先の費用まで含めて見積もります。

料金｜アクティブユーザー課金の計算方法

Amazon Managed Grafanaの料金は、ワークスペースごと・月ごとに、その月にアクティブだったユーザーの数で決まります。アクティブユーザーとは、請求月の間にワークスペースへログインしたか、APIリクエストを1回でも送ったユーザーです。権限を付与しただけで一度も使わなかったユーザーは課金されません。前払いと長期契約は不要です。ただし後述のとおり、ワークスペースごとに最低1 Editor分（月9ドル）がかかります。

ワークスペースには、管理とログインのために最低1つのEditorライセンスが必要です。公式の料金例では、その月に誰もログインしなかったワークスペースにも1 Editor分の9ドルが計上されています。検証用に作ったワークスペースは、使い終わったら削除しないと毎月9ドルずつかかり続けます。

サービスアカウント・APIユーザーの課金単位

料金ページによると、サービスアカウントはGrafanaのユーザーと同じ扱いで、Admin／Editor権限なら月9ドル、Viewer権限なら月5ドルです。Terraformでダッシュボードを管理する、CIからアノテーションを書き込む、といった自動化でサービスアカウントから月内にAPIリクエストを送ると、人間のユーザーとは別にアクティブユーザーとして数えられます。

用途ごとにサービスアカウントを分けると、その月にAPIリクエストを送ったアカウントの数が課金対象になります。読み取りだけの連携（外部ツールからダッシュボードの画像を取るなど）はViewer権限で作り、書き込みが必要な自動化は、同じ権限範囲と管理責任を共有するものに限ってEditor権限のサービスアカウントを共用すると、月額を抑えられます。

料金の計算例

Editor権限の運用担当3人、閲覧だけの開発者20人、Terraform用のEditor権限サービスアカウント1つが毎月使うワークスペースの場合、月額は次のとおりです（公式の単価から計算した例で、税は含みません）。

同じ構成でEnterprise Pluginsを有効にすると、アクティブな24ユーザー分の45ドル（1,080ドル）が上乗せされ、月1,216ドルになります。Enterprise Pluginsは使う人数ではなくアクティブユーザー全員に上乗せされるため、商用データソースを見たい人が数人しかいないなら、その人たちだけのワークスペースを分ける方が安くなります。

Grafana以外にかかる費用

ライセンス料はGrafanaを使う費用だけです。表示するデータの側にも料金がかかります。CloudWatchデータソースの説明によると、Grafanaはメトリクスの一覧取得に ListMetrics、データの取得に GetMetricData を呼び、GetMetricData は課金対象です。自動更新の間隔を短くしたダッシュボードを大勢が開きっぱなしにすると、Grafanaのライセンス料より CloudWatch API の料金が大きくなることがあります。メトリクスの保存にAmazon Managed Service for Prometheusを使う場合も、取り込みとクエリの料金が別にかかります。

対応するGrafanaのバージョンと更新時の注意

Amazon Managed Grafanaでは、ワークスペースを作るときにGrafanaのバージョンを選びます。ユーザーガイドの更新履歴によると、2026年9月17日にバージョン13へ対応し、2026年10月1日にバージョン8のサポートを終了しました。Terraformの aws_grafana_workspace が受け付ける値は 9.4・10.4・12.4・13.2 です。

新しく作るなら、12.4か13.2を選びます。ワークスペース作成の手順には、バージョン9ではGrafanaのアラートが複数回通知されるため、Grafanaでアラートを定義するなら10.4以降で作るよう書かれています。Grafana本体の各バージョンの変更点はGrafana 12と最新版13の違いで扱っています。

バージョン更新前の互換性確認と不可逆の変更

更新の手順によると、バージョンは上げることしかできず、下げられません。更新は途中で止められず、最大10分ほどワークスペースが読み取り専用になります。インストール済みのプラグインは一緒に更新されないので、新しい版に合わないものは個別に更新します。

バージョン間の違いには、旧アラート機能の削除も含まれます。旧アラート設定を残したまま12へ更新するとワークスペースの起動に失敗するため、更新前にGrafana Alertingへの移行が必要です。このほか、次の互換性変更も確認します。

• 12でAPIキーが使えなくなる：既存のAPIキーは機能しなくなる。更新前にサービスアカウントを作り、自動化のトークンを差し替える。
• 12でAngularのプラグインが読み込まれなくなる：Angular製のパネルを使うダッシュボードはエラーになる。React製の代替へ移してから更新する。
• 13でTwinMakerのプラグインが表示されない：13はReact 19に上がり、grafana-iot-twinmaker-app のパネルが描画されない。TwinMakerを使うワークスペースは12.4に留める。
• 13でデータソースを数値IDで指すAPIが既定で無効：数値の id でデータソースを指定している自動化は、uid に書き換える。

12への更新では、Amazon Managed Service for Prometheusを汎用のPrometheusプラグインで参照していたデータソースが、専用プラグインへ自動で移されます。ダッシュボードの参照も自動で書き換わりますが、データソースをコードで管理している場合は定義との差分が出るので、更新後に見直します。

接続できるデータソース

組み込みのデータソースは追加料金なしで使えます（表のAMPはAmazon Managed Service for Prometheusの略）。AWSのサービスは、ワークスペースのIAMロールの権限で読むため、アクセスキーを登録する必要がありません。

ログをLokiに、トレースをTempoに置く構成もそのまま読めます。Lokiの仕組みと導入はGrafana Lokiの導入手順、OpenTelemetryで集めた3種類のデータをGrafanaにつなぐ構成はGrafana OpenTelemetry連携の構成で説明しています。Enterpriseのデータソースは、バージョン9以降のワークスペースでは既定でインストールされないため、Enterprise Pluginsを有効にしたあと、プラグインを個別に入れます。

VPC内のデータベースへ接続する条件

ワークスペースからデータソースへの通信は、既定ではインターネットを通ります。同じリージョンのCloudWatch、Amazon Managed Service for Prometheus、X-RayへはAWS PrivateLink経由で接続されますが、プライベートサブネットにあるRDSやセルフホストのPrometheusは、そのままでは読めません。

その場合は、VPC接続を設定します。2つ以上のアベイラビリティーゾーンにプライベートサブネットが1つずつ必要で、各サブネットに15個以上の空きIPアドレスを残しておく必要があります。空きIPが15を下回ると、設定変更やセキュリティ更新ができなくなる可能性があり、まれにワークスペース全体が使えなくなることもあります。VPC接続を設定すると、CloudWatchへの通信を含むすべての通信がVPC経由になります。そのため、既存のワークスペースに後から接続するときは、先にVPCからCloudWatch等へ届く経路（VPCエンドポイントかNATゲートウェイ）を用意しておきます。

認証とアクセス制御

Amazon Managed Grafanaでは、ログインできる人をIDプロバイダーで、ワークスペースが読めるデータをIAMロールで管理します。Grafanaの画面からユーザーを追加することはできません。

IAM Identity Center・SAML 2.0の選択基準

ユーザー認証は、AWS IAM Identity CenterとSAML 2.0対応のIdP（Microsoft Entra ID、Okta等）のどちらか、または両方を使います。IAM Identity Centerを使う場合は、アカウントでAWS Organizationsが有効になっている必要があります。未設定なら、最初のワークスペースを作るときにAmazon Managed Grafanaが有効化を代行します。

2つの方式の違いは、ロールを割り当てる場所です。IAM Identity Centerでは、Amazon Managed GrafanaのコンソールかAPIでユーザーやグループにAdmin／Editor／Viewerを割り当てます。SAMLでは、ロールはアサーションの属性だけで決まるため、IdP側のグループ設計がそのまま権限になります。SAMLのログインの有効期間は既定1日、最長30日です。ログイン自体をIAM Identity CenterかIdPに任せる仕組みなので、多要素認証（MFA）もそちらの設定で強制します。社内のIdPがOktaやEntra IDで、AWSのIAM Identity Centerを入れていない組織はSAMLを選びます。AWS CLIでSSO認証を使う設定はAWS CLIのインストールと運用で扱っています。

Admin・Editor・Viewerの操作権限

ViewerはExploreを使えません。障害時にExplore画面でログを検索させたい開発者には、月9ドルのEditorを割り当てます。ただし、Viewerも既定ではデータソースへ任意のクエリを送れるため、閲覧可能なデータを絞るにはデータソース権限を別途設定します。逆に、決まったダッシュボードを見るだけの人をEditorにしておくと、1人あたり月4ドルずつ余計にかかります。

ネットワークアクセス制御による接続元の制限

ワークスペースのURLは、既定ではインターネットから到達できます。ネットワークアクセス制御を設定すると、マネージドプレフィックスリストに入れたIPアドレスか、指定したVPCエンドポイント（東京ならサービス名は com.amazonaws.ap-northeast-1.grafana-workspace）からの接続だけを許可できます。

注意点は、プレフィックスリストに 10.0.0.0/16 のようなプライベートIPアドレスの範囲を書いても無視されることです。プライベートIPアドレスで接続元を制限したい場合はVPCエンドポイントを使います。社内ネットワークの固定パブリックIPアドレスをプレフィックスリストで許可する方法もあります。VPCエンドポイントとプレフィックスリストは、1ワークスペースにそれぞれ5つまで指定できます。

ワークスペースの作成手順｜コンソール・AWS CLI・Terraform

手順そのものは単純ですが、IAMロールの扱いが作成方法によって違います。コンソールでは、データソースを読むロールをAmazon Managed Grafanaに作らせる「サービスマネージド」を選べます。AWS CLIとCloudFormationでは、自分で作ったロールを渡す「カスタマーマネージド」しか使えません。

コンソールで作成する手順

1. Amazon Managed Grafanaのコンソールで「ワークスペースを作成」を選び、名前を入れる。
2. Grafanaのバージョン（12.4か13.2）を選ぶ。
3. 認証方式にIAM Identity CenterかSAMLを選ぶ。
4. 権限タイプで「サービスマネージド」を選び、使うデータソース（CloudWatch等）にチェックを入れる。AWS Organizationsのメンバーアカウントでは、サービスマネージドを選ぶために委任管理者の登録が必要になる。条件を満たさない場合は「カスタマーマネージド」を選び、事前に作成したIAMロールを指定する。
5. 状態がACTIVEになったら、IAM Identity Centerではユーザーかグループを割り当て、管理担当者を少なくとも1人Adminにする。SAMLではIdPとの連携設定、メタデータの登録、ロール属性とAdminロール値の設定を完了する。
6. ワークスペースのURLからログインし、データソースを追加してダッシュボードを作る。

AWS CLIによるワークスペース作成

aws grafana create-workspace の必須の引数は、アカウントの範囲（account-access-type）、権限タイプ（permission-type）、認証方式（authentication-providers）の3つです。CLIでは権限タイプに CUSTOMER_MANAGED を指定し、信頼ポリシーで grafana.amazonaws.com を許可したロールのARNを渡します。

# 東京リージョンにGrafana 12.4のワークスペースを作る（ロールは事前に作成）
aws grafana create-workspace \
  --workspace-name ops-dashboard \
  --account-access-type CURRENT_ACCOUNT \
  --authentication-providers AWS_SSO \
  --permission-type CUSTOMER_MANAGED \
  --workspace-role-arn arn:aws:iam::123456789012:role/amg-workspace-role \
  --grafana-version 12.4 \
  --region ap-northeast-1

# 自動化用のサービスアカウント（Editor権限＝月9ドルの課金対象）とトークン
aws grafana create-workspace-service-account \
  --workspace-id g-0123456789 --name ci-editor --grafana-role EDITOR \
  --region ap-northeast-1
aws grafana create-workspace-service-account-token \
  --workspace-id g-0123456789 --service-account-id 2 \
  --name ci-token --seconds-to-live 2592000 \
  --region ap-northeast-1

コード内のワークスペースID（g-で始まる値）とサービスアカウントIDは例示値なので、各作成コマンドの戻り値に置き換えます。ワークスペースの作成は非同期なので、aws grafana describe-workspace で状態がACTIVEになってからサービスアカウントを作ります。

サービスアカウントのトークンの有効期間は最長2,592,000秒（30日）です。AWS CLI 1.46.1（botocore 1.43.62）のサービス定義で、上限が2592000、下限が1であることを確認しました。期限が切れる前に新しいトークンを発行してCIのシークレットを更新し、切り替え後に旧トークンを削除します。期限切れのトークンも、削除するまではワークスペースあたり100個の上限に数えられます。

Terraformによるワークスペース作成

Terraformでは、ロール、ワークスペース、サービスアカウント、トークンを1つの設定にまとめられます。ロールの信頼ポリシーには、AWSが推奨する aws:SourceAccount と aws:SourceArn の条件を入れ、自分のアカウントのワークスペースからしか引き受けられないようにしています。ワークスペースIDはロールより後に決まるため、ARNの末尾はワイルドカードにしました。この例ではIAM Identity Centerを事前に有効化し、作成後に利用者へのワークスペース権限の割り当てとCloudWatchデータソースの追加を別途行います。次の設定は、Terraform 1.16.6とAWS provider 6.69.1で terraform validate と terraform fmt -check を通しました（applyによるワークスペースの作成は行っていません）。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.69"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

data "aws_caller_identity" "current" {}

# ワークスペースが引き受けるロール（信頼先は grafana.amazonaws.com）
# 混乱した代理の防止のため、自アカウントのワークスペースからの引き受けに限定する
resource "aws_iam_role" "grafana" {
  name = "amg-workspace-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "grafana.amazonaws.com" }
      Action    = "sts:AssumeRole"
      Condition = {
        StringEquals = {
          "aws:SourceAccount" = data.aws_caller_identity.current.account_id
        }
        ArnLike = {
          "aws:SourceArn" = "arn:aws:grafana:ap-northeast-1:${data.aws_caller_identity.current.account_id}:/workspaces/*"
        }
      }
    }]
  })
}

# CloudWatch のメトリクスとログを読むだけの権限
resource "aws_iam_role_policy" "cloudwatch_read" {
  name = "cloudwatch-read"
  role = aws_iam_role.grafana.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "cloudwatch:ListMetrics",
        "cloudwatch:GetMetricData",
        "cloudwatch:DescribeAlarms",
        "logs:DescribeLogGroups",
        "logs:GetLogGroupFields",
        "logs:StartQuery",
        "logs:StopQuery",
        "logs:GetQueryResults",
        "ec2:DescribeRegions",
        "tag:GetResources"
      ]
      Resource = "*"
    }]
  })
}

resource "aws_grafana_workspace" "ops" {
  name                     = "ops-dashboard"
  account_access_type      = "CURRENT_ACCOUNT"
  authentication_providers = ["AWS_SSO"]
  permission_type          = "CUSTOMER_MANAGED"
  role_arn                 = aws_iam_role.grafana.arn
  grafana_version          = "12.4"
  # CloudWatchデータソースはワークスペース作成後に別途設定
}

# Terraform や CI から Grafana HTTP API を叩くためのサービスアカウント
resource "aws_grafana_workspace_service_account" "ci" {
  name         = "ci-editor"
  grafana_role = "EDITOR"
  workspace_id = aws_grafana_workspace.ops.id
}

resource "aws_grafana_workspace_service_account_token" "ci" {
  name               = "ci-token"
  service_account_id = aws_grafana_workspace_service_account.ci.service_account_id
  seconds_to_live    = 2592000 # 上限の30日
  workspace_id       = aws_grafana_workspace.ops.id
}

output "grafana_url" {
  value = "https://${aws_grafana_workspace.ops.endpoint}"
}

seconds_to_live を2592001にすると、validateの段階で value must be between 1 and 2592000 というエラーになりました。providerのドキュメントのとおり、サービスアカウントとトークンは属性を変えると作り直しになります。トークンの値（key）はstateに残るので、stateを置く場所の権限を絞っておきます。

AWSの監視基盤をCloudWatchやADOTと組み合わせて設計する全体像はAWSオブザーバビリティの実装にまとめています。ワークスペースやIAMロールの設計を含めたAWS環境の構築を外部に任せたい場合は、AWS・Google Cloud・Azureのインフラ構築支援でも相談を受けています。

作成前に確認する制約｜リージョンとクォータ

対応リージョンのうち、日本は東京（ap-northeast-1）だけで、大阪（ap-northeast-3）には提供されていません。東京は一般提供の開始時から使えます。大阪だけで完結させる構成（災害対策の拠点を大阪に置く等）では、Amazon Managed Grafanaは大阪側には配置できません。東京のワークスペースから大阪のデータソースを読む構成は可能ですが、東京への依存は残ります。東京の障害時にも大阪だけで監視を続ける要件なら、大阪で稼働する別の可視化基盤を用意します。

サービスクォータのうち、設計に効くものは次のとおりです。

最も効くのはアラートの100件です。Grafanaのアラートでは1つのルールがラベルごとに複数のインスタンスを作り、インスタンスの数が上限に数えられます。「インスタンスごとのCPU使用率」のようなルールを1本書くだけで、EC2が100台あれば上限に達します。

Amazon Managed Grafanaを選ぶ場面・避ける場面

監視対象の大半がAWSにあり、Grafanaサーバーの構築・保守の負担を減らしたいなら、Amazon Managed Grafanaを選びます。ただし、バージョン更新の判断と操作、互換性の確認は利用者が行います。IAMロールでCloudWatchやAmazon Managed Service for Prometheusを読めるため、アクセスキーの管理がなくなります。IAM Identity Centerで社員のログインを一元管理している組織では、既存のユーザーとグループを使ってワークスペースへのアクセスを管理できます。

次の条件に当てはまる場合は、採用を見送るか、使い方を限定します。

• アラートをGrafanaに集約したい：アラートのインスタンスは1ワークスペースあたり100が上限で、引き上げられない。大量のアラートはCloudWatchアラームかAmazon Managed Service for PrometheusのAlertmanagerで出し、Grafanaは表示に使う。
• 監視対象がAWS以外に広がっている：データの保存先を自分で用意する必要がある。保存まで任せたいならGrafana Cloud、他のSaaS監視と比べるならDatadogの料金とCloudWatchとの違いも見る。
• 閲覧者が多く、ほとんどが時々しか見ない：1回でもログインした月は5ドルかかる。月に1度だけ見る人が数百人いるなら、CloudWatchダッシュボードの共有を比較候補にする。表示するデータと共有の要件を満たせるかを確かめ、ダッシュボード料金・クエリ料金・移行費用を含めて比べる。
• AWS IoT TwinMakerのパネルを使っている：バージョン13では表示されないため、12.4で止まる。12.4もいずれ更新の対象になるので、別の表示方法へ移す計画が要る。

よくある質問

Amazon Managed Grafanaの読み方は？

「アマゾン マネージド グラファナ」と読みます。Grafanaは「グラファナ」です。2020年のプレビュー時はAmazon Managed Service for Grafanaという名前で発表され、現在の公式表記はAmazon Managed Grafanaです。

Amazon Managed Grafanaは無料で使えますか？

90日間の無料トライアルがあり、アカウントあたり最大5ユーザーまで無料です。6人目以降と、トライアル終了後は、Editor月9ドル・Viewer月5ドルのアクティブユーザー課金になります。恒久的な無料枠はありません。

最低いくらかかりますか？

トライアル終了後は、ワークスペース1つにつき月9ドルが最低額です。各ワークスペースには最低1つのEditorライセンスが必要で、誰もログインしない月にも9ドルが計上されます。サービスアカウントも、月内にAPIリクエストを送った場合はアクティブユーザーとして数えられます。

Grafanaは商用利用できますか？ライセンスは？

Amazon Managed Grafanaは、AWSの利用規約のもとで商用利用できます。セルフホストのGrafanaは、バージョン8.0.0（2021年6月8日公開）からAGPLv3で、7.5まではApache License 2.0でした。AGPLv3第13条では、改変版をネットワーク越しに利用させる場合、その利用者全員に、改変部分だけでなく当該版の「対応するソース」を無償で入手する機会を提供することを求めています。社内利用か社外提供かだけでは義務の有無は決まりません。

大阪リージョンで使えますか？

2026年10月時点では使えません。日本で使えるのは東京（ap-northeast-1）だけです。大阪のCloudWatchのデータは、東京のワークスペースからデータソースのリージョンを指定して読めます。

関連記事

• Grafana 12とは？最新版13との違い・v11からの変更点とバージョン確認方法
• Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り
• Grafana Lokiとは？仕組み・Alloyでの導入手順とLogQLの書き方【v3.7】
• Grafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合まで
• AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】