Multi-Cloud Naming, Tagging and Labelling

Contributions from

who manages public cloud platforms across multiple CSPs for one of the worlds largest enterprises.

Introduction

Consistent labelling of assets is one of the key best practices prescribed in cloud foundations for any organisation deploying resources into any cloud service provider platform. There are several materials provided from the major cloud service providers on the topic.

https://aws.amazon.com/answers/account-management/aws-tagging-strategies/ AWS

https://cloud.google.com/resource-manager/docs/creating-managing-labels GCP

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-using-tags#policies Azure

https://www.ibm.com/support/knowledgecenter/SSMPHF_181114/tag_settings.html IBM

https://docs.cloud.oracle.com/iaas/Content/Tagging/Concepts/taggingoverview.htm Oracle

https://www.alibabacloud.com/help/doc-detail/131053.htm , https://www.ibm.com/support/knowledgecenter/SSMPHF_181114/tag_settings.html Alibaba

They offer guidelines and considerations to support the development of policies and standards for users of their platform. They all fall short however on providing considerations for multi-cloud estates which have become the standard for most enterprises today.

The importance of an organisation wide standard can be summarised under the following benefits

Why tagging/labelling is important

Some of the detailed use cases include

The Multi-Cloud challenge

Labels should primarily be applied at the billing or IAM domain layer (AWS: Account, GCP: Project, Azure:Subscription, Oracle:Compartment) and also at resource layer. Resources can be assumed to share labels with the account they are created in, removing the need for repeating the same label on all resources and allowing a simpler point of change. This however is dependent on the approach taken to allocate and manage multiple accounts, commonly referred to as multi-account strategy which is another topic I have written on here.

There are similarities in services offered by CSPs but no direct parallels. So it is not surprising that they do not have a common approach to labelling. In some cases they even refer to them differently (labels, tags). Organisations are left with the challenge of managing the translations and aligning their reporting tools. There are a good number of multi-cloud management tools in the market that can help with providing a common view of cloud estates but without an aligned labelling standard there is little benefit they can offer for multi-cloud reporting.

The major difference are summarised in the table below. The most common denominator should form the basis for a multi-cloud strategy.

AWS vs GCP vs Azure vs IBM vs Oracle vs Alibaba

Naming Convention

While there are no “global” standards for what kind of labels an organisation can use, some common aggregates are name, owner and environment. The most important label is the resource name.

This label should provide a unique identity for each asset and a link into understanding every other label that is added to the asset.

A generic sample for a multi-tenant multi-cloud environment is (the order of inputs can be varied to suite reporting requirements)

[company]-[CSP]-[business unit]-[programme]-[environment]-[resource type]-[purpose]-[sequence]

Compliance

To gain the benefits highlighted at the beginning it is crucial that a standard policy is published and policed. Expectations should be set and communicated to all stakeholders.

• Get alignment between business, technology and security (BizDevSecOps)
• Publish the standard centrally and where it is easy to reference
• Define Mandatory, Recommended and Optional labels compliance requirements
• Version and change control the labelling standard
• Automate compliance reporting and provide automated remediation solutions where possible.

Note that most CSPs provide some native governance mechanisms for enforcing and monitoring tags (AWS: Tag Policies, GCP: *NGT, Azure: Management Groups)

Tagging and Labelling Standards

The table below provides an example Tagging and Labelling Standard.

Mandatory tags should be applied to all accounts and resources, while Recommended are applied where needed. Optional tags can include resources specific keys that may only apply to certain types of resources or use cases. The compliance levels define the automated reporting classification and severity of any breach of compliance.

In some cases you may define specific sub-standards for common resources such as compute or storage, these may include more detailed security and operational specific labels to help the management of these resources.

Dos and Don’ts

Organisations are complex and dynamic organisms. Change is inevitable, so

• Your policies and standards need to be broad enough that you can keep them even when organisational changes occur without losing meaning or context.
• Where possible avoid using abbreviations or acronyms. For multi-national and multi-cultural business (basically any global business), be aware that abbreviations and acronyms are subjective.
• If possible use only lower case. An alternative is to consider your tags or labels as non case-sensitive for reporting purposes while building in parser (s) into your tooling to deconstruct the limitations from the CSPs.
• Define your delimiters for GCP
• Don’t change often (Maximum of once a year is my recommendation)