Skip to content

Resource Group Naming

Overview

This guide details architectural best practices and guidance for resource group naming deploying services and resources in Azure. Standardized governance will be implemented by SGS to maintain a uniform environment.
While application and delivery teams are encouraged to create a naming standard for resources that each application will employ, governance standards for top level resources will be set through policy. The most common element all teams will deploy will be resource groups.
Resource groups will be used as a granular tool for reporting and for client specific controls and policies.


What

Resource Groups are logical collections of resources such as virtual machines, storage accounts, virtual networks, web apps, databases, and/or database servers. You use resource groups to group related resources for an application together. Resource groups are additionally used to categorize resources by environment or SDLC lifecycle stage.

Azure provides four levels, or “scopes”, of management to organize resources:

  • Management groups:

    These are containers to manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group. SGS may use management groups to group subscriptions according to compliance frameworks.

  • Subscriptions:

    A subscription associates user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the number of resources you can create and use. Subscriptions are often used to manage costs and the resources that are created by users, teams, or projects. SGS will deploy subscriptions only when required by client contract.

  • Resource groups:

    A resource group is a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed.

  • Resources:

    Resources are instances of services like virtual machines, storage, or SQL databases.

Resource groups are a way to operationalize role-based access control (RBAC) and policy deployment.

Why

A naming standard is a common convention that is used for asset management and identification. Common resource naming allows teams to quickly assess impacted resources during an incident, helps you quickly identify the resource's type, associated workload, and deployment environment.

Standardized resource group naming also allows SGS to assess costs across a project, environment, or resource type.

Additionally, SGS will use resource groups for policy enforcement for client specific policies.

When

Resource group naming should be considered as part of application or project design. Resource groups are one of the first objects that will be created upon project kick-off. Application architecture teams are encouraged to design their applications with base resource groups that delivery and operations can expand on.

Resource groups are deployed as part of the initial environment terraforms.

Additional resource groups would be created when new functionality is added to applications or delivery projects.

How

Resource groups are designed as part of the application design to assure adherence with SGS governance. Resource groups are created within subscriptions and are defined based on the application, environment, and client.

This guide is limited to naming conventions of resource groups. Unless otherwise noted, resources should be identified by the resource definition as recommended by Microsoft. A link to the recommended abbreviations can be found in Appendix B.

The resource group name is comprised of four components – the SGS product, the application or microservice, the environment, and the client identifier.

Figure: Resource Group Naming Standard Structure

The product identifier is the SGS commercial product. A list of the acceptable commercial product names is listed in Appendix A.

Some SGS applications contain microservices. The resource group name includes the microservice to help identify costs associated with product subcomponents and to support enhanced troubleshooting. Microservices are also identified in Appendix A.

The third facet of the resource group name is the environment. This is representative of the current placement of resources that belong to the resource group.

Each of the first three components of the resource group name are limited to four characters each.

The last component of the resource group name is the client identifier. Resources that are deployed for common, or shared, use will be identified by SH or CM, where CM is used for common application services and SH is used for Tier 0 services. Tier 0 components are an example of shared resources. Other shared resources are common VNET for a Kubernetes cluster.

If a resource is not shared and is in production, it should be identified with a client identifier. Client identifiers are the two-character state identifier. A complete list is in Appendix A.

When applications are in new product development, there would be no client identifier.
Resource group names are not case sensitive. Hyphens should be used between identifiers.
Sample resource group names include

Anly-EDW-Prod-CA
Anly-ORI-Prod-IN
FADS-PGP-Prod-CA
OMMS-PEP-Dev-MT
IE-RE-UAT-WV

Who

Resource groups design is the responsibility of the solution architect and the delivery team.

Naming conventions for resource groups will be used by

  • SGS Architects
  • SGS Engineers
  • Deployment teams
  • Operations teams

Resource group naming standards are enforced by Azure policy.