2026年6月3日に確認された公式更新のポイントは、Azure Database for MySQL Flexible Server のクォータ管理を、Azure portal の Azure Quotas からセルフサービスで行いやすくなったことです。現在の使用量と上限を確認し、必要に応じてクォータ引き上げをポータル上で依頼できます。多くのケースではサポートチケットを作らずに処理できるため、新規デプロイやスケール変更の前に「上限不足で失敗する」リスクを減らせます。(マイクロソフトアジュール)
注意点として、この更新の直接対象は Azure SQL Database ではなく Azure Database for MySQL Flexible Server です。Azure SQL 管理者も「Azure のクォータ管理」という観点では関係がありますが、Azure SQL のクォータ申請とは対象サービス、申請種別、確認すべき項目が異なります。混同せず、MySQL Flexible Server を使っているサブスクリプション・リージョン・SKU ファミリを確認することが重要です。
Azure Database for MySQL Flexible Server のクォータ管理で何が変わったのか
今回の更新では、Azure Database for MySQL Flexible Server 向けに、Azure portal の Quotas ページから使えるクォータ管理体験が一般提供になりました。Azure Updates では本件が Launched として掲載されており、Azure Updates 上の Launched は「本番利用可能で、すべての Azure 顧客が利用できる状態」を示すステータスです。(マイクロソフトアジュール)
主な変更点は次のとおりです。
| 変更点 | 実務上の意味 |
|---|---|
| Azure Quotas から MySQL Flexible Server のクォータを確認できる | サブスクリプション、リージョン、SKU ファミリごとの使用量を把握しやすくなる |
| 現在の vCore 使用量と上限を確認できる | 本番展開前に「あと何 vCore 使えるか」を確認できる |
| クォータ引き上げをポータル上で依頼できる | 多くのケースでサポートチケット作成前提の運用を減らせる |
| 多くの申請は自動承認の対象になる | 小〜中規模の増加であれば、手動レビュー待ちを短縮しやすい |
| 自動承認できない場合はサポート要求に進める | 大きな増加、複数サブスクリプション、リスク判定が必要なケースにも対応できる |
Microsoft Learn では、このセルフサービス体験により、現在の使用量確認、インラインでの増加申請、多くのリクエストの数分以内の自動承認、デプロイ失敗前の予防的な確認が可能になると説明されています。ただし、すべての申請が自動承認されるわけではなく、上限超過や不審な利用パターンが疑われる場合はレビューに回る点も押さえておきましょう。(Microsoft Learn)
そもそも Azure のクォータとは何か
Azure のクォータは、サブスクリプションに割り当てられたリソース利用上限です。仮想マシン数、ストレージアカウント数、ネットワークリソース数、API 呼び出し数など、Azure サービスごとにカウント可能なリソースに対して設定されます。クォータは、誤った大量デプロイや想定外の消費から利用者を保護するための仕組みです。(Microsoft Learn)
重要なのは、クォータを増やすこと自体が即コスト増になるわけではない点です。Microsoft Learn でも、クォータ増加要求に関連するコストはなく、コストはクォータそのものではなく実際のリソース使用量に基づくと説明されています。つまり、クォータ引き上げは「使える上限を広げる」操作であり、「自動的にリソースを増やす」操作ではありません。(Microsoft Learn)
ただし、上限を広げた後にサーバーを追加したり、vCore 数を増やしたりすれば、その分の利用料金は発生します。管理者は、クォータ申請とコスト管理を分けて考えつつ、実際の展開計画と予算承認をセットで確認する必要があります。
影響範囲：Azure SQL ではなく MySQL Flexible Server が直接対象
今回の公式更新は、Azure SQL の AI/Copilot 機能更新ではありません。対象は Azure Database for MySQL Flexible Server のクォータ管理です。
Azure SQL Database や Azure SQL Managed Instance でもクォータ申請は存在しますが、Microsoft Learn では Azure SQL Database のクォータ申請種別として、vCores per subscription、Region access、Zone Redundant Access が示されています。また、Azure SQL Database では購入モデルに関係なく、クォータ申請は vCore ベースで扱われ、DTU モデルでは目安として 1 vCore ≒ 100〜125 DTU の換算が案内されています。(Microsoft Learn)
| 観点 | Azure Database for MySQL Flexible Server | Azure SQL Database / Managed Instance |
|---|---|---|
| 今回の GA 更新の直接対象 | 対象 | 対象外 |
| 主に確認する単位 | サブスクリプション、リージョン、SKU ファミリ、vCore 使用量 | サブスクリプション、リージョン、vCore、可用性ゾーン関連など |
| ポータル上のプロバイダー名 | Azure Database for MySQL flexible servers | SQL Database / SQL Managed Instance 系 |
| 注意点 | SKU ファミリごとに必要なクォータを確認する | Azure SQL 専用の申請種別・手順を使う |
社内の更新情報やチケットで「Azure SQL のクォータ管理」とまとめられている場合でも、実際に対象リソースが MySQL Flexible Server なのか、Azure SQL Database なのかを最初に切り分けてください。ここを誤ると、違うプロバイダーのクォータを見てしまい、デプロイ直前まで上限不足に気付けません。
管理者が確認すべき設定と運用ポイント
Azure 管理者や DBA がまず見るべきなのは、どのサブスクリプション・リージョン・SKU ファミリで上限に近づいているかです。MySQL Flexible Server のクォータは、コンピューティング層ごとに SKU ファミリとして扱われます。Microsoft Learn では例として、Burstable Series の standardBSFamily、General Purpose Series の standardDDSv4Family や standardDADSv5Family、Business Critical Series の standardEDSv4Family などが挙げられています。(Microsoft Learn)
特に次のケースでは、事前確認が必須です。
- 本番環境を新しいリージョンに追加する
- 検証環境から本番環境へ同じ構成を複製する
- Burstable から General Purpose へ変更する
- 高負荷対策で vCore 数を増やす
- 障害復旧やリストアで別リージョンにサーバーを作成する
- 複数チームが同じサブスクリプションを共有している
クォータは「サブスクリプション全体で共有される上限」として効いてくるため、別チームの検証環境が vCore を使っているだけでも、本番デプロイ時に不足することがあります。月次の棚卸しだけでなく、大きな展開やリリースの前に確認する運用へ変えるのが現実的です。
Azure portal でクォータを確認・申請する手順
Azure portal での基本的な流れは次のとおりです。Microsoft Learn では、Quotas ページを開き、プロバイダーとして Azure Database for MySQL flexible servers を選び、サブスクリプションやリージョンで絞り込む手順が案内されています。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Azure portal にサインインする | 正しいテナント・ディレクトリにいるか確認 |
| 2 | 検索バーで Quotas を検索する | Services の Quotas を開く |
| 3 | プロバイダーで Azure Database for MySQL flexible servers を選ぶ | Azure SQL など別サービスを選ばない |
| 4 | サブスクリプションとリージョンで絞り込む | 本番環境で使うリージョンを指定する |
| 5 | Current Usage と上限を確認する | 使用率が高い SKU ファミリを優先確認 |
| 6 | 対象行のペンアイコンから申請する | 増分ではなく「新しい合計上限」を入力する |
| 7 | 申請結果を確認する | 自動承認、部分承認、サポート要求への遷移を確認 |
よくある失敗は、増やしたい分だけを入力してしまうことです。たとえば現在の上限が 35 vCore で、追加で 10 vCore 必要な場合、入力する新しい上限は 10 ではなく 45 です。Microsoft Learn でも、現在の制限が 35 の Burstable Series に 10 vCore 追加したい場合は、新しい制限として 45 を入力する例が示されています。(Microsoft Learn)
開発者が意識すべきデプロイ上の注意点
開発者にとってのメリットは、デプロイ前に「失敗しそうな原因」を見つけやすくなることです。Azure Database for MySQL Flexible Server では、クォータ不足時に Not enough quota to provision or update the server for your subscription. のようなエラーが発生する可能性があります。Microsoft Learn では、この場合の解決策としてクォータ増加要求の送信が案内されています。(Microsoft Learn)
ただし、デプロイ失敗の原因はクォータ不足だけではありません。次のようなケースでは、クォータを増やしても解決しない可能性があります。
| エラーの種類 | 起きやすい場面 | 対応の考え方 |
|---|---|---|
| クォータ不足 | vCore 上限を超えるサーバー作成・スケール変更 | Azure Quotas で対象 SKU ファミリの上限を増やす |
| リソースプロバイダー未登録 | 初めて MySQL Flexible Server を使うサブスクリプション | Microsoft.DBforMySQL の登録状態を確認する |
| リージョン未対応・制限 | 特定リージョンで新規作成する | 別リージョンの検討、またはサポート要求 |
| SKU 未対応・一時的な不足 | 特定 SKU への作成・変更 | 別 SKU の検討、またはサポート要求 |
| 可用性ゾーン未対応 | ゾーン指定で作成する | 別ゾーン・別リージョンを検討する |
特に CI/CD でインフラを自動作成している場合、Bicep、Terraform、Azure CLI のテンプレートが正しくても、サブスクリプション側のクォータ不足で失敗することがあります。リリース当日に気付くと復旧に時間がかかるため、パイプライン実行前のチェック項目に「対象リージョンの MySQL Flexible Server クォータ確認」を入れておくと安全です。
移行・展開前に確認したいチェックリスト
MySQL Flexible Server の移行や新規展開では、クォータ確認を設計フェーズに組み込むべきです。サーバー作成直前ではなく、構成を決めた段階で確認すると手戻りを減らせます。
| 確認項目 | 判断基準 | 見落とした場合のリスク |
|---|---|---|
| サブスクリプション | 本番・検証・DR 用で分かれているか | 違うサブスクリプションの上限を確認してしまう |
| リージョン | 実際にデプロイするリージョンか | Japan East は足りるが Japan West は足りない、などが起きる |
| SKU ファミリ | Burstable、General Purpose、Business Critical のどれか | スケール変更時に別ファミリの上限不足で失敗する |
| 必要 vCore 数 | 現在分、追加分、将来増加分を分けて見積もる | 申請直後に再申請が必要になる |
| HA・レプリカ・復旧構成 | 追加サーバー分も含めて見積もる | 障害対応時に復旧先を作れない |
| 承認リードタイム | 自動承認されないケースを想定する | リリース日程に影響する |
| コスト承認 | クォータではなく実リソース増加分で見る | 使い始めてから想定外の請求になる |
クォータ申請は、運用チームだけの作業に見えますが、実際にはアプリケーション設計にも影響します。たとえば「ピーク時だけ vCore を増やす」「本番と同等構成の検証環境を一時的に作る」「リリース前にレプリカを追加する」といった判断は、すべて利用可能なクォータに左右されます。
申請が自動承認されない場合の対応
セルフサービスで完結しない場合は、サポート要求に進みます。Microsoft Learn では、自動的に満たせない場合や、多数のサブスクリプションに対するクォータが必要な場合はサポート要求を開くと説明されています。また、Azure Database for MySQL Flexible Server のクォータ要求は 24〜48 時間で処理されると案内されています。(Microsoft Learn)
サポート要求に進む場合は、次の情報を事前に整理しておくとやり取りがスムーズです。
- 対象サブスクリプション
- 対象リージョン
- 対象 SKU ファミリ
- 現在の上限と希望する新しい上限
- 申請理由
- デプロイ予定日
- 業務影響
- 発生しているエラーメッセージ
- 代替リージョンや代替 SKU を検討済みか
「とにかく増やしたい」ではなく、「このリージョンで本番環境を何台構成し、合計何 vCore 必要」という形で説明できると、承認判断や代替案の提示を受けやすくなります。
よくある誤解と失敗しやすいポイント
クォータを増やせば必ずデプロイできるわけではない
クォータは上限の問題です。リージョン制限、SKU の一時的な不足、可用性ゾーン未対応、リソースプロバイダー未登録などは別の問題です。Microsoft Learn でも、SKU の可用性はリージョンによって異なり、特定 SKU がリージョンで未対応または一時的に利用できない場合があると説明されています。(Microsoft Learn)
新しい上限は「増分」ではなく「合計」で入力する
現在 35 vCore の上限を 45 vCore にしたい場合、入力するのは 10 ではなく 45 です。ここを間違えると、意図した上限にならず再申請が必要になります。
Azure SQL のクォータ画面を見て安心しない
Azure SQL Database と Azure Database for MySQL Flexible Server は別サービスです。Azure SQL 側の vCore クォータに余裕があっても、MySQL Flexible Server の SKU ファミリに余裕があるとは限りません。
使用量が低くても将来の展開で不足することがある
現在の使用率が低くても、本番展開、障害復旧訓練、検証環境の複製、レプリカ作成が重なると一気に上限に近づきます。リリース計画や DR 計画に必要 vCore 数を含めて確認してください。
通知だけに頼りすぎない
Microsoft Learn では、クォータ要求のフライアウトを閉じると、そのリクエストのポータル通知が停止する既知の制限も示されています。通知を待つだけでなく、Quotas ページに戻って更新後の上限を確認する運用にしておくと安全です。(Microsoft Learn)
まず取るべき行動
Azure Database for MySQL Flexible Server を運用している場合は、次の順で確認してください。
- Azure portal で Quotas を開く
- プロバイダーに
Azure Database for MySQL flexible serversを選ぶ - 本番で使うサブスクリプションとリージョンに絞る
- SKU ファミリごとの Current Usage と上限を見る
- 直近 3〜6 か月の展開予定を vCore 数に直す
- 不足しそうな SKU ファミリは早めに新しい合計上限で申請する
- 自動承認されない場合に備え、サポート要求用の情報を準備する
今回の GA は、MySQL Flexible Server の性能や料金体系を直接変える更新ではありません。価値があるのは、クォータ不足をリリース当日の障害ではなく、事前に管理できる運用課題へ変えられる点です。管理者は Azure Quotas を定期確認の対象に加え、開発者はデプロイ手順の前提条件にクォータ確認を入れておきましょう。
コメント