Azure Sponsorship サブスクリプションで Central India に Azure Database for MySQL Flexible Server を作成しようとすると ProvisionNotSupportedForRegion が表示され、準拠要件やレイテンシの要件を満たせない――この状況は珍しくありません。本稿ではエラーの原因、Azure サポート経由の「リージョンアクセス申請」の具体手順、承認までの実務的なワークアラウンド、設計時の落とし穴とチェックリストまでを網羅的に解説します。
事象の概要
Azure Sponsorship（スポンサーシップ）や一部のプロモーション系サブスクリプションで、Central India リージョンに Azure Database for MySQL Flexible Server をデプロイしようとすると、以下のようなエラーで作成が中断されることがあります。
{
"code": "ProvisionNotSupportedForRegion",
"message": "Provisioning is not supported for this resource in region 'Central India' for the current subscription."
}
このエラーは、単なる「設定ミス」ではなく、リージョンのキャパシティ制御やサブスクリプション種別に紐づく制限が背景にあることがほとんどです。ポータル、CLI、ARM/Bicep、Terraform いずれのデプロイでも同様に発生します。
なぜ起こるのか（技術的背景）
Azure の容量管理とリージョン制御
Azure では、各リージョンにおいて PaaS サービスの物理容量が綿密に管理されています。混雑時やメンテナンス時、あるいは新しいハードウェアのロールイン前後は、新規プロビジョニングの受付が抑制されることがあります。抑制は SKU（vCore サイズ、ストレージ階層、HA モード）単位で発生することもあり、GUI 上では同じ画面でも「特定の組み合わせだけ作れない」という症状が現れます。
サブスクリプション種別による優先度
企業向けの EA（Enterprise Agreement）や CSP（クラウド ソリューション プロバイダー）に比べ、Sponsorship／MSDN などのプロモーション系サブスクリプションでは優先度が低めに設定される場合があります。容量が逼迫しているリージョンでは、こうしたサブスクリプション種別に対して新規作成が一時的にブロックされることがあります。
サービス／SKU 提供状況とゾーン依存
MySQL Flexible Server は、ゾーン冗長（ZoneRedundant）や同一ゾーン HA（SameZone）などの構成オプションがあり、ゾーンごとの空き容量に依存します。「Central India では Single-AZ は可能だが、ZoneRedundant は不可」といったケースも珍しくありません。メッセージは一見同じでも、裏ではSKU×ゾーンの組み合わせが要因になっていることが多い点に注意が必要です。
よくあるエラーと意味（早見表）
| エラーコード | 典型的な原因 | 主な対処 |
|---|---|---|
ProvisionNotSupportedForRegion | リージョン／サブスク種別／SKU 組み合わせの制限または容量不足 | リージョンアクセス申請、SKU 変更、代替リージョンを一時利用 |
CapacityExhausted | 当該 SKU の一時的な容量不足 | SKU ダウンサイジング、ゾーン変更、時間をおいて再試行 |
AuthorizationFailed | ロール／権限不足（RBAC） | サブスクリプション共同管理者または所有者に付与依頼 |
MissingSubscriptionRegistration | リソース プロバイダー未登録 | Microsoft.DBforMySQL を登録 |
根本的な対処：リージョンアクセス申請の完全手順
Microsoft 側で容量・ポリシーを調整してもらうには、Azure ポータルから「Service and subscription limits (quotas)」サポート要求を起票します。最短で効果が出るルートで、かつ監査対応や社内承認にも耐えます。
ポータルでの操作フロー
- Azure ポータルで「Help + support」→「New support request」。
- Issue type は Service and subscription limits (quotas) を選択。
- Quota type で Azure Database for MySQL Flexible Server を選択。
- Problem type で Region access（または Region access with zonal dependency）を選択。
- 以下の項目を入力して送信（自動受付メールが届きます）。
| 入力項目 | 入力例 | ポイント |
|---|---|---|
| Subscription | 対象の Sponsorship サブスクリプション | サブスク ID の取り違えに注意 |
| Location | Central India | 地理要件がある旨を明確に |
| Region dependency | ZoneRedundant を希望など | HA モードを具体的に記載 |
| Requested vCores | 例：32 vCores | 将来分も含めた見積り（余裕を持たせる） |
| SKU / Tier | 例：General Purpose / Dsv5 系 | SKU が変わると可否が変わることがある |
| Business justification | 準拠要件（データレジデンシ/遅延）を明示 | 審査を短縮できる重要欄 |
記載テンプレート（そのまま流用可）
We request region access for Azure Database for MySQL Flexible Server in Central India.
- Subscription: <SUBSCRIPTION NAME/ID>
- Required region: Central India
- HA requirement: ZoneRedundant (preferred) / SameZone (acceptable)
- Initial capacity: 2 servers x 8 vCores
- Peak capacity within 3 months: 32 vCores
- Compliance: Data residency in India is mandatory
- Latency target: < xx ms to users in Maharashtra / Karnataka
- Impact: Go-live blocked; cannot meet regulatory and latency requirements
審査の観点としては「なぜ Central India でなければダメなのか」「必要な vCore と期間の妥当性」「HA モードの希望」が明確だとスムーズです。容量が確保でき次第、数日程度でアクセス付与されることが多いですが、混雑が続くと保留／却下される可能性もあります。
申請が通るまでのワークアラウンド戦略
ビジネスを止めないために、次善策のアーキテクチャを用意しておきましょう。インド国内のSouth India（Chennai）、West India（Mumbai）は同一ジオ内で、データレジデンシの要件を満たしやすい選択肢です。
代替リージョン比較（目安）
| リージョン | 所在地（代表都市） | Central India からの体感レイテンシ帯 | 補足 |
|---|---|---|---|
| South India | Chennai 周辺 | 数十 ms 程度 | 南インド拠点に有利、海底ケーブル近接で北向きはやや増 |
| West India | Mumbai 周辺 | 数 ms～数十 ms | 中央～西インドのユーザー向けに最小化しやすい |
正確なレイテンシは ISP/経路で大きく変わるため、アプリ側から実測するのが唯一の確実な方法です。MySQL Flexible Server の FQDN に対して接続試験を行い、P95/P99 を把握したうえでタイムアウトを調整します。
ネットワーク設計：VNet Peering / Private DNS
- データベースはプライベート アクセス（VNet 統合）を基本とし、アプリ VNet → DB VNet を VNet ピアリングで結びます。
- Private DNS ゾーン（
privatelink.mysql.database.azure.com）をリンクし、FQDN 解決を統一します。 - 東西トラフィックがハブ＆スポークを経由する場合、UDR（ユーザー定義ルート）と NSG を明確にし、過剰なホッピングを避けます。
後日 Central India に戻すための移行計画（ブルーグリーン）
- 暫定プライマリを South/West India に構築（Blue）。
- Central India のアクセス付与後、同リージョンに新規サーバーを構築（Green）。
- データ同期は以下のいずれか：
- MySQL のネイティブレプリケーション（バイナリログ、GTID）
- 一時停止許容なら mysqldump/mysqlpump で完全再構築
- テーブル単位の差分は MySQL Shell Dump & Load を活用
- 切替手順（例）：
- アプリ書き込みを短時間停止。
- レプリケーション遅延が 0 になるのを確認。
- Central India 側を昇格（Promote）。
- DNS（アプリの接続文字列）を切替、アプリを再開。
想定ダウンタイムを数分に抑えるため、接続プールのドレインや長時間トランザクションの抑止など、アプリ側の手順書も同時に整備します。
設計・運用の落とし穴とチェックリスト
事前チェック（失敗を減らすゴールデンルール）
- リソース プロバイダー登録：
Microsoft.DBforMySQLを未登録のままにしない。 - SKU の引き当て可能性：容量が逼迫しやすい vCore サイズや HA モードは特に注意。
- Allowed locations の Azure Policy：組織のガバナンスで Central India 自体が禁止されていないか。
- RBAC 権限：Owner/Contributor が適切に付与されているか。
- サブスク種別：Sponsorship で商用 SLA を求める場合のリスク評価と、将来的な EA/CSP への移行計画。
運用・監視観点（Flexible Server ならでは）
- バックアップ保持と PITR：バックアップ保持期間を法令・社内規定に適合させ、復元テストを四半期ごとに定期実施。
- 高可用性：ZoneRedundant を採用する場合、ゾーン障害時の挙動（フェールオーバー時間、接続再試行）を負荷試験に含める。
- メンテナンス ウィンドウ：適用時間帯とアプリ SLAs の整合性を確認。
- 接続暗号化：
sslmode=REQUIRED（ドライバに応じた相当設定）を標準に。
実務で使えるコマンド／設定サンプル
リソース プロバイダー登録
# Azure CLI
az provider register --namespace Microsoft.DBforMySQL
az provider show --namespace Microsoft.DBforMySQL --query "registrationState"
Central India の提供 SKU を確認
# Azure CLI（MySQL Flexible Server）
az mysql flexible-server list-skus --location centralindia -o table
この出力で、いま現在 Central India で引き当て可能な vCore サイズやストレージ SKU、HA モードの有無を把握できます。作りたい構成が一覧に出てこない場合、リージョンアクセス申請の依頼文に「代替案（次善の SKU）」も添えておくと通りやすくなります。
接続レイテンシの可視化（アプリ側での実測）
# 例：MySQL クライアントからの簡易計測（擬似コード）
for i in {1..100}; do
START=$(date +%s%3N)
mysql -h <server>.mysql.database.azure.com -u <user> -p'<pwd>' -e "SELECT 1" >/dev/null
END=$(date +%s%3N)
echo "$((END-START))"
done | awk '{sum+=$1; arr[NR]=$1} END{print "avg:",sum/NR}'
本格導入前に P50/P95/P99 の応答分布を取り、アプリのタイムアウトやリトライ戦略と整合させます。
エンタープライズ設計の観点（コンプライアンス＆レジデンシ）
金融・公共・医療などでは、インド国内データレジデンシや利用者所在地に応じた遅延保証が求められることがあります。Central India が要求仕様に明記されている場合は、リージョンアクセス申請に法令・契約根拠を添えてください。監査時の説明責任を果たすため、下記のようなエビデンス管理を推奨します。
- 申請内容・受付メール・結果通知の保管（チケット ID・日時）。
- 暫定構成（South/West India）の期間、移行完了日時の記録。
- 移行後のレイテンシ測定結果（Before/After の比較）。
トラブルシューティング（陥りがちな詰まりどころ）
Allowed locations ポリシーで弾かれている
企業テナントでは「許可リージョン」を限定する Azure Policy が入っているケースが多く、Central India が除外されているだけということもあります。デプロイ前にポリシー割り当てを確認し、必要に応じて例外（Exemption）を申請します。
Private Access 周りの名前解決ミス
プライベート エンドポイントを用いた場合、アプリ VNet から Private DNS へのリンクが欠けていると、FQDN が Public に解決されて接続に失敗します。DNS 解決の実測（nslookup/dig）をデプロイ手順に含めましょう。
HA モードの選択と容量のトレードオフ
ZoneRedundant は耐障害性が高い反面、必要なゾーン側の空きが足りずに作成できないことがあります。暫定的に SameZone（同一ゾーン HA）で開始し、後日 ZoneRedundant にリプレースする計画も現実的です。
問い合わせ～解消までの標準オペレーション（プレイブック）
- 前提確認：RBAC／Policy／プロバイダー登録／SKU 提供可否をチェック。
- 事前実測：South/West India で PoC を作り、レイテンシと吞み込み性能を計測。
- リージョンアクセス申請：Central India と必要 vCore、HA 希望、正当性を明記。
- 暫定運用：代替リージョンをプライマリに据え、VNet Peering と Private DNS を整える。
- エビデンス管理：チケット、測定値、意思決定ログを保管。
- アクセス付与後の切替：Blue/Green またはレプリカ昇格でダウンタイム最小の移行。
- 事後検証：SLI/SLO を更新、運用 Runbook に反映。
よくある質問（FAQ）
Q. 申請すれば必ず Central India で作成できますか？
A. いいえ。容量や方針により却下・保留となる場合があります。代替 SKU・HA モード・段階的導入計画を添えることで可能性が上がる傾向があります。
Q. Sponsorship から EA/CSP に変えると改善しますか？
A. 容量が逼迫している局面での優先度やエスカレーションの選択肢が広がるため、商用運用では EA/CSP への移行を検討する価値があります。
Q. Terraform/ARM/Bicep での自動化は？
A. 申請が通るまで同じエラーで失敗します。CI/CD は「代替リージョンを使うブランチ」と「Central India に切り替えるブランチ」を分けると運用が安定します。
ケーススタディ：最小ダウンタイムでの切替例
前提：暫定プライマリは West India、Central India のアクセスが承認済み。24/7 サービスでダウンタイムは 5 分以内。
- Central India に同一バージョン・同一パラメータで MySQL Flexible Server を新規作成。
- West India からダンプ（
mysqldump --single-transaction）を取得し、Central India にロード。 - 以降の差分はネイティブレプリケーションで同期（GTID 有効を推奨）。
- メンテナンスウィンドウで書込みを停止し、レプリケーション遅延が 0 を確認。
- Central India をプライマリに昇格、接続文字列（Key Vault/設定ストア）を切替。
- アプリ再開、エラーレートと P95 を監視、問題なければ旧系を段階停止。
セキュリティとガバナンスのベストプラクティス
- ネットワーク境界：Public Access は原則無効。Private Endpoint + NSG + UDR で強制。
- 資格情報管理：Key Vault とマネージド ID（接続文字列の参照のみを許可）。
- 監査：サーバーログ、クエリ監査、アラート（CPU、接続数、IOPS、レプリ遅延）。
- 変更管理：SKU 変更やメンテ時間の事前承認プロセスを定義。
要点の再整理
- ProvisionNotSupportedForRegion は「あなたの構成やサブスクでは今は作れない」という容量・方針起因のメッセージ。
- 根本対処は 「Service and subscription limits (quotas)」→「Region access」申請。
- 承認までの間は South/West India を暫定利用し、ブルーグリーンまたはレプリカ昇格で Central India へ復帰。
- 設計段階でSKU 提供可否・Policy・RBACを先に確認すれば、後戻りを大きく減らせます。
チェックリスト（コピーして使える運用メモ）
| カテゴリ | 確認項目 | 状態 |
|---|---|---|
| アカウント | 対象サブスクリプションに Owner/Contributor 権限がある | ☐ |
| プロバイダー | Microsoft.DBforMySQL が Registered | ☐ |
| ポリシー | Allowed locations で Central India が許可されている | ☐ |
| SKU | Central India の list-skus に希望 SKU/HA が存在する | ☐ |
| 申請 | Region access 申請のチケット ID を記録した | ☐ |
| 暫定構成 | South/West India の代替プランとレイテンシ測定が完了 | ☐ |
| 移行 | 切替手順書（ドレイン、昇格、DNS 更新）が用意されている | ☐ |
まとめ
ProvisionNotSupportedForRegion は、Central India に MySQL Flexible Server を「いまこの条件では」作れないというシグナルです。焦って構成を妥協するのではなく、リージョンアクセス申請と暫定運用の二段構えで乗り切るのが定石です。代替リージョンでの実測とネットワーク設計を先に固め、承認後はブルーグリーン／レプリカ昇格で計画的に Central India へ戻す――この王道パターンをチームの標準手順に落とし込めば、規制・性能・運用の三拍子を高水準で満たせます。
付録：依頼文の日本語テンプレ（社内承認用）
件名：Azure MySQL Flexible Server（Central India）リージョンアクセス申請のお願い
背景：
* インド国内データレジデンシおよびレイテンシ要件により、Central India での稼働が必須。
* 現状、ProvisionNotSupportedForRegion によりデプロイ不可。
依頼内容：
* Central India に対する Azure Database for MySQL Flexible Server のリージョンアクセス付与
* 初期 2 台 × 8 vCores、3 か月以内に最大 32 vCores を想定
* HA：ZoneRedundant（第一希望）、SameZone（許容）
ビジネス影響：
* 本番リリースのクリティカルパス上にあり、代替リージョン運用は暫定措置。
* SLA を満たすため、XX 日までの対応を希望。
以上、よろしくお願いいたします。 付録：よく使う用語の短縮リファレンス
| 用語 | 意味 | 補足 |
|---|---|---|
| Region access | 特定リージョンでの新規作成許可 | 容量確保や種別制限の緩和 |
| ZoneRedundant | 複数 AZ を跨いだ HA | ゾーン容量に依存、切替を伴う |
| SameZone | 同一 AZ 内の HA | 対障害性は落ちるが引き当てやすい |
| list-skus | 提供 SKU の一覧取得 | 構成可否の事前確認に必須 |
付録：失敗しない依頼のコツ
- 「なぜ Central India か」を定量化：準拠要件の条項、レイテンシ測定値、ユーザー分布。
- 代替案もセット：SKU の第二希望、SameZone 許容範囲、段階導入のロードマップ。
- 運用準備の証跡：監視・バックアップ・復元テスト計画を添付。
付録：エスカレーションの判断基準
承認が長引く場合は、以下のいずれかに該当した時点でエスカレーションを検討してください。
- 法令・契約 SLA を充足できないリスクが具体化。
- レイテンシが UX/KPI に顕著な悪影響（例：P95 > 2× 目標）。
- 四半期の財務報告・監査タイムラインに間に合わない恐れ。
以上、Central India での Azure Database for MySQL Flexible Server プロビジョニング不可に直面したときの「原因の見立て・申請の通し方・止めない運用」の全手順をまとめました。この記事をそのままチームの Runbook にコピーして、今日から実装を進めてください。
コメント