What’s the best naming strategy for Azure storage accounts with a 24-character limit?
Asked by
MellowCedar47
Subscription, container, and resource group names can be fairly descriptive, but storage account names are limited to 24 characters. They must also be globally unique and use only lowercase letters and numbers. This makes it difficult to keep a consistent naming convention when combining details such as the client, environment, region, workload, resource type, and purpose. Is it common to shorten the name and append a deterministic or random hash, or is there a better naming pattern?
Answers
Remember that storage account names are globally unique, not just unique within a subscription. They also allow only lowercase alphanumeric characters. I usually use a compact readable prefix followed by a short random or deterministic suffix to reduce the chance of collisions and accidental reuse.
Reply to this answer
Define both a full logical name and a separate short name for resources with restrictive naming rules. This gives everyone a consistent abbreviation instead of having each deployment truncate names differently. For example, agree on short codes for the client, environment, region, workload, resource type, and use case, then assemble only the essential pieces.
Reply to this answer
Use a short, human-readable prefix and put the full descriptive information in resource tags. A common approach is to reserve the last 4–6 characters for a deterministic hash based on values such as the subscription, resource group, and application. That keeps names unique while allowing templates to generate the same name repeatedly.
Reply to this answer
In infrastructure-as-code, a deterministic function such as a subscription-and-resource-group-based `uniqueString` is useful because it produces a stable suffix without requiring a manually managed random value. Just truncate the readable prefix enough to leave room for the suffix, and make sure the final result stays within 24 characters.
Reply to this answer
A compact structure such as client, cloud, environment, region, workload, resource type, and purpose can work well—for example, short codes followed by something like `stg` and `files`. Keep each component to a fixed length and document the abbreviations. Most of the descriptive metadata can live in tags rather than the resource name.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions