Modern businesses often have several mission-critical applications, services and resources running in the cloud. The bigger the organization, the more likely these assets are spread across public and private clouds and a variety of cloud platforms, including Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure.

It’s easy to understand why: The cloud has enabled greater flexibility, accessibility, and resilience for IT professionals and business units alike.

However, the convenience of the cloud has also created new headaches. Managing all those disparate resources and services — spread across multiple cloud providers and accounts/subscriptions — can be an incredible challenge for systems administrators. In such a complex and dynamic environment, it’s difficult to even get comprehensive visibility, let alone audit and enforce security policies, track and optimize operational costs, and even determine who’s responsible for fixing what.

Organizations can simplify and automate critical tasks across complex multi-cloud environments with relative ease. 

The key to these efforts is a global tagging policy. These helpful bits of user-defined data identify and describe the resources running across one or more cloud environments. They can provide insight into the application running on that infrastructure, the team responsible for that particular resource, billing code, and anything else the company finds useful in governing their cloud environment.

Many companies are embracing multi-cloud strategies and in doing so need to be very purposeful in creating global tagging strategies that will work across all clouds.  All cloud providers are not created equal when it comes to tagging and have different limitations. It is important that your global tagging policy does not violate any of the limitations of any of the cloud providers that you use today or will possibly use.  This lowest common denominator approach will ensure that you don’t end up with a fragmented tagging strategy. Fragmentation of your strategy is a sure fire way to reduce its usefulness and longevity.

We recommend the following tagging strategy design to accommodate all major cloud providers:

  • Maximum Key Length (driven by GCP): 63 Characters
  • Maximum Value Length (driven by GCP): 63 Characters
  • Maximum # of Tags Per Resource (driven by Azure): 15 Tags
  • Case Sensitive
  • Keys and values can only contain lowercase letters, numeric characters, underscores, and dashes. International characters are allowed.
  • Label keys must start with a lowercase letter and international characters are allowed.
  • Label keys cannot be empty
  • Tag names can’t contain these characters: <, >, %, &, \, ?, /, @
  • AWS-generated tag names and values are automatically assigned the aws: prefix, which you cannot assign. User-defined tag names have the prefix user: in the Cost Allocation Report.
  • Use each key only once for each resource. If you attempt to use the same key twice on the same resource, your request will be rejected.
  • You cannot tag a resource at the same time you create it. Tagging requires a separate action after the resource is created.
  • You cannot backdate the application of a tag. This means that tags only start appearing on your cost allocation report after you apply them, and do not appear on earlier reports.
  • Tags applied to the resource group are not inherited by the resources in that resource group.
  • Tags can’t be applied to classic resources such as Cloud Services.

Keep in mind, all of the providers are regularly expanding their tagging support, but best to plan for today and expand later when able to.  

For those who may only plan on using a different combination, we have provided the following high-level overview of the tagging limitations of each cloud provider as of October 2018:

AWS (uses the term tags)
  • Maximum key length: 128 Unicode characters
  • Maximum value length: 256 Unicode characters
  • Case sensitive
  • Maximum number of tags per resource: 50
  • Maximum active tag keys for Billing and Cost Management reports: 500
  • Reserved prefix—aws:
  • AWS-generated tag names and values are automatically assigned the aws: prefix, which you cannot assign. User-defined tag names have the prefixed user: in the Cost Allocation Report.
  • Use each key only once for each resource. If you attempt to use the same key twice on the same resource, your request will be rejected.
  • You cannot tag a resource at the same time you create it. Tagging requires a separate action after the resource is created.
  • You cannot backdate the application of a tag. This means that tags only start appearing on your cost allocation report after you apply them, and do not appear on earlier reports.
  • Allowed characters are Unicode letters, whitespace, and numbers, plus the following special characters: + – = . _ : /
Azure (uses the term tags)
  • Each resource or resource group can have a maximum of 15 tag name/value pairs. This limitation applies only to tags directly applied to the resource group or resource. A resource group can contain many resources that each have 15 tag name/value pairs. If you have more than 15 values that you need to associate with a resource, use a JSON string for the tag value. The JSON string can contain many values that are applied to a single tag name. This article shows an example of assigning a JSON string to the tag.
  • The tag name is limited to 512 characters, and the tag value is limited to 256 characters. For storage accounts, the tag name is limited to 128 characters, and the tag value is limited to 256 characters.
  • Virtual Machines are limited to a total of 2048 characters for all tag names and values.
  • Tags applied to the resource group are not inherited by the resources in that resource group.
  • Tags can’t be applied to classic resources such as Cloud Services.
  • Tag names can’t contain these characters: <, >, %, &, \\\\, ?, /
GCP (uses the term labels)

A specific set of resource types where labels can be applied:

  • Virtual machine instances
  • Forwarding rules (Alpha)
  • Images
  • Persistent disks
  • Persistent disk snapshots
  • Static external IP addresses (Alpha)
  • VPN tunnels (Alpha)

You can assign up to 64 labels to each resource.

Resources listed as Alpha do not yet have support in gcloud or the Google Cloud Platform Console. Instead, use the Alpha API to set labels for these resources.

Label keys and values must conform to the following restrictions:

  • Keys and values cannot be longer than 63 characters each.
  • Keys and values can only contain lowercase letters, numeric characters, underscores, and dashes. International characters are allowed.
  • Label keys must start with a lowercase letter and international characters are allowed.
  • Label keys cannot be empty.

So if tagging delivers so many benefits why don’t more companies use them?  The answer is complicated. It turns out that while on the surface tagging seems easy to do, doing it comprehensively and consistently takes a lot of time, effort, and expertise.   In some scenarios, an organization has already been using a complex multi-cloud environment for years, and tagging simply wasn’t on the radar when those assets were deployed. Other times, an organization may have neglected to put a dedicated team in charge of creating, managing, and enforcing a company-wide tagging strategy. And occasionally, a company may have had a strong tagging strategy in place, but a merger or integration project may introduce assets without tags. Ultimately, one of the biggest reasons tagging doesn’t happen is that it is really hard to get developers and engineers to consistently tag the resources that they provision and configure.

This white paper will discuss tagging strategies at a higher level, including methods that can be employed on any provider that supports tags. It will explain what tags can do, why they’re so critical, and discuss the best practices – and things to avoid — when implementing your own tagging strategy.

The good news is that if you are one of the many organizations that haven’t been able to fully realize a global tagging strategy you aren’t alone and there are clear-cut pathways to success.  For example, the idea of adding tags to an already-running multi-cloud infrastructure may seem daunting — impossible, even — but it doesn’t have to be. Later in this white paper, we’ll discuss some best practices for “retrofitting” your multi-cloud environment with a global tagging strategy.

Why Tags Are Absolutely Vital in a Multi-Cloud Environment

To understand why tags are so useful, imagine a massive bookshelf filled with books – books that don’t have titles on their spines or covers. Finding what you need would involve tediously pulling each book out, opening it up, and reading the first few pages. Or imagine having to recognize each phone number in your smartphone’s address book, because no names could be applied to each string of numbers.

Similarly, tags make it much easier for systems administrators to find specific resources that they need to audit, update, fix, troubleshoot, and shut down. They make the deployment of new features and applications, security-policy enforcement, and investigating security breaches much more manageable. And perhaps most importantly, good tagging practices enable automation that can save your organization significant time and money.

That’s a basic explainer of the importance of tags – providing important contextual information at a glance – but the power of tags goes much further in a complex multi-cloud infrastructure. At a fundamental level, tags can identify whether each cloud resource is part of an application and who is responsible for it and how it should be charged back.

All of those factors make tags essential in any software-defined infrastructure, and supercritical to the mature governance of a multi-cloud environment. When your company’s resources are spread across multiple cloud providers and multiple accounts/subscriptions it’s essential to have a common taxonomy that allows you to rapidly identify the how what and who of a resource and use this to automate operations including enforcement of policies.  Without a global tagging policy, and one that is actually consistently and comprehensively applied, you are left to hunt manually for specific assets and the resulting sprawl is simply impossible to govern. This means you ultimately spend more than you should and open yourself to security and compliance risk.

Comprehensive tagging powers everything.  For example, tags can enable more-effective auditing and report for your cloud infrastructure. Accounting code tags for individual resources can help identify chargebacks and savings opportunities, data-sensitivity and encryption tags can ensure assets hosting confidential information receive the proper attention, and compliance tags can identify which resources must adhere to regulations such as PCI or HIPAA.

And finally, tags can help IT, security, and risk professionals with to more easily and consistently fulfill their core responsibilities and functions. Tags can reveal an asset’s operating schedule, flag temporary resources that require deletion, identify the version number of the applications running on a server, and ensure all resources associated with a single workflow are tagged with the same label.  

TagScenarioExample Values
EnvironmentIdentify resources and set policy/workflow by stage of developmentDev, QA, Test, Prod
Resource OwnerFor notification, visibility and user-based policiesMarketingAdmin,SalesEngineeringTeam
Cost Center / Accounting CodeFor chargeback and budget purposes#78925
CriticalityUnderstand whether a machine is highly critical or not (useful for opt-out of automation)P1, P2, P3
Application IDIdentify all resources associated with a workloadWidget-2
EncryptionKnow whether encryption is required or not for data at restRequired, Recommended, Optional, NoEncryption
ComplianceKnow whether a resource is subject to compliance/audit requirements and trigger compliance automationHIPAA-1, PCI
ScheduleKnow whether a machine is meant to be turned off on a regular schedule6pm-6am, weekends off, business hours only, 10pm+
Age LimitFor environments or resources that are meant to be temporaryDeleteMe-12hrs, DeleteMe-30days
Operating SystemAnd OS version, for management, patching and vulnerability assessmentUbuntu-17-04
ApplicationAnd version(s), for management, patching and vulnerability assessmentPortal-123

The Four Tags That Everyone Should Use

The full scope of your tagging strategy depends on a variety of factors. Every organization has different goals, and every tagging strategy should be defined based on those unique business needs. With so many tag options, you may be wondering where to even start.

We recommend that your tagging strategy should begin with the following four tags (we call these our “Core Tags”). From there, you can build out a more-complex tagging infrastructure, but these Core Tags will cover some very important bases for any multi-cloud environment.

As you might expect, each of these tags becomes more powerful when used in combination with other essential tags. Basic tag combinations allow for fairly rudimentary automated tasks, but these Core Tags become the foundation for complex automation processes.

Application ID: In a multi-cloud environment, your organization’s mission-critical applications may have important resources installed on several different servers from several different providers. A consistent application ID tag ties all these assets together, making it much easier to schedule uptime and downtime, deploy necessary updates, manage version control, enforce security policies, and determine which assets require data encryption or automated shut-down in the event of a breach.

Owner: With a dynamic and diverse multi-cloud environment, it can be surprisingly difficult to pinpoint basic information such as “which department is paying for this resource,” “who is the point of contact in case anything goes wrong,” and “which teams should be notified in case of an outage or significant event.” This is why owner tags are absolutely essential. In order to examine and manage costs for specific resources, contact stakeholders in case of emergency, and alert all asset users of important changes, a simple owner tag goes a very long way. Your users must be in the habit of adding an owner tag to any asset when they deploy it.

Environment: Development, QA, staging, and production environments have radically different update cycles, administration needs, rates of usage, and security requirements. That’s why an environment tag — a simple keyword that designates each asset as dev, QA, staging, or production — is one of the first tags your organization should implement.  Coupled with operational tags and risk tags, environment tags can also be used to automate processes such as scheduled shutdown, startup, and maintenance of key assets based on their environmental descriptor.  

Risk: Any cloud resource that involves sensitive customer data or confidential business information should be labeled appropriately with a risk-level tag. Based on the risk level of an individual resource, responses to open access or security breaches can be automated based on the level of severity. For example, resources containing customer data could automatically be shut down if a breach is detected. For lower-risk scenarios, automation could simply send an email alert to the point of contact designated in the owner tag.

Extend Your Tagging Strategy With These Key Tags

In this section, we’ll discuss some of the other important and frequently used tag types that can help any company improve structure and automation within a multi-cloud infrastructure. Once your foundational tagging baseline is set, you can augment your automation and auditing processes with these types of tags.

Technical Tags

Technical tags are essentially “Tagging 101,” as they provide basic information about the assets spread throughout a cloud infrastructure. Some examples of technical tags include the name and environment of a particular resource, the function of each asset, the version number of each cloud application, and tags that identify resource clusters devoted to a specific application.

Business Tags

Business tags give each of those named resources a sense of context and ownership within an organization. While technical tags define what each resource is, business tags define who is responsible for it in terms of administration and cost. Common business tags include department codes, cost codes, the technical point of contact, and the business point of contact.

Specific Risk, Security and Compliance Tags

These tags identify any resources containing sensitive customer data and confidential information, and they also flag any systems that require compliance with mandates and regulations. Common compliance and security tags such as “HIPAA,” “sensitive,” or “encrypted” can be combined with DivvyCloud Bots to automatically remediate problems or alert resource owners.

Operational Tags

Operational tags can be used to denote certain instructions and tasks, such as identifying critical resources that should always be left running, the times of day certain resources should be shut down or started up, noting whether a specific resource’s data should be encrypted, and flagging temporary resources that should be deleted at a specific time. Combined with DivvyCloud Bots, many of these processes can be automated based on the corresponding tags.

problems or alert resource owners.

Business Tags

Business tags give each of those named resources a sense of context and ownership within an organization. While technical tags define what each resource is, business tags define who is responsible for it in terms of administration and cost. Common business tags include department codes, cost codes, the technical point of contact, and the business point of contact.

Operational Tags

Operational tags can be used to denote certain instructions and tasks, such as identifying critical resources that should always be left running, the times of day certain resources should be shut down or started up, noting whether a specific resource’s data should be encrypted, and flagging temporary resources that should be deleted at a specific time. Combined with DivvyCloud Bots, many of these processes can be automated based on the corresponding tags.

Tags Enable Everything From Identification to Automation

Tags can certainly help you streamline automation, but there are simpler advantages that make tagging essential for any organization with a cloud-based infrastructure. Just being able to see whether certain resources are for development or production, the critical resources that should always be running, and the point of contact in case any issues arise are all key benefits for systems administrators.

Particularly in a multi-cloud environment that involves several providers and accounts, complex pricing schemes can be difficult to audit and manage. In addition to identifying which departments should be charged for utilization, cost-based tags can help organizations determine potential areas for savings.

As we’ll discuss in the “Effective Tagging Strategies” section, tags can also help standardize and validate information. In the case of billing codes and cost-related tags, standardized metadata can ensure this information wasn’t entered erroneously or fabricated to get a resource deployed. Standardized cost tags can also help manage and verify cloud-based costs.

To enable automation, your organization needs a deep and well-thought-out tagging strategy combined with bots and scripts. System administrators can use tag values to enforce policies, orchestrate remediation efforts, and automate responses to important events. For example, if you have a resource tagged as having sensitive data that is accidentally made accessible to the public, bots and scripts can automate the process of shutting that resource down. For less-alarming situations, automation can simply notify the resource owner that action must be taken.

How to Create and Deploy an Effective Tag Strategy

Whether you’re starting your tagging strategy from scratch or “retrofitting” your current cloud infrastructure, here’s how your organization can tackle the challenge. First a reminder from the beginning of this guide: design your tagging strategy using the lowest common denominator approach.  In other words, design it to accommodate the various and distinct limitations of each major cloud provider. Now on to a few different strategies based on where you are today in your global tagging strategy journey.

Starting from scratch: When launching your tagging strategy as part of the provisioning process, ensure that your tags represent all the needs of your organization. This will take planning and collaboration across several departments – from finance to operations to each of the business units that use the cloud as part of their workflow – and it’s best to put in a lot of effort before deployment. If your organization doesn’t address all the tags needed at launch, it means a lot of work will be needed after deployment. In general, more tags are better than fewer tags, just as long as the tags are standardized and well-documented to eliminate input mistakes and redundancy. Once your strategy is fully fleshed out, it’s best to implement it with as much automation as possible to eliminate human error and potential gaps.

Once that groundwork is in place, it’s important to ensure your tagging strategy evolves and improves over time. As you go through each application sprint or development sprint, you have an opportunity to re-tag through automation. If there are any tags you have added to your strategy, this is the perfect time to apply them. If new resources are available and you’ve added those tags to your pipeline, those changes can be applied as you deploy your next code base.

Retrofitting your existing cloud infrastructure: When dealing with a messier implementation scenario, such as adding tags to an existing cloud infrastructure, there is no easy button.  Take a phased approach. Establish your policy and begin to implement it first within the IT departments. Once you have full compliance here then move on to developers and engineers in business units or who sit outside of central IT.  Start in all cases on applying this policy to all net new resources and build this muscle memory. Establish the value of tagging with all the parties involved. Demonstrate the benefits to everyone in the organization – up and down the company hierarchy.  Once you have buy-in then begin to move through legacy environments and update tags. Do so on some type of incremental basis that limits the period and frequency of disruption to the people who will have to inform or execute this effort.Developing and implementing a strong tagging strategy works best when your organization is starting with a clean slate. That way, tags can be implemented, standardized, and enforced as part of the provisioning process. Starting from scratch also lets administrators fine-tune the tagging process moving forward: New and updated tags can be added cleanly and seamlessly as new code bases are deployed.

Unfortunately, few organizations have the luxury of starting their efforts with a blank canvas. Instead, most tagging strategies are implemented as a “uh oh, we need to address this” measure — a necessary reaction to an increasingly complex and diverse cloud infrastructure. Perhaps the company has grown quickly or moved more critical resources to the cloud over the years. Maybe the cloud provider has made additional resources available for tagging. In other scenarios, organizations may have implemented effective tagging strategies already, but a merger or acquisition requires getting an inherited infrastructure up to speed.

The Big Tagging “Don’ts”

It’s also essential to avoid common stumbling blocks when it comes to tagging. The biggest “don’t” of all is to avoid tagging altogether, but there are a few implementation strategies that can be detrimental to your bigger goals.

Don’t put your head in the sand: Many organizations can get overwhelmed at the prospect of devising and implementing a tagging strategy, but avoiding the problem just means your existing problems will get worse.

Don’t duplicate tags: In some cases, granular tags may not be necessary. If there’s only one group that owns a specific set of resources, that can be reflected in a separate internal data set. An internal project ID or application ID can relate those items together, reducing error, emission, and cause for replication.

Don’t ignore the fine print: Every cloud provider has different rules about what can and cannot be tagged, as well as different character sets that are supported within tags. Make sure you know the lay of the land before devising your organizational tagging strategy.

Don’t forget to standardize your tags: By incorporating a drop-down list or a standardized database of tags to draw from, you can ensure tagging remains consistent. Fixed tags eliminate misspellings, and they can also help validate things like billing codes.

Don’t forget to follow up: When tags are applied at the time of provisioning, make sure they last. Sometimes, asset owners will apply tags to ensure their resources are deployed, then modify or delete them later. Use DivvyCloud Bots to flag those instances as non-compliant resources, and make sure resource owners are notified for remediation.

Don’t forget to audit your code templates: Be sure to audit your code templates routinely, as organizations often define a lot of their cloud infrastructure inside of those templates. It can lead to major conflicts with your tagging strategy: Parent autoscaling groups may simply redeploy the resources that your tagging-based automation has shut down.

Conclusion

With an effective tagging strategy, any organization can achieve a greater sense of clarity and structure within a multi-cloud infrastructure. But that’s just the ground floor when it comes to the benefits of tagging: Tags are the key to an extensive slate of operational benefits, from simple identification of assets to full-scale automation across a diverse range of assets and cloud providers. They can help identify who to call when a resource is inaccessible, the assets that represent ripe opportunities for savings, and enforce critical security policies. Best of all, your tagging strategy can start simply and seamlessly. Over time, it can mature and grow in complexity as your business evolves and scales. All you need is a solid tagging foundation, an understanding of best practices, and an inspired first step.

Similar resources that you may also enjoy