The next pitfall to avoid in setting up your Azure environment is one that trips up many organizations. If you fail to establish clear naming conventions, you will limit your team’s ability to know what’s going on, find things, and understand and manage them. So don’t start naming things “Nathan’s test” or “Bob’s system!”
Here’s an example of one naming structure that has proven useful in operation—through plenty of trial and error:
<Azure Object> – <Business Unit> – <Descriptor> – <Prod or NonProd or QA> – <Azure Region>
Then, add a 01 or 02 depending on the number of things you have. For example, the following name would apply to a resource group, infrastructure, domain controller, production, and then the north central U.S. region:
Of course, adjust this structure in ways that fit your environment—but stay consistent. You can also choose to create policies that stop short of telling your team members exactly what name they need to use but rather just something that fits your criteria.
One further point of consideration: some security-focused people express a concern that descriptive naming conventions may enable outsiders to easily distinguish just what your items are. If you share that concern, then consider a less-descriptive approach—but still one you can implement consistently.
Just don’t name anything “Nate’s domain controller” or the like!