Virtual Tagging Examples

Use these examples to design practical tagging workflows in Vantage. The examples show how to standardize existing tags, create Virtual Tags for allocation and ownership changes, handle untaggable resources, and collapse inconsistent tag keys into a cleaner reporting model.

Custom Values

Map provider costs to standardized team, product, or application values.

Allocation Tags

Allocate shared or fixed costs using cost-based, business metric-based, or percent-based rules.

Nested and Time-Bound Tags

Model hierarchies and ownership changes without rewriting every report.

Tag Key Collapsing

Consolidate inconsistent provider tag keys into a single reporting key.

Custom Values Examples

The following diagram shows how a single Virtual Tag can map provider costs into standardized team values that you can use in Cost Reports.

Example 1 - Cross-Provider Tagging

You want to create a tag mapping for each of your teams that maps corresponding teams with certain services and provider accounts.

Create a New Tag

You create a tag key called Teams.

The Tag Key field displayed in the Virtual Tags UI; the name Teams is entered

Add Tag Values and Filters

You add the corresponding set of virtual tag values and filters:

The data team tag value corresponds with a filter for all costs for GCP BigQuery and Amazon Redshift.
The mobile team tag value corresponds with a filter for its related GCP projects and AWS accounts.
You continue this pattern and create similar values with corresponding filters for your other teams.

A sample Tag Value field for a value of data with filter for Service of BigQuery and Amazon Redshift

A sample Tag Value field for a value of data with a filter for GCP Project of mobile and AWS account of mobile

Within Cost Reports, you can filter and group by these tag options to see costs for an individual team. In the following visual example, the Cost Report is grouped by the team tag, and the mobile and data values are displayed along with the other team tag values you created.

A sample Cost Report grouped by Tag showing a mobile and data tag

If a team’s filter logic is the same across every connected provider—for example, every provider tags resources with a team key—you can use All Providers in the filter set and add a single tag rule (e.g., Tag team is data) instead of one rule per provider. See Best Practices for Filtering Across All Providers before using All Providers for high-volume tags.

Example 2 - Consolidate Existing Tags

You have a tagging practice established at your organization, but teams often create tags with spelling variations, tags with typos, or they create duplicate tags. For example, the data team has resources tagged with data, Data, and data-prod. This is an issue across many of your teams. You want to consolidate all these tags, across providers, into one data tag.

Create a New Tag

You create a tag key called Teams to override existing tags.

Add Tag Values and Filters

You add the corresponding set of virtual tag values and filters. In this example, all permutations of the data team tag are combined into one virtual tag.

A sample Tag Value field for a value of AWS team tags equaling data, data-prod, and Data. Another value for a GCP team Label equaling data

Within Cost Reports, you can filter by this tag to see all costs related to the data team. This saves you from repeatedly filtering for every permutation of the tag. You need to filter by only one tag.

A Cost Report with a filter for AWS and GCP team tag of data

Example 3 - Using Flexible Match to Consolidate Similar Tag Values

Your teams use inconsistent tagging conventions, resulting in multiple variations in casing and formatting. For example, Team A’s tag appears in several forms across usage data, such as teamA, team_a, team-a, and Team A. You can use the flexible match filter option to match for all of these variants, as well as future variants, in a single tag configuration.

Create a New Tag

You create a tag key called Teams to override existing tags.

Add Tag Values and Filters

Create a virtual tag configuration for Team A. For the Output Costs Filter, use the Teams flexible match to the string Team A.

A sample Tag Value field for a value of AWS Team tag flexible matches Team A

This will automatically match all variants of Team A, such as teamA, team_a, team-a, and Team A.

Cost-Based Allocation Example

In your organization, teams share resources, such as RDS databases or EC2 instances, and each team consumes different percentages of these resources each month. Your organization is also charged a static support fee each month for AWS. As shown in the following diagram, you want to allocate a portion of the support fee to each team based on their proportional use of AWS resources. In this example, since the Infra team is responsible for 50% of all AWS costs, they should also be responsible for 50% of the support fee. You can create a cost-based allocation virtual tag for allocating portions of the support fee to each respective team. The diagram shows the input AWS usage costs determining how the separate AWS Support cost is distributed across teams.

Prerequisites

You have an existing provider tag in AWS that identifies resources for your teams. This tag will be used in the next step.

Create a New Cost-Based Allocation Tag

Navigate to Settings > Tags.
Create a new virtual tag.
Select the Cost-Based option for the tag value.

Select an Input Costs Filter

For your input cost, select All AWS Costs. Set an additional filter for the Usage charge type to filter on only usage-related costs. This filter will ignore costs related to items like credits, taxes, fees, etc.

Select a Tag Key

You select your existing teams tag key you have in AWS that will be used for allocating costs.

Select an Output Costs Filter

In this example, since your infrastructure team is responsible for 50% of all AWS costs, the mobile team for 20%, and the data team for 30%, you can mimic this allocation across another static cost, or your output cost. Select the filters for the AWS support fee.

A sample Tag Value field for AWS Support Fee costs

Once the tag is created, create a new Cost Report and add the following criteria:

Create a filter for AWS Support costs.
Add grouping criteria to group by your new cost-based dynamic allocation tag.

The resulting report shows how much of the support fee each team is allocated.

Business Metrics-Based Allocation Example

You are working with your infrastructure team and want to ensure that the proportional cost of CPU time on a shared resource is allocated to the distinct cost centers that are consuming the CPU. In this example, you want each team’s portion of CPU usage billed as a corresponding percentage of the overall Namespace CPU cost. So, if Team A uses 30% of the resource’s CPU, then they should be billed a proportional percentage of the total Namespace’s costs. The diagram shows how labeled CPU usage acts as the allocation driver for the shared Namespace costs.

Prerequisites

To determine the cost of CPU time to allocate to each respective team, you first create a labeled business metric that includes the CPU time labeled by team. Vantage then calculates the respective percentage of CPU time for each team. The labeled business metric has the following format.

date,amount,label
2024-01-09,825,teama
2024-01-09,600,teamb
2024-01-10,500,teama
2024-01-10,200,teamb
2024-01-11,723,teama
2024-01-11,456,teamb

Create a New Business Metrics-Based Allocation Tag

You create a new business metrics-based tag:

Navigate to Settings > Tags.
Create a new virtual tag.
Select the Business Metric option for the tag value.

Select the Labeled Business Metric

Search for and select the labeled business metric you just created to use for allocation.

Select an Output Costs Filter

Select the Vantage costs that will be split based on the percentages calculated in your business metric. In this case, you select a filter to show costs for the specific Namespace you want to be allocated.

A sample Tag Value field for specific Kubernetes namespace costs

Once the tag is created, create a new Cost Report and add the following criteria:

Create a filter for the specific Namespace.
Add grouping criteria to group by your new business metrics-based dynamic allocation tag.

The resulting report shows how much of the Namespace costs each team is allocated.

A Cost Report showing namespace costs allocated by team

Percent-Based Allocation Example

Your organization has negotiated fixed cost splits for Marketplace purchases. For example, at the time of purchase, you pre-agreed that Marketplace costs should be split 60% to the Infrastructure team, 30% to the Mobile team, and 10% to the Data team. You want these allocations to be automatically applied in your chargeback models. The diagram shows a fixed split where each team receives a predefined percentage of the same Marketplace purchase costs.

Prerequisites

You have an existing provider tag in AWS that identifies resources for your teams. This tag will be used to attribute the allocated costs.

Create a New Percent-Based Allocation Tag

Navigate to Settings > Tags.
Create a new virtual tag (e.g., Marketplace Allocation).
In the Values section, click +Add and select Percent-Based.

Add First Tag Value - Infrastructure Team

Specify the Output Costs Filter to match your Marketplace purchase costs (i.e., costs where Marketplace purchases Only).
Enter the tag value name: infra. Titles can contain only letters, numbers, and the following characters: _ - @ & + , . : / \.
Enter the percentage: 60 (between 0 and 100).

Add Second Tag Value - Mobile Team

Click +Add a Tag Value to add another value.
Enter the tag value name: mobile.
Enter the percentage: 30.

Add Third Tag Value - Data Team

Click +Add a Tag Value to add another value.
Enter the tag value name: data.
Enter the percentage: 10.

Review Allocations in Cost Reports

Once the tag is created, create a new Cost Report and add the following criteria:

Create a filter for Marketplace costs.
Add grouping criteria to group by your new percent-based allocation tag.

The resulting report shows how much of the costs each team is allocated based on your fixed percentages.

Allocation-on-Allocation Example

Many FinOps teams need a layered chargeback model. For example, you may first allocate shared AWS costs to high-level teams, then take one team’s share and allocate it again to sub-teams for a second level of accountability. Allocation-on-allocation supports this pattern when the allocated tags are part of the same provider-specific allocation chain. In this example, your organization has three Percent-Based allocated tags for AWS:

Team splits all AWS costs across Engineering, Sales, and Marketing.
Sub-Team takes the costs already allocated to Engineering via the Team tag and splits them further across Frontend, Backend, and Platform.
Region independently splits all AWS costs across US, EU, and APAC.

Create the Parent Allocated Tag

Create a Percent-Based allocated tag called Team that splits all AWS costs across your primary owners, such as Engineering, Sales, and Marketing.

Create the Child Allocated Tag

Create a second Percent-Based allocated tag called Sub-Team.

In the Output Costs Filter, select AWS costs where Team = Engineering.
Add the downstream values you need, such as Frontend, Backend, and Platform.
Set the percentages so the Engineering share is fully reallocated across those sub-teams.

Validate the Allocation Chain

Because Sub-Team references Team, both tags belong to the same AWS allocation chain. That means you can use them together on the same Cost Report.The diagram shows why Team and Sub-Team can be used together, while an independent Region allocation should be analyzed separately.

Review the Results in a Cost Report

Create a Cost Report and:

Filter to AWS if needed.
Group by Team.
Add a second grouping for Sub-Team.

This lets you keep the top-level team view while drilling into the Engineering portion of the allocation.

Use Separate Reports for Independent Chains

If you also create another allocated tag for AWS that does not reference Team or Sub-Team, such as the separate Region allocation in this example, that tag belongs to a different allocation chain. Create a separate Cost Report when you need to analyze that independent AWS allocation.

Nested Virtual Tags Example

The diagram shows how one Virtual Tag can become an input to another, creating a reporting hierarchy without duplicating every filter rule. You want to maintain a hierarchy that reflects how your business units are associated with various applications, and track costs of all your applications per business unit over time. In addition, you also want to avoid having to manually update multiple virtual tags whenever an application changes ownership to another business unit, so you aim to set up a dynamic structure that’s automatically updated.

Create an Application Virtual Tag with Values for Each App

You create a new tag called Applications:

Each value represents a specific application (e.g., app1, app2, app3, app4).
The filters for each value are AWS costs related to specific resources, like RDS or EC2 instances.

An example of an application tag based on specific AWS resources

Create a Virtual Tag for Business Unit Costs

Next, you define a virtual tag for Business Units:

Each value represents a specific business unit (e.g., Core Production, Core Development).
Each filter uses the preexisting Applications virtual tag you just created to associate specific apps with the corresponding business unit. Notice that virtual tags are denoted by a purple Vantage tag icon to differentiate them from provider tags (gray icon).

An example of a business unit tagged associated with an existing application tag

Review the Nested Virtual Tag in Reports

In associated reports, you can track all costs per business unit, knowing that each business unit comprises a set of corresponding apps. If an app ever changes its associated business unit, you need to update only the filter criteria on the Business Units virtual tag, and all other costs will be processed accordingly. The following report is grouped both by business unit and application to show the total breakdown.

An example Cost Report with the Applications and Business Unit tag groupings

Time-Bound Virtual Tag Example

Your organization recently went through a re-org. A shared Kubernetes cluster was owned by the Infrastructure team through June, but in July, responsibility moved to the Platform team. You want your Virtual Tags to reflect this change so that chargeback reports correctly attribute costs to the right team during each period. The diagram shows the same cluster receiving different Virtual Tag values for different ownership periods.

Create a Virtual Tag

Navigate to Settings > Tags and create a new virtual tag called Cluster Owner.

Add the First Time-Bound Value

Click +Add and select Assign Custom Value:

Enter the tag value name: infrastructure.
Set the Output Costs Filter to match the shared Kubernetes cluster (e.g., filter for the specific cluster’s resource IDs or namespace).
Click the Set a Time Frame toggle to enable it.
Leave the Start Date empty so the rule applies from the beginning of your data.
Set the End Date to June 30 to indicate the Infrastructure team’s ownership ends at the close of June.

Add the Second Time-Bound Value

Click +Add and select Assign Custom Value again:

Enter the tag value name: platform.
Set the same Output Costs Filter to match the shared Kubernetes cluster.
Click the Set a Time Frame toggle to enable it.
Set the Start Date to July 1.
Leave the End Date empty so the rule applies indefinitely into the future.

Save and Review

Click Save. Vantage will process costs and apply the infrastructure value to costs incurred through June 30 and the platform value to costs from July 1 onward. In your Cost Reports, you can now group by the Cluster Owner tag to see accurate cost attribution across the ownership transition.

Tagging Untaggable Resources in AWS Example

While you can apply cost and metadata tags in AWS to many resources, there are many other resources that are untaggable in AWS. Therefore, it is hard, if not almost impossible, to achieve 100% allocation in AWS alone. One quick way to first get an inventory of all untagged resources in Vantage—regardless of if they are untaggable—is to create a Cost Report with the following filters:

Provider is AWS
Where Not Tagged with Any Key

Then, add grouping criteria for Service and Category to get a view of the types of resources that are currently untagged. If these resources are taggable in AWS, you can add cost allocation tags there and see those tags represented in Vantage when you filter or group by specific tag.

See the AWS documentation for more information on what you can tag directly in AWS.

Many services and resource categories, however, cannot be tagged in AWS. You can use virtual tags to create tags in Vantage for these untaggable resources. In the following table, the Vantage Resource Filters column represents the filters you can set as the Output Costs Filter in the virtual tag configuration. For example, if you want to tag S3 Data Transfer for specific resources, you could use the following filter criteria.

AWS Resource	Description	Vantage Resource Filters
Elastic IPs	According to AWS, “You can tag an Elastic IP address that’s allocated for use in a VPC, however, cost allocation tags are not supported.”	Provider: AWS Subcategory: Amazon Virtual Private Cloud contains `inuse`
CloudWatch Metrics	CloudWatch Metrics involve performance data from AWS services, which are not taggable and are used for monitoring and alerting.	Provider: AWS Category: AmazonCloudWatch is Metric Further filter by resource ID
S3 Data Transfer	Data transferred in and out of S3 buckets, which is tracked but not taggable.	Provider: AWS Category: Amazon Simple Storage Service is Data Transfer Further filter by resource ID
QuickSight resources	Resources within Amazon QuickSight, such as dashboards and analyses, which do not support tagging.	Provider: AWS Service: Amazon Quicksight Optional detailed filters for Category (e.g., Business Analytics) or individual resource ID
CloudSearch resources	Amazon CloudSearch domains and their configurations, which are untaggable.	Provider: AWS Service: Amazon CloudSearch Optional detailed filters for Category (e.g., Data Transfer, Search Instance) or individual resource ID
EBS Snapshot Copy	Amazon EBS Snapshots that are copied between regions for Disaster Recovery or restore purposes	Provider: AWS Service: Amazon Elastic Block Storage (EBS) Category: Storage Snapshot Further filter for resource ID

Tag Key Collapsing Examples

The diagram shows multiple provider tag keys flowing into one standardized Virtual Tag key for consistent reporting.

Example 1 - Standardizing Inconsistent Provider Tags

Teams often use variations of the same tag key due to different tagging conventions across your cloud providers. For example:

env, environment, Environment
team, Team, team_name
app, Application, application

With Tag Key Collapsing, you can map all these provider tag variations to a single standardized virtual tag key (e.g., “environment”) without needing to update tags in your cloud providers.

Create a Virtual Tag

Create a new virtual tag with the key name “environment” (or your preferred standardized name).

Add Collapsed Keys

In the Collapsed Keys tab, add all the variations you want to consolidate:

env
environment
Environment

Set Priority Order

Reorder the collapsed keys so that your preferred collapsed key (for example, if you prefer environment over env) appears first in the list. This ensures that if a resource has multiple of these tags, the value from the highest-priority collapsed key (the one highest in the list) is used.

Save and Review

Click Save. Vantage will automatically merge all values from the collapsed tag keys into your standardized “environment” virtual tag. You can now filter and group by this single tag in your reports.

Example 2 - Cross-Provider Tag Normalization

If you have the same concept tagged differently across providers (e.g., “team” in AWS and “Team” in Azure), you can collapse both provider tags into a single virtual tag key for consistent reporting across all providers.

Create a Virtual Tag

Create a new virtual tag with the key name “team” (or your preferred standardized name).

Add Provider-Specific Collapsed Keys

In the Collapsed Keys tab, add team and Team as separate collapsed keys. Expand each row and, under Add a Filter, scope to the right cloud provider (for example Provider = AWS for team, and Provider = Azure for Team). Set priority if a resource could match both.

Save and Review

Click Save. Your reports will now show a consistent “team” tag across both AWS and Azure, regardless of the original tag casing in each provider.

Example 3 - Collapsing Virtual Tags

You can collapse existing virtual tag keys into other virtual tags, allowing you to create hierarchies or consolidate multiple virtual tags into a single standardized tag. For example, you might collapse several application-related virtual tags into a single “Application” virtual tag for simplified reporting.

Create a Consolidated Virtual Tag

Create a new virtual tag with the key name “Application” (or your preferred consolidated name).

Add Existing Virtual Tags as Collapsed Keys

In the Collapsed Keys tab, add your existing application-related virtual tags:

“app”
“App”
“application”

Set Priority and Save

Reorder the collapsed keys to set your preferred priority order, then click Save. All values from the collapsed virtual tags will now appear under the single “Application” virtual tag in your reports.

Get Started

Account & Security

AI, Terraform, & Developer Tools

Provider Integrations

App Integrations

Cost Reporting Features

Financial Planning Features

Virtual Tagging Examples

Custom Values

Allocation Tags

Nested and Time-Bound Tags

Tag Key Collapsing