RMNFR1 - Module Naming

ID: RMNFR1 - Category: Naming - Module Naming

Resource modules MUST follow the below naming conventions (all lower case).

Important

The module’s approved name is captured in the module proposal issue. The related module index page and CSV file remain published lookup references.

Module owners must use the name approved in the module proposal, not construct a new one. If it differs from the index, confirm the correction with the AVM core team.

Correct descriptive fields through the metadata review process. Changing moduleDisplayName does not rename the module or change its repository path.

Note

The CSV files in the AVM Central Repo (Azure/Azure-Verified-Modules) remain available for checks that use the approved singular resource names. To see their formatted content with additional information, visit the AVM Module Indexes page.

Report missing or incorrect resource names to the AVM core team. The scheduled catalog sync publishes agreed source corrections automatically; no separate index edit or publication request is required.

Bicep Resource Module Naming

  • Naming convention (module name for registry): avm/res/<hyphenated resource provider name>/<hyphenated ARM resource type>
  • Example: avm/res/compute/virtual-machine or avm/res/managed-identity/user-assigned-identity
  • Segments:
    • res defines this is a resource module
    • <hyphenated resource provider name> is the resource provider’s name after the Microsoft part, with each word starting with a capital letter separated by dashes, e.g., Microsoft.Compute = compute, Microsoft.ManagedIdentity = managed-identity.
    • <hyphenated ARM resource type> is the singular version of the word after the resource provider, with each word starting with a capital letter separated by dashes, e.g., Microsoft.Compute/virtualMachines = virtual-machine, BUT Microsoft.Network/trafficmanagerprofiles = trafficmanagerprofile - since trafficmanagerprofiles is all lower case as per the ARM API definition.

Bicep Child Module Naming

  • Naming convention (module name for registry):avm/res/<hyphenated resource provider name>/<hyphenated ARM resource type>/ <hyphenated child resource type/<hyphenated grandchild resource type>/<etc.>

  • Example: avm/res/network/virtual-network/subnet or avm/res/storage/storage-account/blob-service/container

  • Segments:

    • res defines this is a resource module
    • <hyphenated resource provider name> is the resource provider’s name after the Microsoft part, with each word starting with a capital letter separated by dashes, e.g., Microsoft.Network = network.
    • <hyphenated ARM resource type> is the singular version of the word after the resource provider, with each word starting with a capital letter separated by dashes, e.g., Microsoft.Network/virtualNetworks = virtual-network.
    • <hyphenated child resource type (to be repeated for grandchildren, etc.)> is the singular version of the word after the resource provider, with each word starting with a capital letter separated by dashes, e.g., Microsoft.Network/virtualNetworks/subnets = subnet or Microsoft.Storage/storageAccounts/blobServices/containers = blob-service/container.

Terraform Resource Module Naming

  • Naming convention:
    • avm-res-<resource provider>-<ARM resource type> (module name for registry)
    • terraform-<provider>-avm-res-<resource provider>-<ARM resource type> (GitHub repository name to meet registry naming requirements)
  • Example: avm-res-compute-virtualmachine or avm-res-managedidentity-userassignedidentity
  • Segments:
    • <provider> is a legacy requirement of the Terraform registry. This must be set to azure
    • res defines this is a resource module
    • <resource provider> is the resource provider’s name after the Microsoft part, e.g., Microsoft.Compute = compute.
    • <ARM resource type> is the singular version of the word after the resource provider, e.g., Microsoft.Compute/virtualMachines = virtualmachine