Subscription, container, and resource group names can be much longer, but storage account names are limited to 24 characters and must be globally unique, lowercase, and alphanumeric. This makes it difficult to preserve a full naming convention, especially when including a client, environment, region, workload, and purpose. Is it common to truncate names, use a short readable prefix with a hash or random suffix, or maintain separate human-readable metadata elsewhere?
4 Answers
A common approach is to use a short, human-readable prefix and append a deterministic hash or unique suffix. For example, you might derive a six-character value from the subscription, resource group, and application so deployments remain repeatable while reducing the chance of collisions. Store the full descriptive name in resource tags for easier identification.
Use tags for the details that cannot fit in the storage account name, such as the full project name, owner, workload, and purpose. The name only needs enough information to distinguish the account and provide basic context; it does not have to carry the entire naming convention.
Keep a separate long name and short name in your organization’s naming standard. The short version can include compact codes for the client, cloud, environment, region, workload, resource type, and purpose—for example, something like `czpeappstgfiles`. This avoids arbitrary truncation and keeps names reasonably understandable.
Remember that the limit is not the only constraint: storage account names must be globally unique and can contain only lowercase letters and numbers. A four- to six-character random suffix is simple, but a deterministic value based on identifiers such as the subscription and resource group is usually better for idempotent infrastructure deployments.
That separation makes sense. Workload names often contain multiple words, so having an explicitly defined short name would be more consistent than trimming each resource name differently.