Azure Managed Grafana Essential SKU を使っているチームが今すぐ決めるべきことは、単純に「Standard SKUへ上げるか」ではありません。2026年4月14日時点の Azure Updates では、Azure Managed Grafana Essential SKU は 2027年3月30日に退役予定とされ、利用中の環境は Azure Managed Grafana Standard SKU または Azure Monitor dashboards with Grafana への移行が推奨されています。(Microsoft Azure)
結論から言うと、本番監視・アラート・外部データソース・プライベートネットワーク・SLAを重視するなら Standard SKU、Azure Monitor や Managed Prometheus 中心の可視化で、Grafana運用コストを抑えたいなら Azure Monitor dashboards with Grafana が有力です。この記事では、Observabilityチームやプラットフォーム管理者が、退役通知を「移行作業リスト」ではなく「意思決定ガイド」として使えるよう、判断基準、比較表、移行手順、失敗しやすいポイントを整理します。
Azure Managed Grafana Essential SKU の退役で何が変わるのか
Azure Managed Grafana Essential SKU は、もともと評価・テスト用途を想定したプレビュー系のサービス階層です。Microsoft Learn では、Essential は Standard と Azure Monitor dashboards with Grafana に置き換えられる方向であり、新規ワークスペースは Standard を使い、既存の Essential は Standard へアップグレードするか Azure Monitor dashboards with Grafana へ移行するよう案内されています。(Microsoft Learn)
重要なのは、退役日までに「ダッシュボードをどこへ移すか」を決めるだけでなく、監視運用の責任範囲をどちらのサービスに寄せるかを決めることです。
たとえば、同じ Grafana ダッシュボードでも、以下のように性格が違います。
| ダッシュボードの種類 | 典型的な用途 | 移行先の考え方 |
|---|---|---|
| NOC/SRE向け本番監視 | 障害検知、オンコール、SLO確認 | Standard SKUを優先 |
| AKSやAzureリソースの可視化 | CPU、メモリ、Pod、ログ、Prometheusメトリクス確認 | Azure Monitor dashboards with Grafanaも候補 |
| 経営・運用報告用 | 定期レポート、PDF配布、週次レビュー | Standard SKUを優先 |
| 検証・開発用 | 一時的なメトリクス確認、PoC | Azure Monitor dashboards with Grafanaを優先しやすい |
| 外部SaaSや他クラウド連携 | GitHub、JSON API、サードパーティ監視ツールなど | Standard SKUを優先 |
退役対応では「無料に近いから Azure Monitor dashboards with Grafana」または「推奨だから Standard」のように決めると失敗します。ダッシュボードごとに、データソース、アラート、共有方法、ネットワーク要件、運用責任者を確認してから判断しましょう。
まず結論：Standard SKU移行とAzure Monitor dashboards with Grafanaの選び方
Azure Monitor dashboards with Grafana は、Azure portal 内で Grafana ダッシュボードを使える機能です。Azure Monitor データを可視化する用途では、追加コストなし・設定不要で利用できる選択肢として説明されています。一方、Azure Managed Grafana は、より多様なデータソースやGrafana機能を使えるフルマネージドなGrafanaサービスです。(Microsoft Learn)
| 比較項目 | Azure Managed Grafana Standard SKU | Azure Monitor dashboards with Grafana |
|---|---|---|
| 向いている用途 | 本番運用、SRE/NOC、複数データソース統合 | Azure Monitor中心の可視化、Azure portal内での運用 |
| 料金の考え方 | Standardのコンピュート、アクティブユーザー、必要に応じてゾーン冗長などを考慮 | Grafana体験自体は追加コストなし。ただしAzure Monitor、Log Analytics、Prometheus、ADXなどのデータ保存・クエリ費用は別途考慮 |
| データソース | Azure Monitor、Prometheus、Azure Data Explorer、OSS/Enterprise系データソースなど | Azure Monitor Metrics、Azure Monitor Logs、Azure Monitor Traces、Managed Prometheus、Azure Resource Graph、Azure Data Explorerなど |
| Grafanaアラート | 対応 | 非対応 |
| レポート | 対応 | 非対応 |
| Private Link / Managed Private Endpoint | 対応 | 非対応 |
| 決定的な送信元IP | 対応 | 非対応 |
| 認証方式 | 現在ユーザー、マネージドID、アプリ登録などを構成可能 | 基本は現在のユーザー権限に依存 |
| 移行のしやすさ | 既存ワークスペースを維持しやすい | JSONエクスポート・インポート、RBAC再設計が必要になりやすい |
| 選ぶべきケース | 「Grafanaを監視基盤として使い続ける」 | 「Azure Monitorの可視化画面としてGrafanaを使う」 |
Microsoftの比較では、Azure Monitor dashboards with Grafana はアラート、レポート、Library panels、Snapshots、Playlists、App pluginsをサポートしないとされています。これらが必要な場合は、Azure Managed Grafana を選ぶべきです。(Microsoft Learn)
Standard SKUへの移行が向いているケース
Standard SKUは、Essentialの延長ではなく、本番向けのAzure Managed Grafanaとして考えるべき選択肢です。Microsoftの概要では、Standard は推奨階層であり、パフォーマンス向上、より多くの機能、SLAが提供されると説明されています。X1とX2の2サイズがあり、X2はX1より多くのメモリを備え、1組織あたりのアラートルール数も多くサポートします。(Microsoft Learn)
Standard SKUを選ぶべき判断基準
次のいずれかに当てはまるなら、Standard SKU移行を第一候補にしてください。
- Grafanaのアラートを使いたい
- 障害対応でGrafanaダッシュボードを常時参照している
- 監視画面にSLAや可用性を求める
- Private Link、Managed Private Endpoint、固定的な送信元IPが必要
- Azure以外のデータソースも統合している
- Grafanaのレポート機能やメール通知を使いたい
- 既存URL、フォルダー構成、ユーザー体験をできるだけ維持したい
- 将来的にGrafana Enterpriseプラグインの利用を検討している
Azure Managed Grafana の価格ページでは、Standard はアラート、メール、レポート、プライベートネットワーク、決定的な送信元IP、ゾーン冗長、99.9%可用性SLAに対応する一方、Essentialではこれらが非対応と整理されています。(Microsoft Azure)
Standard SKUへの移行手順
基本的な流れは、既存の Azure Managed Grafana ワークスペースで価格プランを変更する作業です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前バックアップ | ダッシュボードJSON、データソース、フォルダー構成を保存 | 復旧用ではなく、差分確認用としても使う |
| コスト確認 | Standard X1 / X2、ゾーン冗長、アクティブユーザー数を見積もる | Azure価格計算ツールや契約条件で確認 |
| SKU変更 | Azure portalで対象ワークスペースを開き、Settings > Configuration > Pricing Plans から Standard SKU を選択 | 必要に応じてX2を選択 |
| 動作確認 | ダッシュボード、変数、データソース、アラート、通知先を確認 | 特に本番オンコール用ダッシュボードを優先 |
| 運用切替 | 監視手順書、リンク、通知先、RBACを更新 | 利用者にURLや権限変更を周知 |
Microsoft Learn の移行ガイドでは、Azure portalで対象ワークスペースの Settings > Configuration > Pricing Plans から Standard SKU を選択し、必要に応じてX2へ増やす手順が示されています。また、StandardからEssentialへのダウングレードや、大きいインスタンスサイズから小さいサイズへの変更はサポートされない点に注意が必要です。(Microsoft Learn)
X1とX2の選び方
最初からX2を選ぶべきか迷う場合は、次の基準で判断すると現実的です。
| 選択肢 | 向いている環境 |
|---|---|
| Standard X1 | ダッシュボード数やアラート数が中規模、まずEssential相当の継続性を確保したい環境 |
| Standard X2 | アラートルールが多い、同時利用者が多い、重いパネルが多い、運用監視の中心にGrafanaを置いている環境 |
迷った場合は、まず現在の利用状況を棚卸ししてください。特に「誰が月に何回見ているか」よりも、障害時に何人が同時に見るかが重要です。平常時は軽くても、障害時に多数のエンジニアが同じダッシュボードを開く環境では余裕を持たせる価値があります。
Azure Monitor dashboards with Grafanaが向いているケース
Azure Monitor dashboards with Grafana は、Azure Monitor内でGrafanaダッシュボードを使える選択肢です。Azure Monitor Metrics、Managed Prometheus、Azure Monitor Logs、Azure Monitor Traces、Azure Resource Graph、Azure Data Explorerなどがサポート対象として説明されています。(Microsoft Learn)
この選択肢が合うのは、Grafanaを「独立した監視基盤」として使うより、Azure portal上の可視化機能として使いたいケースです。
Azure Monitor dashboards with Grafanaを選ぶべき判断基準
次に当てはまる環境では、Azure Monitor dashboards with Grafanaを優先的に検討できます。
- データソースがAzure Monitor、Log Analytics、Managed Prometheus、Azure Resource Graph、Azure Data Explorer中心
- Grafanaアラートではなく、Azure Monitor Alertsなど別の仕組みで通知している
- レポート配信やPDF出力に依存していない
- プライベートネットワークや固定送信元IPが不要
- Azure portal内で完結する運用を好む
- 開発・検証・チーム別ダッシュボードを低い管理負荷で持ちたい
- Standard SKUの固定費を避けたい
Azure Monitor dashboards with Grafanaでは、テンプレートダッシュボードの利用、新規ダッシュボード作成、JSONからのインポート、Grafana public galleryからのインポートなどが可能です。ただし、インポートできるのはサポート対象データソースを使ったダッシュボードに限られます。(Microsoft Learn)
移行手順の流れ
Essential SKUからAzure Monitor dashboards with Grafanaへ移す場合は、単なるSKU変更ではありません。ダッシュボードをエクスポートし、Azure Monitor側へインポートする移行になります。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 既存ダッシュボードを分類 | Azureデータソースだけか、外部データソースを含むかを確認 | 外部APIやプラグイン依存を見落とす |
| JSONをエクスポート | Grafana UIのShare > Export、またはCLIでバックアップ | フォルダー構成やデータソースUIDの違いに注意 |
| Azure Monitorへインポート | Azure portal > Azure Monitor > Dashboards with Grafana > New > Import | 非対応データソースのパネルは表示できない |
| RBACを設定 | ダッシュボード閲覧者とデータソース閲覧権限を付与 | リンク共有だけではデータを見られない場合がある |
| 表示確認 | 変数、時間範囲、PromQL/KQL、パネル表示を確認 | 一部パネルだけ空になるケースがある |
| 旧URLを置換 | Wiki、Runbook、障害対応手順書のリンクを更新 | 障害時に古いリンクへ飛ぶ問題が起きやすい |
移行ガイドでは、Grafana UIからダッシュボードJSONを保存する方法に加え、プレビューの az grafana backup コマンドで dashboards、datasources、folders などをバックアップする方法も案内されています。(Microsoft Learn)
az grafana backup \
--name MyGrafana \
--resource-group MyResourceGroup \
--directory "c:\temp" \
--components datasources dashboards foldersAzure Monitor dashboards with Grafana側では、Azure portalで Azure Monitor を開き、Dashboards with Grafana から New > Import を選択してJSONを読み込む流れになります。(Microsoft Learn)
移行先を決めるための実務チェックリスト
退役対応では、全ダッシュボードを同じ移行先にそろえる必要はありません。本番監視はStandard、チーム別の参照用ダッシュボードはAzure Monitor dashboards with Grafana、という分け方も現実的です。
| 確認項目 | Standard SKUを選ぶサイン | Azure Monitor dashboards with Grafanaを選ぶサイン |
|---|---|---|
| データソース | Azure以外、外部API、OSS/Enterpriseプラグインがある | Azure Monitor、Managed Prometheus、ADX中心 |
| アラート | Grafanaアラートを使う、今後使いたい | Azure Monitor Alertsなど別系統で十分 |
| レポート | 定期レポート、画像レンダリング、メール配信が必要 | 画面閲覧が中心 |
| ネットワーク | Private Link、固定送信元IP、閉域要件がある | Azure portalアクセスで足りる |
| 可用性 | 監視画面そのものにSLAを求める | 参照用・分析用の位置づけ |
| コスト | 有償でも運用継続性を優先 | 追加のGrafana費用を抑えたい |
| 移行影響 | 既存ワークスペースやURLを維持したい | JSON移行やリンク更新を許容できる |
| 管理体制 | Grafana管理者がいる | Azure Monitor管理の延長で運用したい |
判断に迷う場合は、次のルールを使うと整理しやすくなります。
- 障害対応の一次画面ならStandard SKU
- Azure Monitorデータを見るだけならAzure Monitor dashboards with Grafana
- 外部データソースが1つでも重要ならStandard SKU
- 「無料だから」だけで本番監視を移さない
- 「推奨だから」だけで全環境をStandardにしない
- 退役対応を機に、使われていないダッシュボードは移行しない
特に大規模環境では、ダッシュボード数よりも「誰が責任を持って直すのか」が重要です。オーナー不明のダッシュボードをそのまま移行すると、退役後も不要な運用負債が残ります。
棚卸しで使える確認コマンド例
Azure Managed Grafana ワークスペースを横断的に洗い出す場合は、Azure Resource Graphで対象リソースを確認すると便利です。Azure Managed Grafana のリソース種類は Microsoft.Dashboard/grafana です。(Microsoft Learn)
az graph query -q "
Resources
| where type =~ 'microsoft.dashboard/grafana'
| project name, resourceGroup, subscriptionId, location, sku=tostring(sku.name), tags
| order by subscriptionId, resourceGroup, name
"Essentialだけを絞り込む場合は、環境に応じてSKU名の出力を確認したうえで、次のようにフィルターします。
az graph query -q "
Resources
| where type =~ 'microsoft.dashboard/grafana'
| where tostring(sku.name) has 'Essential'
| project name, resourceGroup, subscriptionId, location, sku=tostring(sku.name)
"この一覧をもとに、各ワークスペースについて次の情報をスプレッドシートやIssueで管理すると、移行判断が速くなります。
| 項目 | 記入例 |
|---|---|
| ワークスペース名 | grafana-prod-jpeast |
| 所有チーム | Platform SRE |
| 重要度 | Critical / High / Medium / Low |
| 主な利用者 | SRE、アプリチーム、開発者 |
| 主なデータソース | Azure Monitor、Managed Prometheus、ADX |
| Grafanaアラート利用 | あり / なし |
| レポート利用 | あり / なし |
| 外部データソース | あり / なし |
| 移行先候補 | Standard X1、Standard X2、Azure Monitor dashboards |
| 移行期限 | 例：2026年12月末まで |
| 検証担当 | 担当者名またはチーム名 |
料金比較で見るべきポイント
退役対応では「Standardは有償、Azure Monitor dashboards with Grafanaは追加コストなし」という単純比較に寄せすぎないことが大切です。
Azure Managed Grafanaの価格ページでは、Standard Unit、Zone Redundancy Unit、アクティブユーザー課金などの考え方が示されています。価格は見積もりであり、契約形態、購入日、為替レート、リージョン、通貨などにより変わるため、実際の見積もりはAzure pricing calculatorや契約条件で確認する必要があります。(Microsoft Azure)
一方、Azure Monitor dashboards with GrafanaはGrafana体験自体の追加コストを抑えやすい選択肢ですが、裏側で参照するLog Analytics、Azure Monitor、Managed Prometheus、Azure Data Explorerなどのデータ取り込み、保存、クエリ実行コストは別に発生し得ます。
コスト判断では、次の3つを分けて考えてください。
| コスト種別 | 見るべき内容 |
|---|---|
| サービス費用 | Standard SKUのコンピュート、ユーザー、ゾーン冗長など |
| データ費用 | ログ、メトリクス、Prometheus、ADXの保存・クエリ費用 |
| 運用費用 | 移行作業、障害時の調査時間、権限管理、手順書更新 |
本番障害時にGrafanaが見られず、復旧が30分遅れるなら、月額費用の差以上に高くつく可能性があります。逆に、月に数回しか見ない参照用ダッシュボードをStandardに残すと、不要な固定費になります。
移行で失敗しやすいポイント
退役日が先に見えると、作業を後回しにしがちです。しかしGrafana移行は、ダッシュボードのJSONを動かせば終わるとは限りません。特に以下の問題は早めに潰しておくべきです。
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| インポートしたのに一部パネルが空 | データソースUID、権限、非対応データソースの違い | 代表ダッシュボードで先にPoCする |
| リンク共有した相手が見られない | ダッシュボード権限とデータソース権限が別 | Azure RBACとデータアクセス権を同時に確認 |
| Standard移行後に戻せない | ダウングレード非対応を見落とした | 事前にコスト承認とバックアップを取る |
| 障害対応手順書が古い | URLや画面導線を更新していない | Runbook、Wiki、Teams固定リンクを棚卸し |
| 不要ダッシュボードまで移行 | オーナー不明のまま一括移行 | 90日以上未使用のものは廃止候補にする |
| アラート移行を忘れる | ダッシュボード移行だけに集中 | 通知先、ルール、オンコール連携を別タスク化 |
| グローバルチームで混乱 | 日付、タイムゾーン、リージョン、通貨の認識差 | 期限はUTCと現地時間を併記し、リージョン別に確認 |
Azure Monitor dashboards with GrafanaからAzure Managed Grafanaへダッシュボードをコピーする機能もありますが、コピー対象はユーザー保存済みダッシュボードであり、Azure管理テンプレートは直接コピーできません。また、データソースは自動移行されず、同じIDのダッシュボードがある場合は上書きされる可能性があります。(Microsoft Learn)
推奨移行スケジュール
2027年3月30日の退役を基準にするなら、2026年中に移行先を決め、2027年初めには本番切替を終えておくのが安全です。年度末や凍結期間、グローバルチームの休暇を考えると、期限直前の移行は避けるべきです。
| 時期 | やること |
|---|---|
| 2026年4〜6月 | Essentialワークスペースの棚卸し、オーナー確認、移行先の仮分類 |
| 2026年7〜9月 | Standard移行とAzure Monitor dashboards移行のPoC、コスト見積もり、権限設計 |
| 2026年10〜12月 | 本番ダッシュボードの移行、Runbook更新、利用者周知 |
| 2027年1〜2月 | 残タスク解消、不要ダッシュボード廃止、監視手順のリハーサル |
| 2027年3月 | 旧Essential依存の最終確認、リンク・アラート・権限の凍結確認 |
このスケジュールで進めると、移行後の「見えるけれど運用に使えない」状態を避けやすくなります。
最終判断：本番監視はStandard、Azure中心の可視化はAzure Monitor dashboardsを軸にする
Azure Managed Grafana Essential SKUの退役対応では、まず全ワークスペースを棚卸しし、ダッシュボードごとに「本番監視の中核か」「Azure Monitor中心の参照用か」を分けてください。
本番運用、アラート、レポート、外部データソース、プライベートネットワーク、SLAが必要なら、Azure Managed Grafana Standard SKUへの移行が自然です。Azure Monitor、Managed Prometheus、Log Analytics、Azure Resource Graph、Azure Data Explorer中心で、追加のGrafana運用を増やしたくないなら、Azure Monitor dashboards with Grafanaが有力です。
次に取るべき行動は明確です。まず、Essentialワークスペースを一覧化し、重要度とデータソースを確認してください。そのうえで、最重要の本番ダッシュボードを1つStandardへ、Azure中心の参照用ダッシュボードを1つAzure Monitor dashboards with Grafanaへ移す小さな検証を行います。そこでコスト、権限、表示差分、運用手順の課題を洗い出せば、残りの移行は判断しやすくなります。
コメント