Dimension Patterns
Dimension Pattern 1
When building dimensions, there is one pattern that exists more than any other.
- You want to build a Dimension for a business context where there is tagging in place to drive the elements.
- Because tagging represents user generated content, you need to do some cleanup of the values
- You’d like to improve the dimension coverage for the non-tagged resources
From a practical perspective, this involves building your dimension in 3 sections. Because CostFormation represents sequential, conditional logic, the order is important:
My_Dimension:
Name: My Dimension
Rules:
#--------------------------------------------
# Section 1 - Override / Cleanup Logic
# Will usually use Group or Metadata type rules
#--------------------------------------------
- CostFormation Here
#--------------------------------------------
# Section 2 - Default Logic
# Will usually use GroupBy sourcing from customers tags
#--------------------------------------------
- CostFormation Here
#--------------------------------------------
# Section 3 - Manual Logic
# Will usually use Group or Metadata type rules
#--------------------------------------------
- CostFormation Here
Dimension Pattern 2 - Here is a related, slightly more complex, pattern:
- You want to build a Dimension for a business context where there is tagging in place to drive the elements.
- There are a handful of accounts that that belong to the different elements regardless of the tag value(s).
- Because tagging represents user generated content, you need to do some cleanup of the values
- You’d like to improve the dimension coverage for the non-tagged resources
My_Dimension:
Name: My Dimension
Rules:
#--------------------------------------------
# Section 1 - Account Mapping Logic
# Must come first if we want this logic to override any tagging
#--------------------------------------------
- Type: Group
Name: Element A
Conditions:
- Source: Account
Equals: 123456789012
- Type: Group
Name: Element B
Conditions:
- Source: Account
Equals: 210987654321
#--------------------------------------------
# Section 2 - Override / Cleanup Logic
# Will usually use Group or Metadata type rules
#--------------------------------------------
- CostFormation Here
#--------------------------------------------
# Section 3 - Default Logic
# Will usually use GroupBy sourcing from customer's tags
#--------------------------------------------
- CostFormation Here
#--------------------------------------------
# Section 4 - Manual Logic
# Will usually use Group or Metadata type rules
#--------------------------------------------
- CostFormation Here
This pattern is identical to the first pattern except that there are certain accounts that should get entirely mapped to a specific element. This logic must come first since we want everything in that account to go to the element.
Updated 8 days ago
What’s Next