Dimensions

Dimensions are Costory reporting fields. They map provider-specific tags, labels, and billing metadata to consistent values you can group, filter, allocate, alert, and report on across AWS, GCP, and Azure. Costory resolves dimensions on top of your billing export and recomputes history on every change, so a dimension reads the same in Explorer, dashboards, alerts, and reports. The UI and the Costory MCP write the same definitions: rules you build in the app are the same CEL conditions an agent drafts and publishes through the virtual dimension tools.

​

Overview

There are two kinds of dimension. An imported dimension points several native tags or labels at the same concept. Map aws:Environment, env, and environment into one Environment dimension so filters and splits stay consistent across providers. A virtual dimension derives its values from rules instead of an existing tag. Each rule is a CEL condition evaluated top to bottom, first match wins. A Team virtual dimension can route rows where cos_gcp_project_id.startsWith("eng-") to Engineering and send everything else to a leftover bucket. A large lookup that lives in git is an enrichment. Enrichments are in beta. You publish them from files, separately from the rules on this page. Common uses:

• Collapse duplicate tag keys across AWS, GCP, and Azure into one field
• Normalize values such as prod, prd, and production
• Allocate untagged resources to teams, products, or cost centers
• Build shared dashboards, alerts, and reports on stable business fields

​

Key terms used in this article

• Dimension: A Costory reporting field used to filter, group, allocate, or scope costs.
• Imported dimension: A dimension built from native provider tags, labels, or billing metadata.
• Virtual dimension: A dimension whose values come from CEL rules you define in Costory.
• Leftover bucket: The automatic catch-all value for any row that matches no rule. A large leftover share signals a missing or too-narrow rule.

See the Glossary for a full list of terms.

​

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.

​

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. Every virtual dimension ends with a leftover bucket: a catch-all value for any cost row that matches none of your rules. Watch its share when you build rules: a large leftover usually means a rule is missing or too narrow.

​

Explore and build allocation with your AI assistant

Most of the work in allocation is deciding which field to split on, not entering the rules. Through the Costory FinOps MCP, an assistant runs that exploration against your real spend and turns the result into a published dimension from chat. Before any rule exists, it can:

• Surface the values behind a concept with semantic search. Ask for “checkout” and you also get payment-api, order-service, and cart-backend, so one rule covers related spend a literal match would miss.
• Test which field best separates your cost with group-by suggestions and ad-hoc queries, so you split on something meaningful instead of guessing.
• Preview where the money lands. A per-rule preview shows trailing-30-day cost per bucket and the leftover share, so a missing or too-narrow rule is obvious before you publish.
• Flag rules that overlap. The overlap matrix shows when a broad early rule shadows a later one and swallows its spend.

Creating the dimension is the easy last step. The assistant drafts the rules as CEL conditions (top to bottom, first match wins), adds the leftover bucket automatically, and keeps everything on a draft. Publishing is explicit and triggers a data refresh, so production stays unchanged until you confirm. See the FinOps MCP reference for the underlying tools and parameters.

​

Reallocate shared cost with a usage metric

Beyond mapping rows to fixed values, a virtual dimension rule can split a shared cost proportionally across teams based on a synced usage metric, a telemetry allocation. For example, divide a shared Cloud SQL bill across teams by each schema’s size instead of guessing a flat percentage. Connect a metric source from Integrations > + Add integration > External metric (Metrics Correlation), then add the allocation rule from the web app or through MCP. See Shared Cost Allocation for the full walkthrough and supported sources.

​

Dimension sources

​

Common patterns

​

Environment dimension

Merge env, 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