Resource Naming
Overview
This guide details architectural best practices and guidance for resource 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
Resources such as virtual machines, storage accounts, virtual networks, web apps, databases, and/or database servers.
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.
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 naming also allows SGS to assess costs across a project, environment, or resource type.
When
Resource naming should be considered as part of application or project design. Resource are one of the first objects that will be created upon project kick-off.
Resources are deployed as part of the initial environment terraforms.
Additional resource may be created when new functionality is added to applications or delivery projects.
How
Resources are designed as part of the application design to assure adherence with SGS governance. Resources are created within subscriptions under resource group and are defined based on the application, environment, and client.
The resource name is comprised of multiple components
| Components | Purpose |
|---|---|
| Resource abbreviation | An abbreviation that represents the type of Azure resource or asset. This component often is used as a prefix or suffix in the name |
| Capability/Module name | Name of a project, application, or service that the resource is a part of |
| Client name | Two letter names of the client |
| Environment | The stage of the development lifecycle for the workload that the resource supports |
| Region | The region or cloud provider where the resource is deployed |
| Instance Number | The instance count for a specific resource to identify more than one resource that has the same naming convention |
Sample resource group names include:
EventHub for Arkansas: eh-cl-ar-dev-cus -001
EventHub for Shared: eh-cl-sh-dev-eus2-001
Who
Resource design is the responsibility of the solution architect and the delivery team.
Naming conventions for resource will be used by:
- SGS Architects
- SGS Engineers
- Deployment teams
- Operations teams
Exception
Any resource that falls under the category for following :
- Resource length is 24 chars
- Resource not allowing - in between char
For the following scenarios use the same naming conventions without -
e.g., storage: stclardevcus001