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:
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:
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.
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:
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.
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 papp001.xyz.com. 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, awspapp001.xyz.com.
Alternatively, a globally unique instance ID in AWS can be included in the name tag: i-06599a38675.xyz.com.
But how is that making our lives easier in identifying resources? Here's how:
For that reason, AWS has a straightforward naming standard for other resources using dot notation. It contains only three fields:
A security group for a web server in production would then get the following name: prod.webserver.sg, where prod is the account name, webserver the resource name, and sg the type suffix.
The naming convention for GCP is very simple. For every resource in Compute Engine, the name has to be compliant with the following rules:
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 https://www.ietf.org/rfc/rfc1035.txt.
In the Further reading section, you will find the references for naming and tagging in GCP.
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:
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.
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:
In the next section, we will look at 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 https://console.aws.amazon.com/; 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.
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.
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:
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 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.
You can refer to the following for more information on the topics covered in this chapter:
3.142.250.114