MS_AzureQuota - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Azureのクォータ

概要

クラスタを組んでたらエラーが出た（Azure Databricksチュートリアル）。

詳細

  • プロバイダ毎（COMP、NW、Storage 等）に、様々なクォータが存在する。
  • 各クォータは、サブスクリプションのリージョン毎に決まっているらしい。
    • 故に、リージョン毎に設定が必要で、サブスクリプション単位で指定できない。
    • わざわざ「リージョンの」と言うプレフィックスがあっても、どのクォータもリージョン毎。

補足（クォータは「制限」であり「課金の上限」ではない）: 最初に
押さえるべき点として、クォータと課金は別物である。

クォータ 予算（Budget）
何を制限するか 作れるリソースの量 何も制限しない（通知のみ）
超えたら 作成が失敗する（エラー） 通知が飛ぶだけ（動き続ける）
目的 基盤側の容量管理／利用者の暴走防止 コストの可視化

AzureのPoC環境を契約するで述べたとおり
予算アラートは課金を止めない。
したがって、費用を物理的に抑えたいならクォータを絞るのが
実効性のある手段になる。

【対策の強さ】
  予算アラート（通知）      … 気付けるだけ
       ↓
  Azure Policy（SKU 制限）  … 高価な種類を作らせない
       ↓
  クォータ（数量制限）      … そもそも量を作れない  ← 最も確実

クラウド利用時の注意事項で触れた
クリプトジャッキング（侵害されて大量の VM を起動される攻撃）への
備えとしても、vCPU クォータを必要最小限に絞っておくのが有効である。

補足（「リージョン毎」であることの実務上の影響）: 本文が
繰り返し強調しているとおり、クォータはリージョン単位である。
これは次の場面で問題になる。

場面 起きること
DR のために別リージョンへ切り替える 切り替え先のクォータが 0 に近く、VM を起動できない
検証で別リージョンを使う 同じ作業なのに片方だけ失敗する
新しいリージョンに展開する 改めて申請が必要

特に 1 つ目は深刻で、
Azureの障害復旧で
「復旧できることを実際に確認する」ことの重要性を述べたが、
クォータ不足はテスト フェイル オーバーで初めて発覚する
典型的な項目である。

DR 先リージョンのクォータを事前に確保しておくこと。
なお、Azure Site Recovery を使う場合、
平常時は VM を起動しないためクォータを消費しないが、
フェイル オーバー時には必要になる、という点に注意が要る。

VMのクォータ

vCPU数

リージョンの vCPU 数

VM サイズのvCPU数

リージョンの VM サイズ毎の vCPU 数

VM、VM ScaleSet数

リージョンの

の合計

補足（vCPU クォータが 2 段構えである点が躓きどころ）: 上の 2 つは
名前が似ているが、別々に効く 2 段の制限である。

【リージョン全体の vCPU 数】        例：合計 20 vCPU まで
     ↑ これを満たしていても
【VM サイズ（ファミリ）毎の vCPU 数】 例：Dsv3 ファミリは 10 vCPU まで
     ↑ こちらで弾かれることがある

つまり、**「全体には余裕があるのに、
そのシリーズだけ上限に達している」**という状態が起こり得る。

エラー メッセージにはどちらに引っかかったかが書かれているため、
まずそこを読むのが早い。

メッセージ 意味
Total Regional vCPUs リージョン全体の上限
Standard DSv3 Family vCPUs そのファミリの上限

回避策として、別のファミリ（例: Dasv5、Easv5）を選ぶと
通ることがある。
参考の ASCII.jp の記事「Azure VM の vCPU クォータによる制限を
回避するには」がこの話である。

なお、無料アカウントや従量課金の初期状態では
クォータが小さく設定されている
（AzureのPoC環境を契約するの
「VM サイズが B1S に限定される」もこの一種）。

ストレージのクォータ

...

ネットワークのクォータ

...

移行メモ: この 2 節は原典でも「...」のみで内容が無い。

補足（見落とされやすい主なクォータ）: VM 以外にも
実務で当たりやすいものがある。

種別 主な上限（既定） 当たる場面
パブリック IP Standard は数十／リージョン 多数の VM に個別 IP を付ける
VNET / サブネット VNET は数十／サブスクリプション 環境を分けすぎたとき
NSG / 規則数 NSG あたり 1000 規則 細かく書きすぎたとき
ストレージ アカウント 250／サブスクリプション・リージョン リソースごとに作ると枯渇
ロード バランサ規則 LB あたりの上限 多数のポートを公開
リソース グループ内のリソース数 800（種類による） 大規模な IaC
API の呼び出し回数 ARM のスロットリング IaC の一括デプロイで当たる

最後の ARM API のスロットリングは
クォータと呼ばれないことが多いが、
大量のリソースを一度にデプロイすると 429 で失敗するという形で
顕在化する（Azureの管理ポータルとARM API）。
IaC では分割してデプロイするなどの対処が要る。

なお、後掲の ASCII.jp の記事にあるとおり
**「上限変更ができないクォータ」**も存在する
（アーキテクチャ上の固定値。例: サブネットあたりの IP 数、
VNET ピアリングの上限など）。
設計段階で確認しておく必要がある。

手順

確認方法

Azure CLI

  • ログイン、サブスクリプション選択後、
  • 以下のコマンドにロケーションを指定して実行
az vm list-usage --location "Japan East" -o table

Azure PowerShell

  • ログイン、サブスクリプション選択後、
  • 以下のコマンドにロケーションを指定して実行
Get-AzVMUsage -Location "Japan East"

ポータル

ポータルのサブスクリプションから変更可能

補足（構築前に確認するのが定石）: これらのコマンドは
**「エラーが出てから調べる」**のではなく、
構築計画の段階で実行しておくべきものである。

# 現在の使用量と上限を一覧（CurrentValue / Limit）
az vm list-usage --location japaneast -o table

# ネットワーク系
az network list-usages --location japaneast -o table

# ストレージ系
az storage account list --query "length(@)"

特に、

  • 大規模な検証（AKS のノード数、Databricks のクラスタ）、
  • DR 先リージョンへの展開、
  • IaC での一括構築

の前には必ず確認する。
クォータの引き上げには申請と待ち時間（数時間〜数営業日）が発生するため、
当日に気付くと作業計画が崩れる。

変更方法

ポータルのサブスクリプション使用量 + クォータから確認可能。

ヘルプとサポート

  • ［サポート + トラブルシューティング］の［新しいサポート リクエスト］を選択
  • 若しくは、エラーメッセージ中の URL を使用する（必要な値がある程度、入力されるので簡単）。

使用量 + クォータ

  • ［場所］と［クォータ］を選択する。
  • ［使用量］のリンクから新しい［制限の値］を入力する。
  • 結局、ヘルプとサポートに飛ばされることもある。

補足（最新化：多くは自動承認されるようになった）: 本文が
「結局、ヘルプとサポートに飛ばされることもある」と書いているとおり、
当時はサポート リクエスト（人手の審査）が必要だった。

現在は「クォータ」画面から直接引き上げを申請でき、
多くの場合は自動的に即時承認される
（Quota API / My quotas 画面）。

状況 処理
一般的な範囲の引き上げ 自動承認（数分）
大幅な引き上げ、特殊な SKU（GPU 等） サポート リクエスト（人手）
容量が逼迫しているリージョン 承認されないことがある

なお、本文の
**「エラーメッセージ中の URL を使用する」**という助言は今も有効で、
必要な値（サブスクリプション、リージョン、クォータ種別）が
事前に埋まった状態でフォームが開くため、確実かつ早い。

変更例

VMのクォータ

Azure Databricksチュートリアルを参照。

ストレージのクォータ

ネットワークのクォータ

移行メモ: この 2 節は原典でも見出しのみで本文が存在しない。

参考

ASCII.jp

Microsoft Docs

Azure Resource Manager

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️