Chapter 12: Defining Naming Conventions and Tagging

Cost control starts with enabling the clear identification of resources and accountability for these resources. In multi-cloud environments, naming and tagging should be consistent across all utilized cloud platforms.

We will learn how we can define a consistent naming and tagging convention. Both naming and tagging are required to identify resources. A name is used to recognize resources and tags act as extra labels to specify the role and characteristics of a resource. We will see that there are differences between the major cloud providers when it comes to guidelines and restrictions on names and tags for resources. This chapter provides an overview of the main guidelines for the major platforms–AWS, Azure, and GCP. We will also learn that consistent naming and tagging is crucial for the billing process and for allocating the costs of cloud resources to the right cost center.

In this chapter, we're going to cover the following main topics:

  • Creating a naming convention
  • Creating a tagging convention
  • Implementing naming and tagging
  • Managing naming and tagging conventions

Creating a naming convention

Let's assume that we will have a lot of resources deployed to our cloud environments. We need a way to identify these resources. This is what a naming convention does. The naming convention is part of our architecture. Of course, one way to identify resources such as virtual machines is by IP addresses, but with a lot of resources, this is not very convenient or even possible. A naming convention makes our lives a lot easier. Basically, it's just an agreement on how we want to identify resources. You can compare it with street names. In a small village, it might be sufficient to just give each house a number, but in a big city, street names make it easier to find a certain address.

The goal of a naming convention is to enable identification. Typically, the name of a resource also describes what the resource is or does. For example, the naming convention to specify a name for a VM might comprise the following information:

  • Where the resource is deployed—for example, an Azure environment in the region West-US
  • What the role of the resource is—for example, database, application server, or domain controller
  • The type of resource (development, test, quality assurance (QA) or pre-prod, or production system)
  • Who the owner of the resource is

So, if we have a production database server running SQL on a Windows operating system, hosted in the US West region of Azure, the name might be something like DBSQLWIN-AZUSW_P. But what if we have more SQL databases? Then we need to add a unique identifier. That can be a number or the name of an application to which the server belongs – in our example, DBSQLWIN001-AZUSW_P. Now the name tells us that this is the SQL database server number 001, running on Windows, hosted in Azure West-US, and in production.

We would also need to specify who the owner of the resource is, typically expressed as an abbreviation that identifies the tenant. If company XYZ is the owner of the cloud tenant where the resources are hosted, then the naming convention would most likely start with XYZ followed by the rest: XYZ_DBSQLWIN001-AZUSW_P.

Unfortunately, it's not as easy as that. Major cloud providers Azure, AWS, and GCP all have specific demands for a naming convention. In our example, we have used 22 characters to specify the name for one resource, including the hyphens. Cloud providers differ in how they allow different numbers of characters and the use of special characters, such as hyphens. In the next sections, we will explore these standards as defined by the cloud providers.

Naming convention standards in Azure

One important thing to remember is that we're only talking about databases and VMs when we discuss naming conventions. Since everything in the public cloud is software-defined—meaning that there is no physical device that we can identify—all assets or resource types that are used in the public cloud need to have a unique name. This includes networking, security assets such as gateways and firewalls, policies, and integration patterns such as APIs.

To make it a bit more complex, we're not completely free in how we define our naming convention. Azure prescribes a vast number of resource type prefixes.

Every resource group name needs to have the identification rg-, and every VNet must contain vnet- in the name. Every VM deployed in Azure is identified with vm and every SQL database with SQL. The list is extensive. A few things are up to us to define:

  • The business unit—for example, fin for finance or the abbreviation of the company
  • The subscription type—for example, prod or prd for production
  • Application or service name
  • Deployment environment—production, test, development, acceptance, staging, QA, or sandbox
  • Region

Azure does provide guidance and recommendations to define naming standards for all resource types. Next, there are naming rules and restrictions that we need to apply. This is again a very extensive list.

Let's use the example of a VM. The prefix is -vm, so that needs to be included in the name. The scope of the VM is the resource group that it belongs to, so it needs to be clear in the name where the VM is hosted. Then we have to deal with a couple of restrictions. For a VM running on Windows, there is a limit of 15 characters. The following characters are forbidden: /"'[]:|<>+=;,?*@&. Lastly, names can't begin with an underscore or end with a period or a hyphen.

A usable format would be <organization><deployment-environment><region><service><hostname>-vm. In the example used earlier, it would be xyz-p-usw-app-app001-vm. The organization is XYZ, the deployment environment is production (p), it is hosted in US-West, it's an application server for app001, and it's a VM, indicated by -vm, the prefix that Azure prescribes. In the Further reading section, you will find the references for naming and tagging in Azure.

Naming convention standards in AWS

AWS takes VMs in EC2—the compute service of AWS—as a starting point to create a naming standard for resources, but they take a different approach than Azure. AWS connects the name to the fully qualified domain name (FQDN) of an instance. AWS assumes that a company already has a naming standard to identify servers, comprising the location, deployment type, role, application or service ID, and a unique identifier. AWS recommends associating this with the FQDN.

To use the previous example again, say application server 001 is in production for company XYZ but is now hosted in AWS. To identify this server, it's named p-app001. AWS now recommends assigning this name to the FQDN If we are running instances on-premises as well, it might be advisable to have something that indicates that this resource is in AWS or a specific AWS region—for instance,

Alternatively, a globally unique instance ID in AWS can be included in the name tag:

But how is that making our lives easier in identifying resources? Here's how:

  • First of all, AWS assumes a very high level of automation, where we have as little human interference as possible. A script or API would be able to recognize the ID very quickly, so why not use the unique ID that AWS automatically assigns to a resource?
  • Second, AWS has very extensive tagging possibilities, assigning metadata to resources in a lot of different ways. We will explore that in the section about tags. Tags are AWS' method to identify resources, rather than using names.

For that reason, AWS has a straightforward naming standard for other resources using dot notation. It contains only three fields:

  • Account name prefix: For example, production (prod) or development (dev)
  • Resource name: A free-form field that contains a logical name
  • Type suffix: Indicates what type of resource it is—for example, security group or subnet

A security group for a web server in production would then get the following name:, where prod is the account name, webserver the resource name, and sg the type suffix.

Naming convention standards in GCP

The naming convention for GCP is very simple. For every resource in Compute Engine, the name has to be compliant with the following rules:

  • Every name has a maximum of 63 characters.
  • The following characters are allowed: [a-z]([-a-z0-9]*[a-z0-9])?.
  • The first character must be a lowercase letter. All subsequent characters must be lowercase letters, digits, or hyphens. The last character can't be a hyphen.

There's one more restriction: GCP wants the naming convention to be compliant with RFC 1035 conventions. That probably needs some explanation. RFC 1035 is issued by the Internet Engineering Task Force (IETF) and describes the convention for domain names.

The reason for this is that name servers across the globe must be able to retrieve instances, no matter where they are hosted: whether in on-premises systems, in colocations, or on public clouds. RFC 1035 makes sure that instances are uniquely identifiable. Although only GCP mentions it explicitly, all providers should comply with this statement. For those who want to read the full document, it's published at

In the Further reading section, you will find the references for naming and tagging in GCP.

Creating a tagging convention

Tags are likely the most important attribute in terms of cost management and control in cloud environments. Naming conventions are much more focused on the identification of resources and are also crucial to the automation of cloud management. Tags are metadata that allow additional information on resources that can't be stored in a name. Tagging will help in understanding cost allocation, since we can use tags to categorize cloud resources.

All cloud providers offer extensive ways to apply tags to our resources. However, standard tags can be utilized across these different clouds. It's recommended to have tags for at least the following attributes:

  • Application: Typically, a resource is part of an application or an application stack. To categorize resources—meaning VMs, storage, databases, and network components—that belong to one application or application stack, a tag should be added to identify to what stack or application a resource belongs.
  • Billing: Especially large enterprises will have divisions, business units, or brands. These entities might have budgets or might be separate cost centers. Tags will ensure that resources are billed to specific budgets or the accounting cost centers.
  • Service class: Tags can indicate what service level is applicable to resources. Are they managed 24/7, what is the patch schedule, and what is the backup scheme? Often enterprises have a tiered categorization for resources, such as gold, silver, and bronze. Gold is the highest level for production systems and may have disaster recovery solutions and uptime of 99.999%; silver and bronze would be for single systems with a much lower service level. A tag indicating gold, silver, or bronze will make clear what the service class is of that particular resource.
  • Compliance: These tags indicate whether compliance rules apply. These can be industry compliance regulations, such as for healthcare or financial institutions, as well as internal compliance rules. These can be important in, for example, granting access to specific resources or the way data is securely stored.

Now that we have learned what the recommended parameters are for applying tags, we can look at how we can define tags in Azure, AWS, and GCP.

Defining tags in Azure

All resources that can be deployed with Azure Resource Manager (ARM) can be tagged, but there are some restrictions to take into account.

Azure allows a maximum of 15 tags per resource with a length of 512 characters, strictly alphanumeric.

JSON strings can be used if more than 15 tags are needed. Azure recommends setting tags at the level of resource groups, because there are a limited number of tags. From the resource group, all the associated resources would be identifiable together, thus limiting tagging resources individually. Best practice for tagging in Azure includes the following:

  • Application taxonomy: Indicator for the owner—for example, a specific business unit or DevOps team—of the resource group and the function of the application.
  • Environment type: This indicates the purpose of the resource group—for example, test, development, or production.
  • Billing indicator: This is the identifier for the cost center accountable for the costs that are generated with resources in this resource group.
  • End date of the project: States when the project is ending; resources can be removed to save costs.

In the next section, we will look at tags in AWS.

Defining tags in AWS

Of all the public clouds, AWS has the most extensive method of tagging resources. Resources can have 50 tags each, with a maximum length of 127 characters. Both alphanumeric, spaces, and the special characters + - = . _ : / @ can be used. On top of that, tags are case sensitive. But also, AWS has a few restrictions regarding tags.

Tags can primarily be used for resources that are deployed from the compute service of AWS–EC2. There are more services that can be tagged, but this doesn't comprise every service or resource that AWS offers.

More importantly, tags must be activated for cost allocation for these resources to show up in billing reports. There's a maximum of 500 tags that can be used for billing and cost management. So, the best practice is to first create user-defined tags using AWS' Tag Editor or through the API from the AWS console. Next, allocate these tags for billing and cost management through the console. Be aware that the console is not the same thing as the AWS portal. The management console is accessed through; this is the console where we manage our environment in AWS.

With the possibility of having 50 tags per resource, it could easily be tempting to actually use them all. One of the best practices of AWS, however, is less is more, start small. Tags are reversible and can be removed, and new tags can be added—even in bulk—if needed. One exception: the aws: prefix can't be used or modified. It's reserved for AWS use only.

Defining tags in GCP

Tagging is implemented differently in GCP. Google calls them labels as opposed to tags. The purpose of labels is the same—they are meant to group resources together easily.

Labels are pairs of keys and values. For example, say a key is environment and a value is development. The label, therefore, is environment/development. We need to include that in a script through the gcloud command line. It will look like this:

{  "labels": {    "environment": "development",  …  }}

GCP allows 64 labels per resource, with a maximum of 63 characters for keys and values. There's also a restriction on the type of resources that can have labels. At the time of writing, labels are fully supported on VMs, images, disks, and storage buckets. Labels on forwarding rules, static external IP addresses, and VPN tunnels are in beta.

It's important to note that that GCP has network tags. These are not related to labels.

Implementing naming and tagging

The successful implementation of a naming and tagging standard starts with a clear policy. Tags should be consistent and applied to all resources: VMs, storage, databases and network components, applications, and services. Remember that every resource in a cloud environment costs money. To have a complete overview of our cloud spending, we have to make sure that all resources are identified and tagged so that they appear in the billing. This means that every team deploying resources to cloud environments must be required to tag resources; even better, a policy should prevent—preferably in a fully automated way—resources without tags being deployed in the first place.

As a best practice, the following steps should be executed to implement a consistent naming and tagging convention:

  • Defining the policy: This is part of the multi-cloud architecture. The naming and tagging policy need to be centrally defined so that it's consistent throughout every cloud environment to which we deploy. This will take time. Start with a policy following the recommendations and best practices of the clouds that the company will use, but the policy needs to be validated and agreed upon throughout the enterprise. Without the consent of stakeholders, naming and tagging might not be followed in the desired manner consistently.
  • Enforce the policy: This doesn't sound nice, but it's an absolutely necessary step. Every team working in a company's cloud environment must adhere to the naming and tagging policy. Store the policy in a central place so that everyone has access to it. Don't make it too complicated: a wiki page with the proposed naming and tags can be stored on the intranet. Next, point the teams to this file. Often, teams are led by project managers or product owners; they should be alerted to use the policy.
  • Monitor the policy: Especially at the beginning of projects, it's advised to check on a weekly basis whether naming and tagging is applied according to the policy. The reason to be strict in this is that naming and tagging are crucial for billing. We want a complete billing statement that shows all assets deployed in our clouds and be sure that costs are accounted for and allocated to the right cost center or budget. Without consistent naming and tagging, that's virtually impossible.
  • Automate: The tagging process can be automated. As soon as the policy is accepted, it's strongly recommended to automate the tagging process. Automation can be triggering an alert as soon as resources get deployed without tags. A resource shutdown policy could also be automatically enforced when they don't have tags assigned. One step further would be full automation of the tagging process, where tags get automatically assigned as soon as resources are provisioned. This can be done from the CI/CD pipeline using native deployment tools from the cloud providers, or by using tooling for it.

    This tooling is often referred to as cloud spend management or spend optimization. Flexera is one example of this type of tooling. It uses policy-based automation to control spending over all major cloud providers and a wide variety of SaaS options. It also generates feedback on how to optimize costs, when resources are, for instance, no longer in use. One of the basic features is that it checks for tagging policies.

In the Further reading section, you will find URLs to documents explaining the implementation of tags and labels in Azure, AWS, and GCP.

Managing naming and tagging conventions

Managing naming and tagging conventions is part of cloud governance. Once a convention is designed and confirmed by all stakeholders in the enterprise, it needs to be enforced. This means that an enterprise might want to deploy default tags on resources—as we have described in the previous sections—but also a policy that enables the termination of instances if they are not tagged or tagged correctly.

Regular reports must be published to verify that naming and tagging is applied as agreed and defined in the convention, but preferably this is automated.

Having said that, the naming and tagging convention will probably not be set in stone. There has to be flexibility in changing the convention when required. Think of a new service that is launched by a cloud provider and that an enterprise would like to use in future deployments, or an enterprise that acquires a new company with its own budgets or cost centers. In these cases, we will need to adapt the convention. The convention is part of our multi-cloud architecture and governance, and therefore change management is applicable.

A good practice is to review the convention at regular intervals. This can be done in an architecture review. Most companies have regular meetings or platforms such as an architecture board where architectural decisions are made. That's the place to decide whether changes to conventions are needed and how these changes should be applied. This is important since changing naming and tagging can have consequences for automation and for billing. Automation might not be able to identify resources or resources might not show up in billing reports anymore. Changes to a convention should therefore be considered very carefully.


In this chapter, we have learned that names and tags are crucial to be able to identify our resources in public cloud environments. They are crucial to correct billing and to allocating costs to the appropriate budget or cost center. But they are also very important in terms of automation. We have learned that we can automate the naming and tagging process; however, it starts with a definition of the naming and tagging convention. After this chapter, you should have a good understanding of the different guidelines and restrictions for naming and tagging in AWS, Azure, and GCP.

Lastly, we've learned that as soon as a convention is agreed upon, we should apply it in a consistent way and that the convention itself should be part of the architecture. We've learned that updates to the naming convention should follow the change management control processes of the enterprise and be discussed by an architecture board or in an architectural board meeting/review.

The final step in cost management in multi-cloud is the billing itself. In the next chapter, we will learn how billing in public clouds works and how we can validate this.


  1. True or false: it's recommended to have the role of a resource indicated in the name of the resource.
  2. AWS recommends connecting the name to the FQDN. What does FQDN stand for?
  3. What are tags called in GCP?

Further reading

You can refer to the following for more information on the topics covered in this chapter:

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.