This guide explains how to create and configure rules using the Visual Editor in Dimension Studio. Rules determine how your cloud costs are categorized or allocated across different elements.

ℹ️
This guide focuses on creating rules using the Visual Editor in Dimension Studio. If you're working with CostFormation YAML files directly, see the CostFormation Definition Language Guide.

Rule Types Overview

CloudZero supports three primary rule types:

Group Rules: Create elements that you name explicitly for spend
- Example: Create an element called "Production" for all production environment costs
- Use when: You want specific, business-friendly element names
GroupBy Rules: Create elements that are named automatically based on existing dimension values
- Example: Automatically create one element per AWS account name
- Use when: Elements should dynamically reflect your infrastructure
Metadata Rules: Apply metadata or tags without creating visible elements
- Use when: You need to enrich data for downstream processing
- Note: Less commonly used; most use cases are covered by Group or GroupBy rules

How Rules Are Evaluated

Understanding rule evaluation order is critical for writing effective dimensions:

Top-to-bottom evaluation: Rules are processed in the order they appear in the UI
First match wins: Once spend matches a rule, evaluation stops
Default value fallback: Spend that doesn't match any rule receives the Default Value

Best practice: Structure your rules from most specific to most general, with a catch-all rule or default value at the end.

Example evaluation:

Rule 1: Environment Tag = "prod" → "Production" (most specific)
Rule 2: Account Name contains "prod" → "Production-Related" (broader)
Rule 3: Cloud Provider = "AWS" → "AWS-Other" (very broad)
Default Value: "Uncategorized" (catch-all)

Writing Group Rules

Group rules create elements that you name explicitly. They're the most common rule type.

Basic Configuration

When you expand a Group rule card in the Visual Editor, you'll configure:

Type: Select "Group" from the dropdown (this is the default)

Name: Enter the element name that will appear in reports and dashboards

Examples: "Production", "Finance Department", "Mobile App", "US - Storage"
Best practice: Use clear, business-friendly names that stakeholders will recognize

Logic operator (And/Or/Not): Choose how multiple conditions are evaluated

Logic Operators Explained

And: ALL conditions must be true

Example: Region = us-east-1 AND Service Category = Storage
Result: Only costs that are both in us-east-1 AND are storage costs match this rule
Use when: You need to narrow down to very specific spend

Or: ANY condition can be true

Example: Account Name = prod-account-1 OR Account Name = prod-account-2
Result: Costs from either account match this rule
Use when: You want to group multiple similar items into one element

Not: Spend NOT matching the condition

Example: Cloud Provider is NOT Azure
Result: All non-Azure spend matches this rule
Use when: You want to create inverse elements or exclusion rules

Source, Operator, and Value

Source: The dimension or attribute to evaluate

Field shows: "Select source..."
Examples: "Cloud Provider", "Region", "Service Category", "Environment Tag", "Account Name", "Resource ID"
Tip: Use the search function to find specific sources quickly

Operator: The comparison method

Common operators: "Equals", "Contains", "Starts With", "Ends With"
Most common: "Equals" for exact matching

Value: What to match against

Field shows: "Search or type to add more..."
You can select multiple values (they appear as dismissible tags)
Examples:
- For "Region" source: "us-east-1", "us-west-2", "eu-west-1"
- For "Environment Tag": "production", "prod", "prd"

Adding Multiple Conditions

Add Condition: Creates another condition at the same level

Click Add Condition below an existing condition
All conditions are combined using the logic operator you selected (And/Or/Not)

Example with And:

Condition 1: Region = us-east-1
Condition 2: Service Category = Storage
Condition 3: Account Name = prod-account
→ All three must be true for spend to match

Add Condition Group: Creates nested logic

Click Add Condition Group to create a sub-group of conditions
The nested group is evaluated independently, then the result is applied to the overall rule
See Condition Groups below for detailed examples

Group Rule Examples

Example 1: Simple element

Type: Group
Name: Production
Logic: And
  - Source: Environment Tag
    Operator: Equals
    Value: production

Example 2: Multiple environments in one element

Type: Group
Name: Production
Logic: Or
  - Source: Environment Tag
    Operator: Equals
    Values: production, prod, prd

Example 3: Regional storage element

Type: Group
Name: US - Storage
Logic: And
  - Source: Region
    Operator: Equals
    Values: us-east-1, us-east-2, us-west-1, us-west-2
  - Source: Service Category
    Operator: Equals
    Value: Storage

Example 4: Exclusion rule

Type: Group
Name: Non-Production
Logic: Not
  - Source: Environment Tag
    Operator: Equals
    Values: production, prod, prd

Writing GroupBy Rules

GroupBy rules are more dynamic than Group rules. Instead of explicitly naming elements, they automatically create elements based on existing dimension values.

Basic Configuration

When you expand a GroupBy rule card in the Visual Editor, you'll configure:

Type: Select "GroupBy" from the dropdown

Sources: Select one or more source dimensions whose values will become element names

Field shows: "Select source..."
You can select multiple sources
How it works: If you select "Account Name", CloudZero will automatically create an element for each unique account name in your data

Format: A template string that controls how element names are displayed

Field shows: "Enter format template (for example, COGs: {0})"
Use {'{0}'} for the first source, {'{1}'} for the second source, and so on
This is how you control the output format

Coalesce: Toggle on/off for each source

When ON: If the source has no value, CloudZero will try the next source
When OFF: Each source is evaluated independently
See CostFormation Language guide for details

Format Template Examples

The Format field is where you control how your element names appear.

Single source:

Sources: [Region]
Format: {0}
Output: "us-east-1", "us-west-2", "eu-west-1"

Single source with prefix:

Sources: [Product]
Format: COGs: {0}
Output: "COGs: Mobile", "COGs: Web", "COGs: API"

Two sources:

Sources: [Environment, Region]
Format: {0} - {1}
Output: "prod - us-east-1", "dev - us-west-2", "staging - eu-west-1"

Three sources with custom formatting:

Sources: [Cloud Provider, Region, Service Category]
Format: [{0}] {1} | {2}
Output: "[AWS] us-east-1 | Storage", "[Azure] eastus | Compute"

Adding Conditions to GroupBy Rules

Unlike Group rules where conditions determine if spend matches, GroupBy rule conditions act as filters that limit which spend the GroupBy applies to.

Example: GroupBy only for AWS

Type: GroupBy
Sources: [Account Name]
Format: AWS: {0}
Conditions (And):
  - Source: Cloud Provider
    Operator: Equals
    Value: AWS

Result: Creates categories for AWS accounts only; non-AWS spend is ignored by this rule

Example: GroupBy for production regions only

Type: GroupBy
Sources: [Region]
Format: Prod-{0}
Conditions (And):
  - Source: Environment Tag
    Operator: Equals
    Value: production

Result: Creates categories like "Prod-us-east-1" only for production-tagged resources

When to Use GroupBy vs Group

Use GroupBy when:

You want categories to automatically reflect your infrastructure
You don't want to manually maintain a list of category names
Your categories change frequently as you add/remove resources
Examples: One category per AWS account, one per team name, one per service

Use Group when:

You want explicit control over category names
You want business-friendly names that don't match source data exactly
You want to combine multiple conditions into a single named category
Examples: "Production" (combining multiple tags), "Critical Services" (specific list), "COGS" (business concept)

Condition Groups

Condition Groups enable complex nested logic by creating sub-groups of conditions that are evaluated independently.

Why Use Condition Groups

Without condition groups, you're limited to flat logic:

Condition 1 AND Condition 2 AND Condition 3
or
Condition 1 OR Condition 2 OR Condition 3

With condition groups, you can create complex nested logic:

Condition 1 AND (Condition 2 OR Condition 3)

How to Create a Condition Group

Within a rule, click Add Condition Group
A nested panel appears with its own logic operator (And/Or/Not)
Add conditions within the group
The group is evaluated first, then combined with other conditions

Condition Group Example

Scenario: Create a category called "LLM Only" for AI/LLM workloads, but only in specific environments.

Visual Editor Configuration:

Type: Group
Name: LLM Only
Logic: And
  - Source: AI Category
    Operator: Equals
    Value: LLMs
  - Condition Group (Or):
    - Source: Account Name
      Operator: Equals
      Value: LLM-Playground
    - Source: Environment
      Operator: Equals
      Value: LLM-Playground

How it evaluates:

First, CloudZero evaluates the nested group: (Account Name = LLM-Playground OR Environment = LLM-Playground)
If either condition in the group is true, the group evaluates to TRUE
Then CloudZero checks if AI Category = LLMs
Because the top-level is AND, both the group result AND the AI Category check must be true

In plain language: "Categorize spend as 'LLM Only' if it's in the LLMs AI category AND (it's in the LLM-Playground account OR tagged with LLM-Playground environment)."

Written as a formula:

IF (Account Name = LLM-Playground OR Environment = LLM-Playground) AND AI Category = LLMs
THEN categorize as "LLM Only"

Complex Condition Group Example

Scenario: Create a "High Priority" category for production resources in critical regions, but exclude test databases.

Type: Group
Name: High Priority
Logic: And
  - Condition Group (Or):
    - Source: Region
      Operator: Equals
      Values: us-east-1, eu-west-1
    - Source: Environment Tag
      Operator: Equals
      Value: production
  - Condition Group (Not):
    - Source: Resource Tag
      Operator: Contains
      Value: test
    - Source: Service Category
      Operator: Equals
      Value: Database

How it evaluates: Spend matches if it's in critical regions OR tagged as production, AND it's NOT (a test resource OR a database).

Transforms

Transforms standardize data before rules are evaluated, ensuring consistent matching even when source data varies.

When to Use Transforms

Example Problem: Your tags have inconsistent capitalization.

Source data: PROD, Prod, prod, pRoD

Solution: Use the Lower transform.

Result: All values become prod before rule evaluation.

Problem: Your naming includes prefixes you want to ignore.

Source data: Tag-prod, Tagging-prod, Tags-prod

Solution: Use the Split transform

Result: Extract just prod from each value

Problem: Source data has special characters and inconsistent formatting.

Source data: My-Service!, my_service, My.Service

Solution: Use the Normalize transform

Result: All become my-service

Available Transforms

Lower: Makes all values lowercase.

Input: PROD, Prod, pRod
Output: prod, prod, prod
Use when: You have mixed-case data

Split: Splits values by a delimiter and extracts a specific part.

Parameters:
- Delimiter: The character to split on (for example, -, _, /)
- Index: Which part to extract (0-based)
Example 1: Split Tag-prod by - at index 1 → prod
Example 2: Split aws/us-east-1/ec2 by / at index 2 → ec2
Use when: You need to extract part of a structured value

Normalize: Makes lowercase and converts special characters to dashes.

Characters converted: .,/#!$%^&*;:=_ ~()\' → -
Input: My.Service_Name!, MY-SERVICE
Output: my-service-name-, my-service
Use when: You need consistent formatting across varied inputs

How to Add Transforms

Within a rule or condition, expand the Transforms section.
Click + Add Transform.
Select the transform type from the dropdown.
Configure any required parameters (for example, delimiter and index for Split).
Click the trash icon next to a transform to delete it.

Transform Application Scope

Transforms can be applied at multiple levels:

Rule-level transforms: Apply to all conditions within the rule
Condition-level transforms: Apply only to a specific condition
Best practice: Apply at the narrowest scope needed to avoid unintended side effects

Transform Example

Scenario: Your Environment tags have inconsistent formatting: PROD, prod, Production, Prod-US, prod-EU.

Without transforms, you'd need this rule:

Type: Group
Name: Production
Logic: Or
  - Value: PROD
  - Value: prod
  - Value: Production
  - Value: Prod-US
  - Value: prod-EU

With transforms:

Type: Group
Name: Production
Source: Environment Tag
Transforms:
  - Lower
  - Split (delimiter: -, index: 0)
Logic: Or
  - Value: prod
  - Value: production

How it works:

PROD → lower → prod → split → prod → matches
Prod-US → lower → prod-us → split → prod → matches
Production → lower → production → matches

Rule Best Practices

Ordering Rules

Most specific first: Place narrow, specific rules at the top

✓ Rule 1: Environment = prod AND Region = us-east-1 AND Service = RDS
✓ Rule 2: Environment = prod AND Region = us-east-1
✓ Rule 3: Environment = prod
✗ Rule 1: Environment = prod  (too broad at the top)

Test your logic: Think through example resources to verify rules catch them correctly

Naming Conventions

Group rule names: Use business-friendly terminology

✓ "Production Environment"
✓ "COGS - Mobile App"
✗ "prod-env-1" (too technical)

GroupBy format templates: Balance clarity with conciseness

✓ {'{0}'} - {'{1}'} when combining two meaningful dimensions
✓ COGs: {'{0}'} when adding business context
✗ {'{0}'}-{'{1}'}-{'{2}'}-{'{3}'} (too many sources create long, confusing names)

Common Patterns

Pattern 1: Environment-based categorization

Rule 1 (Group): Name = "Production", Environment Tag = production
Rule 2 (Group): Name = "Development", Environment Tag = dev
Rule 3 (Group): Name = "Staging", Environment Tag = staging
Default Value: "Uncategorized"

Pattern 2: Hierarchical grouping

Rule 1 (GroupBy): Sources = [Account Name], Format = {0}
  With condition: Cloud Provider = AWS
Rule 2 (GroupBy): Sources = [Subscription Name], Format = {0}
  With condition: Cloud Provider = Azure
Default Value: "Other"

Pattern 3: Cost type categorization

Rule 1 (Group): Name = "COGS", Service Category in [Compute, Storage, Database]
Rule 2 (Group): Name = "R&D", Account Name contains "research"
Rule 3 (Group): Name = "SG&A", everything else

Troubleshooting Rules

Problem: Spend not matching expected rule

Check: Rule order (is a broader rule matching first?)
Check: Condition logic (should it be OR instead of AND?)
Check: Source data (does the actual value match what you entered?)

Problem: Too many categories from GroupBy

Solution: Add conditions to filter which spend the GroupBy applies to
Solution: Use a Group rule instead with explicit categories

Problem: Inconsistent matching due to data variations

Solution: Add transforms (Lower, Normalize) to standardize data
Solution: Use "Contains" operator instead of "Equals"