Module owners MUST create the defaults, waf-aligned folders within their /tests/e2e/ directory in their resource module source code and SHOULD create a max folder also. Module owners CAN create additional folders as required. Each folder will be used as described for various test cases.

A Pattern Module MAY create Resource Group(s).

Pattern Modules MUST follow the below naming conventions (all lower case):

• Naming convention: avm/ptn/<hyphenated grouping/category name>/<hyphenated pattern module name>
• Example: avm/ptn/compute/app-tier-vmss or avm/ptn/avd-lza/management-plane or avm/ptn/3-tier/web-app
• Segments:
  • ptn defines this as a pattern module
  • <hyphenated grouping/category name> is a hierarchical grouping of pattern modules by category, with each word separated by dashes, such as:
    • project name, e.g., avd-lza,
    • primary resource provider, e.g., compute or network, or
    • architecture, e.g., 3-tier
  • <hyphenated pattern module name> is a term describing the module’s function, with each word separated by dashes, e.g., app-tier-vmss = Application Tier VMSS; management-plane = Azure Virtual Desktop Landing Zone Accelerator Management Plane

• Naming convention:
  • avm-ptn-<pattern module name> (Module name for registry)
  • terraform-<provider>-avm-ptn-<pattern module name> (GitHub repository name to meet registry naming requirements)
• Example: avm-ptn-apptiervmss or avm-ptn-avd-lza-managementplane
• Segments:
  • <provider> is the logical abstraction of various APIs used by Terraform. In most cases, this is going to be azurerm or azuread for resource modules.
  • ptn defines this as a pattern module
  • <pattern module name> is a term describing the module’s function, e.g., apptiervmss = Application Tier VMSS; avd-lza-managementplane = Azure Virtual Desktop Landing Zone Accelerator Management Plane

A Pattern Module SHOULD be built from AVM Resources Modules to establish a standardized code base and improve maintainability. If a valid reason exists, a pattern module MAY contain native resources (“vanilla” code) where it’s necessary. A Pattern Module MUST NOT contain references to non-AVM modules.

A Pattern Module MAY contain and be built using other AVM Pattern Modules. A Pattern Module MUST NOT contain references to non-AVM modules.

An item MUST be logged onto as an issue on the AVM Central Repo (Azure/Azure-Verified-Modules) if a Resource Module does not exist for resources deployed by the pattern module.

If the Resource Module adds no value, see Resource Module functional requirement ID: RMFR2 .

Parameter/variable input names SHOULD contain the resource to which they pertain. E.g., virtualMachineSku/virtualmachine_sku

A resource module MUST only deploy a single instance of the primary resource, e.g., one virtual machine per instance.

Multiple instances of the module MUST be used to scale out.

A resource module MUST add value by including additional features on top of the primary resource.

A resource module MUST NOT create a Resource Group for resources that require them.

In the case that a Resource Group is required, a module MUST have an input (scope or variable):

• In Bicep the targetScope MUST be set to resourceGroup or not specified (which means default to resourceGroup scope)
• In Terraform the variable MUST be called resource_group_name

Scopes will be covered further in the respective language specific specifications.