Azure Database for MySQL Flexible Server をプライベート アクセス（VNet 統合）で作成しようとしたときだけ、特定リージョンで「ProvisionNotSupportedForRegion」エラーが出てしまう――そんな状況にハマると、VNet 設定やサブネット設計を延々と疑ってしまいがちです。本記事では、このエラーの本当の原因である「Region access（クォータ）」制限と、その具体的な解決手順、あわせて VNet 統合時の実務的な注意点を詳しく解説します。
Azure Database for MySQL Flexible Server が VNet 統合で作成できない状況とは
よくある発生パターンの整理
まずは、実際に多くの人が遭遇しているパターンを整理してみます。
- サーバーのネットワーク モードとして 「プライベート アクセス（VNet 統合）」 を選択
- リージョンは Brazil South / East US 2 / Central US など、複数の場所で試しても一貫して失敗
- 既存の VNet を選んでも、ウィザードで新規作成した VNet を選んでも結果は同じく失敗
- 一方で、ネットワーク モードを 「パブリック アクセス」 にすると、同じリージョンでもサーバー作成が成功する
この挙動だけを見ると、つい次のように考えてしまいます。
- 「VNet の設定がどこか間違っているのでは」
- 「委任サブネットの設定に問題があるのでは」
- 「プライベート DNS の設定をミスしているのでは」
ところが実際には、ネットワーク設定が完璧でもエラーが出るケースがあります。そのときに表示される代表的なメッセージが、次のものです。
代表的なエラー「ProvisionNotSupportedForRegion」
ProvisionNotSupportedForRegion
Provisioning in requested region is not supported. Your subscription might not have access to create a server in the selected region. (https://aka.ms/mysqlcapacity)
英語メッセージを素直に読むと「このリージョンではプロビジョニングがサポートされていない」「サブスクリプションがこのリージョンでのサーバー作成にアクセスできない可能性がある」と書かれており、ネットワークよりもサブスクリプション側の制限を疑うべきであることがわかります。
ここでのポイントは、次の2つです。
- エラーは プライベート アクセスに特有なものではない
- 多くの場合、原因は Region access（リージョン アクセス）のクォータ未付与
事象と原因を俯瞰する早見表
| 現象 | ネットワーク モード | リージョン | 想定される主な原因 |
|---|---|---|---|
| サーバー作成が失敗し、ProvisionNotSupportedForRegion が表示される | プライベート アクセス（VNet 統合） | 特定リージョンのみ | Region access（クォータ）未付与の可能性が高い |
| サーバー作成が成功する | パブリック アクセス | 同じリージョン | 別 SKU / 設定のため、たまたまクォータ条件を満たしている |
| 他のリージョンでは問題なく作成できる | プライベート / パブリック問わず | 一部リージョンのみ失敗 | リージョンごとのクォータ・容量制限の違いによるもの |
それでは、この Region access（クォータ）が何者なのかを整理していきます。
根本原因：Region access（リージョン アクセス）クォータが付与されていない
Region access とは何か
Azure では、単に「vCPU 何個まで」といったリソース量の制限だけでなく、「特定のサービスを、特定のリージョンで利用してよいか」というアクセス権レベルのクォータが存在します。これが Region access や「リージョン アクセス」と呼ばれるものです。
Azure Database for MySQL Flexible Server の場合、サブスクリプションによっては一部リージョンでの利用に事前承認が必要であり、その承認がない状態でサーバーを作成しようとすると、ネットワーク設定に関係なくデプロイがブロックされます。その結果として、ProvisionNotSupportedForRegion エラーが返ってきます。
他のクォータとの違い
Azure には複数種類のクォータがあり、混同しやすいので整理しておきます。
| クォータ種別 | 主な対象 | 制限内容 | 典型的な影響 |
|---|---|---|---|
| vCPU クォータ | VM / コンピュート系 | リージョンごとの vCPU 上限 | VM の追加作成ができない、スケールアウトできない |
| DB サービスのリソース クォータ | MySQL / PostgreSQL など | サーバー数、ストレージ容量など | サーバー数や容量上限に達すると追加作成できない |
| Region access（リージョン アクセス） | 特定サービス＋リージョン | そのリージョンでサービスを使用できるかどうか | サーバー作成自体が禁止され、ProvisionNotSupportedForRegion などが発生 |
今回のケースでは、最後の「Region access」が問題になっているため、いくら VNet・サブネット・DNS をいじっても解決しません。Azure ポータルからクォータ申請を行い、リージョン アクセスを付与してもらう必要があります。
有償サポート不要：Azure ポータルから Region access を申請する手順
Region access の申請は、有償サポート契約がなくても 標準サポート（無料）の範囲で実施できます。以下では、日本語 UI を想定しつつ、英語 UI 名称も併記します。
サポート リクエストの作成手順
- Azure ポータルで「ヘルプとサポート」を開く
画面右上の「?」アイコン、またはナビゲーション メニューから Help + support を選択します。 - 「サポート リクエストの作成」をクリック
画面上部の New support request（サポート リクエストの作成）ボタンをクリックします。 - Support AI Assistant が開いた場合は旧エクスペリエンスに切り替え
最近のポータルでは AI ベースのサポート画面が開くことがあります。その場合は画面右側の 「旧エクスペリエンスに切り替え」（Switch to the previous experience）リンクから、従来のフォームベース UI に切り替えます。 - 検索ボックスで「quota」と入力し、「移動」
Issue type の候補画面で検索ボックスにquotaと入力し、表示された Service and subscription limits (quotas) に進みます。 - カテゴリを「その他 / サービスとサブスクリプションの制限（クォータ）」に設定
カテゴリ選択で 「その他 / サービスとサブスクリプションの制限（クォータ）」 を選び、「次へ」をクリックします。 - 「サポート リクエストの作成」を確定
表示された内容を確認し、改めて 「サポート リクエストの作成」 をクリックします。 - Issue type と Quota type を選択
以下のように設定します。- Issue type：Service and subscription limits (quotas)
- Quota type：Azure Database for MySQL Flexible Server
- 「追加の詳細」タブで Region access を指定
「追加の詳細」タブを開き、「詳細を入力」ボタンをクリックします。- 対象項目として Region access（または Region access with zonal dependency）を選択
- 対象リージョン（例：East US 2）を指定
- 必要な コア数（必要な vCore 数の目安）を入力
- 入力内容を確認して「作成」
連絡先、影響度などの項目を確認し、問題なければ 「作成」 をクリックします。 - 自動受付メールを確認し、承認を待つ
数分以内に自動返信メールが届きます。通常はそれほど時間をかけずに審査・承認されることが多いので、承認後に同じリージョン・同じ設定で再度デプロイを試します。
申請時に押さえておきたい実務ポイント
- 本番環境に使う予定のサブスクリプションを間違えない
検証用サブスクリプションと本番サブスクリプションが分かれている場合は、どちら側に Region access を付与すべきか事前に整理しておきましょう。 - 少し余裕のあるコア数を申請する
今必要な vCore 数ギリギリではなく、今後 1～2 年の拡張余地を見越して多少余裕を持った数値を申請しておくと、再申請の手間を減らせます。 - 複数リージョンをまとめて申請する
マルチリージョン DR 構成を検討している場合は、本番用リージョンと DR 用リージョンをまとめて Region access 申請しておくとスムーズです。
Region access 承認後に再デプロイしても失敗するときの確認ポイント
Region access の承認後も、別の要因でデプロイが失敗することがあります。その場合は、以下の観点で切り分けを進めると効率的です。
別リージョンでの再試行
- 同じサブスクリプションで、別リージョン（例：Japan East / West Europe）に同様の条件で作成できるかを試します。
- 別リージョンで問題なく作成できる場合、該当リージョン固有の一時的な容量逼迫や制限の可能性が高くなります。
Azure Policy / RBAC による制限の有無を確認
- 管理グループやサブスクリプションに適用されている Azure Policy によって、特定地域や SKU の利用が制限されていないか確認します。
- また、リソース グループに対する権限が Contributor 未満の場合、必要なリソース（サブネット、プライベート DNS ゾーンなど）の作成がブロックされることがあります。
CLI で SKU／提供可否を確認する
Azure CLI を利用すると、特定リージョンでどの SKU が利用可能かを確認できます。例として、East US 2 の SKU を確認するコマンドは次の通りです。
az mysql flexible-server list-skus -l eastus2 -o table
このコマンドの結果から、以下のような観点をチェックします。
- 指定しようとしている コンピューティング層（例：General Purpose / Business Critical） が一覧に含まれているか
- 必要な vCore 数の SKU がそのリージョンで提供されているか
- ゾーン冗長構成を希望する場合、該当 SKU がゾーン冗長に対応しているか
VNet 統合（プライベート アクセス）での前提条件チェック
Region access の問題が解決したら、今度は 本来のネットワーク構成の前提条件を確認しておきましょう。ここが曖昧だと、今後の運用やネットワーク変更時にトラブルの原因になります。
委任サブネット（Delegated Subnet）の設計
- Azure Database for MySQL Flexible Server をプライベート アクセスで利用する場合、サーバーは 委任サブネット に配置されます。
- このサブネットは 「Microsoft.DBforMySQL/flexibleServers」 に委任されている必要があります。
- 作成ウィザードから新規サブネットを作成する場合は、自動で委任設定されますが、既存サブネットを流用する場合は委任状態を必ず確認しましょう。
また、サブネットのアドレス空間設計にも注意が必要です。
- IP 枯渇を避けるため、十分なアドレス数を確保する（将来のスケールアウトやメンテナンスを見越して余裕を持たせる）
- 他 VNet とのピアリングや VPN 接続を行う場合は、アドレス空間の重複がないようにする
プライベート DNS ゾーンの構成
- プライベート アクセスの Flexible Server は、通常
privatelink.mysql.database.azure.comドメインのプライベート DNS ゾーンと連携します。 - ウィザードで「新規作成」を選ぶと、サーバー名に応じた必要なレコードが自動で作成されます。
- ハブ＆スポーク構成の場合、ハブ VNet のみリンクされていても、スポーク VNet に名前解決できないことがあります。接続する各 VNet とのリンク状態を確認しましょう。
| 観点 | チェック内容 |
|---|---|
| プライベート DNS ゾーンの有無 | privatelink.mysql.database.azure.com のプライベート DNS ゾーンがサブスクリプション上に存在するか |
| VNet リンク | アプリケーションが動作する VNet が、この DNS ゾーンにリンクされているか |
| DNS フォワーダー | オンプレミス接続やカスタム DNS を利用している場合、DNS フォワーダー設定が正しいか |
ネットワーク セキュリティと NSG の設定
- 委任サブネットに Network Security Group（NSG） をアタッチしている場合、必要な通信（アプリ側 VNet から DB への通信）が許可されているか確認します。
- MySQL の標準ポート（デフォルト 3306/TCP）をブロックしていないかをチェックします。
よくある勘違いと落とし穴
実際の現場でよく見かける「思い込み」を整理し、それに対する正しい認識をまとめておきます。
| よくある思い込み | 実際には… |
|---|---|
| 「ProvisionNotSupportedForRegion は VNet 設定が悪いから出る」 | 多くの場合、ネットワークではなく Region access クォータ未付与が原因です。 |
| 「リージョンを変えればそのうち動くはず」 | 別リージョンで動くのは、単にそのリージョンに Region access が付与済みなだけの可能性があります。本番で使いたいリージョンに対して正しく申請する必要があります。 |
| 「ネットワーク モードは後から簡単に切り替えられる」 | Flexible Server のネットワーク モードは、後からの切り替えが困難または非サポートであることが多いため、最初の設計が非常に重要です。 |
| 「とりあえずウィザード任せなら安全」 | ウィザードで VNet や DNS を自動作成すると、既存ネットワーク設計との整合性が崩れることがあります。ハブ＆スポーク構成などでは特に注意が必要です。 |
暫定対応：まずはパブリック アクセスで検証するという選択肢
どうしても急ぎで検証環境が必要な場合、Region access の承認を待っている間の暫定策として、一時的に「パブリック アクセス」でサーバーを作成するという手があります。
暫定対応のポイント
- 検証用途に限定し、本番データは扱わない
- Azure Database for MySQL Flexible Server の ファイアウォール ルールで、接続元 IP を最小限に絞る
- 可能であれば、Azure Bastion や踏み台 VM 経由で接続し、直接インターネットからの接続を行わない構成を検討する
Region access が付与された後、本番運用用としては改めて プライベート アクセス（VNet 統合） でサーバーを新規作成し、データ移行を行う方が安全です。ネットワーク モードの切り替えを前提にするのではなく、ネットワーク モードごとに別サーバーとして計画的に移行する方針を取ると、後戻りしづらい構成変更に悩まされにくくなります。
実務で使えるトラブルシューティング フロー
ここまでの内容を踏まえ、現場でそのまま使える簡易フローをまとめます。
| ステップ | 確認内容 | 目的 |
|---|---|---|
| 1. エラー メッセージの確認 | ProvisionNotSupportedForRegion が含まれているか | Region access 問題かどうかの切り分け |
| 2. 他リージョンでの作成テスト | 別リージョンで同条件サーバーを作成 | リージョン固有の制限かどうかを確認 |
| 3. Region access クォータ申請 | サポート リクエストで Region access を申請 | 根本原因の解消 |
| 4. 承認後の再デプロイ | 同じリージョン＋VNet 統合で再度作成 | クォータ側の問題が解消されたことを確認 |
| 5. それでも失敗する場合 | Azure Policy / RBAC / NSG / DNS 設定を確認 | ネットワーク／ポリシーの問題を切り出す |
まとめ：ProvisionNotSupportedForRegion の本当の意味を理解しておく
Azure Database for MySQL Flexible Server をプライベート アクセス（VNet 統合）で作成するときに、ProvisionNotSupportedForRegion エラーに遭遇すると、多くの人はまずネットワーク設定を疑います。しかし、実際には次のポイントを押さえておくことが重要です。
- ProvisionNotSupportedForRegion は、Region access（リージョン アクセス）クォータ未付与が原因であることが多い
- この問題は、Azure ポータルからの 「サービスとサブスクリプションの制限（クォータ）」 のサポート リクエストで解消できる
- 有償サポート契約は不要で、標準サポートの範囲で申請可能
- Region access が解決したうえで、初めて VNet／サブネット／DNS／NSG などのネットワーク設計が効いてくる
- ネットワーク モードは後からの切り替えが難しいため、設計段階でプライベート アクセス利用を前提に考えることが重要
本記事の内容を踏まえて、まずはエラー メッセージの意味を正しく読み解き、Region access を適切に申請することで、希望するリージョンに Azure Database for MySQL Flexible Server をプライベート アクセス（VNet 統合）で問題なくデプロイできるようになるはずです。
「ネットワークが悪いのでは？」と悩み続ける前に、一度サブスクリプションのクォータと Region access を確認する――それが、ProvisionNotSupportedForRegion に振り回されないための、最も効果的な一歩です。
コメント