Multi-Cloud Tagging Policy

⭐️⭐️⭐️⭐️🏢 CoreDefine and enforce a consistent tagging of cloud tenants and resource across multiple cloud platforms.

Cloud Foundation teams who implement Cloud Tenant Tagging or Cloud Resource Tagging often find the need to centrally define and communicate tagging conventions. This is a pre-requisite for shared-responsibility tagging, e.g. cloud foundation teams enforcing tenant tagging but leaving cloud resource tagging to application teams.

Make your Cloud Security a Priority

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

Best Practices for a Multi-Cloud Tagging Convention

Establish a Naming Convention for Tags

Cloud Tagging works best when following a consistent naming convention. This naming convention should consider the technical limitations for storing tags in cloud platformsopen in new window. Namespace prefixes on tags help to separate the responsibilities for maintenance of a particular tag. For example, when some tags are automatically reconciled with a Cloud Tenant Database by the cloud foundation’s automation systems, giving them a clear prefix helps separate those tags from tags maintained by customers individually.

Focus on Information That’s Relevant across All Cloud Platforms

The most common metadata manage on cloud accounts and resources are listed below. Namespacing can be a good solution to enable individual cloud platforms to maintain additional tags that are relevant to their operation.

Metadata NameDescriptionPossible values
Contact PersonEmail address or other information to get information about the responsible contact person for the cloud resource or cloud account.
Usually used for Security contact, Operations contact, Account owner etc.
my-personal-postbox@example.com
Integration and Automation tagsMetadata to enable automation or integrations. Cloud providers provides tools to apply templates, policies or similar depending on metadata.SoC, security requirement (high, mid, low) etc.
MailboxUsing a group email postbox instead of using a dedicated persons email address. This is in most scenarios more appropriate and has the benefit of protecting PII while ensuring that multiple recipients.
Usually used for Security contact, Operations contact, Account owner etc.
project-postbox@example.com
Cost CenterCost Center, Budget ID, internal recipient number for internal cost controlling and billing.Any type of text or number depending on the enterprise cost center schema
Data ClassificationMetadata describing the data classification of the information processed by the cloud resource or cloud account.internal, confidential, top secret, business secret
Environment / StageMetadata regarding the stage for which the cloud resource or cloud account is used.dev, test, qa, prod, ressource, data

Involve All Cloud Foundation Stakeholders

Tagging can serve many different use cases. It’s thus important that the cloud foundation involves all cloud foundation stakeholders in the definition and evolution of the central tagging policy.

💡 Clarity and consistency are only possible if cloud foundation team have the organizational authority to make a binding decision on these matters.

One important challenge here is to make stakeholders aware of the consequences that introducing tags has on the application teams’ experience. For example, when every cloud platform wants to introduce a slightly different convention for an environment/stage tag, application teams will get confused about the differences.

Consider Backwards Compatibility and Update Procedure

As a cloud foundation evolves, cloud foundation teams will discover the need to define additional tags or change the definition of existing tags. Performing these changes should always consider the implications on existing application teams and automation processes. Enforcing the tagging policy via a Self-Service Multi-Cloud Tenant Database for example enables the cloud foundation team to request additional metadata from existing application teams or apply automated data migration to existing metadata. Combined with automation that reconciles cloud tenant and resource tags with this database, cloud foundation teams eliminate configuration drift and gain a lot of agility for evolving their tagging policy.

Treat Tags like Global State

Global state is evilopen in new window because it tends to make system behavior unpredictable. This analogy will be familiar to those with a background in programming. From the point of view of building a cloud foundation tags behave in much the same way like global state in a program.

One important technique to avoid the downsides of global state is to prevent uncoordinated mutation of this state by assigning explicit responsibilities and authority to systems and processes for maintaining this state. These systems can also enforce “business logic” around updating this state.

Another good heuristic is to try and avoid global state in the first place. For example, a clear Resource Hierarchy can remove the need for some kind of tags. Having a Chargeback via consumption cost allocation process integrated with the cloud tenant database (which is also useful for Tenant Inventory Reconciliation) can avoid putting extensive chargeback related data into the cloud. Tenant-specific configuration data may be better kept in services like a Virtual Network Service instead of a on-prem-conncetivity.cidr:10.0.0.0/24 tag.

  • meshStack

    meshStack makes metadata an integral part of the tenant provisioning process and allows cloud foundation teams to create a full customizable list of tags that should be filled in by cloud tenant owners.

    Learn More open in new window
  • collie-cli

    Get a quick overview of cloud tenant tags with open-source Collie CLI across AWS, Azure & GCP.

    Learn More open in new window