Resource Provider Registration / API Versionを理解するための前提
Azure resource providerは特定Azure serviceの機能を支えるREST operationの集合で、resource typeはprovider/type形式で表現される。 provider registrationはsubscription単位だがsupported regionごとに進み、必要regionがRegisteredになればresource creationを開始できる。
provider registrationには/providerNamespace/register/actionが必要で、Contributor/Ownerに含まれる。 Microsoftはleast privilegeのため、使用準備ができたproviderだけをregisterするよう案内している。
API versionはresource provider REST APIのversionであり、新機能やpropertyを使うIaC/RESTでは実際に利用可能なversionを確認する。
Control plane と Data plane
仕組みと設計上の意味
ARM deploymentの「resource typeが見つからない」「NoRegisteredProviderFound」「MissingSubscriptionRegistration」は、単なるservice outageではなくprovider registration、region support、API versionの三角形で切り分けます。Portalが自動registerするケースがあるため、同じsubscriptionでも過去の利用履歴によって状態が違います。
registrationは全regionが完了するまで一括で待つ必要はありません。Microsoft Learnは、登録処理はsupported regionごとに行われ、対象regionで完了していればcreationを続行できると説明しています。逆に新しいlocation supportが追加された場合はre-registerが必要になることがあります。
Operational / decision path
対象scopeと時刻を固定し、read-only evidence → 判断 → change → same testで再検証の順を崩さない。
- エラーのresource provider namespace / resource type / location / api-versionを抽出する。
- subscriptionのregistrationStateをread-onlyで確認する。
- 対象resource typeのLocationsとApiVersionsをprovider metadataから確認する。
- template/Bicep/Terraform/RESTが指定するversionと必要propertyを照合する。
- register/re-registerが必要な場合はchangeとして扱い、完了後に同じdeploymentを再試行する。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Registration | 必要providerのみregister | least privilegeとtenant app sprawlを抑える |
| API version | GA優先、Previewは明示的に採用 | feature dependencyとsupport boundaryを管理 |
| Region support | deployment前にLocationsを確認 | provider registeredでもresource typeがregion非対応の場合がある |
| IaC | api-versionをsource controlで固定 | Portal生成差分やprovider upgradeを再現可能にする |
確認手順
Azure Portal
- Subscriptions → Resource providersでMicrosoft.Network等のregistration stateを確認。
- Resource Explorerでprovider → resource typeを開き、valid locations / API versionsを確認。
- deployment errorのOperation detailsからnamespace/type/api-version/locationを控える。
Evidence contract
Read-only first: 以下のCLI/PowerShellは原則として参照系から開始します。コメントでMUTATINGと示した操作は、必要性・scope・rollbackを確認した後にのみ実行します。
# read-only first
az provider list --query "[].{Provider:namespace,Status:registrationState}" -o table
az provider show --namespace Microsoft.Network -o jsonc
az provider show --namespace Microsoft.Network --query "resourceTypes[?resourceType=='virtualNetworks'].{type:resourceType,apiVersions:apiVersions,locations:locations}" -o jsonc
# MUTATING: registrationが必要と判断した場合のみ
# az provider register --namespace Microsoft.NetworkGet-AzResourceProvider -ListAvailable |
Select-Object ProviderNamespace, RegistrationState
(Get-AzResourceProvider -ProviderNamespace Microsoft.Network).ResourceTypes |
Where-Object ResourceTypeName -eq 'virtualNetworks' |
Select-Object ResourceTypeName, ApiVersions, Locations
# MUTATING: 必要時のみ
# Register-AzResourceProvider -ProviderNamespace Microsoft.Network障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| MissingSubscriptionRegistration | provider未登録 | registrationState + deployment error | register権限と必要性を確認 |
| NoRegisteredProviderFound | region/api-version/resource type mismatch | provider metadata | Locations/ApiVersionsを照合 |
| Registeringが長い | 全region完了待ちをしている | 対象regionのprovider state | 対象regionでcreation可能か再確認 |
| IaCだけ失敗、Portalは成功 | IaC api-version/propertyが古い/新しすぎる | deployment template + provider metadata | supported GA versionへ調整 |
変更・rollback
- provider register/re-registerはcontrol-plane changeとして記録し、read-only確認と混同しない。
- 不要providerのunregisterは、そのproviderのresourceがsubscriptionに残っていると実行できない。resource inventoryを先に取る。
- api-version変更はproperty defaultやresponse schema差を伴う可能性があるため、plan/what-ifと実deploymentを分けて検証する。
- rollbackは元のtemplate/provider versionをsource controlで保持し、provider registration自体の即時unregisterを安易なrollbackにしない。