All Azure users, especially after the Classic-to-ARM switchover, have noticed this... There are a lot of different resource types, even for a simple deployment. Naming them becomes critical to find the appropriate resource, especially in an emergency. To make matters worse, there are a lot of similar resource types which, if you're not careful, you may end up naming the same. Need a couple of new Virtual Machines? You have to name the availability group, storage accounts, load balancer, resouce group and more.

Here is a summary of my recommendations for naming the most common types of resources (based on Microsoft guidelines).

Overall

Feel free to use suffixes or prefixes to describe the resource type within the name. Back in the old days of programming, we used to name variables with a prefix denoting the type. This was to make it absolutely clear how a variable was defined (usually in a different file) so that the code is more maintainable. With recent IDEs, this isn't needed any longer and the convention was dropped to favour shorter more readable code. In Azure, prefixes help because sorting a list of resources by name automatically groups resources by type, but sometimes (ex. storage accounts for VM disks) the first letter is used for something else. Therefore, suffixes are fine. For example, use rg for resource groups or sqldb for SQL Databases. Also, you may want to come up with two service names: one being the full name and one is a short equivalent. At times, you will have space to write the whole awesome-product-name-that-is-very-awesome and sometimes you just want to refer to it via the short name. Otherwise, just choose a short one.

Subscriptions

I suggest creating a subscription to keep logical boundaries between different resources. It's ultimately up to you to decide if to create a new subscription or use an existing one, but the main decision factor usually boils down to billing. Need absolute isolation between resources? Then you need a new subscription. Even if they are for the same company or product, if you keep separate budgets for production and development, you probably need a new subscription. Subscriptions are free so make use of them. There is a limit on the maximum number of subscriptions, but it's usually high enough not to be a problem. Besides, usually it is quite straightforward to move a resource from one subscription to another after the fact, either from the portal/powershell or through azure support. You do have an Azure support subscription, right?

Clear naming for your subscription is important. I suggest including the following things: Company Name, Product or service and environment (prod/stg/test/dev)

ex: MarbleHouse MarbleOrdersSite Prod

Resource Group

The aim or resources groups is to group multiple resource types together. Usually, we call this a deployment. Any resource being used for the same end objective, we should group it under the same resource group. Keep the name short and sweet (but recognisable) and put all related resources together.

ex: ordersite-prod-rg

Availability Set

Make sure you include the short name of the service and the role, especially in a layered infrastructure.

ex: ordersite-frontend-as, order-site-sql-as

Virtual Machine

I suggest putting the short name of the service as well as the role. Use VMx when you have multiple VMs with the same role.

ex: ordersite-frontend-vm1, ordersite-frontend-vm2

App Service (Web App/Function/Bot)

This is tricky because it needs to be unique across of Azure. I suggest have a company prefix (to make it rather unique) and add the app name. You may also want to add the type of app service it is (function, app or bot etc.). Remember that app services can also have slots.

ex: marbles-ordersite-app

Storage Account for Blobs/Tables/Files/Queues

Again, this one needs to be unique across of Azure. Adding a company prefix helps make it unique. Some people prefer to use GUIDs for storage account names, especially those created programmatically though that is definitely not readable.

Storage Account for VM Disks

Similarly for storage accounts for blobs/tables/files/queues, this needs to be unique. However, if you're using storage accounts to support your VM availability group, I suggest creating a storage account per VM to avoid 1) having a performance bottleneck your VM set and 2) if the storage account goes down, the effect should be limited to one VM only. Microsoft also suggests to have a different first character for each storage account to ensure that each account is created in a different Azure storage 'stamp'. A 'stamp' is a collection of storage accounts with the same hardware dependencies. Therefore, I suggest a naming convention whereby the first letter is the VM's index number.

ex: 1marbles-vm-sa, 2marbles-vm-sa

Storage Table

Annoyingly, table names have a lot of restrictions, including not supporting the hiphen character, and are lower case only. Luckily they don't need to be globally unique (just unique for your storage account). Therefore keep them short and readable.

ex. marblesservicelogs

VNet

This is one of those resources that if you get wrong, is difficult to correct. Changing VNet details once your VMs are deployed is annoying and sometimes requires you to recreate the VMs themselves. Make sure you include the service name, but keep in mind that eventually, you may want to connect different VMs/services to the same VNet. Remember to name your subnets too (but these should be simple).

ex. marbles-vnet

If you need to save additional information, each resource can have a maximum of 15 tags. Each tag name is limited to 512 characters and each value can have up to 256 characters. Perfect for scripting. Use them wisely.

You can use any convention that makes sense to you but it also makes sense to see what's out there, especially if you're starting anew. Whatever the case, before you start any project, create your own policy (WRITE IT DOWN) and stick to it. Changing policy usually means that you need to go through the services and rename them (when possible), so starting with a good policy makes absolute sense. Be consistent!

Here's Microsoft's Best Practices: Naming Conventions: https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions