Azure Verified Modules
GlossaryGitHubGitHub IssuesToggle Dark/Light/Auto modeToggle Dark/Light/Auto modeToggle Dark/Light/Auto modeBack to homepage

Last updated: 10 Oct 2023

Module Classifications

AVM defines two module classifications, Resource Modules and Pattern Modules, that can be created, published, and consumed, these are defined further in the table below:

Module ClassificationDefinitionWho is it for?
Resource ModuleDeploys a primary resource with WAF best practice configurations set by default, e.g., RBAC, Locks, Private Endpoints etc. (if supported).

They MAY include related resources, e.g. VM contains disk & NIC. Focus should be on customer experience. A customer would expect that a VM module would include all required resources to provision a VM.

Furthermore, Resource Modules MUST NOT deploy external dependencies for the primary resource. E.g. a VM needs a vNet and Subnet to be deployed into, but the vNet will not be created by the VM Resource Module.

Finally, a resource can be anything such as Microsoft Defender for Cloud Pricing Plans, these are still resources in ARM and can therefore be created as a Resource Module.
People that want to craft bespoke architectures that default to WAF best practices, where appropriate, for each resource.

People that want to create pattern modules.
Pattern ModuleDeploys multiple resources, usually using Resource Modules. They can be any size but should help accelerate a common task/deployment/architecture.

Good candidates for pattern modules are those architectures that exist in Azure Architecture Center, or other official documentation.

Note: It is feasible that pattern modules can contain other pattern modules, however, pattern modules MUST NOT contain references to non-AVM modules.
People that want to easily deploy patterns (architectures) using WAF best practices.