Azure SQL関連で「Manage Licensing and Billing – SQL Server enabled by Azure Arc」を確認している人が最初に押さえるべき結論は、これは Azure SQL Database の料金プラン変更ではなく、オンプレミス、他クラウド、ホスティング環境などにある SQL Server を Azure Arc に接続した場合のライセンス管理と課金方法を整理する公式情報だという点です。
特に重要なのは、SQL Server enabled by Azure Arc が直接サポートするのは基本的にコアベースのライセンス管理であり、管理者は PAYG、Paid、LicenseOnly の選択、v-core / p-core の課金単位、物理コアライセンス、HA/DR 構成、Linux 環境での制限を確認する必要があることです。設定を誤ると、想定外の課金、ライセンス権利の不足、無料扱いにできるはずの待機系インスタンスの課金につながる可能性があります。(Microsoft Learn)
Azure SQLの「Manage Licensing and Billing – SQL Server enabled by Azure Arc」で確認すべきこと
「Manage Licensing and Billing – SQL Server enabled by Azure Arc」は、Azure Arc に接続した SQL Server のライセンスと課金をどう管理するかを説明する Microsoft Learn の公式ドキュメントです。
ここで扱う対象は、Azure SQL Database や Azure SQL Managed Instance そのものではありません。主な対象は、次のような SQL Server 環境です。
| 対象環境 | 確認すべきポイント |
|---|---|
| オンプレミスの仮想マシン上の SQL Server | v-core 課金にするか、物理コアライセンスでまとめるか |
| 物理サーバーに直接インストールされた SQL Server | p-core 課金、Edition 上限、ホスト単位の課金範囲 |
| VMware などの仮想化基盤上の SQL Server | Enterprise ライセンスによる無制限仮想化の適用可否 |
| 他クラウドやホスティング事業者上の SQL Server | 物理基盤を管理できない場合の v-core ライセンス選択 |
| Always On / FCI などの HA/DR 構成 | パッシブインスタンスとして無料扱いできる条件 |
| Linux 上の SQL Server | PAYG 課金時のパッシブ検出制限 |
| 開発・検証環境 | Developer Edition または Azure dev/test サブスクリプションの利用可否 |
実務上のポイントは、「SQL Server を Azure Arc に接続すれば自動的に最適なライセンスになる」と考えないことです。Azure Arc は管理・可視化の入り口であり、どのライセンス方式を使うか、どの課金メーターに乗せるかは、環境ごとに明示的に判断する必要があります。
何が変わるのか：ライセンスをAzure上の管理設定として扱う
今回のテーマで大きく意識すべき変化は、SQL Server のライセンスを単なる契約・台帳管理だけでなく、Azure Arc 上のリソース設定として管理する点です。
SQL Server enabled by Azure Arc では、Azure Extension for SQL Server の導入時にライセンスタイプを指定します。Azure Portal では、Azure Arc 対応 SQL Server リソースの概要画面でホストのライセンスタイプを確認できます。つまり、管理者は「契約上ライセンスを持っているか」だけでなく、「Azure Arc 側の設定が契約内容と一致しているか」を確認しなければなりません。(Microsoft Learn)
特に、物理コアライセンスを使って無制限仮想化を適用する場合は、SQLServerLicense リソースを作成し、スコープ、サイズ、課金プラン、アクティブ化状態を管理します。さらに、対象 VM 側でも物理コアライセンスを使う設定が必要です。ここを片方だけ設定しても、期待したライセンス適用にならない可能性があります。(Microsoft Learn)
Azure SQL利用者への影響範囲
この情報の影響を受けるのは、主に SQL Server を Azure Arc で Azure に接続している、または今後接続する組織です。
一方で、Azure SQL Database だけを利用している場合は、この記事のライセンス方式を直接設定する場面は基本的にありません。ただし、オンプレミスの SQL Server から Azure SQL Database や Azure SQL Managed Instance へ移行する途中で Azure Arc を使ってインベントリ管理、移行準備、課金管理を行う場合は、確認対象になります。
影響を受けやすい担当者
| 担当者 | 影響する作業 |
|---|---|
| インフラ管理者 | Azure Arc 接続、拡張機能導入、VM / 物理ホスト単位のライセンス設定 |
| DBA | SQL Server Edition、HA/DR 構成、待機系インスタンス、関連サービスの確認 |
| クラウド管理者 | Azure サブスクリプション、課金メーター、Cost Management での確認 |
| 情シス・ライセンス管理者 | Software Assurance、SQL Server サブスクリプション、BYOL の権利確認 |
| 開発者 | 開発・検証環境の Edition 選択、読み取りセカンダリへの接続設計 |
| 移行担当者 | Azure 移行前の棚卸し、ライセンス方式の見直し、展開テンプレートの修正 |
見落としやすいのは、開発者も無関係ではない点です。たとえば、検証環境に Standard / Enterprise Edition を立てたまま通常のサブスクリプションに接続すると、意図しないメーターが使われる可能性があります。また、読み取り可能なセカンダリにアプリケーションや監視ツールが接続すると、パッシブ扱いの条件から外れる場合があります。
本番環境で選べる3つのライセンス方式
SQL Server enabled by Azure Arc の本番環境では、主に次の3つのライセンス方式を検討します。公式情報では、v-core、VMを使わない物理コア、無制限仮想化を伴う物理コアの3方式が示されています。(Microsoft Learn)
| ライセンス方式 | 向いている環境 | 課金・管理の単位 | 主な注意点 |
|---|---|---|---|
| v-core ライセンス | VM単位でSQL Serverを管理する環境、他クラウド、ホスティング環境 | SQL Server を実行する VM の vCPU / v-core | VMごとに個別管理。Standard Edition は v-core 上限に注意 |
| VMを使わない p-core ライセンス | 物理サーバーへ SQL Server を直接インストールする環境 | 物理ホストの p-core | ホスト上の最上位 Edition を基準に課金される |
| p-core ライセンス + 無制限仮想化 | 自社管理の仮想化基盤で多数の SQL Server VM を動かす環境 | 物理ホストの p-core を表す SQLServerLicense リソース | Enterprise ライセンス前提。対象外インフラでは適用できない場合がある |
判断の軸はシンプルです。物理基盤を自社で管理できず、VM単位でしか把握できない場合は v-core が現実的です。自社の仮想化基盤で多数の SQL Server VM を集約している場合は、Enterprise ライセンスと Software Assurance などの権利を確認したうえで、p-core ライセンスによる無制限仮想化を検討します。
PAYG、Paid、LicenseOnlyの違い
ライセンス方式を決めたら、次にライセンスタイプを選びます。ここを誤ると、課金や利用権の扱いが変わります。
| ライセンスタイプ | 意味 | 選ぶ場面 | 確認ポイント |
|---|---|---|---|
PAYG | Azure 経由の従量課金 | 既存ライセンスを使わず、時間単位で課金したい場合 | Azure との接続維持、CSP利用時の継続課金同意 |
Paid | Software Assurance または SQL Server サブスクリプション付きの既存ライセンスを持ち込む | BYOL / Azure Hybrid Benefit 的に既存権利を使う場合 | SA または SQL Server サブスクリプションが有効か |
LicenseOnly | 永続ライセンス、無料 Edition、Server+CAL などを管理・報告する | Azure 経由で SQL Server ライセンス料金を払わない場合 | 付帯特典や自動評価機能の対象範囲が変わる |
PAYG は柔軟ですが、Azure との接続が前提です。公式情報では、SQL Server が稼働している時間帯にホストがオンラインであれば時間単位で課金され、断続的な接続断については一定の回復性がある一方、30日を超えて切断された場合は PAYG サブスクリプションが期限切れとなり、ソフトウェア利用が許可されなくなると説明されています。(Microsoft Learn)
Paid は、既存の Enterprise / Standard ライセンスに有効な Software Assurance または SQL Server サブスクリプションがある場合に選ぶ選択肢です。単に「社内に SQL Server ライセンスがある」だけでは不十分で、契約状態と利用条件を確認する必要があります。
LicenseOnly は、永続ライセンスや無料 Edition、Server+CAL ライセンスなどで使います。Server+CAL ライセンスの SQL Server を Azure Arc に接続する場合は、Software Assurance があっても LicenseOnly を設定する必要があります。Enterprise Server+CAL をコアベースへ変換した場合は、Paid または PAYG を使う整理になります。(Microsoft Learn)
管理者が確認すべき設定
Azure Extension for SQL Server導入時のライセンスタイプ
Azure Extension for SQL Server をインストールするとき、ライセンスタイプは必須パラメーターとして扱われます。既存環境を一括で Azure Arc に接続する場合、ここを手作業任せにすると、同じ用途の SQL Server で PAYG と LicenseOnly が混在するなど、後から追跡しづらい状態になります。
展開前に、最低でも次の情報を棚卸ししておくべきです。
| 棚卸し項目 | 理由 |
|---|---|
| SQL Server の Edition | Enterprise / Standard / Developer / Express でメーターが変わるため |
| 実行環境 | VMか、物理サーバー直インストールかで課金単位が変わるため |
| vCPU / 物理コア数 | v-core / p-core の判断材料になるため |
| Software Assurance の有無 | Paid を選べるか判断するため |
| SQL Server サブスクリプションの有無 | BYOL の根拠になるため |
| HA/DR ロール | パッシブ扱いできるか確認するため |
| OS | Linux では PAYG の検出制限があるため |
| 関連サービス | SSAS、SSIS、SSRS、Power BI Report Server の課金確認が必要なため |
特に大規模環境では、先に命名規則とタグ設計を決めるだけでは不十分です。Arc data resources のタグ対応範囲には制限があるため、ライセンス管理をタグだけに依存せず、Azure Resource Graph、課金レポート、SQL Server インベントリを組み合わせて確認できる形にしておく必要があります。(Microsoft Learn)
p-coreライセンスを使う場合のSQLServerLicenseリソース
物理コアライセンスで無制限仮想化を使う場合は、SQLServerLicense リソースの設計が重要です。これは、ライセンスを表す Azure リソースであり、対象範囲や課金プランを定義します。
| プロパティ | 確認内容 | よくあるミス |
|---|---|---|
licenseCategory | Core に設定されているか | 物理コアライセンスの前提を誤る |
scopeType | テナント、サブスクリプション、リソースグループのどこに適用するか | 想定外の範囲までライセンスを適用する |
Size | 対象ホストの物理コア合計を反映しているか | 追加ホスト分のコアを入れ忘れる |
Subscription | どの Azure サブスクリプションで請求するか | 請求先サブスクリプションを誤る |
billingPlan | PAYG か Paid か | VM側の LicenseType と不一致になる |
activationState | いつ有効化するか | 契約更新日やEA終了日とずれる |
公式情報では、p-core ライセンスを正しく適用するには、対象 VM 側で UsePhysicalCoreLicense を True にし、さらに VM の LicenseType を p-core ライセンス側の billingPlan と一致させる必要があるとされています。(Microsoft Learn)
つまり、SQLServerLicense リソースを作っただけでは安心できません。対象 VM が物理コアライセンスを使う設定になっているか、PAYG と Paid の組み合わせに矛盾がないかまで確認する必要があります。
課金メーターはインスタンス数だけで判断しない
SQL Server enabled by Azure Arc のメーターは、単純な「SQL Server インスタンス数」だけで決まりません。公式情報では、ソフトウェア使用量は1時間に1回報告され、SQL Server Edition、OSE から見える v-core / p-core 数、ライセンスタイプなどに基づいてメーターが選ばれると説明されています。(Microsoft Learn)
注意すべきルールは次の通りです。
| ルール | 実務上の意味 |
|---|---|
| VM上で物理コアライセンスを指定しない場合、OSEに割り当てられた v-core 数でメーターされる | VMのCPU割り当て変更が課金に影響する |
| 物理サーバー直インストールでは、OSEから見える p-core 数でメーターされる | 物理ホストの構成変更をライセンス管理に反映する必要がある |
| 最小は OSE あたり4コア | 小規模VMでも最低単位に注意 |
| 同一 OSE に複数インスタンスがある場合、最上位 Edition が課金基準になる | Standard と Enterprise を混在させると Enterprise 基準になる可能性がある |
| 同一 Edition が複数ある場合、使用量報告は最初のインスタンスが代表する | インスタンス名だけで課金有無を判断しない |
たとえば、1台の VM に Standard Edition と Enterprise Edition の SQL Server が同居している場合、管理者が「Standard 用の小さな環境」と認識していても、課金上は上位 Edition が基準になる可能性があります。ライセンス整理では、インスタンス単位だけでなく OSE 単位で見直すことが重要です。
移行・展開時に注意すべきポイント
PAYGはAzureへの接続維持が前提
PAYG を選ぶ場合、ホストマシンが Azure と接続できる状態を保つ必要があります。ネットワーク分断が短期間であれば課金精度への影響を抑える仕組みがありますが、30日を超える切断では PAYG サブスクリプションが期限切れになるとされています。(Microsoft Learn)
閉域網、プロキシ、ファイアウォール、メンテナンスによる長期停止がある環境では、次の点を事前に確認してください。
| 確認項目 | 対応例 |
|---|---|
| Azure Arc エージェントの通信経路 | プロキシ、名前解決、アウトバウンド通信を事前検証する |
| 長期停止の予定 | 停止期間が長くなる場合はライセンス方式を再確認する |
| 監視 | Arc 接続状態のアラートを用意する |
| CSP契約 | 継続課金への同意が必要か確認する |
単に SQL Server が動いているだけではなく、Azure Arc として正常に接続・報告できているかを監視対象に含めることが重要です。
Linux上のSQL ServerはPAYG課金の見え方に注意
Linux 上の SQL Server で PAYG を使う場合は、Windows と同じ感覚で HA/DR 検出を期待しないほうが安全です。公式情報では、Linux では可用性グループやフェールオーバークラスターインスタンスのパッシブレプリカ自動検出が利用できず、すべてのインスタンスがアクティブとして課金されると説明されています。(Microsoft Learn)
これは、ライセンス違反になるという意味ではありません。ただし、費用見積もりでは差が出ます。Linux で Always On 可用性グループを組む場合は、Windows と同じ前提で「待機系は自動的に無料」と見積もらないようにしてください。
HA/DRのパッシブインスタンスは条件を満たす必要がある
Software Assurance 付きライセンスまたは PAYG では、HA/DR 構成におけるパッシブ SQL Server インスタンスの扱いが重要です。Azure Extension for SQL Server は、Always On 可用性グループやフェールオーバークラスターインスタンスのパッシブインスタンスを検出し、条件を満たす場合に $0 メーターとして扱います。(Microsoft Learn)
ただし、パッシブ扱いになるには条件があります。
| 構成 | パッシブ扱いの考え方 |
|---|---|
| 非読み取りセカンダリ | 原則としてパッシブ DR ライセンスの対象になり得る |
| 読み取り可能セカンダリ | アクティブなユーザー接続がない場合のみ対象になり得る |
| プライマリレプリカ | ワークロードを処理するため対象外 |
| FCIのパッシブノード | SQL Server サービスが稼働していないなどの条件を満たす必要がある |
| ログ配布・ミラーリングなど | 自動検出の対象外とされている |
開発者や運用担当者が見落としやすいのは、監視ツール、バッチ、レポート、読み取り専用接続です。読み取り可能セカンダリにアプリケーションが接続していると、パッシブ扱いから外れる可能性があります。DR環境をコスト最適化したい場合は、接続先、監視方法、バックアップ方法まで含めて設計してください。
関連サービスもライセンス管理の対象になる
SQL Server enabled by Azure Arc では、SQL Server Database Engine だけでなく、SQL Server Analysis Services、Integration Services、Reporting Services、Power BI Report Server などの関連サービスもライセンス管理の対象になります。(Microsoft Learn)
特に注意が必要なのは、関連サービスが Database Engine なしで単独インストールされている場合です。公式情報では、関連サービスがスタンドアロンインスタンスとしてインストールされている場合に別ライセンスが必要になると説明されています。PAYG 構成では、該当する PAYG メーターが有効になる場合があります。(Microsoft Learn)
「DBエンジンはないから課金対象外」と判断するのは危険です。SSIS サーバー、SSRS 専用サーバー、Power BI Report Server の構成も棚卸しに含めましょう。
開発・検証環境はDeveloper Editionとdev/testサブスクリプションを使い分ける
非本番環境では、Developer Edition と Azure dev/test サブスクリプションの扱いを確認してください。SQL Server Developer Edition は無料で利用でき、Azure Extension for SQL Server は Dev edition の $0 メーターとして報告すると説明されています。また、本番環境と同じ Edition を使った検証環境では、Azure dev/test サブスクリプションを利用することで SQL Server メーターが無効化されるとされています。(Microsoft Learn)
実務では、次のように使い分けると判断しやすくなります。
| 利用シーン | 推奨される整理 |
|---|---|
| 開発者の検証、機能確認、CI用DB | Developer Edition を優先 |
| 本番相当の Edition や構成を再現する検証 | Azure dev/test サブスクリプションを検討 |
| 性能検証や負荷試験 | Edition、サブスクリプション、利用権を事前確認 |
| 一時的な移行リハーサル | 180日デュアルユースなど契約上の権利も確認 |
開発チームが独自に SQL Server VM を作る運用では、環境作成テンプレートに LicenseType や Edition の選択ルールを含めると、後からの修正を減らせます。
現場別の判断例
VMware基盤に多数のSQL Server VMがある場合
自社管理の VMware 基盤に多数の SQL Server VM があり、Enterprise ライセンスと Software Assurance を保有している場合は、p-core ライセンスによる無制限仮想化を検討する価値があります。
この場合の確認ポイントは、物理ホストのコア数、対象ホストを含む Azure Arc のスコープ、SQLServerLicense リソースの Size、VM 側の UsePhysicalCoreLicense、LicenseType の整合性です。
ただし、すべての仮想化環境で無条件に使えるわけではありません。公式情報では、特定のプロバイダーのインフラ上で実行される VM には無制限仮想化の特典が適用されず、v-core ライセンスのみになる場合があるとされています。(Microsoft Learn)
ホスティング事業者や他クラウド上のSQL Serverを管理する場合
物理ホストを自社で管理できない場合は、v-core ライセンスで VM 単位に管理するのが現実的です。公式情報でも、物理インフラを管理できないホスティングパートナーや非Microsoftクラウド上の VM では、v-core ライセンスが適したシナリオとして示されています。(Microsoft Learn)
このケースでは、VM の vCPU 数変更がコストに直結しやすいため、スケールアップ時の承認フローにライセンス確認を組み込むと安全です。
物理サーバーへ直接SQL Serverを入れている場合
物理サーバーに SQL Server を直接インストールしている場合は、p-core ライセンスを検討します。ただし、同じ物理ホスト上に複数の SQL Server インスタンスがある場合、Edition の混在に注意が必要です。
たとえば、ほとんどが Standard Edition でも、一部に Enterprise Edition があると、最上位 Edition が課金上の基準になる可能性があります。物理サーバーの棚卸しでは、インスタンス名だけでなく Edition と関連サービスまで確認してください。
DRサイトにSQL Serverを置いている場合
DRサイトの SQL Server は、パッシブ扱いできるかどうかでコストが変わります。非読み取りセカンダリであれば条件を満たしやすい一方、読み取り可能セカンダリにレポートや監視が接続していると、アクティブと見なされる可能性があります。
DRサイトを「待機系」として設計している場合でも、実際には以下のような接続が発生していないか確認してください。
| 接続元 | 注意点 |
|---|---|
| 監視ツール | ユーザーデータベースへ接続していないか |
| レポートツール | 読み取りセカンダリを参照していないか |
| バッチ処理 | DR側を定期参照していないか |
| 開発者の手動接続 | 検証目的の接続が残っていないか |
パッシブ扱いを維持したい場合は、接続先を master、msdb、tempdb、model などに限定する必要がある場面があります。運用手順書に「DR側へ接続してよい処理」と「接続してはいけない処理」を明記しておくと、トラブルを防ぎやすくなります。
管理者・開発者向けチェックリスト
Azure Arc で SQL Server のライセンスと課金を管理する前に、次の順番で確認すると抜け漏れを減らせます。
| 順番 | 確認項目 | 具体的な作業 |
|---|---|---|
| 1 | SQL Serverの棚卸し | Edition、バージョン、インスタンス、関連サービスを一覧化する |
| 2 | 実行環境の分類 | VM、物理サーバー、他クラウド、ホスティング環境に分ける |
| 3 | コア数の確認 | v-core / p-core、最小4コア、Standard Edition上限を確認する |
| 4 | 契約状態の確認 | SA、SQL Serverサブスクリプション、Server+CAL、永続ライセンスを整理する |
| 5 | ライセンス方式の選択 | v-core、p-core、p-core + 無制限仮想化を決める |
| 6 | LicenseTypeの設定 | PAYG、Paid、LicenseOnly を環境ごとに決める |
| 7 | p-core設定の確認 | SQLServerLicense、UsePhysicalCoreLicense、billingPlan を確認する |
| 8 | HA/DR構成の確認 | パッシブ判定条件、Linux制限、監視接続を確認する |
| 9 | 非本番環境の整理 | Developer Edition または dev/test サブスクリプションを使う |
| 10 | 課金確認 | Azure の請求・利用状況で想定メーターになっているか確認する |
特に、移行プロジェクトでは「移行前の棚卸し」と「Arc 接続後の課金確認」を別工程として扱うことをおすすめします。Arc に接続した直後は、ライセンスタイプ、Edition、コア数、HA/DR ロールが想定通りに反映されているかを必ず確認してください。
実務で避けたい失敗例
LicenseOnlyを選べば常に安くなると考える
LicenseOnly は Azure 経由で SQL Server ライセンス料金を払わない選択肢ですが、既存ライセンスの利用権があることが前提です。また、Software Assurance や SQL Server サブスクリプションに紐づく特典を活用したい場合、Paid や PAYG のほうが適切な場面があります。
「課金を避けたいから LicenseOnly」ではなく、「契約上の根拠があるから LicenseOnly」と判断する必要があります。
物理コアライセンスのスコープを広げすぎる
SQLServerLicense はテナント、サブスクリプション、リソースグループなどのスコープに適用できます。スコープを大きくすると管理は楽になりますが、対象外のマシンまで意図せず含めたり、追加ホスト分のコア数を反映し忘れたりするリスクがあります。
最初は対象ホストや対象リソースグループを明確にし、増設時のルールを決めてからスコープを広げるほうが安全です。
パッシブレプリカに監視・読み取り処理を接続してしまう
DR側の読み取り可能セカンダリに、レポート、監視、バックアップ確認用の処理が接続していると、パッシブ扱いから外れる可能性があります。特に、開発チームが「読み取り専用だから問題ない」と判断して接続先に使っているケースは注意が必要です。
コスト最適化を優先する DR 構成では、読み取り利用を許可するセカンダリと、完全な待機系として扱うセカンダリを分けて設計しましょう。
Linux環境をWindowsと同じ見積もりにする
Linux 上の SQL Server では、PAYG のパッシブ検出に制限があります。HA/DR 構成で待機系を含む場合、Windows と同じ前提で費用を見積もると差異が出る可能性があります。
Linux を採用している場合は、ライセンス管理者、DBA、クラウド管理者が同じ前提で見積もりを確認してください。
開発者が確認すべきポイント
開発者にとっても、このライセンス管理は無関係ではありません。アプリケーションの接続先、検証環境の作り方、CI/CD で作成する一時DB環境が、ライセンスと課金に影響することがあります。
開発チームでは、次のルールを用意しておくと安全です。
| 項目 | 推奨ルール |
|---|---|
| ローカル・検証DB | 原則として Developer Edition を使う |
| 自動作成されるSQL Server VM | テンプレートに LicenseType を明示する |
| 読み取りセカンダリ利用 | パッシブ扱いが必要な環境では接続しない |
| 性能検証 | 本番相当 Edition を使う場合は事前にライセンス確認する |
| 監視クエリ | DR側のユーザーデータベース接続を避ける設計にする |
特に IaC を使って Azure Arc 対応サーバーや SQL Server 拡張を展開している場合、LicenseType を環境変数やパラメーターとして管理し、開発・検証・本番で値を分けることが重要です。
まず取るべき次の行動
「Manage Licensing and Billing – SQL Server enabled by Azure Arc」を確認した管理者が最初にやるべきことは、新しい機能を試すことではなく、既存 SQL Server 環境の棚卸しです。
まず、SQL Server の Edition、実行場所、v-core / p-core、SA の有無、HA/DR 構成、関連サービス、開発・検証環境を一覧化してください。そのうえで、各環境に対して v-core、p-core、p-core + 無制限仮想化のどれを使うかを決めます。
次に、Azure Arc 接続時の LicenseType、p-core 利用時の SQLServerLicense リソース、VM 側の UsePhysicalCoreLicense、HA/DR のパッシブ判定、Linux 制限を確認します。最後に、Azure の利用状況と請求データを見て、想定したメーターになっているかを確認します。
Azure SQL への移行やハイブリッド管理を進める企業にとって、Azure Arc は SQL Server を可視化・管理する強力な仕組みです。ただし、ライセンスと課金は自動で最適化されるものではありません。契約、構成、Azure Arc の設定を一致させることが、想定外課金を防ぎ、コンプライアンスを保つための最短ルートです。
コメント