Cloud Tenant Tagging
Most cloud platforms support tagging as a means of attaching custom key-value pairs to cloud resources. Cloud Foundation teams can leverage tags to store important metadata about a cloud tenant directly in the cloud platform’s control plane. This metadata can help cloud foundation teams efficiently implement common operational procedures, e.g. by discerning cloud tenants hosting productive vs. non-productive workloads.
💡 Cloud platforms can use different terms for tags like labels or annotations. The Cloud Foundation Maturity Model refers to tags as any mechanism that allows attaching a custom key-value pair to a cloud tenant or resource.
Control panels like the Azure or Google Cloud Console display this metadata directly. This can simplify operations significantly because operators have key information immediately available.
Most cloud platforms offer APIs to read the metadata which allows the cloud foundation team to develop or build reporting automations or similar. Some platforms also enable users to create reports and dashboards for tagged cloud resources based on the metadata by providing tools, CLIs, or other native services.
Tagging can thus facilitate security & compliance automation scenarios. For example, an Incident Management Process can automatically classify criticality of detected incidents based on a tenant tag indicating whether the tenant is used productively or as a development/staging environment.
Tagging Is a Foundation for Good Cloud Management
Since tagging with key-value pairs is such a basic mechanism, cloud foundation teams can leverage their flexibility to implement many different cloud foundation capabilities. For example, tenant tagging can help implement a basic Chargeback via consumption cost allocation by assigning a
costCenter: tag to each AWS Account. At the same time, tagging a cloud tenant with
owner: firstname.lastname@example.org can enable 🔖 Security & Compliance processes like Incident Management Process. However, this means that many different requirements and stakeholders may place demands on tagging. This can create conflicting requirements. That’s why cloud foundation teams need to establish a clear strategy for tags and their use.
A Winning Tagging Strategy
Tagging and labeling is an early stage topic of your cloud journey. It forms the foundation of secure and structured growth.Learn more about Tags →
Consistent Tagging Is a Matter of Compliance
While cloud tenant tagging enables a basic implementation of many other cloud foundation building blocks, Cloud Foundation teams should treat adherence to the established tagging strategy as a matter of compliance. This is why the Cloud Foundation Maturity Model puts this building block into the Security & Compliance pillar, as opposed to putting it in the 🗂 Tenant Management or 💵 Cost Management pillar.
Tag the Most Useful Subset of Tenant Metadata
The key advantage of cloud tenant tagging is that it makes important metadata about a cloud tenant available directly in the cloud platforms. This means that a human operator or cloud-native automation does not have to interact with a separate Cloud Tenant Database to retrieve important tenant metadata. However, cloud tenant tagging is rarely a sufficient solution for storing all required metadata about a cloud tenant due to their technical limitations.
💡 Cloud Tagging needs to be consistent. Establish authoritative sources for each tag and clarify responsibilities for keeping the tag value up to date.
As Cloud Foundations mature, they also often find the need to implement self-service capabilities to maintain tenant metadata, e.g. using a Self-Service Multi-Cloud Tenant Database. This is difficult to implement when relying on cloud-native tagging APIs because their permissions are not fine-granular enough to distinguish “customer update-able tags” from “authoritative tags”. This can lead to inconsistent or incorrect tagging.
Best Practices for Cloud Tenant Tagging
Understand the Difference between Tenant and Resource Tagging
Most cloud platforms have tagging facilities that can cover the Tenant and Resource level of the Resource Hierarchy. Cloud Foundation teams should treat tenant tags as the preferred solution for tags that should apply consistently to all resources in a tenant. For example, when tagging a cloud tenant as
stage: production, tagging individual cloud resources inside the tenant with the same tag should not be necessary. Having the tag stored in a single place at a higher level in the resource hierarchy simplifies managing and updating the tag. Since the cloud foundation team is already responsible for 🗂 Tenant Management, it should typically also assume responsibility for tenant tagging.
Cloud Resource Tagging is useful for resources that need to be individually tagged, for example when labeling cloud resources storing personally identifiable information (PII). This responsibility best resides with the cloud foundation’s customers.
To get the most benefit out of tagging cloud tenants, cloud foundation teams should set clear expectations and guidelines for the name and values of tags. These guidelines are often called a “tag catalog” or “cloud tagging policy”. The building block Multi-Cloud Tagging Policy covers this capability.
Inconsistent (or even worse - incorrect) tagging severely limits the opportunities for building on tagging data for building higher-level cloud foundation capabilities. For example, taking a risk-based automation approach based on
stage for Tenant Deprovisioning / Decommissioning or classifying incident severity in an Incident Management Process becomes impossible when the cloud foundation team can’t trust that each tenant is consistently tagged with the correct
Consider a Multi-Cloud Tagging Strategy
Cloud Tenant Tagging is a platform-scoped building block in the cloud foundation maturity model. Cloud Foundation teams following a multi-cloud strategy should look into Multi-Cloud Tagging Policy to implement consistent tagging across all cloud platforms at the core scope.
Understand Tagging Limitations of Cloud Platforms
Most cloud platforms impose technical limitations on the use of tags. Cloud Foundation teams should be aware of the following restrictions
Limited number of tags: Azure and AWS limit the number of tags to a maximum of 50 tags per tenant
Limited length: Platforms can limit the length of key/value pairs, sometimes as short as 64 characters
Restricted character-set: Most platforms only support alpha-numeric characters, with a few exceptions for punctuation characters
Restricted words: Some platforms forbid the use of certain keywords, e.g. the
Cloud Tagging Cheat Sheet
For a detailed overview of platform tag limitations and comparison of allowed tags have a look at this tagging cheat sheet.View Tagging Cheat Sheet →
Automating Cloud Tenant Tagging
Since consistency is crucial for making a cloud tenant strategy useful, cloud foundation teams should aim for a high degree of automation when implementing this building block. Most teams will initially start with a manual tagging approach e.g. by manually setting tenant tags during Tenant Provisioning. Automation of the provisioning process also enables semi-automated tagging. To ensure consistent tenant tagging for the entire cloud tenant lifecycle, cloud foundation teams should also enable self-service updates of tags, for example by leveraging a Self-Service Multi-Cloud Tenant Database with automated reconciliation of tenant tags to achieve full tagging automation.
meshStack ensures up-to-date tags at least once a day for all cloud tenants based on metadata entered by cloud tenant owners and/or platform operators.Learn More
Get a quick overview of cloud tenant tags with open-source Collie CLI across AWS, Azure & GCP.Learn More
- GCP CFT - Example Foundation
It sets some default labels like environment, security contact, etc for all projects. But adding any custom tags requires modification of the terraform files.Learn More
- Azure LZ Terraform module - ES
Provides a default_tags variable that can be adapted and applied to multiple resources and resource groups. Additionally base_module_tags includes a tag that shows the deployment source (i.e. terraform), this is by default enabled but can be disabled with disable_base_module_tags. One downside is that it is not clear which Azure objects will be tagged from the module structure. But there isn’t any policies forcing the tags to inherit.Learn More
- Azure CAF Terraform Modules
An object called global_settings is created and used by the module. It governs the creation of resources based on a set of common criteria (naming convention, prefixes, region of the deployment, name of the environment, tags inheritance settings, etc.) But there isn’t any policies forcing the tags to inherit.Learn More
- GCP Fabric FAST
Tenants can be tagged via the project’s YAML file of the project factory. Defaults that shall be applied to all projects can also be defined. Tags cannot be defined at the Team level yet.Learn More
- AWS Control Tower with AFT
By default provisioned accounts are not tagged. It is possible to tag those accounts through a terraform variable account_tags.Learn More