As a product manager focused on Oracle Cloud Infrastructure's core platform capabilities, such as compartments and tagging, I'm often asked for best practices on how to use these services to optimize cost management, simplify operations, and maintain governance. In this post, I discuss the purpose of tags versus compartments, and the best way to use tags across your enterprise to maximize your ability to track costs and organize cloud resources. I also show you how you can set up a tagging infrastructure as an administrator, along with providing sample policies that you can use, tips for fixing mistakes, and how to combat dreaded “tag spam.”

Why Use Tags?

You might be wondering, “Why should I use tags?” Simply put, tags allow you to “tag” your resources with extra data so that you can accurately describe how the resources are used and what they are used for. With tags, you can associate individual resources with a project, a department, or even a customer. Therefore, you can leverage tags for cost tracking purposes and also set budgets based upon cost tracking tags. This allows you to manage costs by project, cost center or even by operator.

Tags are metadata that you can apply to resources in your tenancy. They are composed of a key and a value, and are usually written like this: CostCenter:W1234. In that example, the key is CostCenter and the value is W1234.   

Tags also let you add operational characteristics, so that you can easily determine an application version running on a set of compute instances. For example, you could add “application” and “application_version” tags to all your compute instances, which would let you easily determine which compute instances are running which versions of your applications.

We see tags as a powerful tool to help you organize your resources, and we plan to support tags with all our resources and most of our management features.

Can't I Use Compartments for That?

Now you might be thinking, “Wait, I thought I could use compartments to organize resources by business unit or department.” It’s true that you can use compartments to group and organize your resources, although usually for less complex tenancies. However, compartments are inherently different from tags because compartments are hierarchical. You can make a nested tree of compartments, which is not easily done with tags. Another inherent difference between tags and compartments is that a resource can live in only one compartment. However, it can have up to 64 tags on it, which lets you describe many dimensions of a resource. In that sense, tags span compartments, so you can have resources residing in different compartments tagged as being used for a specified project.

Because compartments are hierarchical by design, I recommend that you structure your compartment layout primarily to achieve your access-management goals. This kind of layout lets tenancy administrators create broad policy at the highest levels of a tenancy. It also lets compartment administrators create more fine-grained policy as they go down the compartment tree. You have the flexibility to move entire compartment trees to another parent compartment within the same tenancy, but again, consider your goals for access management when doing so.

Best Practices for a Sound Tag Nomenclature

You can use tags to add descriptive metadata to all your resources. However, to do that in an organized way, you need to ensure that your tag nomenclature is sound.

Just like there’s no one perfect dress nor shoe, there’s no one perfect tag nomenclature. However, here is some general advice I give customers to help them design their tag nomenclature.

Create a list of questions and dimensions that you want to answer with tags. One obvious question is “which department should pay for this resource?” Other questions might include “Which customer is this for?” and “What customer project?”. Usually these questions break down into three groups based on their primary purpose: cost management, operational, and governance. Following are some of my example tags for each group:

• Cost Management: Cost_center, Customer, Department, and Project. These tags can be used as dimensions for how you allocate the costs of a resource.
• Operational: Application, Application_version, Last_updated, Created_by, 24_hour, and Daily_usage. These tags describe the operational nature of the resource, and are the tags that your team uses as a basis for IT operations.
• Governance: HIPAA and Data_classification. This category includes data about governance like HIPAA compliance and data classification, for example, Public, Confidential, Secret, and Top Secret.

Setting Up Your Tagging Infrastructure

Now for some of the very basics of tagging in Oracle Cloud Infrastructure. We have two types of tags.

• Free-form tags are simply key-value pairs. Free-form tags are standard across the IaaS industry. However, they don’t allow for securing tags, and they can’t be used with our advanced tagging features.
• Defined tags are unique to Oracle Cloud Infrastructure and let you create a predefined key for your tags. Defined tags reduce the error rate when applying tags because you can select from a predefined list of tag keys. Defined tag keys are grouped in tag namespaces, which are simply a group of tag key definitions. Tag namespaces can have access control policies placed on them, enabling you to enforce proper security controls.

My first suggestion is to create a tag namespace for each group of tags. In the preceding example, I would create tag namespaces for cost management, operational, and governance tags.

Creating a tag namespace for each group helps you organize your tags and lets you create specific access policies for each group of tags. Generally, you can write policies that allow anyone access to your operational tags, because the consequence of users changing these tags is fairly small. However, there might be profound consequences if cost management or governance tags are changed improperly, so you should have more restrictive policies in place to limit access to them.

Policy and Tags

We suggest that you put the tags in the root of the compartment tree in which they will be used. For example, if you plan to use tags across your Product-AcmeGizmo compartment tree, put the tag namespaces and the associated policy in the Product-AcmeGizmo compartment. For more information, see our tag policy.

The following sections show how I set up the policy for my tagging strategy.

Example Policy for Any User

The following policy makes it easier for any user to see the values of the tags in the tenancy:

allow any-user to inspect tag-namespaces in tenancy

Operators Policy

The following policy statements let your operators create compute instances and their related resources. However, they have access only to the “operations” tag namespace and not to, for example, the “finance” (cost management) tag namespace.

allow group Operators to manage instance-family in compartment Product-AcmeGizmo
allow group Operators to manage virtual-network-family in compartment Product-AcmeGizmo
allow group Operators to use tag-namespaces in tenancy where target.tag-namespace.name = 'operations'
allow group Operators to read all-resources in compartment Product-AcmeGizmo

Tag Administrators Policy

The following lines of policy give the TagAdmin group full control over all tag resources in the tenancy.

allow group TagAdmin to manage tag-namespaces in tenancy
allow group TagAdmin to manage tag-defaults in tenancy

All of the preceding policy statements let only the TagAdmin group manage the tags in the cost management and governance namespaces, while the Operators group can create resources and use the operational tags.

Fixing Mistakes

If you create a badly named tag namespace or tag key definition, you can rename them or even delete the tag key definition.  

Consider that when you delete a tag key definition, that tag is removed from all Oracle Cloud Infrastructure resources. This ensures that you can keep your tag data clean.

Combating Tag Spam to Achieve Trusted Tags

You now have a good base for a well-formed set of compartments, tag namespaces, and tag key definitions, and the associated policy to protect your tag keys from accidental alteration. This base allows Oracle Cloud Infrastructure engineers to create some unique and robust capabilities to help you ensure that end users always apply the correct tags at the correct times. Next, I'll talk about the configurations that you can put in place to help combat tag spam and make it easy to always ensure that the correct tag is applied.

Default Tags

When you set default tags, you implement a rule that resides in a compartment that applies a tag on any resource created in that compartment. For example, if you want the Operations.Project=AcmeGizmo tag to be automatically applied to every resource created in the Project-AcmeGizmo compartment, you create a default tag for that compartment to apply that tag automatically. These tags are also applied hierarchically. That is, if you set a default tag on a compartment, then every child of that compartment inherits that tag.

Default tags can also be used to apply tags to a resource that the creator of a resource can’t apply. From the preceding example, the Operators group has no permissions to the cost management tags. However, you can use a default tag to apply a tag to which the creator of the resource has no permissions. For example, Tony the Tag Administrator creates a tag called Finance.CostCenter. Tony wants to ensure that no one can change these tags, so he restricts them. Tony also creates a default tag to always apply the Finance.CostCenter tag with a value of AcmeGizmo. When a member of the Operators group creates a compute instance in the compartment, the Finance.CostCenter=AcmeGizmo tag is applied, and that user can’t change the tag. This solution is ideal for ensuring accurate cost tracking and proper governance.

Tag Variables

You can automate the application of tags based on who created the resource and the date and time when it was created. Specifically, use can use tag variables to automatically apply these tags, based on variables. The variable name is translated when it’s applied to the resource. The following tag variables are available:

Using a tag variable with default tags lets you ensure that all the resources created in a compartment are always tagged with the right variables, and lets you automate the application of tags that describe when the tag was applied and who created the resource.

Here's an example of how you can put this in action:

1. Create a tag namespace and key.
2. In your root compartment, create a default tag. Choose the tag namespace and key that you created, and for the value, use ${iam.principal.name}. This step implements your tag variable.
3. Add another default tag for ${oci.datetime}. Now these tags are automatically applied to every resource that is created in your tenancy.

These tagging capabilities greatly support customers who follow the model of continuous integration and continuous deployment (CI/CD), and as such, rely on Terraform to create and update resources. Terraform fully supports applying tags to resources, and it also works well with the other features described here. For example, you can have your Terraform script always apply the tags when a resource is created and re-created, but you could also instead rely on a tag default to automatically apply tags to resources in a compartment.

Ensuring That Tags Have Been Applied Correctly

Despite all the automation we’ve used to set up a tagging strategy for Oracle Cloud Infrastructure, it’s still possible for tagging mistakes to occur. For such cases, examine the sample in the Oracle Cloud Infrastructure Python SDK called stop_untagged_instances.py. This sample shows how to write code that uses the Search service (RQS) to help find any resource that isn’t tagged correctly and stop it. It also creates a CSV history file that shows you who created the resource and when and where it was created.

This sample is a starting point for creating your own scripts that scan your infrastructure for resources that aren’t tagged correctly. These scripts can either report on the mistagged resources or, in extreme circumstances, stop the mistagged resources.

The Result of a Well-Executed Tagging Strategy

Tag namespaces allow for better organization and precise security policy for tags. The carefully created tag namespace policy means that operators can’t change tags accidentally. The result is that you have data that you can trust. Following are some benefits of a well-executed tagging strategy.

Accurate chargeback and show back scenarios: You can use that trusted data to allocate costs successfully for chargeback or showback scenarios. Specifically, you can see the actual costs associated with a particular tag. For example, you can see all the costs for the CostCenter:W1234 no matter where they reside in the tenancy. For details about how you can use these tags for better cost management, see Phil Newman’s blog post on controlling your costs on Oracle Cloud Infrastructure. 

Easily find resources used for specific projects/customers: If you trust your tag data, you can use it to find your resources across your entire tenancy using the Search service. For example, you can use it to find all the resources associated with a particular customer or project across your entire tenancy.

Governance and auditing: Use tags for auditing. For example, you can classify your resources on a data sensitivity scale, from public to secret to top-secret information. Using tags to classify your Oracle Cloud Infrastructure resources in this way lets you write reports on which resource types are interacting with each other.

Cost optimization: Use tags for cost optimization. For example, you can tag resources that are supposed to start only during the day. Then you can run a script that looks for these tags on resources started after business hours and stop them to optimize your spending on Oracle Cloud Infrastructure.

As you can see, there are many benefits to having a well-executed tagging strategy. I hope you continue to use tags with your tenancies, and check back often because we are always creating new and important features to make it easier for you to manage costs, and organize and govern your cloud resources.