What are Google Cloud Platform labels?
Labels are simply Google Cloud Platform’s (GCP) version of tags—though don’t confuse them with GCP’s network tags (those are different). Like tags, GCP Labels are a simple tool for organizing GCP resources by attaching metadata to them. CloudHealth has written extensively about effective tagging strategies and how to maintain good tagging hygiene and these same principles apply to GCP Labels.
The obvious first step is to create and enforce a universal labeling policy and make sure it spells out a label format that is consistent with your tagging formats for other public cloud resources from AWS and Azure. In addition to a universal policy, there are some best practices for labeling that, along with using CloudHealth, can help minimize operational headaches and make your life a whole lot easier.
We’re far enough along in cloud adoption that you more than likely know the basics of tagging and the most common use cases for tags/labels such as “customer,” “product,” “team,” “owner,” “cost center,” etc. These are examples of labeling at the resource level. Governance is a good example. You can create a label, “dev”, for development resources and create a policy called “dev shutdown” that spins down any resource with a dev label every Friday night at 6pm to avoid unused infrastructure incurring charges all weekend long. You could also create a label, “prod override” and add it to resources that are pushed into production so that the dev shutdown policy will not be applied to those instances.
Using Google Cloud Platform labels for showback
For chargeback and showback, however, there are some good reasons to label at the project level. First, labeling at the project label requires strict permissions. Since chargeback/showback is allocating costs to a specific BU, cost center, or owner, it’s possible that someone could inadvertently (or intentionally) charge to the wrong BU. The requirement for strict permissions at the project level mitigates that risk. As a best practice, you should minimize the number of people with this responsibility.
Secondly, when labeling at the project level, costs in the Google BigQuery export can then be aggregated across multiple projects for chargebacks. This is actually a popular use case for CloudHealth Perspectives, where an admin can create a rule for labels at the project level. Because many BUs will have multiple projects, or an application could have multiple projects, labeling at the project level and then building a Perspective can simplify chargeback for multiple projects within a BU.
An important thing to consider is that there are times that projects may be shared across teams. Teams may have copied the way an AWS account was previously set up or services (eg. Google Kubernetes Engine (GKE) clusters) are shared across multiple teams (and a cluster must live in one project). Projects may also be shared across teams simply due to the way you initially deployed your infrastructure in GCP. Some organizations may have initially deployed GCP as one central project with a lot of teams and usage and now find it difficult to break it out into multiple projects.
In any of the above scenarios, it’s best to label at the resource level, but pay particular attention to governance and specify who can add labels in those situations.
To sum up, good labeling and tagging hygiene is essential for optimally operating and governing any cloud environment. Specific to GCP, labeling at the project level is best for showback/chargeback since you can then use Perspectives to easily showback/chargeback multiple projects to the same BU and/or application. It’s another way CloudHealth provides detailed visibility into GCP costs, brings accountability across teams and project owners, saves you time, and makes your life a little easier.
Co-author: Lucas Paratore, Sr. Product Manager, CloudHealth by VMware
