---
title: "Amazon Managed Grafanaとは？料金・対応バージョン・作成手順とGrafana Cloudとの違い"
url: "https://www.issoh.co.jp/tech/details/4540/"
published: 2024-12-17
updated: 2026-10-16
categories: ["監視・オブザーバビリティ"]
publisher: "株式会社一創"
---

# 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のユーザーガイド](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)では、ワークスペースを「論理的に分離されたGrafanaサーバー」と説明しており、そのプロビジョニング、設定、スケーリング、保守をAWSが担います。利用者が用意するのは、ログインさせるユーザーと、データソースを読むためのIAMロールです。

2020年12月のプレビュー発表時の名称はAmazon Managed Service for Grafanaでした。2021年8月31日の[一般提供の発表](https://aws.amazon.com/blogs/aws/amazon-managed-grafana-is-now-generally-available-with-many-new-features/)以降、公式ドキュメントの表記はAmazon Managed Grafanaです。AWS料金計算ツールの項目名などに旧称が残っていますが、指しているサービスは同じです。

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

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

| 観点       | セルフホスト（OSS）            | Grafana Cloud        | Amazon Managed Grafana |
| -------- | ---------------------- | -------------------- | ---------------------- |
| 運用する人    | 自社                     | Grafana Labs         | AWS                    |
| 主な費用     | インフラ費・運用保守費（OSS利用料は無料） | プランと使用量              | ワークスペースのアクティブユーザー      |
| データの保存   | 別途用意                   | メトリクス・ログの保存込み        | 別途用意（AMP・CloudWatch等）  |
| AWSの認証連携 | IAMロール・アクセスキー等         | Grafana Assume Role等 | ワークスペースのIAMロール         |
| バージョンの選択 | 自由                     | Grafana Labsが更新      | AWSが提供する版から選ぶ          |

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

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

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

| ライセンス                | 月額（1アクティブユーザー） | できること                        |
| -------------------- | -------------- | ---------------------------- |
| Editor（Admin・Editor） | 9ドル            | ダッシュボード・アラートの作成（管理操作はロールによる） |
| Viewer               | 5ドル            | ダッシュボードとアラートの閲覧              |
| Enterprise Plugins   | 45ドルを上乗せ       | Datadog・Splunk等の商用データソース     |
| 無料トライアル              | 0ドル（90日間）      | アカウントあたり最大5ユーザー              |

ワークスペースには、管理とログインのために最低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つが毎月使うワークスペースの場合、月額は次のとおりです（公式の単価から計算した例で、税は含みません）。

| 内訳                  | 計算        | 月額    |
| ------------------- | --------- | ----- |
| Editor（人）           | 3人 × 9ドル  | 27ドル  |
| Viewer（人）           | 20人 × 5ドル | 100ドル |
| サービスアカウント（Editor権限） | 1 × 9ドル   | 9ドル   |
| 合計                  | –         | 136ドル |

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

### Grafana以外にかかる費用

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

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

Amazon Managed Grafanaでは、ワークスペースを作るときにGrafanaのバージョンを選びます。[ユーザーガイドの更新履歴](https://docs.aws.amazon.com/grafana/latest/userguide/doc-history.html)によると、2026年9月17日にバージョン13へ対応し、2026年10月1日にバージョン8のサポートを終了しました。Terraformの `aws_grafana_workspace` が受け付ける値は 9.4・10.4・12.4・13.2 です。

| バージョン | 対応した日      | 押さえる変更                      |
| ----- | ---------- | --------------------------- |
| 13.2  | 2026-09-17 | AWS IoT TwinMakerプラグインが動かない |
| 12.4  | 2026-04-02 | APIキーとAngularプラグインを削除       |
| 10.4  | 2024-05-15 | アラートの重複通知を解消                |
| 9.4   | 2023-04-28 | プラグイン管理に対応                  |
| 8     | 2021-08-31 | 2026-10-01にサポート終了           |

新しく作るなら、12.4か13.2を選びます。[ワークスペース作成の手順](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html)には、バージョン9ではGrafanaのアラートが複数回通知されるため、Grafanaでアラートを定義するなら10.4以降で作るよう書かれています。Grafana本体の各バージョンの変更点は[Grafana 12と最新版13の違い](/tech/details/8395/)で扱っています。

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

[更新の手順](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-workspace-version-update.html)によると、バージョンは上げることしかできず、下げられません。更新は途中で止められず、最大10分ほどワークスペースが読み取り専用になります。インストール済みのプラグインは一緒に更新されないので、新しい版に合わないものは個別に更新します。

[バージョン間の違い](https://docs.aws.amazon.com/grafana/latest/userguide/version-differences.html)には、旧アラート機能の削除も含まれます。旧アラート設定を残したまま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プラグインで参照していたデータソースが、専用プラグインへ自動で移されます。ダッシュボードの参照も自動で書き換わりますが、データソースをコードで管理している場合は定義との差分が出るので、更新後に見直します。

## 接続できるデータソース

[組み込みのデータソース](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-data-sources-builtin.html)は追加料金なしで使えます（表のAMPはAmazon Managed Service for Prometheusの略）。AWSのサービスは、ワークスペースのIAMロールの権限で読むため、アクセスキーを登録する必要がありません。

| 区分             | 主なデータソース                                      |
| -------------- | --------------------------------------------- |
| AWS（メトリクス・ログ）  | CloudWatch、AMP、OpenSearch Service             |
| AWS（トレース・分析）   | X-Ray、Athena、Redshift、Timestream              |
| AWS（IoT）       | IoT SiteWise、IoT TwinMaker                    |
| OSS            | Prometheus、Loki、Tempo、Jaeger、InfluxDB         |
| 他クラウド          | Azure Monitor、Google Cloud Monitoring         |
| データベース         | MySQL、PostgreSQL、Microsoft SQL Server         |
| Enterprise（有料） | Datadog、Splunk、New Relic、Dynatrace、Snowflake等 |

ログをLokiに、トレースをTempoに置く構成もそのまま読めます。Lokiの仕組みと導入は[Grafana Lokiの導入手順](/tech/details/9570/)、OpenTelemetryで集めた3種類のデータをGrafanaにつなぐ構成は[Grafana OpenTelemetry連携の構成](/tech/details/16566/)で説明しています。[Enterpriseのデータソース](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-data-sources-enterprise.html)は、バージョン9以降のワークスペースでは既定でインストールされないため、Enterprise Pluginsを有効にしたあと、プラグインを個別に入れます。

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

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

その場合は、[VPC接続](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-configure-vpc.html)を設定します。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を使う場合](https://docs.aws.amazon.com/grafana/latest/userguide/authentication-in-AMG-SSO.html)は、アカウントでAWS Organizationsが有効になっている必要があります。未設定なら、最初のワークスペースを作るときにAmazon Managed Grafanaが有効化を代行します。

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

### Admin・Editor・Viewerの操作権限

| 操作                 | Admin | Editor  | Viewer  |
| ------------------ | ----- | ------- | ------- |
| ダッシュボードの閲覧         | ○     | ○       | ○       |
| ダッシュボード・アラートルールの編集 | ○     | ○       | ×       |
| Explore（その場のクエリ）   | ○     | ○       | ×       |
| 通知チャネルの編集          | ○     | ○       | ×       |
| データソースの追加・削除       | ○     | ×       | ×       |
| チーム管理（基本ロール）       | ○     | ×       | ×       |
| フォルダの編集・削除         | ○     | 個別権限による | 個別権限による |

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

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

ワークスペースのURLは、既定ではインターネットから到達できます。[ネットワークアクセス制御](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-configure-nac.html)を設定すると、マネージドプレフィックスリストに入れた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が推奨する](https://docs.aws.amazon.com/grafana/latest/userguide/cross-service-confused-deputy-prevention.html) `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のドキュメント](https://github.com/hashicorp/terraform-provider-aws/blob/main/website/docs/r/grafana%5Fworkspace%5Fservice%5Faccount%5Ftoken.html.markdown)のとおり、サービスアカウントとトークンは属性を変えると作り直しになります。トークンの値（`key`）はstateに残るので、stateを置く場所の権限を絞っておきます。

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

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

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

[サービスクォータ](https://docs.aws.amazon.com/grafana/latest/userguide/AMG%5Fquotas.html)のうち、設計に効くものは次のとおりです。

| 項目                            | 既定の上限            | 引き上げ |
| ----------------------------- | ---------------- | ---- |
| ワークスペース数                      | 1リージョンあたり5       | 可    |
| アラート（Grafanaアラートはルールのインスタンス数） | 1ワークスペースあたり100   | 不可   |
| ダッシュボード                       | 1ワークスペースあたり2,000 | 不可   |
| データソース                        | 1ワークスペースあたり2,000 | 不可   |
| ユーザー                          | 登録10,000・同時500   | 不可   |
| サービスアカウント                     | 1ワークスペースあたり100   | 不可   |

最も効くのはアラートの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との違い](/tech/details/6476/)も見る。
- **閲覧者が多く、ほとんどが時々しか見ない**：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](https://github.com/grafana/grafana/blob/v8.0.0/LICENSE)で、7.5まではApache License 2.0でした。AGPLv3第13条では、改変版をネットワーク越しに利用させる場合、その利用者全員に、改変部分だけでなく当該版の「対応するソース」を無償で入手する機会を提供することを求めています。社内利用か社外提供かだけでは義務の有無は決まりません。

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

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

## 関連記事

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

---

出典: [Amazon Managed Grafanaとは？料金・対応バージョン・作成手順とGrafana Cloudとの違い](<https://www.issoh.co.jp/tech/details/4540/>)（株式会社一創）