I must admit right up front: I'm more than a little obsessed with naming conventions. Prefixes...suffixes...I really enjoy coming up with the optimal convention to use so that a name is at least somewhat self-documenting without being horribly long.

In Azure, we use a combination of resource groups and resource names to organize things. Here's the naming convention for resources that I currently prefer:

Purpose --> Type of Service --> Environment

Resource Group examples:

InternalReportingRGDev

InternalReportingRGTest

InternalReportingRGProd

Virtual Machine examples:

BISQLVM1Dev (this one runs the engine, SSIS, and MDS)

BISQLVM2Dev (this one runs SSAS in multidimensional mode)

BISQLVM1Test

BISQLVM2Test

BISQLVM1Prod

BISQLVM2Prod

Storage Account examples (non-managed storage):

BISQLVM1DataStrgDev (this is the unit of recovery for a single VM)

BISQLVM2DataStrgDev

BISQLVM1BckStrgDev (SQL Server backups; sent to geo-redundant storage)

BISQLVM2BckStrgDev

BISQLVM1DiagStrgDev (diagnostic & logging data)

BISQLVM2DiagStrgDev

Additional criteria:

• Some resources require a unique name across all of Azure. This is the case if the resource has a data access endpoint or URI. Therefore, depending on your implementation, you might need to auto-generate part of the name to enforce uniqueness. In that case, I would still try to make the prefix human-understandable, followed by the uniqueString().
• The type of service in the name helps with logging/metrics in monitoring scenarios. You probably want to use a standard abbreviation (in the examples above, RG is for resource group; VM is for virtual machine; and Strg is for storage).
• Environment (such as Dev/Test/Prod) as the suffix makes concatenations easier within scripts. You may also want to use tags to denote the environment.
• We do denote Prod in the name of Production resources (rather than omitting it completely). This is because our Dev/Test/Prod resources are all contained within one subscription, separated by resource group. Therefore, we want to be very specific.
• No dashes (hyphens) or underscores in the names since all resources don't allow them.
• Camel case if the resource allows it; otherwise all lower case. (Storage accounts are actually required to be all lower case - the storage example shown above is camel case only because it's easier to read in this blog post.) You might decide to do the opposite: always go lower case so things are consistent. There's some appeal in that too.
• The maximum length allowed varies quite a bit between resources.
• Depending on how many teams/groups in your organization share a subscription, you might want to include a prefix of who owns or maintains this resource. This can also be done with a tag, but this sort of naming convention is helpful for sorting resources especially if you have wide permissions to see the entire subscription.
• There are times when you do need the names to be the consistent across all environments, or you introduce too much complexity. One example of this is Azure SQL Database (its parent server differs between Dev, Test, and Prod but not the database name itself). Another example is for Azure Data Factory - to prevent maintaining duplicate JSON code multiple times I'm finding it best to keep the name of linked services, datasets, and pipelines the same name across data factories (whereas the name of Azure Data Factory resource would differ between Dev, Test, and Prod).
• In addition to Dev/Test/Prod, we also use a 'Sandbox' as a suffix which essentially means: this is an individual's area for learning or exploration. For instance: DataScienceVMSandbox.
• Unless you're supporting a multi-tenant platform, putting the organization/company name within the name doesn't add any valuable context.

In the end, the actual naming convention you decide on isn't the important thing. Most important is that you can locate resources easily and secure them properly -- which requires some consistency with the naming policy.

You Might Also Like...

Displaying Columns of Metadata in the Azure Portal

Why Some Azure VM Sizes are Unavailable When Resizing in the Portal