MegaBill Telemetry
Last updated
Last updated
MegaBill Telemetry allows you to dynamically reallocate shared costs based on ratios derived from historical cost and usage data within Finout’s MegaBill. These ratios can be calculated daily or based on a custom sliding window (e.g. previous month, last 30 days), leveraging user-defined groupings and filters.
Transforming internal cost and usage data into a telemetry enables flexible and precise cost reallocation within Finout. Organizations can distribute shared expenses across dimensions such as teams, namespaces, or cost centers using proportional ratios derived from historical cost or usage trends. This can be can be generated from any existing MegaBill view, enabling you to customize cost reallocation to fit your specific needs.
Use Cases
AWS Support Costs Reallocation: AWS support charges are typically applied as a percentage of an organization’s cloud spend, but they often lack a clear breakdown per team or business unit. With the MegaBill Telemetry Generator, these costs can be redistributed based on proportional usage or spend, ensuring accurate financial accountability.
Idle Resource Cost Allocation: In cloud environments, idle or underutilized resources often contribute to unnecessary unallocated or shared costs. By leveraging historical telemetry, FinOps teams can allocate these idle costs proportionally to the teams or services associated with them, enabling better visibility and cost accountability.
In MegaBill, select a view that you want to base the telemetry on.
Copy the View ID.
Open a support ticket at support@finout.io with the following information:
View ID (obtained from Step 2)
Metric Name: Choose a clear and descriptive name to identify and locate the telemetry easily.
Timeframe Type: Specify either "Same-Day" or "Sliding Window":
Same-Day Calculation: (See for a more detailed explanation)
Ratios are calculated using data from the current day only.
Each day's calculation is independent and does not incorporate historical data.
Use case: Ideal when cost behavior or usage patterns vary significantly day to day (e.g., spot instances, ephemeral environments).
Data scope: Only today’s data is considered; no historical context is applied.
Sliding Window Calculation: (See for a more detailed explanation)
Ratios are calculated using historical data over a defined period up to 31 days. The current day is always excluded from the window.
Use case: Ideal for stable environments where you want allocations to reflect historical averages.
Data scope: A rolling window of past days, excluding the current day.
After the ticket is submitted, a telemetry will be created based on your configuration, and a support representative will notify you when it's ready.
Definition: Ratios are calculated independently for each day, using only that day’s data.
Use case: This is ideal when cost behavior or usage patterns vary significantly day to day (e.g., spot instances, ephemeral environments).
Data scope: Only today’s data is considered; no historical context is applied.
Example:
You want to distribute daily Datadog costs across teams based on their cloud spend on that same day:
On March 5th:
Team A spent $200
Team B spent $800
Total daily spend: $1,000 Datadog bill for March 5th: $100
Ratio-based allocation:
Team A: $100 × (200 / 1,000) = $20
Team B: $100 × (800 / 1,000) = $80 This calculation resets daily, using only the respective day’s spend.
Definition: Ratios are based on historical data over a defined window of days (up to 31 days max).
Use case: This is ideal for stable environments where you want allocations to reflect historical averages.
Data scope: A window of past days, excluding the current day.
Example:
You want to allocate March 1st’s AWS support cost based on spend from the previous 30 days (Feb 1–Feb 29).
Historical team spend:
Team A: $900
Team B: $8,100
Total: $9,000
AWS Support bill for March 1st: $270
Ratio-based allocation:
Team A: $270 × (900 / 9,000) = $27
Team B: $270 × (8,100 / 9,000) = $243
This sliding window recalculates daily, shifting one day forward and excluding today’s data.
Last X Days: For each day, sum of the cost and usage of the previous X days, not including the current day.
For Example: On April 9, with a 3-day window, the value includes April 6, 7, and 8.
Last Month (Previous Calendar Month): For each day, sum of the cost and usage of the entire previous calendar month.
Example: On any day in April, the value will be the total of March 1–31.
Current Month (Same Calendar Month): For each day, sum of the cost and usage of the current calendar month.
Example: On April 9, the value includes April 1–9. On April 30, it includes April 1–30.
How do I use telemetry for shared cost reallocations?
What is the recommended daily telemetry data limit?
The recommended daily telemetry limit is up to 1,000 telemetry values per day to ensure optimal performance and reliability.
How frequently is historical telemetry data recalculated?
Historical telemetry data is automatically recalculated for three months. Data older than three months remains static and will not recalculate.
What is the maximum number of hierarchical levels or nested categories I can effectively implement when organizing telemetry data in the MegaBill Ratio system?
It is recommend to use up to three nested levels of virtual tags for optimal performance when working with MegaBill Ratio telemetry
How many active MegaBill Ratio telemetries can I maintain per account?
Each account supports up to 50 active MegaBill Ratio telemetries.
If I change a view, when will the updated data appear in MegaBill?
A: Changes to a view will be reflected in MegaBill telemetry by the next day. The updated calculation will also apply to the configuration for the current month.
Can I assign the result of a cost or usage calculation back to the same tag I used in the calculation?
To ensure accurate and reliable cost allocation, it’s best to avoid assigning results back to the same tag used as the basis for calculation. The system relies on a clear, one-directional logic, and using the same tag for both input and output can create a loop that prevents proper resolution. This keeps your tagging structure clean and your cost calculations fully functional.
Example Scenario:
If you're using vtag:environment as the basis for a MegaBill ratio and also trying to assign the result back to environment, the logic becomes circular and cannot be resolved.
Recommended Approach:
Separate the source of the calculation from the destination of the result:
Source Tag: Use a dedicated tag like environment-prerequisite to define the basis for your calculation.
Destination Tag: Assign the result to a different tag, such as a new or separate environment tag.
To use telemetry for shared cost reallocations, select the generated MegaBill Telemetry from the existing dropdown within the Virtual Tag reallocation options. Reallocations are performed similarly to external telemetry sources. For detailed instructions, please refer to the documentation.
