Azure / Azure/Azure-Verified-Modules
[Module Proposal]: `avm-common-abbreviations`
- Dominant language
- PowerShell
- Stars
- 580
- Forks
- 161
- Avg merge
- 11h 3m
- Merged PRs (30d)
- 15
Description
### Check for previous/existing GitHub issues/module proposals
- [x] I have checked for previous/existing GitHub issues/module proposals.
### Check this module doesn't already exist in the module indexes
- [x] I have checked for that this module doesn't already exist in the module indexes.
### Bicep or Terraform?
Bicep
### Module Classification?
Utility Module
### Module Name
avm/utl/naming/avm-common-abbreviations
### Module Details
# Overview
This proposal outlines the creation of an Azure Verified Module (AVM) utility module for standardized resource naming based on Azure Cloud Adoption Framework (CAF) naming conventions. The module provides a comprehensive set of abbreviations and naming functions to ensure consistent resource naming across Azure deployments.
# Problem Statement
Currently, there is no standardized AVM utility module that provides:
Consistent resource type abbreviations based on [Azure CAF recommendations](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming)
Regional abbreviations for Azure locations
Standardized naming pattern functions
String manipulation utilities for naming compliance
This leads to:
Inconsistent naming patterns across different Azure deployments
Manual maintenance of abbreviation lists in multiple projects
Difficulty in enforcing naming standards across teams
Duplicate effort in creating naming utilities
Proposed Solution
Create an AVM utility module `(avm/utl/naming/abbreviations)` that provides:
# Core Functions
1. `createName()` Function
- Generates standardized resource names following the pattern: `{abbreviation}-{workload}\{application}-{environment}-{region}-{instance}`
- Parameters: resourceType, namingObject, optionalApplicationName, location, instance
- Returns: Formatted resource name in lowercase
2. Resource Type Abbreviations
- Comprehensive mapping of 200+ Azure resource types to their CAF-recommended abbreviations
- Includes modern services like Azure AI, Container Apps, and Azure Functions
- Easy lookup via getAbbreviationResourceType() function
3. Regional Abbreviations
- Complete mapping of all Azure regions to 3-character abbreviations
- Supports global, sovereign, and edge locations
- Accessible via getAbbreviationRegion() function
4. String Manipulation Utilities
- Remove special characters (colons, commas, dots, hyphens, semicolons, underscores, whitespaces)
- Ensures naming compliance with Azure resource naming requirements
Module Structure:
```
avm/utl/naming/abbreviations/
├── main.bicep # Main module file with exported functions
├── functions.bicep # Core naming functions and abbreviation mappings
├── README.md # Comprehensive documentation
├── tests/ # Test files for validation
│ ├── e2e/ # End-to-end tests
│ └── unit/ # Unit tests
└── metadata.json # Module metadata
```
Usage Example:
```
import * as naming from 'br/public:avm/utl/naming/abbreviations:1.0.0'
param workload string = 'contoso'
param environment string = 'prod'
param location string = 'westeurope'
// Generate storage account name
var storageAccountName = naming.createName('storageAccount', {
workload: workload
environment: environment
}, '', location, '01')
// Result: st-contoso-prod-weu-01
// Get individual abbreviations
var vmAbbreviation = naming.getAbbreviationResourceType('virtualMachine')
var regionAbbreviation = naming.getAbbreviationRegion(location)
```
### Do you want to be the owner of this module?
No
### Module Owner's GitHub Username (handle)
_No response_
### (Optional) Secondary Module Owner's GitHub Username (handle)
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the proposed avm/utl/naming/abbreviations/ module structure and review the README.md and functions.bicep requirements. Implement the createName, resource-type abbreviation, regional abbreviation, and string utility behavior described in the proposal, then validate it with the listed unit and end-to-end tests. Done means the module files, metadata.json, documentation, mappings, and tests are present.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100