Introduction

What is CoreStack Dimensions?

CoreStack Dimensions is a powerful abstraction layer that enables you to bring business context to cloud billing data by defining logical groupings like Teams, Departments, Applications, or Cost Centers.

Key Benefits:

Map technical billing data into meaningful business structures.
Create custom dimensions dynamically without modifying cloud resources.
Real-time accountability with instant showback and chargeback.
Work with incomplete tagging using flexible grouping rules.
No reprocessing required - changes apply instantly.

Who Should Use This Guide?

This guide is designed for:

FinOps Practitioners configuring cost allocation.
IT Administrators managing cloud cost visibility.
Finance Teams setting up departmental reporting.
MSP/Partner Teams creating customer-specific views.

Key Concepts

Dimension

A logical business entity can be used to group cloud costs. Examples include:

Department (Engineering, Finance, HR)
Application (App A, App B, App C)
Environment (Production, Staging, Development)
Customer (for MSP/partner scenarios)
Cost Center (aligned with GL chart of accounts)

Dimension Group (Grouping Rule)

A specific entity within a Dimension is identified by two key fields.

Field	Description	Example
name	Human-readable display name	`Engineering Department`
grouping_rule_id	Unique identifier	`68c145b1fe2ec71fb388b334`

For example, within a "Department" dimension, groups might include:

Engineering Department
Finance Department
Marketing Department

Each group also has a rule_type:

UserDefined - Custom groups you create
System - System-generated groups (e.g., Unallocated)

Grouping Rule Filters (Cloud Filters and Kubernetes Filters)

The filter logic that determines which costs belong to a specific group. Each grouping rule has two filter attributes:

Filter Attribute	Purpose	Use Case
filters	Cloud cost filters	AWS, Azure, GCP, OCI resources
platform_filters	Kubernetes cost filters	K8s pods, clusters, namespaces

Cloud Filters (filters) - Select cloud resources using:

Tenant IDs / Account IDs
Resource tags (key-value pairs)
Service categories (Compute, Storage, etc.)
Product types
AND/OR logic via QueryOperatorBinaryLogic

Kubernetes Filters (platform_filters) - Select K8s resources using:

Container accounts (cluster IDs)
K8s labels (key-value pairs)
K8s resource types (CPU, Memory)
AND/OR logic via QueryOperatorBinaryLogic

Cost Matching Logic: A cost matches if it satisfies (filters) OR (platform_filters)

Meta Dimension (Attributes)

Business metadata attached to dimension groups, such as:

Owner (VP name, email)
Budget Owner
Cost Center Code
Region
Headcount

Hierarchy (Dependent Grouping Rules)

Parent-child relationships across dimensions that enable cost rollups, implemented via the dependent_grouping_rule field.

Application → Team → Department → Division

Each grouping rule can reference parent groups using:

dimension_id - The parent dimension's ID
group_ids - Array of parent grouping rule IDs

Unallocated Costs

A system-calculated grouping showing costs that don't match any of your defined grouping rules. Formula:

Unallocated = Total Cost - Sum of all matched costs

RBAC (Access Granted Identities)

Role-Based Access Control determines who can view and manage dimensions and groups. Configured via the access_granted_identities field at two levels:

Level	Scope	Field Location
Dimension-level	Controls access to the entire dimension	Root of dimension version
Group-level	Controls access to specific groups	Within each grouping rule

Contains two sub-fields:

user_groups - Array of user group IDs
roles - Array of tenant/role mappings (tenant_id, role_ids)

Cost Anomaly Configuration

Per-group settings for cost anomaly detection and alerting. Configured via the cost_anomaly_configuration field within each grouping rule.

Component	Description
threshold.impact	Cost change triggers (`minimum_cost_impact`, `minimum_cost_impact_percentage`)
threshold.minimum_cost_spend	Minimum spend required to trigger
notification	Alert settings (`notify_on_detection_emails`, `daily_summary_emails`)

Note: Requires is_cost_anomaly_detection_enabled: true at the dimension level.

Getting Started

Prerequisites

Before configuring Dimensions, ensure you have:

Access to CoreStack with appropriate permissions
Billing data ingested from your cloud providers (AWS, Azure, GCP, OCI)
Understanding of your organization's structure and cost allocation needs

Planning Your Dimensions

Step 1: Identify Key Business Entities

Ask yourself:

How is your organization structured?
Who needs to see which costs?
What are your showback/chargeback requirements?

Step 2: Choose Your Starting Dimensions

Organization Size	Recommended Starting Dimensions
Small (< 100 employees)	Application, Environment
Medium (100-500 employees)	Application, Team, Environment
Large (500+ employees)	Application, Team, Department, Environment, Cost Center
MSP/Partner	Customer, Application, Environment

Step 3: Map Your Grouping Logic

Document what criteria will identify each group:

Which accounts belong to which teams?
What tags are commonly used?
Are there naming conventions in resource names?

Creating Your First Dimension

Step 1: Navigate to Dimensions

Log into CoreStack
Navigate to FinOps > Dimensions
Click Create New Dimension

Step 2: Define the Dimension

Complete the Dimension Definition:

Field	Description	Example
Name	Unique identifier	"Department"
Description	Purpose explanation	"Organizational departments for cost allocation"
Scope	Organization or Tenant	"Organization"
Owner	Responsible person/team	"[email protected]"

Step 3: Create a Dimension Version

Dimension Versions define when the configuration is active:

Field	Description	Example
Start Date	When this version becomes active	2025-01-01
End Date	When this version expires (optional)	null (ongoing)

Tip: Use time-based versioning to model organizational changes without losing historical accuracy.

Step 4: Add Grouping Rules

For each group in your dimension:

Click Add Group
Enter group name (e.g., "Engineering Department")
Configure filters (see next section)
Add attributes (optional)
Save

Configuring Grouping Rules

Basic Grouping Rule Structure

Each grouping rule requires:

Name: Human-readable group name
ID: Unique identifier
Filters: Logic to match costs
Attributes (optional): Business metadata

YAML Configuration Example

# Dimension Details (root level)
is_active: true
name: Department
description: Organizational departments for cost allocation
source: Billing
dimension_type: AccountGroup
dimension_template_type: Custom
is_cost_anomaly_detection_enabled: false

# Dimension Version Configuration
start_date: 2025-01-01T00:00:00.000Z
end_date: 2025-12-31T23:59:59.000Z
enable_cost_center: false

# Attributes Definition
attributes:
  - name: Owner
    mandatory: true
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: false
  - name: CostCenter
    mandatory: false
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: false

# RBAC Configuration
access_granted_identities:
  user_groups: []
  roles:
    - tenant_id: your-tenant-id
      role_ids:
        - role-id-1
        - role-id-2

# Grouping Rules
grouping_rules:
  - name: Engineering Department
    grouping_rule_id: eng-dept-001
    rule_type: UserDefined
    attributes:
      - name: Owner
        __type: AttributeValueForString
        values:
          - John Smith
      - name: CostCenter
        __type: AttributeValueForString
        values:
          - CC-ENG
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - your-tenant-id
      b:
        __type: ResourceQueryTagKeyValue
        tag_key: Department
        tag_values:
          - Engineering
      op: And
    dependent_grouping_rule: []
    platform_filters:
      __type: TenantQueryOperator
      tenant_ids: []
  - name: Unallocated
    description: System defined rule to capture unallocated cost.
    grouping_rule_id: unallocated-cost-rule
    rule_type: System

Using the UI

Add Group: Click the Add button
Enter Name: "Engineering Department"
Configure Filters: Use the filter builder to add conditions
Add Attributes: Fill in business metadata
Save: Click Save to apply

Working with Filters

Available Filter Types

CoreStack supports 30+ filter operators:

Category	Filter Types
Provider	AWS, Azure, GCP, OCI
Account	Account IDs, Subscription IDs, Project IDs
Tags	Tag key, Tag value, Tag key-value pairs
Services	Service category, Product category
Charge Types	Usage, Credit, Refund, Tax, Fee
Resource	Resource name (2503+), Resource ID

String Operators

Operator	Description	Example
equals	Exact match	tag:Department equals "Engineering"
not_equals	Exclusion	tag:Environment not_equals "Production"
contains	Partial match	resource_name contains "backend"
starts_with	Prefix match	resource_name starts_with "app01-"
ends_with	Suffix match	resource_name ends_with "-prod"
in	Match list	account_id in ["123", "456", "789"]
not_in	Exclude list	region not_in ["us-east-1"]

Combining Filters

Use AND/OR logic with QueryOperatorBinaryLogic:

filters:
  __type: QueryOperatorBinaryLogic
  a:
    # First condition: Tenant filter
    __type: TenantQueryOperator
    tenant_ids:
      - your-tenant-id
  b:
    # Second condition: Tag filter
    __type: ResourceQueryTagKeyValue
    tag_key: Department
    tag_values:
      - Engineering
  op: And  # Combine with And or Or

Service Category Filter Example

Filter by cloud service categories:

filters:
  __type: QueryOperatorBinaryLogic
  a:
    __type: TenantQueryOperator
    tenant_ids:
      - your-tenant-id
  b:
    __type: ServiceCategoryQueryOperator
    service_categories:
      - Compute
      - Databases
      - Storage
      - Networking
  op: And

Multi-Cloud Filter Example

Handle tag naming differences across clouds using OR logic:

filters:
  __type: QueryOperatorBinaryLogic
  a:
    # AWS filter (uppercase tag)
    __type: ResourceQueryTagKeyValue
    tag_key: Department
    tag_values:
      - Engineering
  b:
    # Azure filter (lowercase tag)
    __type: ResourceQueryTagKeyValue
    tag_key: department
    tag_values:
      - engineering
  op: Or  # Match either AWS or Azure tag convention

Meta Dimensions (Attributes)

What Are Attributes?

Attributes are business metadata fields attached to dimension groups. They enable:

Rich analytical filtering in dashboards
"One tag to rule them all" strategy
Centralized metadata management
Reduced tagging complexity

Defining Attributes

Attributes are defined at the dimension version level using __type to specify the data type:

# At dimension version level
attributes:
  - name: Owner
    mandatory: true
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: false

  - name: Budget
    mandatory: false
    __type: AttributeDefinitionForNumber
    is_multiple_values_allowed: false

  - name: CostCenter
    mandatory: false
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: false

  - name: Regions
    mandatory: false
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: true  # Allow multiple values

Supported Attribute Types

__type	Description	Example
AttributeDefinitionForString	Text values	"[email protected]"
AttributeDefinitionForNumber	Numeric values	500000
AttributeDefinitionForDateTime	Date/time values	"2025-12-31"
AttributeDefinitionForBoolean	True/false	true

Using Attributes in Groups

Assign attribute values in grouping rules using AttributeValueFor* types:

grouping_rules:
  - name: Engineering Department
    grouping_rule_id: eng-dept-001
    rule_type: UserDefined
    attributes:
      - name: Owner
        __type: AttributeValueForString
        values:
          - [email protected]
      - name: Budget
        __type: AttributeValueForNumber
        values:
          - 500000
      - name: CostCenter
        __type: AttributeValueForString
        values:
          - CC-1000
      - name: Regions
        __type: AttributeValueForString
        values:
          - us-east-1
          - us-west-2
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - your-tenant-id
      b:
        __type: ResourceQueryTagKeyValue
        tag_key: Department
        tag_values:
          - Engineering
      op: And
    dependent_grouping_rule: []

Best Practices for Attributes

Keep it simple: Start with 3-5 core attributes
Make key attributes mandatory: Owner, Cost Center
Use optional for context: Region, Headcount
Document expected values: Provide examples in descriptions

Building Hierarchies

What Are Hierarchical Dimensions?

Hierarchies create parent-child relationships across dimensions, enabling:

Top-down cost rollups (Division → Department → Team → Application)
Bottom-up drill-down (Application → Team → Department)
Organizational structure modeling

Defining Dependent Groupings

Use dependent_grouping_rule array to link groups across dimensions:

# Division Dimension (root) - no dependencies
grouping_rules:
  - name: Technology Division
    grouping_rule_id: tech-division-001
    rule_type: UserDefined
    filters:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    dependent_grouping_rule: []  # Empty - root level

# Department Dimension (child of Division)
grouping_rules:
  - name: Engineering Department
    grouping_rule_id: eng-dept-001
    rule_type: UserDefined
    filters:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    dependent_grouping_rule:
      - dimension_id: dim-division-id
        group_ids:
          - tech-division-001

# Team Dimension (child of Department)
grouping_rules:
  - name: Platform Team
    grouping_rule_id: platform-team-001
    rule_type: UserDefined
    filters:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    dependent_grouping_rule:
      - dimension_id: dim-department-id
        group_ids:
          - eng-dept-001

# Application Dimension (child of Team)
grouping_rules:
  - name: Checkout Service
    grouping_rule_id: checkout-app-001
    rule_type: UserDefined
    filters:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    dependent_grouping_rule:
      - dimension_id: dim-team-id
        group_ids:
          - platform-team-001

Hierarchy Visualization

Technology Division
    └── Engineering Department
        ├── Platform Team
        │   ├── Checkout Service
        │   └── Payment Service
        └── Product Team
            ├── User Service
            └── Notification Service
    └── Finance Department
        └── Finance Systems Team
            └── Accounting App

Hierarchy Query Behavior

When you query "Engineering Department":

Shows all costs for Engineering, Platform Team, Product Team, and all applications
Automatically rolls up costs from all child groups

When you query "Platform Team":

Shows costs for Platform Team, Checkout Service, and Payment Service

Role-Based Access Control (RBAC)

Two-Level RBAC Model

CoreStack enforces RBAC at two levels:

Dimension-Level: Who can view/manage the entire dimension
Group-Level: Who can access specific groups within a dimension

Important: RBAC is enforced on group names, not on attributes.

Configuring Dimension-Level RBAC

RBAC is configured using access_granted_identities with user_groups and roles:

# At dimension version level
access_granted_identities:
  user_groups:
    - finops-team-group-id
    - finance-team-group-id
  roles:
    - tenant_id: your-tenant-id
      role_ids:
        - viewer-role-id
        - editor-role-id
        - admin-role-id

Configuring Group-Level RBAC

Each grouping rule can have its own access_granted_identities:

grouping_rules:
  - name: Engineering Department
    grouping_rule_id: eng-dept-001
    rule_type: UserDefined
    access_granted_identities:
      user_groups:
        - engineering-leadership-group-id
      roles:
        - tenant_id: your-tenant-id
          role_ids:
            - engineering-viewer-role-id
    filters:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    dependent_grouping_rule: []

RBAC Inheritance Rules

Rule	Behavior
Default	Group inherits dimension-level RBAC
Override	Group-level RBAC can be more restrictive (never more permissive)
Hierarchy	Child groups inherit parent visibility if dependent grouping exists

Common RBAC Patterns

Executive View (All Departments)

# CFO sees all departments via dimension-level access
access_granted_identities:
  user_groups: []
  roles:
    - tenant_id: your-tenant-id
      role_ids:
        - cfo-role-id

Team Lead View (Own Team Only)

grouping_rules:
  - name: Engineering Department
    grouping_rule_id: eng-dept-001
    access_granted_identities:
      user_groups:
        - engineering-leadership-group-id
      roles:
        - tenant_id: your-tenant-id
          role_ids: []

MSP/Partner View (Customer-Specific)

grouping_rules:
  - name: Customer ABC
    grouping_rule_id: customer-abc-001
    access_granted_identities:
      user_groups:
        - customer-abc-admins-group-id
      roles:
        - tenant_id: customer-abc-tenant-id
          role_ids:
            - customer-viewer-role-id

Understanding Unallocated Costs

What is Unallocated?

Unallocated is a system-generated grouping rule that shows costs not matched by any of your defined grouping rules.

Unallocated Cost = Total Cost - Sum of all matched costs

Example Breakdown

Department Dimension with rules: [Engineering], [Finance], [Sales]

Dashboard shows:
├── Engineering: $40K (matched rule)
├── Finance: $30K (matched rule)
├── Sales: $20K (matched rule)
└── Unallocated: $10K (didn't match ANY rule)

Total: $100K

Why Unallocated Matters

1. Cost Attribution Quality Metric

Unallocated %	Interpretation	Action
< 5%	Excellent coverage	Maintain
10-15%	Good with some gaps	Review rules
> 25%	Poor coverage	Add more rules

2. Identify Allocation Gaps

Resources missing required tags
New services not covered by rules
Multi-cloud tag inconsistencies

3. Governance Visibility

Finance/FinOps can see "what's unaccounted for"
Ensures no costs are hidden
Supports cost accountability

Key Characteristics of Unallocated

Characteristic	Description
System-generated	Every dimension automatically includes it
Runtime-calculated	Recomputed based on dashboard filters
Independent	Value unchanged by which groups you select
RBAC-controlled	Only dimension owner sees by default
Drillable	Can filter by Service, Account, Tag, etc.

Cannot be configured:

Filter logic (system-managed)
Attributes/metadata
Dependent grouping rules
Name or ID (reserved)

How to Reduce Unallocated

1. Improve Dimension Rules

# Add rule to capture monitoring services
- name: Monitoring Services
  grouping_rule_id: monitoring-001
  rule_type: UserDefined
  filters:
    __type: QueryOperatorBinaryLogic
    a:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    b:
      __type: ServiceCategoryQueryOperator
      service_categories:
        - Management and Governance
    op: And
  dependent_grouping_rule: []

2. Better Tagging

Ensure resources have required tags
Standardize tag naming conventions

3. Use BillOps Allocation

Allocate shared costs to teams
Create transparent chargeback rules

Cost Anomaly Detection

Overview (Available in 2504+)

Dimension-level cost anomaly detection monitors costs at the business context level (Team, Department, Application) and alerts when costs spike unexpectedly.

Enabling Anomaly Detection

Enable at the Dimension level (root level field):

# At dimension root level
is_cost_anomaly_detection_enabled: true

Note: Once enabled, applies to ALL groups under that dimension.

Configuring Per-Group Thresholds

Each grouping rule can have its own cost_anomaly_configuration:

grouping_rules:
  - name: Engineering
    grouping_rule_id: eng-001
    rule_type: UserDefined
    filters:
      __type: TenantQueryOperator
      tenant_ids:
        - your-tenant-id
    cost_anomaly_configuration:
      threshold:
        impact:
          minimum_cost_impact: 10000           # $10K absolute change
          minimum_cost_impact_percentage: 15   # OR 15% change
          op: OR
        minimum_cost_spend: 100000             # AND spend > $100K
        op: OR
      notification:
        notifications_enabled: true
        daily_summary_email_enabled: true
        notify_on_detection: true
        notify_on_detection_emails:
          - [email protected]
          - [email protected]
        daily_summary_emails:
          - [email protected]
    dependent_grouping_rule: []

Threshold Logic Explained

Alert triggers if:
  (cost_change ≥ $10K OR cost_change ≥ 15%)
    AND total_spend > $100K

Cost Anomaly Configuration Structure

cost_anomaly_configuration:
  threshold:
    impact:
      minimum_cost_impact: 0           # Absolute dollar amount
      minimum_cost_impact_percentage: 0  # Percentage change
      op: OR                            # OR or AND between impact conditions
    minimum_cost_spend: 0              # Minimum spend to trigger
    op: OR                              # OR or AND with impact conditions
  notification:
    notifications_enabled: false
    daily_summary_email_enabled: false
    notify_on_detection: false
    notify_on_detection_emails: []
    daily_summary_emails: []

Sample Alert Email

Subject: Cost Anomaly Detected - Department: Engineering

Department: Engineering
Cost Impact: +$12,500 (14% increase)
Current Spend: $110,000
Previous Baseline: $97,500

Top Contributing Resources:
1. ec2-prod-app-01: +$5,000
2. rds-prod-main: +$4,200
3. s3-backups: +$2,100

Dashboard: [Link to Dimension Details Page]

Best Practices for Anomaly Detection

Practice	Description
Tier thresholds	High-spend groups: stricter ($10K+), Low-spend: looser ($1K+)
Use daily summary	Reduce alert fatigue for less critical groups
Monitor monthly	Review threshold effectiveness, adjust as needed
Enable for Unallocated	Catch attribution gaps proactively

Kubernetes Cost Attribution

Overview (Available in 2504.1+)

Kubernetes filter support enables cost allocation for container and Kubernetes workloads using the same Dimensions framework as cloud costs.

Understanding Platform Filters

Dimensions now support two filter types:

Filter Attribute	Purpose	Example Use Case
filters	Cloud costs (EC2, RDS, S3)	Match AWS service account
platform_filters	Kubernetes costs (Pods, Clusters)	Match K8s team label

Supported Kubernetes Filters

Filter	Description	Example
Container Accounts	Kubernetes cluster ID	"prod-cluster-us-east-1"
KBs Label Key	Any K8s label key	"app", "team", "environment"
KBs Label Key Value	Combined key+value	team="backend"
KBs Container ID	Specific pod/container	"kube-system:coredns"
KBs Resource Type	CPU, Memory, Storage	"cpu", "memory"
KBs Utilization Type	Reservation type	"reserved", "on-demand", "spot"

Configuring K8s Filters

Add platform_filters alongside filters:

grouping_rules:
  - name: Backend Team
    grouping_rule_id: backend-001
    rule_type: UserDefined
    attributes: []

    # Cloud costs filter
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - your-tenant-id
      b:
        __type: ServiceAccountQueryOperator
        service_account_ids:
          - backend-prod-sa
      op: And

    # K8s costs filter (platform_filters)
    platform_filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: ContainerAccountQueryOperator
        container_accounts:
          - prod-cluster-us-east
      b:
        __type: KBsLabelKeyValueQueryOperator
        label_key: team
        label_value: backend
      op: And

    dependent_grouping_rule: []

Cost Matching Logic

A cost matches if: (Cloud filters) OR (K8s filters)

Backend Team matches:
├── Cloud cost with service_account="backend-prod-sa" → MATCHED via filters
├── K8s pod with cluster="prod-cluster" AND label team="backend" → MATCHED via platform_filters
└── Combined: Shows both cloud + K8s costs for Backend Team

Duplication Prevention

The dashboard automatically prevents double-counting:

Widget Type	Uses	Shows
Cloud Cost Trend	`filters` only	Cloud costs only
K8s Pod Analysis	`platform_filters` only	K8s costs only
Total Infrastructure	Both	Combined cloud + K8s

No explicit configuration needed - the dashboard handles it automatically.

Configuration Patterns

Pattern 1: Cloud + K8s Hybrid Team

- name: Backend Team
  grouping_rule_id: backend-001
  rule_type: UserDefined
  filters:
    __type: ServiceAccountQueryOperator
    service_account_ids:
      - backend-prod
  platform_filters:
    __type: KBsLabelKeyValueQueryOperator
    label_key: team
    label_value: backend
  dependent_grouping_rule: []

Pattern 2: K8s Only (Fully Containerized)

- name: Search Team
  grouping_rule_id: search-001
  rule_type: UserDefined
  filters:
    __type: TenantQueryOperator
    tenant_ids: []  # No cloud filters
  platform_filters:
    __type: QueryOperatorBinaryLogic
    a:
      __type: ContainerAccountQueryOperator
      container_accounts:
        - prod-cluster
    b:
      __type: KBsLabelKeyValueQueryOperator
      label_key: team
      label_value: search
    op: And
  dependent_grouping_rule: []

Pattern 3: Cloud Only (Legacy)

- name: Legacy Services
  grouping_rule_id: legacy-001
  rule_type: UserDefined
  filters:
    __type: ServiceAccountQueryOperator
    service_account_ids:
      - legacy-prod
  platform_filters:
    __type: TenantQueryOperator
    tenant_ids: []  # No K8s filters
  dependent_grouping_rule: []

Budget Integration

Creating Dimensional Budgets

Budgets can be created per dimension group:

Navigate to FinOps > Budgets
Click Create Budget
Select Dimension: e.g., "Department"
Select Group: e.g., "Engineering"
Set Budget Amount: e.g., $150,000/month
Configure Thresholds and Alerts

K8s-Inclusive Budgets (2504.1+)

When your dimension group has K8s filters, the budget automatically includes K8s costs:

Budget: Engineering Department
├── Cloud Spend: $80,000
├── K8s Spend: $40,000
└── Total: $120,000 (80% of $150,000 budget)

Threshold Configuration

Set multiple thresholds for progressive alerts:

Threshold	Purpose	Recipients
70%	Early warning	Team Lead
85%	Escalation	VP + FinOps
100%	Hard limit	CFO

Forecasting Integration

Budgets include forecasting:

Historical cloud + K8s data feeds predictions
Seasonal patterns accounted for
Proactive alerts when projected to exceed budget

Best Practices

Dimension Design

Practice	Description
Start simple	Begin with 2-3 dimensions, add complexity incrementally
Align to org structure	Match how your organization operates
Plan for change	Use time versioning for org restructures
Document grouping logic	Maintain clear documentation of filter rationale

Grouping Rules

Practice	Description
Be specific	Use precise filters to avoid overlap
Combine methods	Use tags + accounts + services for best coverage
Handle unknowns	Create explicit groups for untagged resources
Test before deploy	Validate filters with sample data

RBAC Configuration

Practice	Description
Principle of least privilege	Grant minimum access needed
Use groups over individuals	Easier to maintain
Document access decisions	Maintain audit trail
Review periodically	Quarterly access reviews

Monitoring and Maintenance

Practice	Description
Monitor unallocated %	Target < 5%, review monthly
Enable anomaly alerts	Proactive cost governance
Version for org changes	Don't modify existing; create new versions
Review thresholds	Adjust quarterly based on patterns

Troubleshooting

Common Issues

Issue: High Unallocated Percentage

Symptom	Cause	Solution
> 25% unallocated	Missing grouping rules	Add rules for uncovered services/accounts
Sudden spike	New services deployed	Create rules for new resources
Consistent 15-20%	Shared infrastructure	Use BillOps allocation

Issue: Costs in Wrong Group

Symptom	Cause	Solution
Overlapping costs	Multiple rules match	Make filters mutually exclusive
Missing costs	Filter too restrictive	Broaden filter conditions
Wrong tenant	Multi-tenant confusion	Add tenant filter to rules

Issue: RBAC Not Working

Symptom	Cause	Solution
User sees too much	Dimension-level access	Add group-level restrictions
User sees nothing	Missing permissions	Grant group or dimension access
Inherited wrong	Hierarchy issues	Check dependent grouping config

Issue: Anomaly Alerts Not Triggering

Symptom	Cause	Solution
No alerts	Thresholds too high	Lower minimum_cost_impact
Too many alerts	Thresholds too low	Raise thresholds, add minimum_spend
Wrong recipients	Notification config	Verify email addresses

Validation Checklist

Before deploying dimensions, verify:

All grouping rules have valid filters
Required attributes are populated for all groups
RBAC restricts visibility appropriately
Hierarchy dependencies are correct
Time versions don't overlap
Test with sample data shows expected results

Quick Reference

YAML Structure Summary

# =====================
# DIMENSION DETAILS (root level)
# =====================
is_active: true
name: Department
description: Organizational departments for cost allocation
source: Billing
dimension_type: AccountGroup
dimension_template_type: Custom
is_cost_anomaly_detection_enabled: true

# =====================
# DIMENSION VERSION CONFIGURATION
# =====================
start_date: 2025-01-01T00:00:00.000Z
end_date: 2025-12-31T23:59:59.000Z
enable_cost_center: false

# Attribute Definitions
attributes:
  - name: Owner
    mandatory: true
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: false
  - name: Budget
    mandatory: false
    __type: AttributeDefinitionForNumber
    is_multiple_values_allowed: false

# RBAC Configuration
access_granted_identities:
  user_groups:
    - finops-team-group-id
  roles:
    - tenant_id: your-tenant-id
      role_ids:
        - viewer-role-id
        - editor-role-id

# =====================
# GROUPING RULES
# =====================
grouping_rules:
  - name: Engineering
    grouping_rule_id: eng-001
    rule_type: UserDefined

    # Attribute Values
    attributes:
      - name: Owner
        __type: AttributeValueForString
        values:
          - [email protected]
      - name: Budget
        __type: AttributeValueForNumber
        values:
          - 500000

    # Cloud Filters
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - your-tenant-id
      b:
        __type: ResourceQueryTagKeyValue
        tag_key: Department
        tag_values:
          - Engineering
      op: And

    # K8s Filters (optional)
    platform_filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: ContainerAccountQueryOperator
        container_accounts:
          - prod-cluster-us-east
      b:
        __type: KBsLabelKeyValueQueryOperator
        label_key: team
        label_value: engineering
      op: And

    # Group-level RBAC
    access_granted_identities:
      user_groups: []
      roles:
        - tenant_id: your-tenant-id
          role_ids: []

    # Hierarchy
    dependent_grouping_rule: []

    # Anomaly Detection
    cost_anomaly_configuration:
      threshold:
        impact:
          minimum_cost_impact: 5000
          minimum_cost_impact_percentage: 10
          op: OR
        minimum_cost_spend: 50000
        op: OR
      notification:
        notifications_enabled: true
        daily_summary_email_enabled: true
        notify_on_detection: true
        notify_on_detection_emails:
          - [email protected]
        daily_summary_emails:
          - [email protected]

  # System-generated Unallocated rule
  - name: Unallocated
    description: System defined rule to capture unallocated cost.
    grouping_rule_id: unallocated-cost-rule
    rule_type: System

Filter Operators Cheat Sheet

__type	Description	Key Fields
`QueryOperatorBinaryLogic`	Combine two conditions	`a`, `b`, `op: And/Or`
`TenantQueryOperator`	Filter by tenant	`tenant_ids: []`
`ResourceQueryTagKeyValue`	Filter by tag key-value	`tag_key`, `tag_values: []`
`ServiceCategoryQueryOperator`	Filter by service category	`service_categories: []`
`ServiceAccountQueryOperator`	Filter by service account	`service_account_ids: []`
`ContainerAccountQueryOperator`	Filter by K8s cluster	`container_accounts: []`
`KBsLabelKeyValueQueryOperator`	Filter by K8s label	`label_key`, `label_value`
`KBsLabelKeyQueryOperator`	Filter by K8s label key	`label_key`

Attribute Type Cheat Sheet

Definition Type	Value Type
`AttributeDefinitionForString`	`AttributeValueForString`
`AttributeDefinitionForNumber`	`AttributeValueForNumber`
`AttributeDefinitionForDateTime`	`AttributeValueForDateTime`
`AttributeDefinitionForBoolean`	`AttributeValueForBoolean`

Operator Casing

Context	Operator	Example
Filter logic	`And`, `Or`	`op: And`
Threshold impact	`OR`, `AND`	`op: OR`
Threshold spend	`OR`, `AND`	`op: OR`

Note: Filter operators use capitalized first letter (And, Or), while threshold operators use all caps (OR, AND).

Key Platform Integrations

Component	How Dimensions Integrate
Dashboards	Filter and group by dimension
Budgets	Create budgets per dimension group
Anomaly Detection	Monitor costs by dimension
Forecasting	Predict costs per dimension
Reports	Generate PDF/CSV by dimension
RBAC	Enforce access by dimension/group

Support Resources

Documentation: Access CoreStack Help Center
Support: Contact your CoreStack representative
Training: Request dimension configuration training
Templates: Access pre-built dimension templates

Complete YAML Examples

Example 1: Department Dimension with Tag-Based Filtering

#Dimension Details
is_active: true
name: Department
description: Organizational departments for cost allocation
source: Billing
dimension_type: AccountGroup
dimension_template_type: Custom
is_cost_anomaly_detection_enabled: false

#Dimension Version Configuration
start_date: 2025-01-01T00:00:00.000Z
end_date: 2025-12-31T23:59:59.000Z
enable_cost_center: false
attributes:
  - name: Owner
    mandatory: false
    __type: AttributeDefinitionForString
    is_multiple_values_allowed: false
access_granted_identities:
  user_groups: []
  roles:
    - tenant_id: 62ce6c76a7c32277f243a689
      role_ids:
        - 669b0b773d27d4910d60ff6d
        - 669b0b773d27d4910d60ff6e
grouping_rules:
  - name: Engineering
    grouping_rule_id: 68c145b1fe2ec71fb388b334
    rule_type: UserDefined
    attributes:
      - name: Owner
        __type: AttributeValueForString
        values:
          - VP Engineering
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - 62ce6c76a7c32277f243a689
      b:
        __type: ResourceQueryTagKeyValue
        tag_key: Department
        tag_values:
          - Engineering
      op: And
    dependent_grouping_rule: []
    platform_filters:
      __type: TenantQueryOperator
      tenant_ids: []
  - name: Marketing
    grouping_rule_id: 68c145b1fe2ec71fb388b335
    rule_type: UserDefined
    attributes:
      - name: Owner
        __type: AttributeValueForString
        values:
          - VP Marketing
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - 62ce6c76a7c32277f243a689
      b:
        __type: ResourceQueryTagKeyValue
        tag_key: Department
        tag_values:
          - Marketing
      op: And
    dependent_grouping_rule: []
    platform_filters:
      __type: TenantQueryOperator
      tenant_ids: []
  - name: Unallocated
    description: System defined rule to capture unallocated cost.
    grouping_rule_id: unallocated-cost-rule
    rule_type: System

Example 2: Multi-Cloud Product Category Dimension

#Dimension Details
is_active: true
name: Multi-Cloud Product Category
description: Group costs by cloud service categories across all providers
source: Billing
dimension_type: AccountGroup
dimension_template_type: Custom
is_cost_anomaly_detection_enabled: false

#Dimension Version Configuration
start_date: 2026-01-01T00:00:00.000Z
end_date: 2026-12-31T23:59:59.000Z
enable_cost_center: false
attributes: []
access_granted_identities:
  user_groups: []
  roles:
    - tenant_id: 67c6a34c424280e760d6f4e4
      role_ids: []
grouping_rules:
  - name: Multi-Cloud All Products
    description: All product categories across cloud providers
    grouping_rule_id: 695b9d552c27d93b2f7315f5
    rule_type: UserDefined
    attributes: []
    filters:
      __type: QueryOperatorBinaryLogic
      a:
        __type: TenantQueryOperator
        tenant_ids:
          - 67c6a34c424280e760d6f4e4  # AWS tenant
          - 67c6bb52424280e760f8fad6  # Azure tenant
          - 67c6b9da424280e760f86bbe  # GCP tenant
      b:
        __type: ServiceCategoryQueryOperator
        service_categories:
          - AI and Machine Learning
          - Analytics
          - Business Applications
          - Compute
          - Databases
          - Developer Tools
          - Integration
          - Management and Governance
          - Migration
          - Networking
          - Other
          - Security
          - Storage
          - Web
      op: And
    access_granted_identities:
      user_groups: []
      roles:
        - tenant_id: 67c6a34c424280e760d6f4e4
          role_ids: []
    dependent_grouping_rule: []
    cost_anomaly_configuration:
      threshold:
        impact:
          minimum_cost_impact: 0
          minimum_cost_impact_percentage: 0
          op: OR
        minimum_cost_spend: 0
        op: OR
      notification:
        notifications_enabled: false
        daily_summary_email_enabled: false
        notify_on_detection: false
        notify_on_detection_emails: []
        daily_summary_emails: []
    platform_filters:
      __type: TenantQueryOperator
      tenant_ids: []
  - name: Unallocated
    description: System defined rule to capture unallocated cost.
    grouping_rule_id: unallocated-cost-rule
    rule_type: System

Key YAML Patterns Summary

Pattern	Usage
Multiple tenants	List tenant IDs in `tenant_ids` array
Multiple tag values	List values in `tag_values` array
Multiple service categories	List in `service_categories` array
Empty K8s filters	`platform_filters: __type: TenantQueryOperator, tenant_ids: []`
Empty RBAC	`access_granted_identities: user_groups: [], roles: []`
System rules	`rule_type: System` for Unallocated
User rules	`rule_type: UserDefined` for custom groups

Version History

Version	Date	Changes
1.0	January 2026	Initial release covering Dimensions v5.2

This guide is based on CoreStack Dimensions documentation and product releases through January 2026.