Azure Database for MySQL Flexible Server を Azure Portal から作成しようとした際、「Subscription ○○ is not allowed to provision in ‘East US 2’.」というエラーが出て先に進めない——そんな状況に悩んでいないでしょうか。本記事では、このエラーの正体と背景、すぐに業務を止めずに済む現実的な回避策、East US 2 を必須とするシステムでのクォータ申請手順、さらに再発防止の設計ポイントまでを、インフラ担当者・アプリ担当者双方の視点で詳しく解説します。
Azure Database for MySQL Flexible Server を East US 2 に作成できない現象とは
Azure Portal で Azure Database for MySQL Flexible Server を作成しようとした際、リージョンに East US 2 を選択すると、次のようなエラーが表示されることがあります。
Subscription <サブスクリプション名> is not allowed to provision in 'East US 2'.
このときのメッセージ ID は、次のように表示されるケースが多いです。
ProvisionNotSupportedForRegion
つまり、サブスクリプションが East US 2 で MySQL Flexible Server を新規作成することを許可されていない、という状態です。クレジット不足や設定ミスではなく、リージョン側の制約・キャパシティ保護による制限である点がポイントです。
なぜ East US 2 で制限がかかるのか
特定リージョンで新規リソース作成が制限される主な理由は、次のようなものです。
- そのリージョンが一時的な キャパシティ不足 になっている
- 障害やメンテナンスなどにより、新規受け入れを制御する保護ポリシー が有効化されている
- セキュリティ・コンプライアンス上、特定リージョンへの展開を クォータ（リージョンアクセス）制御 している
この制限は East US 2 に限らず、Southeast Asia や Japan East など他の人気リージョンでも報告されています。人気の高いリージョンほど、需要集中によりキャパシティ保護がかかりやすいと考えるとイメージしやすいでしょう。
エラーが出たときにまず押さえておきたいこと
このエラーは、次のような誤解を生みやすいですが、実際にはそうではありません。
- 誤解 1: サブスクリプションが無効になっている → 多くの場合、他リージョンでは問題なく作成できます。
- 誤解 2: Azure Database for MySQL Flexible Server 自体が利用不可になっている → サービスではなく「リージョン × サブスクリプション」の組み合わせが制限されています。
- 誤解 3: 自分の操作ミス → ポータルの操作は正しくても、リージョン側の制約でブロックされているだけのケースがほとんどです。
したがって、「自分の環境全体がおかしい」のではなく、「East US 2 というリージョンだけが制限されている」、という認識を持つことが重要です。
目的別の解決方針まとめ
まずは、どのようなシナリオなのかによって最適な対処が変わります。代表的なパターンと解決策を整理すると、次のようになります。
| 目的 | 手順・ポイント | 備考 |
|---|---|---|
| とにかく今すぐ使いたい | 空き容量のある 別リージョン に Azure Database for MySQL Flexible Server を作成する。 例: West US 3、East US、Central US など。 | 最も簡単で確実。アプリケーション側のリージョンやレイテンシを許容できるかを確認。 |
| East US 2 を必ず使いたい | Azure Portal から クォータ (リージョンアクセス) 申請 を行い、East US 2 での MySQL Flexible Server 利用権と必要な vCore 数を申請する。 | 審査の結果、キャパシティ状況により却下されることもある。 |
| 同様のトラブルを避けたい | 設計段階から 複数リージョン構成 (DR/HA) を検討し、クォータ確認・キャパシティ制約を前提としたアーキテクチャにする。 | 人気リージョンでは突発的な制限が起きやすいため、東西ペアや近接リージョンをセットで設計するのが安全。 |
以下では、それぞれのパターンについて、もう少し踏み込んで解説していきます。
すぐに業務を進めたい場合の現実解：別リージョンに作成する
もっとも確実で手っ取り早い解決策は、East US 2 ではなく別リージョンに MySQL Flexible Server を作成する ことです。「今すぐ環境が必要」「期限が迫っている PoC やデモがある」といった状況では、この選択が最も現実的です。
別リージョン選定の考え方
別リージョンを選ぶ際は、以下のポイントをチェックしましょう。
- アプリケーションのリージョン：App Service、AKS、VM など、アプリが動いているリージョンとの距離
- レイテンシ：ユーザーが主にどの地域からアクセスするか
- データ所在地ポリシー：国・業種によるデータレジデンシ要件
- 新しいリージョンのキャパシティ：同様の制限が発生していないか
例えば、US 東海岸のユーザーが多い場合の候補は次のようなイメージです。
| 用途のイメージ | 候補リージョン | コメント |
|---|---|---|
| US 東海岸向け Web アプリ | East US、North Central US | East US 2 に近いレイテンシ。App Service 等と同じリージョンに寄せると管理がシンプル。 |
| US 全域またはグローバルサービス | Central US、West US 3 | 全米からのアクセスをバランスさせたい場合に候補となる。 |
| DR やバックアップ用途 | East US 以外の任意の US リージョン | East US 2 障害時のバックアップリージョンとして構成しやすい。 |
Azure Portal から別リージョンに作成する手順の流れ
具体的な作成手順自体は East US 2 の場合と変わりません。違うのは 「リージョン」の選択だけ です。
- Azure Portal にサインイン。
- 「Azure Database for MySQL Flexible Server」を検索し、「作成」をクリック。
- 「基本」タブで、サブスクリプション と リソース グループ を選択。
- サーバー名、認証方式、管理者ユーザー名・パスワード を入力。
- リージョン のプルダウンで、East US 2 以外 の利用可能なリージョンを選択。
- 必要に応じて コンピューティング + ストレージ を調整。
- 確認画面で設定内容を確認し、「作成」をクリック。
これだけで、「East US 2 ではエラーだったが、別リージョンでは普通に作成できた」というケースが多くあります。まずは一度、同じサブスクリプションで他リージョンに作成できるか を試すと、原因切り分けにもなります。
別リージョンに作った場合に気を付けたいポイント
とはいえ、別リージョンに作ることで新たな懸念が生まれることもあります。代表的なものを表にまとめます。
| 観点 | 確認ポイント | 対策のヒント |
|---|---|---|
| ネットワークレイテンシ | アプリと DB が異なるリージョンにある場合、待ち時間が増えないか。 | アプリ側も同じリージョンへ移す、またはキャッシュ導入・接続プール調整で影響を抑える。 |
| データ所在地 | 国・地域の規制で「この国からデータを出せない」制約がないか。 | 法務・コンプライアンス部門に確認し、必要であれば同一地域内リージョンを選ぶ。 |
| バックアップと DR | バックアップや災害対策が元々 East US 2 基準で設計されていないか。 | 新リージョンを前提に、バックアップポリシーと DR 方式を再設計する。 |
短期的には「まず別リージョンで稼働させる」、中長期的には「本番の要件に合わせて構成を整える」という二段構えで考えると運用しやすくなります。
East US 2 を必ず使いたい場合：クォータ (リージョンアクセス) 申請の手順
システム要件や顧客指定で 「どうしても East US 2 で稼働させる必要がある」 場合は、Azure サポートに対してクォータ申請 (リージョンアクセス申請) を行う 必要があります。
申請自体は Azure Portal から数分で終わりますが、審査結果はリージョンのキャパシティ状況に依存し、必ずしも承認されるとは限りません。そのため、申請時には必要な情報を整理し、ビジネス的な重要度が伝わるように記載することが重要です。
Azure Portal からのクォータ申請手順
代表的な手順は以下の通りです。
- Azure Portal 左メニューから 「ヘルプ + サポート」 を開く。
- 「新しいサポート リクエスト」 をクリック。
- Issue type (問題の種類) で 「Service and subscription limits (quotas)」 を選択。
- Subscription で対象のサブスクリプションを選ぶ。
- Quota type で 「Azure Database for MySQL Flexible Server」 を選択。
- その後の画面で Request type に 「Region access」 を選択。
- Location に 「East US 2」 を指定。
- 必要な vCore 数、使用予定の SKU・ワークロード概要、ビジネス上の理由などを記入して送信。
どの項目に何を書くべきかを整理すると、次のようになります。
| 入力項目 | 記入内容の例 | ポイント |
|---|---|---|
| Request type | Region access | リージョンアクセスの解除・拡張を依頼する場合はこれを選択。 |
| Location | East US 2 | 問題が発生しているリージョンを正確に指定する。 |
| vCore limit | 例) 16 vCores | 必要な最大 vCore 数を少し余裕を持って指定（将来のスケールも見込む）。 |
| Workload description | 例) 24時間稼働の業務システム、トランザクション量の目安など | ビジネスの重要性・可用性要件を具体的に書くと、審査時の判断材料になる。 |
| Business justification | 例) 既存システムや他コンポーネントが East US 2 にあり、同一リージョンでの運用が必須 など | 「なぜ East US 2 でなければならないのか」を明確に記載する。 |
なお、クォータ申請自体は無料 です。承認されれば、そのリージョンで複数の MySQL Flexible Server をデプロイすることも可能になります。
どれくらいの vCore 数を申請すべきか
よくある悩みが「何 vCore 申請すればよいのか」です。目安として、以下のように考えると整理しやすくなります。
| 想定ワークロード | サーバー構成例 | 申請を検討する vCore 数の例 |
|---|---|---|
| 小規模検証環境・PoC | 1～2 台の小さいサーバー | 4～8 vCores 程度 |
| 中規模業務システム | 本番 + スタンバイ構成、もしくは読み取りレプリカあり | 16～32 vCores 程度 |
| 大規模・ミッションクリティカル | 複数レプリカ構成、環境分離 (本番 / 検証 / 開発) | 64 vCores 以上も含めて検討 |
あくまで目安ですが、「本番で一時的にスケールアップする余地」や「追加レプリカの将来追加」 なども見越して少し余裕を持った値を指定しておくと、再申請の手間を減らせます。
申請後の流れと注意点
クォータ申請を送信すると、通常は以下のような流れになります。
- サポートから受付メールが届く。
- 必要に応じて、追加の情報提供を求められることがある。
- 審査の結果、承認または却下 が通知される。
ここで重要なのは、キャパシティ状況によっては申請が拒否される場合もある という点です。そのため、「East US 2 での承認を待つ」だけに依存せず、別リージョンでの暫定運用プランも同時に準備しておく ことを強くおすすめします。
時間をおいて再試行する、という選択肢
East US 2 のような人気リージョンでは、制限が 数時間〜数日で解除される ケースもあります。そのため、急ぎでなければ以下のような運用も現実的です。
- まずは別リージョンで検証環境を構築し、アプリ動作や設定を確認しておく。
- 並行して East US 2 に対するクォータ申請を行う。
- 数日おきに East US 2 での新規作成を再試行する。
- 承認・制限解除が確認できたら、本番想定構成を East US 2 に切り替える。
このように、「待ちながらも作業を進める」 形にしておくと、時間を有効に使えるだけでなく、万一制限が長引いた場合にも柔軟に方向転換しやすくなります。
再発防止のための設計・運用ベストプラクティス
今回の問題は、一度しのげば終わりではなく、設計や運用の前提として「リージョン制限は起こり得るもの」として組み込んでおく ことが重要です。ここでは、再発を防ぐための考え方をいくつか紹介します。
複数リージョン構成 (DR/HA) を前提にする
ビジネス要件が許すなら、最初から 複数リージョン構成 を前提にアーキテクチャを設計するのがおすすめです。
- メイン：East US 2
- セカンダリ：East US または Central US
といったペア構成を考え、アプリケーション側でフェイルオーバー先の接続文字列を切り替えられるようにしておけば、キャパシティ制限だけでなく、リージョン障害全般への耐性 が高まります。
| レベル | 対策内容 | メリット | デメリット |
|---|---|---|---|
| 最小限 | バックアップだけ別リージョンに保管 | コストを抑えつつ災害時の復旧先を確保 | 復旧に時間がかかる |
| 中レベル | 読み取りレプリカやスタンバイを別リージョンに配置 | 障害時に早く切り替え可能 | 一定の追加コストが発生 |
| 高レベル | アクティブ-アクティブなマルチリージョン構成 | 可用性とパフォーマンスが高い | 設計・実装が複雑でコストも高い |
新サービス・新 SKU を使う前にクォータ状況を確認する
新しいサービスや SKUを大規模に採用する前に、クォータやリージョン制限がないかをあらかじめ確認しておく ことも重要です。
- 本番リリースの数週間〜数か月前に、小さな検証環境を同一リージョンで構築 して動作確認する。
- その際に、クォータ申請が必要かどうか を確認し、必要なら余裕を持って申請する。
- リリース直前になって初めて「作れない！」とならないよう、スケジュールに「クォータ確認」のタスクを盛り込む。
インフラ構成をコード化 (IaC) しておく
Azure Resource Manager テンプレート、Bicep、Terraform などの Infrastructure as Code (IaC) を利用して構成をコード化しておくと、今回のような制限が発生した際にも以下のようなメリットがあります。
- テンプレート内の
locationを変更するだけで、別リージョンへの切り替えが容易。 - テスト環境で East US 2、代替環境で West US 3 といった リージョン差分を比較しやすい。
- 将来のクォータ申請時にも、どれだけのリソースをそのリージョンに展開する予定か をテンプレートから把握しやすい。
「リージョンを固定して設計する」のではなく、「リージョンをパラメータ化して設計する」ことで、キャパシティ制限への柔軟性が大きく向上します。
よくある質問と補足情報
Q. 既に East US 2 に MySQL Flexible Server があるのに、新規だけ作れないのはなぜ？
これは珍しくなく、「既存リソースの稼働は継続しつつ、新規作成だけ制限される」 ケースです。リージョンのキャパシティ保護は、多くの場合「新規リソース作成」に対してのみ強く制限をかけるため、既存リソースはそのまま利用できる場合が多いからです。
とはいえ、既存リソースも将来的にスケールアップやレプリカ追加の際に制限に引っかかる可能性があります。そのため、
- 今後のスケール計画を見直し、別リージョンへの移行・追加展開を検討する
- 早めにクォータ申請を行い、将来の拡張余地を確保しておく
といった対応をしておくと安心です。
Q. クォータ申請には費用がかかりますか？
クォータ申請そのものは無料 です。承認された後、実際に作成した MySQL Flexible Server や関連リソースの利用に対して通常通り課金されます。
Q. 申請すれば必ず East US 2 で作成できるようになりますか？
いいえ、必ずしも承認されるとは限りません。リージョン全体のキャパシティ状況や、他の顧客とのバランスを踏まえて判断されるため、場合によっては却下されたり、希望より小さい vCore 数での承認となることもあります。
そのため、
- East US 2 での運用を第 1 候補としつつ、セカンドプランとして別リージョンでの構成案 を持っておく
- 業務要件的に East US 2 が必須である理由を、具体的なビジネス背景とともに説明 する
といった準備をしておくとよいでしょう。
Q. 制限が解除されるまでどれくらい待てばいいですか？
明確な SLA が公開されているわけではないため、「何日待てば必ず解除される」という保証はありません。しかし、報告ベースでは 数時間〜数日程度で解消するケースもある とされています。
ビジネス上の締め切りやリリース計画に応じて、
- 短期的には別リージョンで展開する
- 並行して East US 2 へのクォータ申請と定期的な再試行を行う
といった二本立ての運用にするのが、リスクとスピードのバランスが取りやすい方法です。
トラブルシューティングのチェックリスト
最後に、同様の問題が起きたときに確認すべきポイントをチェックリストとしてまとめておきます。実際の運用現場での切り分け作業にもそのまま使えるはずです。
| チェック項目 | 確認内容 | 対処の方向性 |
|---|---|---|
| 1. 他リージョンで作成できるか | 同じサブスクリプションで East US や West US 3 などに MySQL Flexible Server を作成してみる。 | 他リージョンで作成可能なら、サブスクリプション全体ではなく East US 2 に限定した制限と判断できる。 |
| 2. 同じサブスクリプションで他サービスは作れるか | 同じ East US 2 で VM や Storage アカウントなどが作成できるか。 | MySQL Flexible Server に限定した制限かどうかの切り分けに役立つ。 |
| 3. エラー メッセージ ID の確認 | 「ProvisionNotSupportedForRegion」など、リージョン制限を示す ID になっているか。 | クォータ申請すべきケースかどうかの判断材料になる。 |
| 4. ビジネス要件の再確認 | 本当に East US 2 固定が必須なのか、近接リージョンで代替できないか。 | 要件次第では別リージョンでの早期展開の方がビジネスメリットが高いことも多い。 |
| 5. クォータ申請の準備 | 必要な vCore 数、ワークロード概要、ビジネス上の理由を整理したか。 | 整理した内容を元に、Azure Portal から「Service and subscription limits (quotas)」で申請を行う。 |
まとめ：まずは別リージョンで業務を進め、East US 2 必須ならクォータ申請を
Azure Database for MySQL Flexible Server を East US 2 に作成しようとした際の
Subscription <サブスクリプション名> is not allowed to provision in 'East US 2'.
(メッセージ ID: ProvisionNotSupportedForRegion)
というエラーは、多くの場合、一時的またはポリシーベースのリージョン制限・キャパシティ制約 によるものです。
ビジネスを止めないための現実的なアプローチは、次の 3 つのステップに集約できます。
- まずは別リージョンで検証・暫定運用を開始する
レイテンシやデータ所在地に問題がなければ、そのまま本番展開も検討できます。 - East US 2 が必須であればクォータ (リージョンアクセス) 申請を実施する
必要な vCore 数とビジネス上の理由を整理し、Azure Portal から「Service and subscription limits (quotas)」で申請します。 - 今後のために複数リージョン構成やクォータ確認を含めた設計に見直す
DR/HA 設計、IaC によるリージョン切り替えやすさの確保など、再発しても慌てない仕組みづくりを行います。
「Azure のリージョンにはキャパシティ制限が存在し、人気リージョンでは突発的な制約が起こり得る」という前提を設計段階から織り込んでおくことで、今回のようなトラブルに遭遇しても、落ち着いて選択肢を検討できるようになります。
本記事を参考に、まずは別リージョン展開で業務を進めつつ、East US 2 が本当に必要な場合にはクォータ申請を行い、より堅牢で柔軟な Azure アーキテクチャを目指してみてください。
コメント