Cloud Resources Naming Strategies
Brandon Pfeffer, CMA
Strategic Finance ? Corporate Finance ? Operations ? FP&A ? M&A ? Financial Modeling ? Strategic Planning ? Treasury ? Start-ups ? Private Equity ? Budgeting ? Cloud FinOps ? Analytics ? Pricing ? ? [email protected]
Introduction
Some companies that are transiting to the cloud often make the critical mistake of not establishing consistent naming rules and standards for cloud resources, accounts, servers, instances, and other assets. Naming cloud resources is crucial for managing, scaling, and maintaining clarity within cloud environments. ?Individual accounts can be used to isolate costs of one environment or application from another. ?Cloud FinOps teams need to work closely with their Cloud Ops counterparts to establish well thought out naming conventions and processes to ensure that these naming standards are followed. Any new requests to spin up new cloud resources need to flow through a central team that approves or denies the new resource names before the instances are created. The following are the methods these might be created in the big three cloud providers (1):
How a company’s Cloud Ops engineers place their infrastructure into AWS accounts, Azure subscriptions, Google Cloud projects form the first layer of a firm’s cost allocation strategy. (Please see my other article on Cloud Resource Tagging Strategies that should be read in conjunction with this article).
Benefits of a Naming Strategy
A good naming strategy ensures consistency, helps with resource identification, simplifies management, and enhances collaboration, especially in complex multi-cloud environments. Having a proper naming convention in place can make an enormous difference from cost management and operational perspective. By having and enforcing resource naming rules, one can identify valuable information from a cloud asset just by reading its name. You can identify the environment, the role, project, and business unit that the asset belongs to. The key benefits of having a standard naming convention in place include:
Not having standardized naming rules across multiple cloud platforms can lead to different abbreviations and conventions. This can cause different interpretations and opinions, which can lead to operational mistakes and sub-optimal decision making.
Cloud Provider-Specific Considerations
In AWS, the process of naming resources is slightly different from Google Cloud Platform (GCP) and Microsoft Azure. In GCP and Azure, part of the process of creating a cloud resource or asset is giving it a name. In Amazon Web Services (AWS), when a resource or asset is created a name is not required and it is optional as they are given an account ID #. Naming conventions for AWS is more of a tagging strategy. Regardless of which cloud provider that your company is using it is critical to have well thought out naming conventions and rules in place that are enforced. ?
Each cloud provider has its own quirks and best practices for naming. Consider these differences when creating a strategy for a specific platform:
As a reference, here are key resources related to naming conventions from each of the big three cloud providers (2):
Naming vs. Tagging Standards
Many companies do not understand the differences between naming conventions and tagging strategies. ?Naming conventions are required (except for AWS) to create new resources such as servers, CPUs, storage, databases, and networking. Tagging strategies allow one to further classify an asset or resource when they are not part of the name or if the naming conventions were not followed. Please see my other article on tagging cloud resources) Once you create a resource name on GCP or Azure, you cannot change it later because most cloud resources do not support name changes. Tagged assets can be changed and corrected anytime during the life cycle of cloud assets. Tagging strategies can evolve over time as a company change but the naming conventions remain unchanged.
Best Practices and Strategies for Naming Cloud Resources
Below are several best practices and strategies for naming cloud resources that companies should follow:
1) Order of Significance
From left to right the elements in the name should be of decreasing significance which enhances sorting and readability. If you need a naming convention that is multi-cloud, then consider adding additional elements in order of significance. Note, the criteria for what are the considered the most important or essential elements can vary significantly from one firm to the next so there is a wide variation in the sequence of elements for cloud resources globally.
2) Uniqueness of Naming Conventions.
A cloud resource naming convention must allow you to uniquely name both globally named resources and locally named resources, so you do not have a naming conflict that would prevent their deployment.
3)?Syntax and Style
Note, each cloud provider has different rules, limitations & restrictions with regards to naming cloud assets, so it is important to be as consistent as possible across multiple cloud providers. ?The best rule of thumb is to use only lowercase letters and numbers for individual components and utilize dashes (-) as separators between elements. Try to avoid using special characters, underscores and no spaces. The following tables show the major naming conventions or rules and limitations for the big three cloud providers (2):
4)?Separators for Names
Some companies that only have a single cloud provider have naming conventions that utilize a fixed number of characters for each component of a resource name. This means that they have a fixed length and format. However, when working with multiple cloud providers it is important to use a separator that will allow one to separate out the various fields programmatically.? Many firms like to utilize a dash as this common separator as it is easy to see and acceptable syntax for most cloud providers universally.
5)?Structure & Components for Naming Conventions
The number of components or elements in a naming strategy and structure can vary from simple to complex depending upon how sophisticated a firm’s cloud footprint is, the number of cloud hosting providers, and whether it manages customer cloud resources. ?
A firm with only one cloud provider may utilize a simple naming convention with 4 to 5 elements such as:
领英推荐
A firm with multiple cloud providers with hundreds of resources may utilize 6 or 7 elements to convey more information such as:
However, a firm’s that has multiple cloud hosting providers and thousands of resources, needs more sophisticated naming conventions that may have as many as 10 to 12 elements as shown below:
Firms utilizing more complex naming conventions may not have to leverage tagging as much as their names convey so much information already. Each component of a name adds valuable context, ensuring that resources are easily and correctly identifiable, especially for large and complex cloud infrastructures. The following is a brief breakdown of each of these elements found in the naming conventions shown above:
a)?Cloud Hosting Provider: This field is especially important for multi-cloud organizations to allow for filtering and analysis in the simplest manner. This field is best structured as a fixed-length field using 2 or 3 characters for the three major cloud provides as such:
b)?Customer Name: This is the name of the customer that your firm is managing cloud resources for. The name should be as short as possible but identifiable.
c) Customer ID: This is the customer ID number or End User number and should be 6-10 numbers in length.
d)?Project Name: This is the name of the project the resource belongs to. Project names should be 4-6 alpha numeric characters at most in length.
e)?Service Type: The type of cloud service, for example compute, storage, network, data bases. The best practice is to use the preferred abbreviations of the cloud provider which typically range from 2- 5 letters.
f)?Resource Type: This is a further specification of the resource within the. Use abbreviations for the type of resource type such as vm for virtual machine, vnet for virtual network, db for database.
g)?Resource Name: Descriptive name for the resource based on its function such as webapp or database but keep it under 8 letters if possible.
h)?Environment: The environment where the resource is deployed is important as different environments' resources are managed operationally in diverse ways. For example, a virtual machine in development can be subject to automatic shutdown during off-hours in evenings or weekends, while a production machine is not.? A three-letter field name approach provides a best approach to naming environments as it is easily readable:
i)?Business Unit/Cost Center: This element is especially important for allocating resource costs to specific departments, business units or projects. The format of this field depends on how business units and cost centers are named. Try to abbreviate business units to 3-5 letters and cost centers with 3-4 numbers at most.
j) Region: The geographical location of resources is helpful in keeping resource names consistent across multiple cloud environments. For example, us-east1, us-west1, eu-central1 or eu-west2. Usually, a combination of letters and numbers is utilized.
k) Version: For resources that may have multiple versions incorporate version numbers into your naming convention is critical. For instance, v1 or v2 for iterations or updates.
l)?Unique ID: A unique identifier, often alphanumeric, to ensure the resource name is unique and easy to identify.
6) Parent vs. Child Resources
Specific cloud assets can be considered child resources from a parent resource, such as virtual machines and storage drives. For these resources, companies need to use a specific naming convention rule so they can refer to the parent resource name, which should already contain all the information we need.
Here is an example of names following this convention:
7)?Consider Scalability and Automation
When scaling infrastructure, manual naming may not be feasible. Design a strategy that works well with automation tools like Terraform, CloudFormation, or Azure Resource Manager (ARM).
Conclusion
Having a proper naming convention in place can make an enormous difference from cost management and operational perspectives. Not having standardized naming rules across multiple cloud platforms can lead to different abbreviations and conventions. This can cause different interpretations and opinions, which can lead to operational mistakes and sub-optimal decision making. The key to success with naming conventions is establishing them early on and enforcing them consistently across a company’s entire cloud infrastructure. The actual naming convention should always be tailored to a company’s specific cloud environments. Not having firmwide resource naming conventions & standards will make managing and tagging resources cumbersome long-term. A solid naming strategy helps simplify resource management, improve security, and scale cloud environments efficiently. By defining clear naming conventions, enforcing them, and leveraging automation where possible, teams can achieve greater operational efficiency and reduce costs.