Avm Tf Classifications

AVM module classifications & naming (Terraform)

Every AVM module is exactly one of three classes. The class drives the naming convention, the repo name, the spec set that applies, and the review process.

Classification does not change the provider rule. Every new resource, pattern, or utility module repository that deploys Azure resources MUST use AzAPI for every control-plane and supported direct Azure operation. Each permitted azurerm_* resource or data-source block must independently implement one specific unsupported data-plane/non-ARM operation, document the exact block and AzAPI gap with an upstream AzAPI issue or pull request, and be replaced when support ships. One valid block does not authorize another.

Fetch https://azure.github.io/Azure-Verified-Modules/llms.txt and confirm the current versions of these sources:

• https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/content/specs-defs/module-classifications.md
• RMNFR1 — Resource Module Naming
• PMNFR1 — Pattern Module Naming
• RMFR1 — Single Resource Only
• RMFR2 — No Resource Wrapper Modules

The three classes

Resource module (avm-res-)

Deploys a single instance of one primary Azure resource (RMFR1) — e.g. one Key Vault, one Storage Account, one Search Service — plus the standard cross-cutting interfaces (lock, RBAC, diagnostic settings, private endpoints, etc. — see avm-tf-interfaces) and child resources that don't add value as standalone modules.

The primary resource MUST be implemented with AzAPI. Do not create a new AzureRM-based resource module.

If a consumer needs N instances of the resource, they call the module N times. The module itself never loops over the primary resource.

Must add value over raw azapi_resource (RMFR2) — usually via the standard interfaces, validation, and sensible WAF-aligned defaults. If your module is a thin wrapper that just passes inputs through to a single azapi_resource, you don't have a resource module — you have a useless module.

Pattern module (avm-ptn-)

Deploys an opinionated multi-resource solution to a recurring problem — e.g. "hub-and-spoke landing zone", "AKS baseline", "AI Foundry workspace with all dependencies". Pattern modules compose resource modules (TFFR1 — Cross-Referencing Modules requires them to consume AVM resource modules where available rather than re-implementing).

If a resource module doesn't exist for a resource the pattern needs, the pattern owner MUST log an issue on the central AVM repo requesting it (PMNFR4).

Any control-plane resource implemented directly in a pattern module MUST use AzAPI. The absence of an AVM resource module is not permission to use AzureRM.

Utility module (avm-utl-)

Provides shared logic with no resource deployments of its own, or rarely with a single supporting resource (e.g. a deployment script). Today the canonical example is avm-utl-interfaces — the variable schemas for the standard cross-cutting interfaces. Utility modules are introduced gradually and the specifications around them are still maturing.

If a utility module deploys a supporting control-plane Azure resource, that resource MUST use AzAPI.

If a utility module deploys no resources, telemetry collection MUST NOT be added (SFR3).

Decision tree

Are you deploying Azure resources?
  ├─ No → utility module (avm-utl-)
  └─ Yes
       ├─ Exactly one primary resource (+ standard interfaces + child resources)?
       │    └─ Yes → resource module (avm-res-)
       └─ Multiple primary resources composed into a solution?
            └─ Yes → pattern module (avm-ptn-)

If you find yourself wanting to deploy "a Key Vault AND a Storage Account" as one module, that's a pattern module composing two resource modules — not a single resource module.

Naming conventions

Module name (used in the Terraform Registry and in the proposal issue)

Notes on the resource segment:

• <resource provider> is the lowercased and trimmed ARM provider name — Microsoft.KeyVault → keyvault, Microsoft.Storage → storage, Microsoft.Search → search.
• <ARM resource type> is the lowercased and singular-ish resource type — vaults → vault, storageAccounts → storageaccount, searchServices → searchservice, virtualMachines → virtualmachine.
• For sub-resources that warrant their own module: avm-res-keyvault-vault-key, avm-res-storage-storageaccount-blob. But sub-resources within a single resource module live under modules/ (TFRMNFR1) — not every child resource becomes its own AVM module.