Overview
A dimension is a reporting field in Costory. You can create one by pointing several native tags or labels at the same concept. For example, mapaws:Environment, env, and environment into one Environment dimension so filters and splits stay consistent across providers.
A virtual dimension is a rule-based dimension. You define the output values from conditions instead of relying on a tag that already exists. For example, a Team virtual dimension can route rows where project_id starts with eng- to Engineering, and route everything else to Platform.
Use dimensions when you need to:
- Clean duplicate tag keys across AWS, GCP, and Azure
- Normalize values such as
prod,prd, andproduction - Allocate untagged resources to teams, products, or cost centers
- Build shared dashboards, alerts, and reports on stable business fields
Key terms
- Dimension: A Costory field used to filter, group, allocate, or scope costs.
- Imported dimension: A dimension created from native provider tags, labels, or billing metadata.
- Virtual dimension: A dimension whose values come from rules that you define in Costory.
Create a dimension from native tags and labels
Use imported dimensions when the data already exists in your cloud billing export, but the names or values are inconsistent.
Choose the reporting name
Pick the name you want Costory users to see, such as
environment, team, or cost_center.Normalize values
Review suggested value mappings and adjust them. For example, map 
prod, prd, and production to production.Publish
Click Publish all changes. Costory reprocesses historical data so the dimension is available in Explorer, Dashboards, Alerts, and Reports.
Create a virtual dimension from rules
Use virtual dimensions when the right grouping does not exist as a clean tag. Rules can use billing metadata, imported dimensions, or other virtual dimensions.Create the virtual dimension
Open Dimensions, click + Add new dimension > Virtual dimension, and enter a name such as 
team, business_unit, or product.Define rules
Add conditions that map cost rows to output values. Conditions can use fields such as account, service, resource name, Kubernetes namespace, imported dimensions, or another virtual dimension.
Order the rules
Rules are evaluated from top to bottom. Drag rules into the priority order you want.
Dimension sources
| Source | Examples | When to use |
|---|---|---|
| Native tags and labels | env, aws:Environment, project.labels.team | You already tag resources, but names or values differ by provider |
| Standard columns | Provider, account, service, region, namespace | You need allocation from billing metadata that is always present |
| Other dimensions | environment, team, business_unit | You want a hierarchy, such as namespace -> team -> business unit |
| Usage metrics | Database size, API calls, CPU time | You need shared cost allocation based on actual consumption |
Common patterns
Environment dimension
Mergeenv, environment, and k8s_label_env, then normalize values into development, staging, and production. Use this for environment cost reports and alerts.
Team virtual dimension
Map accounts, namespaces, services, and project IDs to teams. This helps you allocate untagged resources and create team scopes in Teams.Allocation hierarchy
Build one dimension on top of another. For example: When the team mapping changes, every dashboard, alert, and report that uses the downstream dimensions updates after reprocessing.Next Steps
Tag & Allocate overview
See how dimensions and shared cost allocation fit together
Shared Cost Allocation
Split shared infrastructure costs with usage metrics
Explorer
Use dimensions to filter and group cost data
Automated Environment Visibility
Walk through an environment dimension example