Resource modules MUST implement a common interface, e.g. the input’s data structures and properties within them (objects/arrays/dictionaries/maps), for the optional features/extension resources:
Parameters/variables that pertain to the primary resource MUST NOT use the resource type in the name.
e.g., use sku, vs. virtualMachineSku/virtualmachine_sku
Another example for where RPs contain some of their name within a property, leave the property unchanged. E.g. Key Vault has a property called keySize, it is fine to leave as this and not remove the key part from the property/parameter name.
Module owners MUST output the following outputs as a minimum in their modules:
| Output | Bicep Output Name | Terraform Output Name |
|---|---|---|
| Resource Name | name | name |
| Resource ID | resourceId | resource_id |
| System Assigned Managed Identity Principal ID (if supported by module) | systemAssignedMIPrincipalId | system_assigned_mi_principal_id |
Module owners MAY also have to provide additional outputs depending on the IaC language, please check the language specific specs:
RMFR8 - Dependency on child and other resources
A resource module MAY contain references to other resource modules, however MUST NOT contain references to non-AVM modules nor AVM pattern modules.
RMFR9 - End-of-life resource versions
When a given version of an Azure resource used in a resource module reaches its end-of-life (EOL) and is no longer supported by Microsoft, the module owner SHOULD ensure that:
RMNFR1 - Module Naming
We will maintain a set of CSV files in the AVM Central Repo (
Azure/Azure-Verified-Modules) with the correct singular names for all resource types to enable checks to utilize this list to ensure repos are named correctly. To see the formatted content of these CSV files with additional information, please visit the AVM Module Indexes page.RMNFR2 - Parameter/Variable Naming
A resource module MUST use the following standard inputs:
name(no default)location(if supported by the resource and not a global resource, then use Resource Group location, if resource supports Resource Groups, otherwise no default)RMNFR3 - RP Collaboration
Module owners (Microsoft FTEs) SHOULD reach out to the respective Resource Provider teams to build a partnership and collaboration on the modules creation, existence and long term maintenance.
Review this wiki page (Microsoft Internal) for more information.
SFR1 - Preview Services
Modules MAY create/adopt public preview services and features at their discretion.
Preview API versions MAY be used when:
- The resource/service/feature is GA but the only API version available for the GA resource/service/feature is a preview version
- For example, Diagnostic Settings (
Microsoft.Insights/diagnosticSettings) the latest version of the API available with GA features, like Category Groups etc., is2021-05-01-preview- Otherwise the latest “non-preview” version of the API SHOULD be used
Preview services and features, SHOULD NOT be promoted and exposed, unless they are supported by the respective PG, and it’s documented publicly.
SFR2 - WAF Aligned
Modules SHOULD set defaults in input parameters/variables to align to high priority/impact/severity recommendations, where appropriate and applicable, in the following frameworks and resources:
- Well-Architected Framework (WAF)
- Reliability Hub
- Azure Proactive Resiliency Library (APRL)
- Only Product Group (PG) verified
- Microsoft Defender for Cloud (MDFC)
They SHOULD NOT align to these recommendations when it requires an external dependency/resource to be deployed and configured and then associated to the resources in the module.
