Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Explore our knowledge base for all the right answers, your go-to resource for all things Finout!
Welcome to the Finout documentation hub! Find everything you need to manage your cloud financial operations with ease. Our updated articles, clear guides, and step-by-step instructions help you make the most of the Finout platform. Whether you're just getting started or optimizing your workflows, we aim to empower you with the knowledge to take full control of your cloud costs.
Finout Support
If you need help with anything, please reach out to support@finout.io - we're here to help!
When interacting with the Finout MegaBill, whether you're creating a new Data Explorer, building a widget, or using other system features, you can select from various cost and usage types, each representing a different method of accounting for your cloud service charges. This provides detailed insights into your financial data.
Finout adopts AWS’s cost dataset terminology as a standard, ensuring consistency in cost language across all providers and services. The table below provides a clear representation of this cross-platform cost terminology alignment in Finout.
A cost type indicates how costs are calculated and presented for each cloud service based on the amount of resources used. The default cost setting in Finout is the net amortized cost. If you need to change this default setting, navigate to Settings > Advanced Settings to select a different cost type.
Unblended Cost- This is the actual cost as detailed on your invoice, including charges for resources consumed and any upfront costs associated with Reserved Instances or pre-paid services. It reflects the direct expenses recorded and paid by your finance department, ensuring that the charges on the invoice match the actual payments made. Understanding Unblended Costs is essential for accurate financial accounting.
Net Unblended Cost- The Net Unblended Cost reflects the costs after all applicable discounts have been directly applied to the service. Unlike the standard Unblended Cost, where discounts are usually itemized separately on different lines of the invoice, showing the "regular" costs of services, the Net Unblended Cost integrates these discounts directly into the service costs themselves.
Amortized Cost- Amortized costs distribute the expenses of commitment payments across the duration of the Commitment Plan (SP, RI), matching costs with the actual service usage. This represents the usage costs of your Committed Plans. In contrast, Unblended Cost accounts for expenses as they occur.
Net Amortized Cost- This cost type represents the total expenses after applying all relevant discounts to the amortized costs.
Blended Cost- Blended rates average the costs of Reserved Instances and On-Demand Instances across all accounts. The total cost is calculated by dividing the total cost of services by the amount of data stored or the service usage, excluding monthly CSP/RI fees or upfront RI fees.
FairShare Cost - This cost type eliminates the randomness often seen in AWS's default cost allocation by ensuring discounts are applied fairly across all relevant resources according to actual usage and eligible commitments. This structured approach resolves misaligned costs and inaccurate showback reports, offering a logical and equitable way to allocate savings in environments with multiple teams, regions, and services. Contact Finout support at support@finout.io to enable this feature.
Net FairShare Cost - The AWS refund is factored into the cost of each included service, with the FairShare formula applied afterward. Conversely, for FairShare costs, the refund (e.g., PrivateRateDiscount) is handled as a separate billing line and excluded from the formula. Contact Finout support at support@finout.io to enable this feature.
List Cost: List Cost reflects public cloud pricing, showing what you would pay without discounts, commitments, or Enterprise Discount Plans. It provides a clear, unbiased view of your cloud spend, making cost analysis easier.
Finout standardizes cost calculations across cloud providers and services, ensuring a consistent and accurate view of spending. The table below outlines how Finout's cost types align with different providers.
AWS
Azure
GCP
Snowflake
Datadog
Confluent
OCI
Unblended
Unblended
Actual
Cost
Cost
Cost
Amount
Cost / MyCost
Net Unblended
Net Unblended
Actual
Cost
Cost
Cost
Amount
Cost / MyCost
Amortized
Amortized
Amortized
Cost
Cost
Finout’s Amortization Calculation
Amount
Cost / MyCost
Net Amortized
Net Amortized
Amortized
Cost
Cost
Finout’s Amortization Calculation
Amount
Cost / MyCost
Blended
Blended
Amortized
Cost
Cost
Cost
Amount
Cost / MyCost
List Cost
Public Pricing
Not Available
Public Pricing
Not Available
Not Available
Not Available
Not Available
FairShare Cost
Finout FairShare Calculation
Not Available
Not Available
Not Available
Not Available
Not Available
Not Available
Net FairShare Cost
Finout Net FairShare Calculation
Not Available
Not Available
Not Available
Not Available
Not Available
Not Available
Finout is a comprehensive cloud cost management solution that empowers FinOps, DevOps, and Finance teams to effectively manage and reduce cloud spend while improving profitability without requiring code changes or modifying existing tags.
Our comprehensive suite of features is strategically divided into three key phases of the FinOps lifecycle: Inform, Optimize, and Operate.
Finout is revolutionizing cloud cost management with its innovative Enterprise Discount Program (EDP) feature, designed to empower users with maximum flexibility and accuracy. This feature allows businesses to seamlessly configure their discount agreements directly into Finout, providing a dynamic and self-service approach to monitoring cloud expenses.
Finout’s EDP feature supports two configuration options:
Discount Percentage- Represents the percentage of the discount.
Discount Rate- Represents a change in the actual rate itself.
Note:
Only admins are granted access to configure EDP settings in Finout.
Users can define only a single EDP Tag for each account.
Non-direct EDP users: Finout's EDP feature is especially useful for those who do not automatically receive Enterprise Discount Program (EDP) benefits in their Cloud Usage Report (CUR) from AWS. It enables these users to manually add and configure discounts within Finout for a more accurate representation of their post-discount cloud costs.
Versatile discount application: The EDP feature in Finout is versatile and can be used to apply discounts not just for Amazon Web Services, but across various services integrated into a user's MegaBill. This makes it a valuable tool for businesses managing a diversified cloud infrastructure.
For direct EDP recipients: Users who already receive their EDP discounts directly in their CUR from AWS (or any other cloud provider) might not need to use Finout's EDP feature, as their discounts are automatically applied and reflected in their billing data. However, they can still use Finout's EDP feature for any additional, non-AWS services they wish to apply discounts to, or for further customization and detailed monitoring of their cloud costs.
By selecting a specific cost filter and layering an EDP configuration over it, Finout creates an EDP Tag that includes the assigned rate or percentage. To set your EDP:
In Finout, navigate to Settings and click EDP Setup.
Configure you EDP:
If this is your first time setting up an EDP in Finout, click Add new EDP.
Define EDP Rules: 1)Name: Enter a name for the EDP. 2)Add Category: Select a category for the EDP
3)Where: Select relevant cost center filters for EDP application.
4)Then: Specify the applicable EDP discount rate or percentage. - Percentage: This applies to the entire cloud bill. For example, a 50% discount on the AWS bill due to EDP. - Rate: Represents a specific value. For example, a 1.5$ discount for AmazonEC2 due to EDP. 5)Timeframe settings: Optionally define a timeframe for EDP rules to apply. 6)Additional rules: Incorporate any other specific rules as needed. For instance, a 25% EDP discount on certain services (e.g., Datadog). 7)Untagged Cost: Set the percentage value for the untagged cost. 8)Notifications: Receive notifications on any changes made to this virtual tag.
Click Apply EDP Tag. After applying the EDP tags, you will see a preview of your configurations.
Note: Users can define only a single EDP Tag for each account.
Manage your EDP by enabling EDP adjustments and specific cost types.
Enable this EDP to allow all users to see the cost data with EDP adjustments on all Finout pages.
To enable EDP adjustments:
In Finout, navigate to Settings. You are brought to the Account Settings tab.
In the Account settings tab, toggle-on Select Show cost with EDP adjustments to apply EDP changes across Finout pages. EDP adjustments are enabled on all of Finout’s pages.
Allow users to configure which cost type the EDP should be applied to. This functionality ensures consistent and accurate application of EDP across the platform for various cost types, including Net Amortized, Unblended, Amortized, Net Unblended, Blended Cost, Effective Cost, and Net Effective Cost. This customization gives users precise control over how EDP affects their cost management and visibility, providing more precise insights into both EDP-adjusted and non-adjusted costs.
To enable EDP for specific cost types:
In Settings, navigate to the Account Settings tab.
Under Cost Types & EDP Configuration, toggle-on the cost types where you want EDP to be applied and click Save. The Confirm Changes pop-up appears.
Click Apply. EDP is applied to cost types as default to all views.
After EDP Is set up, you can instantly see it in your MegaBill by toggling the Show cost with EDP.
Note: The Show cost with EDP toggle is only accessible to Admins.
Still need help? Please feel free to reach out to our team at support@finout.io.
List Cost shows the public pricing for your cloud resources, reflecting what you would have paid without any discounts, commitments, or Enterprise Discount Plans. It uses the baseline retail price of services, offering a clear and unbiased view of your cloud spend. This empowers you to take control of your cloud expenses by providing clear, actionable insights based on public pricing data.
What are the benefits of List Cost?
Benchmark Costs: See the raw, unadjusted pricing of your cloud usage.
Simplify Analysis: Understand the true value of your resources without financial manipulations such as Reserved Instances (RIs), promotions, or commitment plans.
Improve Accountability: Evaluate cost anomalies and missed savings opportunities due to lack of coverage or unused resources.
How does it work?
Finout calculates List Cost by sourcing public pricing data from each provider:
AWS: Based on the column pricing_public_on_demand_cost.
GCP: Based on the column cost_at_list.
Add List Cost to your view to analyze your cloud spend at its raw retail value without the noise of discounts or commitments.
Navigate to any cost-related view in Finout and choose List Cost as the cost type.
Dashboards / Widgets
Data Explorer
Resources
Q: Where can I see List Cost in Finout?
A: List Cost is available across all cost-related views in Finout, including:
Dashboards / Widgets
Data Explorer
Resources
Q: Why is List Cost missing or displayed as null for a Cost Center?
A: To maintain a consistent user experience, List Cost will not appear in certain application features if unsupported by a Cost Center but will be displayed as null in Data Explorer. However, to ensure a consistent user experience, List Cost will not appear in certain application features if it is unsupported by a Cost Center; however, it will be displayed as null in Data Explorer.
The FairShare Cost type is an advanced solution for the fair distribution of discounts from Reserved Instances (RIs), Spot Instances, and Savings Plans (SPs), as well as On-Demand costs, across Amazon EC2, AWS Lambda, Amazon ECS, and Compute Savings Plans, RDS, Elasticache, DynamoDB, and RedShift. Designed for organizations managing commitments centrally, it addresses the complexities of AWS’s discount allocations and provides transparency and control over cloud expenses.
Note: K8s costs in FairShare are supported only for AWS, with costs allocated to a node’s pods proportionally based on their usage within the same hour.
Note: Contact Finout support at support@finout.io to enable this feature.
Let’s start with a simple story…
Two brothers buy apples daily, and each apple typically costs $10. They receive a total discount allocation for both apples that equals 4$; however, the store allocates this discount randomly, which varies daily.
Note: The discounts in the following scenarios have a given rate, expressed as a percentage, and are converted into dollar value, which is then subtracted from the apple's total price.
On the first day, Alex’s apple gets a $3 discount, costing $7, while Jon’s apple receives only a $1 discount, costing $9. While the apples are identical, the discounts applied to them vary.
The next day, the discounts are reversed: Jon’s apple gets a $2.50 discount, costing $7.50, while Alex’s apple only gets a $1.50 discount, costing $8.50. While the apples are identical, and the total discount remains the same, the discount allocation per apple varies.
This pattern continues daily, with the total discount remaining the same and the brothers buying identical apples. However, each brother sometimes pays significantly less or more for the same apple. By the end of the week, both brothers are confused—their apples are identical, but their costs fluctuate unpredictably due to the varying discounts applied each day.
The story of these two brothers mirrors the challenges faced by different development teams with identical usage in managing cloud costs, where unpredictable discount allocation creates confusion and unfair distribution, much like the fluctuating discounts on identical apples. Imagine you’ve carefully rightsized your EC2 instances, expecting a reduction in costs, but the next month’s bill unexpectedly increases. Upon closer inspection, you discover that while Reserved Instances (RIs) and Savings Plans (SPs) were applied, the distribution of these discounts varied unpredictably. Some resources received discounts on certain days but not others, causing the anticipated savings to fluctuate.
This issue is compounded by AWS’s discount allocation system, where RIs and SPs may be applied arbitrarily, sometimes with little connection to actual resource usage. For example, discounts meant for production might apply to unrelated environments, such as development, leading to inaccurate budget attribution and distorted cost tracking. This misalignment can inflate costs for the teams requiring savings and disrupt finance teams’ forecasting, budgeting, and reporting. By using FairShare Cost, teams can address these issues, ensuring more predictable and equitable discount distribution across resources.
AWS Pricing Structure Challenges:
Random Discount Allocation:
AWS may arbitrarily apply RIs and SPs to your environment, often unrelated to actual resource usage.
Teams that don’t need specific resources might receive discounts, while those requiring savings pay full price.
Misaligned Costs and Usage:
Discounts for specific workloads or environments (e.g., production) can be applied to unrelated teams (e.g., development), leading to incorrect budget attributions.
This misalignment distorts cloud spend tracking and creates false perceptions of departmental consumption.
Inconsistent and Unpredictable Billing:
The lack of structured allocation makes forecasting cloud expenses challenging, hindering accurate budgeting.
Finance teams struggle to generate reliable showback reports, causing planning disruptions and financial disputes.
Story Continued…
To resolve the confusion, the brothers introduced a predictable discount system with a set price for red apples and a set price for green apples.
Note: The discounts in the following scenarios have a given rate, expressed as a percentage, and are converted into dollar value, which is then subtracted from the apple's total price.
Red Apple Discount: The brothers buy two red apples that each get a 2$ discount costing 8$ per apple. This lowers the price of each apple from $10 to $8, ensuring consistent pricing and eliminating unexpected price fluctuations.
Green Apple Discount: After receiving the discount on red apples, the brothers also decided to buy green apples as well. All green apples share a total $3 group discount, distributed equally across the three apples so that each gets a $1 discount, reducing their price from $10 to $9.
Apples Plan: In addition to the group discounts, the store decided to add a total $10 global discount (equivalent to SP and not EDP) applied to all apples regardless of their color. Since the apples are the same size and there are a total of 5 apples, the global discount of $10 is distributed equally, resulting in a $2 discount per apple.
Summary of final apple prices:
The brothers finally have a fair and predictable discount allocation for all apples.
Red Apples:
Group Discount: $2 per apple (from the $4 total group discount distributed evenly across all 2 red apples, $4 ÷ 2 = $2 each)
Global Discount: $2 per apple (from the $10 total global discount distributed evenly across all 5 apples, $10 ÷ 5 = $2 each)
Final Price: $10 - $2 (Group) - $2 (Global) = $6 per red apple
Green Apples:
Group Discount: $1 per apple (from the $3 total group discount distributed evenly across all 3 green apples, $3 ÷ 3 = $1 each)
Global Discount: $2 per apple (from the $10 total global discount distributed evenly across all 5 apples, $10 ÷ 5 = $2 each)
Final Price: $10 - $1 (Group) - $2 (Global) = $7 per red apple
Both brothers now enjoy a stable, predictable cost structure for their apples. The total discount is permanent, and with the new system, the allocation is also predictable. Similarly, Finout’s FairShare Cost model offers a solution to the AWS discount confusion by providing consistent discount allocation across Amazon EC2, AWS Lambda, Amazon ECS, Compute Savings Plans, RDS, Elasticache, DynamoDB, and RedShift. Each resource will get a fair share of its eligible discounts (RIs, Spot Instances, and Savings Plans) based on usage. This helps teams track and optimize cloud spending without surprises, providing the same predictability and stability the friends now experience with their apples.
FairShare Cost Solutions:
Analyze the Past - Showback and Chargeback: You gain a transparent and accurate view of cloud costs, with each team or service being charged based on actual usage, free from the distortions caused by arbitrary discount allocations.
Eliminates anomalies and false positives
Simplifies analysis of historical spending patterns
Provides accurate and actionable cost insights
Plan the Future - Modern Financial Planning: FairShare Cost allocation ensures that no team benefits unfairly from discounts intended for other workloads, aligning costs with usage and fostering accountability across departments.
Aligns costs with actual usage
Enhances predictability in billing
Supports precise budget planning and resource allocation
FinOps Adoption - A Core Product Value : Structured and predictable cost allocation enables finance teams to generate reliable reports and forecasts, enabling better budgeting and planning.
Simplifies cost models for clarity
Reduces organizational noise
Fosters cross-team collaboration with a shared language
An apple stand sells red and green apples. Each type of apple has unique qualities, and discounts need to be allocated fairly across both types according to specific criteria.
This scenario, along with the various commitment combination types, highlights the similarities and differences between FairShare and Amortized costs, using an apple as a metaphor for a resource.
There are four types of commitment combinations in cost calculations: No Commitments, Group Commitments Only, Global Commitments Only, and Group and Global Commitments, each defining how FairShare and AWS Amortized costs are applied based on eligible discounts and allocation methods.
Note: The discounts in the following scenarios have a given rate, expressed as a percentage, and are converted into dollar value, which is then subtracted from the apple's total price.
No Commitments
Scenario continued:
Both red and green apples are sold at a standard price of $10, without special discounts or commitments. Both apple groups have the same discount, with no adjustments for specific requirements or categories.
Explanation:
All resource costs are calculated on an On-Demand basis (no discount applied). The FairShare cost and the AWS Amortized cost are the same.
Group Commitments Only Scenario continued: Only red apples receive a special discount, reducing their cost over time through a prepaid commitment. This discount is divided evenly among all red apples, ensuring each one benefits equally. Green apples, however, continue to be sold at the public price of $10 with no discount applied. Explanation: Resources with group commitments receive eligible discounts, allocated by the usage ratio calculated through the FairShare cost type (group allocation), while all other resources are calculated at the On-Demand rate (which have no discount). Groups that receive a discount will show different FairShare and Amortized costs, while groups without a discount will have equal FairShare and Amortized costs, reflecting the on-demand rate.
Global Commitments Only
Note: Not including EDP
Scenario continued: A general discount is applied to all apples. Explanation: All resources are calculated using the Fairshare cost calculation (global allocation calculation) and receive their relative discount according to usage. The Fairshare cost for individual resource groups may differ from the AWS Amortized cost but the total price of all resources together will be the same for both cost types.
Group Commitments and Global Commitments Scenario continued: The store gave a discount to all the apples and also an additional discount to each apple type. Explanation: All resources are calculated using the Fairshare cost calculation by both Reserved Instances (RIs) and Savings Plans (SPs) allocation, according to the eligible discounts. The Fairshare cost for individual resource groups may differ from the AWS Amortized cost but the total price of all resources together will be the same for both cost types.
Summary of Fairshare Cost and AWS Amortized Cost Comparison:
The Fairshare cost for individual resource groups may differ from the AWS Amortized cost. Still, the total price of all resources combined will remain the same for both cost types because the total discount is the same; it’s allocated differently between these cost types.
Visualization of Finout’s Fairshare vs. AWS’s Net Amortized cost allocation:
Using Fairshare, you can accurately allocate 100% of each discount to its owner, making showback and chargeback straightforward and efficient.
Inconsistent discount allocation in AWS cloud services presents challenges for organizations across various roles. When Reserved Instances (RIs), Savings Plans (SPs), and Spot Instance discounts are applied unpredictably, it disrupts accurate financial reporting, stable budgeting, and reliable cost tracking. For FinOps managers, finance leaders, developers, and DevOps engineers alike, these fluctuations can lead to inefficiencies and budget disputes, making optimizing and managing cloud costs challenging. The following use cases illustrate how unpredictable AWS discount distribution impacts each role and highlight the need for a consistent cost allocation model.
FinOps
Use Case: Ensuring Accurate Showback and Chargeback Reporting
As a FinOps manager, I’m responsible for generating accurate showback and chargeback reports for each team based on their cloud usage. This reporting helps allocate costs fairly and allows teams to track their spending against their budget. However, AWS’s unpredictable discount allocations, where RIs and SPs may apply randomly to different resources, cause inconsistencies in the cost data. For instance, in one month, Team A’s instances received discounts that Team B’s identical instances didn’t receive, making it appear that Team A’s costs are lower despite similar usage. This creates disputes between teams and makes it challenging to allocate budgets fairly, requiring manual adjustments and reducing the accuracy of our financial reports.
Finance
Use Case: Forecasting Cloud Expenses for Budget Planning
As a finance manager, I need reliable cost data to forecast expenses and plan budgets accurately. However, AWS’s fluctuating discount allocations make this problematic. For example, when preparing the quarterly budget, I notice that cloud spending in one month was significantly lower than in the next, despite stable usage. After investigating, I found that the first month benefited from more RI and SP discounts than the second. These unpredictable shifts mean that projected costs can deviate widely from actual cost, complicating financial planning and making it harder to meet budget goals.
Development
Use Case: Tracking Cost Savings Through Instance Rightsizing
As a developer focused on reducing my team’s EC2 costs, I regularly rightsize instances to match cloud usage better. I recently adjusted our instances, expecting a drop in costs for the following month. To my surprise, the costs remained high and sometimes even increased. After investigating, I found that AWS had inconsistently applied RI and SP discounts to our resources, with some instances receiving discounts and others not, despite identical configurations. This inconsistency makes it challenging to assess the impact of my optimization efforts and accurately communicate cost savings to my manager.
DevOps
Use Case: Stabilizing Cloud Costs for Resource Optimization
As a DevOps engineer, I aim to stabilize cloud costs by monitoring usage and adjusting resources as needed. However, AWS’s variable discount allocations make this problematic. For instance, I track our EC2 usage closely, but in one week, our costs spike without any change in demand. Upon investigation, I found that fewer instances received RI or SP discounts that week compared to the previous one. This irregularity in discount distribution complicates my cost management efforts, as it’s hard to pinpoint actual areas for optimization when costs fluctuate unpredictably.
The FairShare Cost cost type is built to allocate cloud discounts fairly and accurately, ensuring that each resource receives the appropriate cost reductions based on usage and eligible commitments. This sophisticated cost type guarantees that discounts from Reserved Instances (RIs), Spot Instances, Savings Plans (SPs), and On-Demand costs are distributed equitably across all relevant resources. It addresses the complexities of AWS pricing mechanisms by clearly defining how different types of cost commitments are applied across various services.
Commitment and Discount Categorization:
Finout categorizes resource discounts into two types: Group and Global Commitments:
Group-Level Discounts: These include Reserved Instances (RIs) and Spot Instances, which are applied to specific groups of resources sharing attributes such as region, operating system, instance type, and size. For example, if RIs are purchased for EC2 instances in a specific region and instance type, only those instances will benefit from the discount. Finout ensures that these group-level discounts are distributed proportionally across all resources within the group that meet the eligibility criteria, preventing unrelated resources from receiving unintended discounts.
Global Discounts: These include Savings Plans (SPs) and On-Demand, which are applied across all relevant resources, regardless of region or OS. SPs offer flexible discounts that cover multiple services, such as EC2, Lambda, and Fargate. Finout ensures that these global discounts are distributed proportionally based on the actual usage of each resource, ensuring fairness and transparency across all services.
Resource Usage Share: After identifying a resource's group and global commitments, Finout divides the discount for each resource by the resource usage.
Relative Group Cost - measures how much the resource contributes to the total on-demand cost within its specific group (e.g., region or instance type). Formula: Relative Group Cost = resource’s on-demand rate / on-demand group cost
Relative Global Cost - shows the resource's contribution to the total on-demand cost across all groups and services globally. Formula: Relative Global Cost = resource’s on-demand rate / on-demand total cost
Fair Discounts Allocation:
This ensures the discounted costs account for eligible discounts and the relative usage.After configuring the relative cost, FInout multiples the relative cost by the resource commitments, having the discounted cost consider the eligible discounts and the relative usage.
Group Allocation - Combines group-level commitment and relative group cost to represent the adjusted or allocated cost at the group level. Formula: Group Level Commitments × Relative Group Cost
Global Allocation - Combines global-level commitment and relative global cost to represent the adjusted or allocated cost at the global level. Formula: Global Level Commitments × Relative Global Cost
FairShare Cost: Combines the Group and Global allocation as the resource can benefit from both discounts.
Formula: (Relative Group Cost × Group-Level Commitments) + (Relative Global Cost × Global Commitments)
Note: In Net FairShare cost, the AWS refund is incorporated into the cost of each included service, and the FairShare formula is applied on top of that. In contrast, for FairShare cost, the refund (e.g., PrivateRateDiscount) is treated as a separate billing row and excluded from the formula.
Net FairShare Formula: (Relative Group Net Cost × Group-Level Commitments) + (Relative Global Net Cost × Global Commitments)
Group A (us-west-1, Linux, m5.large):
10 On-Demand EC2 instances
5 Spot Instances at $0.25 per hour
On-Demand Rate: $1 per hour
- Cost Breakdown:
On-Demand Group Cost (Group A): -For 10 on-demand instances, the total cost is: $1 * 10 = $10.00 per hour -The 5 spot instances cost: $0.25 * 5 = $1.25 per hour Total On-Demand Cost for Group A = $10.00 + $1.25 = $11.25 per hour
Group B (us-east-1, Windows, t3.medium):
15 On-Demand EC2 instances
On-Demand Rate: $1.20 per hour
-Cost Breakdown:
On-Demand Group Cost (Group B): Total On-demand cost for 15 instances is: $1.20 * 15 = $18.00 per hour
Lambda Functions:
20 Lambda functions across multiple regions
On-Demand Rate: $0.15 per function invocation
Cost Breakdown:
On-Demand Group Cost (Lambda): Total cost for 20 Lambda invocations instances is: $0.15 * 20 = $3.00
Total On-Demand Cost = $11.25 + $18.00 + $3.00 = $32.25
Reserved Instances (RIs): 5 RIs for Group A, 7 RIs for Group B
Spot Instances: 5 Spot instances for Group A
Savings Plans (SPs): A global savings plan covering both EC2 instances and Lambda functions, with a $5/hr commitment
Global Commitments:
On-Demand Cost (globally): On-demand cost for Group A: $5.00 On-demand cost for Group B: $9.60 Total On-Demand Global Cost = $5.00 + $9.60 = $14.60
Total Savings Plan Commitments = $5.00
Relative Group Cost:
RI Cost for Group A: Total RI commitment cost = $2.00 (for 5 RIs) Discount: 60% discount applied, so cost per hour = $0.40/hr
Spot Cost for Group A: Total Spot commitment cost = $1.25 (for 5 Spot instances) Discount: 75% discount applied, so cost per hour = $0.25/hr
Discount Allocation:
Relative Group Cost (for Group A) = On-Demand rate / On-Demand group cost = $1 / $11.25 = 0.0889 (Relative cost for Group A)
Relative Global Cost = On-Demand rate / Total On-Demand cost = $1 / $32.25 = 0.0310 (Relative global cost)
FairShare Calculation Group A
FairShare Cost for Group A = 0.896 per hour
Relative Group Cost:
RI Cost for Group B: Total RI commitment cost = $3.50 (for 7 RIs) Discount: 41.6% discount applied, so cost per hour = $0.50/hr
Global Commitments: Same total global on-demand cost of $14.60 as Group A
Discount Allocation:
Relative Group Cost (for Group B) = On-Demand rate / On-Demand group cost = $1.20 / $18 = 0.0667
Relative Global Cost = On-Demand rate / Total On-Demand cost = $1.20 / $32.25 = 0.0372
FairShare Calculation Group B:
FairShare Cost for Group B = 0.886 per hour
Does FairShare support Kubernetes (K8s) costs?
K8s costs in FairShare are supported only for AWS, with costs allocated to a node’s pods proportionally based on their usage within the same hour.
What is the difference between FairShare and Net FairShare cost types?
FairShare Cost includes both Group and Global allocation, but AWS refunds (e.g., PrivateRateDiscount) are treated as separate billing rows and excluded from the formula. Net FairShare cost types, on the other hand, incorporates AWS refunds directly into the cost of each service before applying the FairShare formula.
Only users with admin privileges have the exclusive right to access the Finout admin portal, which encompasses role management and inviting new members to the platform.
Log into your Finout account with Admin role credentials.
Click on your username, then select Admin Portal.
Navigate to the Users section.
Choose Invite User. The Invite User popup appears.
Provide the new user’s Email.
Fill in the user’s Full Name.
Optionally enter the user’s Phone Number.
Optionally copy the invite link and forward it directly to the user.
Click Invite.
Following this, the new user’s status will display as Pending approval. Once the user activates their account, which can be done through the email link or the shared direct link (instructions provided below), and the setting up of a password, their joining date will be reflected in the Joined column.
As a new user of Finout, account activation is a necessary step before diving in. To activate your Finout account:
Access the Activate Your Account email.
Click on Activate my account.
Set a New password and Confirm new password.
Click Activate. Following this, you are all set to explore Finout.
: Enables you to view all your costs for any cloud provider or service such as AWS, Datadog, GCP, Global, Kubernetes, Snowflake out-of-the-box and easily apply a wide range of quick and advanced source object filters to view the relevant categorized costs.
: Allows you to tag and aggregate various resources (across technologies) by creating rules that group and label costs. This eliminates the need to relabel the original resources. Each virtual tag comprises one or more rules.
: Easily visualize and summarize your costs with Finout's customizable dashboards and widgets. Choose from our library of predefined dashboards or create your own with ease, providing actionable insights for your FinOps strategy.
: Enables you to identify overspending (and potential overruns) to improve cost control and help prevent unnecessary and unexpected expenditures.
: Finout’s solution enables you to plan your company's annual financial plan and expected budgets so that you can allocate accordingly by planning, managing, and monitoring cloud spending.
: A powerful, insight-driven tool that enables users to generate comprehensive, multi-dimensional reports, offering unparalleled flexibility in aggregating data across various fields for tailored cost measurements and dimensions.
: Finout “scans” and analyzes your infrastructure and identifies cost waste and cost optimization opportunities. As cost optimization is always a high priority, CostGuard provides a comprehensive solution that is seamlessly integrated with the MegaBill.
: Provides you with an in-depth view of your cloud commitments.
: Provides you with a comprehensive audit and monitoring capability for all AWS Reserved Instance actions.
: Finout anomaly engine utilizes your MegaBill historical data to identify major cost anomalies that may occur. Anomalies can be sent as alerts to your email or as a message to a designated Slack channel.
: Presents daily, weekly, or monthly reports based on your dashboards. A report can be sent periodically to your email or posted as a message to Slack.
: Tag governance ensures consistent and effective resource management across cloud environments. It involves defining, enforcing, and monitoring organizational policies for tagging cloud resources, such as virtual machines, databases, and storage.
: This enables you to send notifications from Finout to a specific Slack channel or user.
This feature ensures meticulous accuracy in reflecting the true cost after discounts, beyond what’s provided in native billing statements from providers. With Finout, users can effortlessly adjust and apply these discounts to all accounts, experiencing real-time visibility into their financial landscape without any limitations from Service Level Agreements (SLAs). This allows for more strategic, informed decision-making in managing cloud costs, ensuring that businesses are always ahead in their financial planning.
To modify an existing EDP, click an EDP and choose Edit EDP Tag. The EDF Tag key pop-up appears.
FairShare Cost eliminates the randomness often seen in AWS's default cost allocation by ensuring discounts are applied accurately across all relevant resources according to actual usage and commitments. This structured approach resolves misaligned costs and inaccurate showback reports, offering a logical and equitable way to allocate savings in environments with multiple teams, regions, and services. See for more information.
Click Select role and assign appropriate user roles. For a detailed explanation of user roles, refer to .
Finout enhances your cost management capabilities by integrating with leading third-party tools and services. From CI/CD pipelines to monitoring platforms, these integrations provide a unified view of your spend across all operational layers, helping you optimize costs and align them with business objectives effortlessly. The following third-party services can be integrated with Finout:
Finout simplifies cloud cost management with seamless integrations across major cloud providers. By unifying billing data from multiple platforms into a single view, Finout empowers you to track, analyze, and optimize your cloud expenses precisely, regardless of where your resources are hosted.
The following cloud services can be integrated with Finout:
Single Sign-On (SSO) setup simplifies user authentication and access management across multiple applications within an organization. It allows users to securely authenticate once and access various services without having to re-enter credentials. Integrating your SSO providers with Finout enhances security and streamlines administration by reducing the risk of credential-based attacks.
Follow this procedure to integrate your SSO provers with Finout.
To connect SSO providers to Finout:
In Finout, navigate to the Admin Portal.
In the Admin Portal navigation bar, click SSO.
Click on Setup SSO connection. The Setup SSO connection appears.
Select the SSO provider with which you wish to connect with Finout.
Note: It is recommended to choose the SAML integration.
Follow the onscreen instructions for the chosen SSO provider. You are redirected to the Self-service SAML configuration/SSO configuration.
Enter a Domain Name and click Proceed.
Note: The domain must be claimed by copying the TXT record and applying it to your DNS provider.
The Record Name and Record Value appear.
Copy this data and add it to a new TXT record in your DNS file, then click Proceed. You are brought to the Manage Authorization step.
Assign default roles to all SSO users by adding one or more account roles from your list of predefined roles.
You can optionally map your IdP groups to roles available in the application.
Note: Ensure that your IdP passes the groups
attribute that is sent in the SAML Assertion.
Click Done and save the connection.
Login into Finout using the SSO to ensure that it is enabled.
Note: For more information, see Frontegg documentation.
If a user has the following groups:
Group A in Active Directory: Connected to Group 1 in Finout.
Group B in Active Directory: Connected to Group 2 in Finout.
What permissions will the user have if they are moved from Group A to Group B?
The user will have access to both Group 1 and Group 2 in Finout. To remove access to Group A, you must remove it from Group A in Finout.
What happens if a user is part of an Active Directory group and belongs to another group in Finout?
The user will have access to both groups in Finout. This access will be effective immediately upon the next login.
If a user belongs to multiple SAML groups with corresponding groups in Finout, will Finout assign the user to all these matching groups?
Yes, if a user belongs to multiple SAML groups with corresponding groups in Finout, Finout will assign the user to all of these matching groups.
Does Finout support re-evaluating user group memberships upon every SAML login?
No, group provisioning happens only when the user onboards Finout. Then, they need to manage the groups in the admin portal and Finout groups settings.
Integrate Azure with Finout to generate comprehensive cost and usage reports tailored to your organization's needs. Configure Finout to create detailed reports using Azure data, either for specific subscriptions or across your entire organization. This integration allows for in-depth analysis and management of expenses, offering valuable insights into cost allocation and usage trends across your Azure infrastructure.
Azure Configuration Workflow:
The integration to your Azure is achieved by using an Azure service principal. There are two options: a. Create a service principle using the CLI.
b. Create a service principal using the Azure portal and set up an authentication.
From the CLI, type the following:
You will receive an output similar to the following:
Important: Save the following details to use in the Finout console (step 4):
appId → Application (client) ID
tenant → Directory (tenant) ID
password → Application password (Client Secret
From your Azure portal, search for and select Azure Active Directory.
Select App registrations, then click New registration.
Name the application (For example, "Finout").
Leave the default values in the rest of the parameters and click Register.
The Overview page provides two of the credentials required for the Finout console (step 4) the Application (client) ID and the Directory (tenant) ID.
Important: Save the following details to use in the Finout console (step 4):
appId → Application (client) ID
tenant → Directory (tenant) ID
For the Finout integration, use the password-based authentication (application secret) method by following these steps:
Select Certificates & secrets from the left-hand menu on the app registration page.
Click + New client secrets to create a new client secret.
Select a time frame for its expiration, add a description, and then click Add.
Note: If the secret is set to expire, you must remember to renew the credentials and reconfigure it in the Finout console.
Copy the Value from the Client secret to the Application secret field in the Finout console (step 4).
In this step, create the export for the billing scope and grant Finout read-only access to these export files.
Important: Ensure you're on the billing scope when performing the following step. To ensure you're on the billing scope, check the text on your cost management screen that states Billing account.
Note: When creating an export for the billing scope, you can choose to configure Azure settings by overwriting the same file or by generating a new file for each run.
The reports must be exported twice, once for each of the following cost types:
Actual cost
Amortized cost
You should provide a different directory for both exports, but both exports must be exported to the same container.
To create an export in your Azure portal:
In Azure, navigate to Cost Management.
Click Exports in the left-hand menu.
From the Export screen, click + Create. The New export page appears.
Click Cost and Usage (actual or amortized).
Note: The reports must be exported twice, once for each cost type. You should provide a different directory for both exports, but both exports must be exported to the same container.
You are brought to the Datasets tab.
Add the Export Profile name and click Next. You are brought to the Destination tab.
Important: - Ensure that the Format is CSV. - Ensure that the Compression type is None.
Fill in the details required on the destination page.
Note: Save the following details to add to Finout (step 4): -Storage Account
-Container
-Actual Cost Directory and Export Name
-Amortized Cost Directory and Export Name
Click Next. You are brought to the Review and Create tab.
Review the summary and click Create.
After the export is created, select it from the export page and click Run now.
Grant read-only permission by using Azure CLI or the Azure portal.
Type the following command in your CLI and fill in the parameters according to the role and storage details:
From your Storage account page, click Containers and select the export container.
Select Access control (IAM).
Click +Add and then click Add role assignment.
Search for Storage blob data reader, select it, and then click Next.
Click + Select members and find the Finout service principal.
Select the Finout service principal and click Select.
Click Review + Assign.
Navigate to Settings > Cost Centers and click Add cost center. The Connect Accounts window appears.
In Azure, click Connect Now. The Azure integration window appears.
Add the details saved from step 1 and click Next. You are brought to the Create the billing export page.
Add the details saved from step 2 and click Next. The integration is complete.
Important: To successfully finish the Azure integration with Finout, ensure the export files exist in the given container.
Oracle Cloud Infrastructure (OCI) is a comprehensive platform offering high-performance computing and a wide range of cloud services, designed for reliability, scalability, and security.
Integrating Finout with OCI allows you to efficiently manage your cloud resources, optimize spending, and gain valuable insights into your OCI cloud operations.
For official OCI documentation on these steps, refer to Oracle's documentation.
Access permissions in Oracle are assigned to groups. Create a separate group for Finout to ensure access only to the necessary billing resources.
Go to the OCI navigation menu → Identity & Security → Domains → <Finout domain> → Groups (in the right-hand menu).
Note: If you choose to use a domain other than “Default” to set up the integration user make sure that both the user and group are contained in the same domain.
Click Create Group.
Fill in the Group Name and add some Description.
Click Create.
Assign a policy to the group for accessing cost reports. In OCI, group permissions are managed through policies. By assigning a policy to the Finout group, you ensure that all its members can access only what the group policies allow.
Go to the OCI navigation menu → Identity & Security → Policies.
Click Create policy.
Choose a name for the policy that clearly indicates its purpose for accessing cost reports.
In the policy builder box at the bottom of the screen, activate the Show manual editor button and enter the following statements:
Note: Save your tenancy for step 5.
Statement 1:
Important: The following statement is not an example. You need to run this statement exactly as it is shown below.
define tenancy usage-report as ocid1.tenancy.oc1..aaaaaaaaned4fkpkisbwjlr56u7cj63lf3wffbilvqknstgtvzub7vhqkggq
This specifies the tenancy for usage reports, which is in a bucket owned by Oracle.
Statement 2:
endorse group <group name> to read objects in tenancy usage-report
Replace <group name>
with the name of the group created for Finout. If you want your own groups/users to access the cost reports as well, add another policy with the relevant <group name>
.
Examples:
If you chose the “Default” domain:
endorse group default to read objects in tenancy usage-report
If you chose a custom domain named “finoutdomain”:
endorse group finoutdomain/default to read objects in tenancy usage-report
Click Create.
Go to the OCI navigation menu → Identity & Security → Domains → Users.
Click Create User.
Fill in the name and email of the Finout user.
Assign the user to the new Finout group you created in step 1 by selecting the appropriate box under the Groups section.
Note: This setup ensures that a Finout user will have access only to the specified policies, specifically the cost reports bucket. It's important to avoid selecting the administrator option and instead choose only the group dedicated to Finout for proper access control.
Click Create.
Generate an API key to enable Finout users to access the reporting bucket via the Oracle API key.
For detailed instructions, refer to the official Oracle documentation here.
Create an API key pair in the OCI console to enable API signing for the Finout user:
Ensure an administrator user is logged into Oracle, as only administrators can perform these steps.
Navigate to Identity & Security → Domains → <Finout user domain> → Users, and click the Finout user to access their profile.
Navigate to the Resources section in the bottom left screen and select API keys.
Make sure that the Generate API key pair is chosen.
Click Download Private Key and save the key in a local directory.
Click Add.
A configuration is displayed. Click on the copy button below the text box and paste it into a local file editor (save for step 5).
Note: The Oracle documentation offers alternative methods for generating the key. Ensure that you have the complete configuration details as outlined in the following step.
In Finout, navigate to Settings > Cost Centers and click Add cost center. The Connect Accounts window appears.
In OCI, click Connect Now. The Connect to OCI window appears.
Fill the relevant fields from the "Configuration file preview" text box you copied in the previous step (Step 4). For “Private key data” you need to open the file and copy the entire file contents, including the key header.
Click Next. The cost center is created.
Integrate AWS with Finout to generate comprehensive cost and usage reports tailored to your organization's needs. Configure Finout to create detailed reports using AWS data, specifying specific accounts or encompassing your entire organization. This integration enables in-depth expense analysis and management, providing valuable insights into cost allocation and usage trends across your AWS infrastructure.
AWS Configuration Workflow:
To begin using Finout to monitor the cost of your cloud bill, Finout needs access to your Amazon Cost and Usage Report (CUR).
Prerequisite: If you have several Amazon accounts, provide access to the parent or EDP account.
To create a CUR in AWS:
Sign in to your AWS console and create a new CUR.
Mark Legacy CUR export.
In Export name, enter a report name.
Example: yourcompanyname-billing-reports
Export content:
- In Additional export content, mark the following:
Include resource IDs - Ensure that this is marked for successful configuration.
Split cost allocation data - Optionally mark to add more detailed cost and usage data. Enabling split cost allocation does not make any changes to the Finout console.
Note: Pod label enrichment remains a separate Finout feature that is not covered in AWS's split data. Finout will also continue providing Kubernetes rightsizing recommendations.
- In Data refresh settings, ensure the Refresh automatically is marked.
Data export delivery options:
Ensure the time granularity is marked Hourly.
Choose either Create new report version or Overwrite existing report. Both report versioning types are supported.
Choose the Parquet compression type
Data export storage settings:
Create the destination bucket to store the cost and usage data:
Add a bucket name. Save it for future use in step 5.
Choose a region. Save it for future use in step 5.
Mark The following default policy will be applied to your bucket.
Click Save. Your bucket is created.
Add your S3 path prefix. Save it for future use in step 5.
Click Next and then Review and Complete. The report is created within a few hours.
Verify that the tags you want included in your CUR are activated so that Finout can provide visibility for those tags.
To check if tags are activated:
Go to the cost allocation tags screen: https://console.aws.amazon.com/billing/home#/tags
Ensure that all the tags you want Finout to analyze, both now and in the future, are activated.
Important: If a tag is not activated, the data will not be tagged in the CUR and cannot be added retroactively.
Get the external ID in order to Grant Finout Access to Your CUR Bucket.
Navigate to Settings > Cost Centers and click Add cost center. The Connect Accounts window appears.
In AWS, click Connect Now. The Connect to AWS window appears.
Copy the External ID and continue to grant Finout access to your CUR bucket.
Note: Save this ID for later and keep this window open for future use (Step 5).
Once the CUR is created, grant Finout access to your CUR bucket by creating an IAM role. This can be done manually or by using CloudFormation.
Note: It is recommended to grant access through CloudFormation.
Prerequisite: Obtain an External ID from Finout.
To grant access using CloudFormation:
Create a CloudFormation Stack from a template by following the instructions on the AWS website.
Use the following Amazon S3 URL for your Stack template.
Complete the steps by adding the “external-id” (obtained in step 3) and the bucket name created for your CUR (step 1).
Click Next and then Submit. You are brought to the Stack details page.
Click Output and copy the ARN IAM role value to add in Finout (step 5).
To grant access manually:
Click on creating a new cross-account role in IAM to create a role for another AWS account.
In the account ID, enter: 277411487094
.
Paste the Require external ID and enter the “external-id
” (obtained in step 3).
Click Next. The Review step appears.
Add a Role name: FinoutMetricsReadOnlyRole
and then configure the role.
A new role is created.
Go to your new role in Summary.
Copy the Role ARN and save it for use in Finout (step 5).
Click on Add permissions and choose Create inline policy.
Choose JSON format and paste the following JSON:
Replace <CUR_BUCKET_NAME>
with the name of the bucket you created in step 1 or your existing CUR bucket:
Click Next until the Review step, and name it finout-access-policy
.
Click Create policy. Your IAM role is finalized and created.
After creating your CUR in AWS and granting Finout access to your CUR bucket, you can add your AWS details to Finout.
To add bucket details in Finout:
Navigate back to the Finout console that you used in step 3.
Fill in the following fields:
Add a personalized Cost Center Name.
Add the Role ARN from step Grant Finout Access to Your CUR Bucket. The Amazon Resource Name (ARN) specifies the role.
Add the Bucket Name from Create a CUR in the AWS Console step 7. This is the name under which AWS stores your cost and usage reports.
Add the S3 Path Prefix from Create a CUR in the AWS Console step 8. This is the folder in S3 in which the CUR files are located.
Add the Region from Create a CUR in the AWS Console step 7.
Click Continue. After verifying the information entered, Finout will create a new cost center.
Connect AWS China to Finout billing to securely share your AWS China billing data with Finout. Once the files are copied to a non-China region, continue with the regular AWS integration.
Connect AWS China to Finout: To connect AWS China to Finout, ensure your AWS China billing data is copied to an S3 bucket outside of China. This is crucial for Finout to access and process the data effectively.
Billing Data Conversion: Finout support can help convert billing data from Chinese Yuan to US Dollars, ensuring your financial data is consistent and manageable. For assistance, contact support at support@finout.io.
CostGuard Support Limitations: Finout does not support CostGuard for AWS China accounts because the necessary metrics and permissions required for CostGuard scans are not accessible outside of China. This means that some detailed cost management features for other regions may not be available for AWS China.
AWS China Known Limitations:
When connecting Finout to AWS China, please be aware of the following limitations:
Account Names:
Account names are not included in the Cost and Usage Report (CUR) files provided by AWS China. As a workaround, Virtual Tags can be used to manage and identify accounts.
Enrichments:
Enrichments that require data beyond the CUR files, like Account-Level Tags, are not supported. This limitation exists because Finout only has access to the CUR files and lacks the additional permissions needed to retrieve these enrichments.
Resource and Metric Access:
Finout does not have access to any AWS resources or metrics within the China region. The integration is limited to processing the billing files that are exported to an accessible location outside of China.
Note: We are actively exploring more native solutions to address these limitations and improve our integration with AWS China.
What format should the CUR file be in for optimal integration with Finout? We recommend using the CUR file in the Parquet format for optimal integration, although Finout also supports CSV/csv.gz format. The Parquet format is preferred for its efficiency in processing and analytics, especially for large-scale data handling.
Does the CUR file need to be located in the master payer account? No, the CUR file does not need to be in the master payer account. The important requirement is to be comprehensive of all billing data for the master payer to ensure accurate and complete data analysis.
Is it acceptable for the CUR file to overwrite itself throughout the month? Yes, it is acceptable for the CUR file to overwrite itself throughout the month. This allows for up-to-date data analysis as new billing information becomes available.
Can we use a CUR file from CloudHealth or another third-party service?
Yes, you can use a CUR file from services like CloudHealth as long as it matches the settings required by Finout and contains all necessary billing data. For integration, the directory structure should be in the format: s3://bucket_name/cur/year=2023/month=12/*.parquet.
How long does it usually take for data to appear in the Finout platform? Finout usually takes about 24 hours to complete the first fetch of data from AWS. We recommend checking first thing in the morning (10 AM your local time) the next day.
What Should I Do If My AWS Self-Onboarding Process Fails? If the self-onboarding process fails, check the following:
Verify S3 Bucket Content: Ensure that your S3 bucket contains the CUR files and is not empty.
Check S3 Path Prefix: An incorrect S3 path prefix is the most common issue. The path prefix should typically follow the format your-organization-name/cur-report-name/. Avoid including the date-range part in the prefix, as it is replaced dynamically with the actual date range. Example: Use fedramp-org/finout-cur instead of including the date range in the path.
Manifest.json File: Confirm that the Manifest.json file is in your S3 bucket, as it's essential for the CUR integration. If the problem persists, contact Finout support with the credentials for further debugging.
How can I correct an incorrect S3 path prefix?
The S3 path prefix should be static and consistent with the location of the CUR files in your S3 bucket without including date ranges. If you included the date range in your path prefix, remove it and try again.
Example: Use your-path/cur-report-name/
instead of your-path/20240101-20240201/
.
What if validations pass locally but fail during onboarding? If validations pass locally but fail during onboarding, double-check the S3 path prefix to ensure that it matches the CUR setup in your S3 bucket. The prefix provided to Finout should match the prefix where the CUR files are stored. If you have made changes and everything is set up correctly, attempt the onboarding process again.
Can I enable encryption on a S3 bucket created for cost reports? Yes, the S3 encryption is supported.
With Finout's seamless Datadog integration, gain precise cost visibility and monitor expenses daily. Conveniently view your Datadog spend alongside other providers, facilitating easy cost allocation for teams, applications, and environments. Utilize Finout's comprehensive cost governance suite for anomaly detection, budget enforcement, and accurate bill forecasting.
Moreover, Datadog is seamlessly integrated into our cost optimization suite, CostGuard, which automatically detects and offers waste reduction recommendations for logs, metrics, and other Datadog products.
a. Log into your Datadog account.
b. Hover over your Datadog user and select Organization Settings. The Organization Settings view appears.
c. Click API Keys. The New API Key pop-up appears.
d. Enter an API key name and click Create Key.
e. Copy the new API key, save it for later (step 2-f), and click Finish.
a. In your Datadog account, hover over your Datadog user and select Organization Settings.
b. Choose Application Keys.
c. Enter an API key name and click Create Key.
d. The default configuration is a non-scoped app key. To scope the API key, click Edit under the scope section. The Edit Key Scope appears.
e. Choose the relevant scopes according to this table and click Save.
f. Copy the new App key and save it for later (step 3-f).
a. In Finout, navigate to Settings.
c. Click Cost Centers. You are brought to the cost centers page.
d. Click Add cost center. The Connect Accounts popup appears.
e. Find Datadog and click Connect Now. The Datadog integration popup window appears.
f. Add the API key and APP key (created in step 1 and 2) and click Next. The cost center has been created.
Still need help? Please feel free to reach out to our team at support@finout.io.
Confluent is a full-scale, advanced data streaming platform that facilitates seamless access storage, and management of continuous real-time data streams.
The Confluent cost center is available in the MegaBill, providing breakdowns by services, clusters, usage type (e.g., network write, storage), and network access type (e.g., Peered VCP, Internet).
This integration ensures a unified view of all associated costs, combining the environment's expenditures with its related cloud expenses. Virtual Tags can be utilized to further consolidate costs and obtain a comprehensive view.
Note: To retrieve cost data from Confluent, use the following endpoint:
http://api.confluent.cloud/billing/v1/costs
Navigate to confluent cloud home.
Select the menu on the right and choose Cloud API keys.
Click on Add key.
Choose Granular access.
Select Create a new one, input a new service account name and description, and proceed (a new service account will be created).
Once the key is generated, an option to describe it appears. Click Download and continue.
On the right menu, select Accounts and Access.
Navigate to Service Accounts under Accounts.
Search for the newly created service account and select it.
Select Add role assignment under organization.
Choose BillingAdmin and confirm this choice.
Provide Finout with the generated API key and secret.
Important: You must hold the BillingAdmin role for successful integration.
Still need help? Please feel free to reach out to our team at support@finout.io.
Finout offers a structured breakdown of Datadog costs by Datadog products and additional tags using an estimated cost summary API for a detailed product cost breakdown. Each day, the API reports the total cost accumulated so far in the month. For example, on the 3rd of the month, the data reflects the total for the 1st, 2nd, and 3rd days combined. To isolate the cost for just the 3rd, we subtract the cumulative cost up to the 2nd from that of the 3rd. This difference gives us the specific cost for the 2nd day.
These represent pay-as-you-go expenses, accruing and displaying on the relevant days when on-demand usage occurs.
Commitment costs are usually displayed on the 1st of every month, while on-demand costs will be presented on the day they occur.
Commitment costs can be categorized into different models:
Usage-based- In this model, your commitment costs are based on a predetermined “bank” of usage. Once you run out of your usage, on-demand charges kick in.
Host/ Hourly commitment- An hourly commitment is set, beyond which on-demand rates are applicable.
Unblended costs represent the expenses as received from Datadog. In the case of commitments, these are shown on the 1st of the month, while on-demand costs are displayed on the relevant day of usage.
Finout uses the usage API to divide these costs across all days of the month to spread out the commitment cost throughout the month.
Usage-based- Finout’s algorithm calculates daily costs based on usage, adapting the rate based on historical and current monthly data. Since the discounted rate isn't reflected in the API and may vary, Finout's dynamic adjustment, leveraging the data received through the APIs, ensures the most current and precise cost representation.
Host- The commitment is evenly divided across the month's total hours, ensuring a consistent and understandable cost breakdown.
Infra host, APM host products- The monthly cost is updated daily based on the top 99th percentile of usage, with the final cost confirmed on the last day of the month.
Datadog tracks hourly host counts for Infrastructure and APM billing, with end-of-month billing based on the 99th percentile usage. The billable host count is calculated using the highest count in the lower 99% of usage hours, excluding the top 1%, to mitigate the impact of usage spikes.
Timeseries (custom metrics)- The billable count for custom metrics is determined by averaging the number of custom metric hours over the month. Your monthly billable count for custom metrics (reflected on the Usage page) is calculated by taking the total of all distinct custom metrics recorded each hour throughout the month and dividing this month’s cumulative hours to receive a monthly average value.
The Finout Microsoft Teams integration allows your organization to seamlessly send reports and Anomalies alerts directly from the Finout platform to your organization Microsoft Teams channels. This document outlines the steps required to set up and manage this integration, ensuring that your teams can efficiently be notified and get the relevant information they need from Finout.
Before starting the integration process, ensure the following prerequisites are met:
Consistent Tenant
App Installation Permissions
1. Navigate to the Integrations tab:
Log in to your Finout account and go to Settings > Integrations tab.
Locate the Microsoft Teams integration box and click on Connect.
Sign in to Microsoft:
You will be redirected to Microsoft’s sign-in page. Enter your Microsoft credentials and grant the necessary permissions to Finout.
The required permission is User.Read, set to Delegated.
3. Complete the Integration:
After clicking Accept, you will be redirected back to Finout. You will now see that Microsoft Teams is successfully integrated with your Finout account.
Install the Finout App:
Start by selecting a standard (public) channel for the app installation. This channel will serve as the primary channel for the bot, as Teams requires each app to have a primary channel, which must be a standard channel.
Note: Once the app is installed, the bot will automatically have access to all public within the selected Team, based on your organization's security policy, not just the channel where the bot was initially installed.
Note: Bots are not supported in either private or shared channels within Microsoft Teams.
After installing the Finout app, the channel where the bot is installed will send a welcome message, and all the channels in the Team will appear as endpoints in Finout automatically.
How does Microsoft Teams channel work with Endpoint Metadata?
All public channels in a Team will automatically mapped to an endpoint ID in Finout.
You can then assign each endpoint ID to the relevant virtual tag value through the virtual tag metadata API.
I completed the integration and installed the app in Teams, but I still can't see any channels in Finout. What should I do? Ensure that you complete the integration setup in Finout before installing the Finout app in Teams. If you installed the app in Teams first, try the following steps:
Delete Finout app from Teams.
Reinstall Finout app in Teams.
What happens if the person who accepted the permission request on the AD side leaves the company? The integration will continue to function without interruption.
Does Finout create any resources for the client’s tenant? No, Finout does not create any data or resources in the tenant's account. We only store basic information about the logged-in user.
OAuth 2.0 Authentication: The integration uses OAuth 2.0 for secure authentication between Finout and Microsoft Teams, ensuring your data is protected during integration.
Permissions Management: Finout requires specific permissions within your Microsoft Teams environment to function correctly. These permissions are limited to the necessary scope, ensuring that your organization maintains control over its data.
Create an S3 bucket that is continuously updated with Databricks usage reports.
After creating the bucket, you need to grant Finout access to your bucket by creating an IAM role.
Copy your “external-id”
from the Finout console, or use a random one, preferably in the format of finout-XXXXXXX
In the Account ID field, enter: 277411487094
.
Select the Require external ID option, and enter the “external-id”
you got from the previous section.
Click Next until the review screen is displayed. Then configure it as shown below and click Next.
Go to your newly created role.
Copy the Role ARN
and paste it into the Finout console.
Click Add permissions and select Create inline policy.
Select JSON, and paste this inside - While changing <BUCKET_NAME> with the bucket you create in the first section (or your existing CUR bucket, if you already have AWS as a Cost Center in Finout)
Click Next until the review screen is displayed, then name it finout-access-policy
.
Click on Create policy to have your policy created for the IAM role.
Send Finout the following details:
The newly created role
The external ID
Bucket name
Path in the bucket
Region
Provide Finout with the cost per DBU for each Databricks service.
Finout’s most basic offering. Add your Datadog’s product cost to Finout’s MegaBill with breakdowns by, sub-products, regions, and organizations.
Finout supports all Datadog products.
Required scopes: usage_read
With this advanced integration level, you can add cost-per-tag visibility to the Finout MegaBill. By incorporating product tags, you can access a more comprehensive breakdown of your Datadog Logs and Timeseries products, facilitating precise cost attribution to these services.
Two groups of tags can be added to Finout:
Customers have the freedom to set their own custom tags. Our process is designed to dynamically resolve tag values based on customer specifications. In cases where resolution is unsuccessful, Finout utilizes its default tag set as a fallback option.
Required scopes: not scoped
Note: For Timeseries products, only the metric_name tag is available.
Finout enables you to effortlessly access out-of-the-box actionable cost optimizations and insights for your Datadog usage via the CostGuard product.
Required scopes: monitor_read, dashboard_read
Required scopes: not scoped
Connecting Google Cloud Platform (GCP) to Finout enables seamless tracking and monitoring of your cloud expenses. By integrating GCP, Finout provides detailed insights into your usage, allowing you to visualize costs, optimize spending, and manage budgets across your GCP resources. The connection process involves securely linking your GCP billing account to Finout for real-time cost analysis.
Important: Skip this step if GCP detailed billing has already been activated.
In the Google Cloud account, select Billing.
Choose Billing export.
Make sure that the Detailed usage cost is enabled.
Note: Enabling Detailed usage cost is a one-time action for the entire billing account. This setting applies to all projects under the billing account, so there is no need to enable it individually for each project.
To connect GCP, Finout requires minimal permission to BigQuery in the project that is tied to your billing. To identify that project, check your billing page to see the connected project.
Perform the following steps after selecting the correct project:
Search for Service Accounts, and click Create New.
Configure these three roles:
BigQuery Data Viewer BigQuery Job User BigQuery Read Session User
Leave section 3 blank and click Done.
From the context menu, select Manage Keys
.
Click Add Key and Create New Key.
Choose JSON and paste the JSON in Finout's console:
GCP credit types enable users to categorize and display different types of credits. This addition, which includes the ability to group and filter GCP credit types and show original costs, performs as an effective tool for cloud expense management and aims to deliver clarity and ease in financial analysis, empowering users with a more transparent view of their GCP billing and spending patterns.
This feature allows users to easily identify and analyze different types of GCP credits impacting their costs. It simplifies understanding how these credits play a role in overall expense management.
Common GCP credit types
Sustained use discounts: For continuous resource usage.
Committed use discounts: For consistent resource usage over time.
Free tier usage: Covering costs under the GCP Free Tier.
Promotional credits: Offered during promotions or special events.
Research credits: Provided for academic or research-related purposes.
When no credits are applied to a cost, the Credit Types field will show Cost Without Credits. This distinction ensures clarity in cost analysis, helping users differentiate between discounted and non-discounted expenses. Understanding the original cost before credits is essential for a comprehensive view of spending and evaluating the effectiveness of credits used.
Key feature functionalities
Grouping by Credit Types: Offers an aggregated view of how different credits influence your total cloud expenses.
Filtering by Credit Types: Allows for targeted analysis of specific credit types, offering deeper financial insights.
How can I grant Finout access to my GCP billing table through a custom project instead of the primary project?
Project Name
Dataset
GCP Table
Note: Ensure the table includes the full Google billing table structure, including the partitioned time column.
Connect Jira to Finout to streamline cost tracking for your projects. Jira, a popular tool for project management, issue tracking, and agile development, can be integrated with Finout to gain insights into your project costs and resource usage, enhancing financial visibility and control across your workflows.
Prerequisites:
An active Jira Cloud account, along with administrative rights.
Access to the third-party tool with necessary permissions to set up and manage integrations.
Note: The Jira integration applies only to Jira Cloud.
Sign in to your Jira Cloud account.
Navigate to Account Settings and select Security.
Under API token, select Create and manage API tokens.
Select Create API token, provide the API with a name for easy identification, and securely save the generated token.
Before setting up the integration in Finout, ensure you have these details:
Jira cloud base URL: Your specific Jira Cloud instance URL (e.g. https://yourdomain.atlassian.net).
API token: The token generated in Jira Cloud.
In Finout, navigate to Settings.
Go to the Integrations.
Choose Create Jira Integration.
Enter the details from step 2: User Email, URL, and API Token.
Click Submit.
Note: Successful integration will prompt a success message and redirect you to the integration page.
Identification: The Jira email address is an important identifier of your user account in Jira Cloud, essential for authenticating and authorizing the connection between your third-party tool and Jira.
API Authentication: For API requests to Jira Cloud, such as creating a ticket, authentication is required to verify the legitimacy and authorization of the request. Typically, this involves using an email address in combination with an API token for basic authentication in Jira Cloud.
Integration Context: The chosen email address determines the specific Jira account with which the third-party tool will interact. This is important as any actions (such as creating or updating issues) performed by the tool will be under the privileges and permissions of the associated Jira account.
Audit and Traceability: Actions performed through the API are typically logged by Jira. The email address can be used to identify the account involved in these actions, helping in audit trails and troubleshooting purposes.
In a team or enterprise setting, it's recommended to use an email associated with a service account rather than an individual's account for more effective management of permissions and access control.
For organizations with an unlimited user count in their Jira Cloud subscription, we highly advise creating a dedicated service user account for the integration with our tool. This method offers enhanced control and stability.
Navigate to the user management section in Jira.
Create a new user, designated for the integration. Provide a clear user name such as integration_service_user, for easy recognition.
Provide the new user with the necessary permissions for tasks such as issue creation and management.
Note: Avoid giving administrative rights unless necessary.
Permission Control: Simplifies permission management and auditing as they are isolated actual user accounts.
Stability and Continuity: The integration is not linked to an individual employee’s account, ensuring continuity regardless of staff changes.
Improved Security: Reduces the risk associated with using personal accounts for integrations and helps in maintaining a clear separation between user activities and automated processes.
Clear Audit Trails: Any actions performed by the integration are attributed to the service user, simplifying tracking and auditing.
License Usage: For Jira Cloud accounts with limited user seats, adding a service user consumes one of these seats. However, for accounts without user count limitations, this is not a concern.
Regular Maintenance: Like any account, ensure that the service user’s credentials are securely managed and that its permissions are reviewed regularly for any necessary updates.
By following these recommendations, organizations can achieve a more secure, controlled, and reliable integration with Jira Cloud.
Note: You can Edit the user capabilities and limit to only API keys.
In S3 Bucket, click Configure. The Configure S3 Bucket window appears.
Use the same Microsoft Teams account for both the integration setup within the Finout platform () and the Finout app installation on Teams (). The integration in Finout and the bot installation require the same Microsoft Tenant.
Make sure that the user has permissions to install apps from Teams marketplace. Team owners can define which members can install Teams apps. For more information see .
Note: Finout leverages Microsoft’s OAuth 2.0 authorization code grant flow to integrate your Microsoft account with Finout’s services securely. You can find more details about this process .
Use this to install the Finout app for each team where you want to receive notifications.
Select the channels to receive notifications for and .
To connect Databricks to the Finout platform, refer to the original Databricks guide for exporting billable usage in a CSV format:
Click to create a role for Another AWS account.
Still need help? Please feel free to reach out to our team at .
The Finout-Datadog integration offers multiple levels, granting users the flexibility to choose from diverse Finout features and supported Datadog products available at each level. Each level requires different . To gain all Datadog capabilities and features in Finout, ‘not scoped’ key is required.
Note: For the basic Datadog integration, having keys for the is mandatory. However, for enhanced integrations, API keys for all multiple are required.
Note: Every role assigned to Finout’s service account by the customer can be restricted to a specific project, dataset, table, or other resource, ensuring access is limited to only the necessary tables.
To add a specific condition to a role:
1. Click Add condition.
The condition builder appears.
2. Choose a key name.
3. Apply the following format to the table for which you want to grant permissions:
projects/<project-id>/datasets/<dataset-id>/tables/<table-id>
For all format types, see .
This setup is not available through the app’s onboarding process. If you need Finout to access your billing table through a custom project for security reasons, contact Finout support at and provide the following details:
Still need help? Please feel free to reach out to our team at .
Jira email address: The email address linked to your Jira account (Further details on selecting the appropriate email are provided ).
Ensure you select the Jira email address that has the appropriate permissions (see our recommendation to use a dedicated service user for the integration) required for the API operations you intend to perform. For example, if your integration aims to create issues, the Jira account linked to the email should have the necessary permissions to create issues in the designated Jira project.
Sign in to your Jira account as this service user and create an API token (refer to the ). This token will be used for the integration, ensuring that the tool's actions are done under this service user’s profile.
Datadog scopes
Finout platform functionality
Organization keys level
API Used
usage_read
Basic Datadog cost center integration - View Datadog’s products in Finout’s MegaBill with breakdowns by usage type (committed / on-demand cost), products, and organization.
Only Parent organization
usage_read,
metrics_read, timeseries_query
Parent organization + all multiple child-organizations
monitors_read, dashboards_read
CostGuard- Out-of-the-box actionable cost optimizations for Idle Synthetics.
Parent organization + all multiple child-organizations
Not scoped
Products basic list of tags- Indexed Log
Parent organization + all multiple child-organizations
Finout’s Kubernetes integration brings powerful cost visibility and optimization to your containerized workloads. Finout provides granular insights into resource utilization and costs by connecting directly to your Kubernetes clusters, enabling precise allocation and optimization across namespaces, pods, and workloads. Transform your Kubernetes environment into a cost-efficient, fully transparent part of your cloud strategy.
This topis covers the following topics:
Finout allows users to import telemetry data to the platform daily. This functionality enables the creation of precise unit economics, detailed breakdowns of shared costs, and the development of telemetry-based widgets that enhance the monitoring of various data sources together with the MegaBill.
Telemetry refers to any data measurements that users intend to incorporate into Finout. This includes any metrics or data points that can be leveraged to enhance insights, enable monitoring, or assist in managing costs within the platform.
When preparing your telemetry data for Finout, ensure your input can support the following format, which includes three main attribute types: Date, Metadata, and Metric.
Type of attribute
How many columns can be used?
Mandatory/Optional
What is this used for?
Format / Notes
Date
Single
Mandatory
Each data row input represents the telemetry for a specific date, accompanied by their metadata values, indicating the day on which the telemetry was recorded.
YYYY-MM-DD
“date” column
Metadata (multiple)
0-10
Optional
Any tagging attributes can be utilized to group and filter telemetry data based on metadata such as team, group, or feature.
Optional
Telemetry
1
Mandatory
Represents the total of the telemetry for the given date and metadata.
Positive number
If the data can be integrated into Finout using this format, it can be used as a telemetry source in Finout’s abilities.
One of the major advantages of Finout’s telemetry data integration is its ability to provide detailed allocation and breakdown of shared costs, beyond the resource level. This capability is especially important for breaking down multi-tenant use cases (such as cost per development team or cost per customer) that are not easily attributed to their right destinations. It addresses the challenge of expenses that lack granularity from cloud service providers, such as EC2 data transfers or database instances utilized by several tenants (teams/customers).
With Finout's advanced capabilities, users achieve a more granular reallocation of costs beyond basic resource levels, enabling deeper cloud cost analysis and management.
For instance, users can utilize Finout’s reallocation abilities to select a Virtual Tag value and determine a reallocation strategy. This means you can reallocate the cost of an S3 bucket according to an external metric using the Virtual Tags advanced allocation (reallocation) section.
To integrate your telemetry data with Finout effectively, please utilize one of the supported methods listed below.
Note: The data for each method is updated once a day as part of our data retrieval process.
S3 Bucket Telemetry Export - Export your telemetry data to an S3 bucket accessible by Finout. Finout automatically samples the bucket daily, identifying new CSV files and data by checking the uploaded file names and their last modification date.
Datadog- If your telemetry data is collected and managed via Datadog, integrate directly with Finout to import metrics.
Snowflake - Connect your Snowflake data warehouse directly with Finout. Documentation is coming soon.
Prometheus - For systems monitored by Prometheus, leverage this integration to forward metrics directly to Finout. This is supported only for accounts with K8s environments that are monitored using Prometheus. After integrating successfully, Finout collects the relevant metrics. Documentation is coming soon.
You can connect to custom cost centers in addition to the native cost centers supported by Finout. This can be done in the following two ways: CSV - Connect custom cost centers using CSV format in a container that can be read, such as an S3 bucket.
Note: You can send Finout support in CSV format without a bucket for an initial cost center connection.
Snowflake - Connect custom cost centers using the Snowflake table containing cost data.
The CSV format we support is based on three main columns:
"UsageDate","ServiceName","Cost"
UsageDate
- YYYY-MM-DD - The day the cost incurred
ServiceName
- String - The name of the cost, the way you want it to appear in Finout
Cost
- double - the cost in dollars
For example:
"UsageDate","ServiceName","Cost"
"2022-06-07","Servers","12.12"
"2022-06-07","Storage","6.22"
"2022-06-08","Network","0.05"
With this custom integration, you can make more complicated integrations and add metadata fields as well.
The following table structure in Snowflake could be used for us to ingest custom data from:
Where:
SOURCE
is an indication to the source cloud or system, i.e Datadog, Azure etc.
USAGE_DATE
is the date you would want to add the costs to.
SERVICE_NAME
is a sub-service within the source, COST
is the cost in USD.
METADATA
is a custom key-value object for tags, optional.
Follow this guide to allow Finout to access Snowflake data and add Finout’s role privileges to query the above table.
Finout’s solution for managing container costs is completely agentless. It reduces security risks and performance overhead by automatically identifying Kubernetes waste across any Kubernetes resource.
The Finout agentless Kubernetes integration consists of three steps:
Configure an S3 bucket to which the Prometheus Kubernetes data will be exported. In this step, it is also required to set read-only permissions to Finout to read your Prometheus files.
Note: It is highly recommended to use the same S3 bucket and permissions that are set for your AWS Cost and Usage Report (CUR) files.
Add a policy to a K8s node worker to enable the CronJob to write permissions to your S3 bucket.
Create a CronJob to export the data from Prometheus to your S3 bucket.
The S3 bucket consists of the K8s data extracted from Prometheus. This bucket will have read-only permissions for Finout.
Important: If you have already connected an S3 bucket to Finout for the AWS Cost and Usage Report (CUR), you can use the same S3 bucket with the same ARN role already configured. The role and bucket information are automatically filled out in the Finout console. If you want to configure a different S3 bucket or haven’t set up one yet, go to Grant Finout Access to an S3 bucket.
If you have more than one cluster, repeat steps 2 and 3 for all of your clusters.
Attach the following policy to the K8s worker node role. This enables the CronJob to write the K8S data from Prometheus into your S3 Bucket.
Start a version of kube-state-metrics (most likely 2.0.0+). To fetch data from the Prometheus-kube-state-metrics daemon set, include the following flag to export all labels to Prometheus (or change the pattern to your required pattern):
--metric-labels-allowlist=pods=[*],nodes=[*]
Do this by adding an arg to the kube-state-metrics container, for example:
spec:
containers:
args:
--port=8080
--metric-labels-allowlist=pods=[*
],nodes=[*
]
Copy the CronJob configuration below to a file (for example, cronjob.yaml) This is an example of a CronJob that schedules a Job every 30 minutes. The job queries Prometheus with a 5-second delay between queries so as not to overload your Prometheus stack.
Run the command in a namespace of your choice, preferably the one where the Prometheus stack is deployed: kubectl create -f <filename>
Trigger the job (instead of waiting for it to start):
kubectl create job --from=cronjob/finout-prometheus-exporter-job finout-prometheus-exporter-job -n <namespace>
The job automatically fetches Prometheus data from 3 days ago up to the current time.
Additional fields that can be configured to the yaml file:
QUERY_<QUERY_NAME>
Add a custom query by setting the value of this environment variable.
TIME_FRAME
Defines the time frame window for a query in seconds.
Default: 3600
(1 hour).
BACKFILL_DAYS
Specifies the number of days the exporter retrieves historical samples.
Default: 3d
.
To configure these fields, add them to the configuration file under the env
section and use the name/value format for each desired field.
For example:
Ensure that the field names and corresponding values are correctly specified to apply the desired configuration.
The K8s internal address for the Prometheus server must be structured as follows: <PROMETHEUS_SERVICE>.<NAMESPACE>.svc.cluster.local
After configuring the final step, the CronJob starts exporting data from Prometheus into your S3 bucket. After the integration, the Kubernetes cost data may take up to 24 hours to become available in your Finout account.
If this process fails, guidance is provided in the Finout console to help resolve the problem, or review the Troubleshooting FAQs as this will assist you to easily fix any errors.
If you want to export the Kubernetes data into a different S3 Bucket than the one with the AWS Cost and Usage Report (CUR) files, follow the steps below:
Go to your newly created role.
Click Add permissions and select Create inline policy.
Select JSON, and paste the following (change the <BUCKET_NAME> to the bucket you created or to your existing CUR bucket):
Click Next until the review screen appears, and name the policy finest-access-policy_K8S.
Click Create policy to create your policy for the IAM role.
Fill in all the details in the Finout console.
The following troubleshooting FAQs explain common integration issues and how to easily resolve them.
Make sure that the relevant read permissions for Finout were created. If the account that writes the Prometheus files into the S3 bucket is not the same account that created the ARN role for Finout, generate a new ARN role for Finout from the former account (that is, the account that writes into the S3 bucket) and send it to Finout, following the instructions below.
If you already created a trust policy for Finout when setting up your AWS connection, you should use the same trust policy (Read more about how to Grant Finout access to your S3 bucket).
Use the following policy for your ARN role:
To ensure your Kubernetes monitoring is compatible with Finout, you need a Prometheus-compatible system (such as VictoriaMetrics, Thanos, Cortex, M3) and a functioning Kubernetes cluster for deploying the Finout cronjob. Follow these integration steps:
Validate that your system exports the correct metrics, including memory, CPU, network usage, and node info.
Deploy the Finout cronjob in your Kubernetes cluster.
Configure connectivity with the necessary environment variables.
Ensure Finout has the required permissions to access your metrics export.
For detailed instructions and requirements, refer to the Finout integration documentation.
Apply the correct policy on the node worker or the pod. See instructions here.
After updating or adjusting Prometheus configurations, memory metrics may no longer appear in Finout dashboards.
Immediately following the identification of this issue, ensure you’re familiar with the best practices for configuring and reloading Prometheus by consulting the official Prometheus documentation.
Verify the recording rule: Check that the "node_namespace_pod_container:container_memory_working_set_bytes"
recording rule is correctly set up in your Prometheus environment.
Add or update the rule: If the rule is absent or improperly configured, add or amend it within your Prometheus configuration settings.
Reload the configuration: Implement the new or modified rule by reloading Prometheus’s configuration.
Access the configuration: Open the Prometheus configuration, either directly through the file or via the UI.
Edit the rules: In the recording rules section, verify the presence of "node_namespace_pod_container:container_memory_working_set_bytes"
. If it’s not there, insert or correct it.
Apply the changes: Reload or restart Prometheus to apply and activate the rule.
This approach ensures you directly address the issue with missing memory metrics in Finout, supported by a foundational understanding of Prometheus configuration and management principles.
When all clusters share the same Prometheus disk space settings, larger clusters can quickly use up disk space due to their higher metrics output, limiting data retention to a few hours. This can lead to the Finout exporter timing out, particularly when fetching the previous day's metrics. To address this, adjust the metric retention settings according to each cluster's size and output, ensuring sufficient disk space for longer data retention.
When integrating with Finout, you can effectively monitor different Kubernetes clusters using specific monitoring tools, such as Datadog and Prometheus, all within the same AWS environment. This method supports the development of customized monitoring strategies that cater to each cluster's particular needs and budgetary considerations. For example, a cluster dedicated to customer-facing applications might benefit from Datadog's sophisticated capabilities, while a cluster utilized for internal operations might find Prometheus to be a more budget-friendly option.
To ensure successful integration with Finout in such a setup:
Verify that each cluster operates independently without shared node resources.
Configure each cluster's monitoring tool properly to ensure seamless data capture and integration.
Deployments may not appear in the monitoring dashboard if specific metrics are missing due to retention policies or configurations not capturing them. It's crucial to ensure all essential metrics are retained. Reviewing and adjusting the configuration to capture and retain these metrics can improve visibility and ensure comprehensive monitoring.
The metrics exporter might face out-of-memory (OOM) errors with insufficient resources, especially when dealing with a lot of data. This limitation can prevent the exporter from functioning properly. Allocating more resources based on its needs can solve this. By fine-tuning memory allocation to match the data workload, the exporter can run smoothly and without breaks.
To address performance issues with the exporter, reduce the values for TIME_FRAME
and/or BACKFILL_DAYS
. Lowering these values decreases the data volume processed, improving speed and reliability. See the CronJob Yaml configuration example.
Use QUERY_<QUERY_NAME>
to add a custom query. Enter the desired metric name as the value to start collecting it. See the CronJob Yaml configuration example.
Finout currently supports ingesting metrics from AWS S3 only. You have two options:
Use your own AWS S3 bucket – Push your Kubernetes monitoring metrics to an AWS S3 bucket hosted in your infrastructure and follow the standard integration steps.
Use Finout's AWS S3 bucket – Push your metrics to an AWS S3 bucket hosted by Finout. To set this up, contact us at support@finout.io.
Integrating your telemetry data into Finout using a S3 bucket of your choosing, requires setting up a consistent export process to an S3 bucket, for which Finout has been granted read access. This ensures that Finout can retrieve and process your data, which should be structured to include a daily timestamp, the telemetry value for each day, and the granularity of the data collected.
Generate a daily CSV export by selecting from two approaches for your CSV exports:
Maintain a single CSV that receives updates daily with new data entries.
Create a new CSV file for each day's telemetry data.
We recommend opting for the second option, which is creating a distinct CSV file for each day's telemetry data.
When preparing your telemetry data for Finout, ensure your CSV files follow the required format, which includes three main column types: Date, Metadata, and Telemetry.
Type of column
How many columns can be used?
Mandatory/Optional
What is this used for?
Format / Notes
Date
Single
Mandatory
Each data row input represents the telemetry for a specific date, accompanied by their metadata values, indicating the day on which the telemetry was recorded.
YYYY-MM-DD
“date” column
Metadata (multiple)
0-10
Optional
Any tagging attributes can be utilized to group and filter the telemetry data based on metadata such as team, group, or feature.
Optional
Telemetry
1
Mandatory
Represent the total of the telemetry for the given date and metadata.
Positive number
Important:
The CSV must include at least two specific columns: date and <telemetry_name>.
The Telemetry column name will be used as the unique identifier for this telemetry within Finout.
Column headers must not include spaces.
Example:
In this example, we will supply the mandatory columns date (“date") and telemetry (“bytes") together with an optional metadata column “teamname”.
"date","teamname","bytes"
"2022-06-07","Servers","12.12"
"2022-06-07","Storage","6.22"
"2022-06-08","Network","0.05"
Date = date
teamname = metadata
Bytes = telemetry
Create a separate folder within the bucket for each telemetry integration. This setup allows you to easily reuse permissions for sending other telemetries using the same integration.
Set up an S3 bucket. Ensure the bucket is properly configured to store and manage your data securely.
I want to use an S3 bucket already being accessed by Finout
If an S3 bucket is already linked to Finout for the AWS Cost and Usage Report (CUR) or a previous telemetry integration, you can utilize the same S3 bucket and ARN role. The role and bucket details will auto-populate in the Finout console (in the cost center integrations page). In this case, proceed directly to step 5.
I want to set up a new S3 bucket for telemetry-based export
For setting up a new S3 bucket or if you haven't configured one yet, follow the instructions below to grant Finout access to your S3 bucket.
Grant Finout access to an S3 bucket
After creating the daily export, you need to grant Finout access to your export bucket by creating an IAM role that will have read access to the daily export.
Copy your “external-id” from the Finout console, or use a random one, preferably in the format of finout-XXXXXXX.
Click on create a new cross-account role in IAM to create a role for another AWS account.
Enter the AWS Account ID associated with the S3 bucket in the Account ID field.
Choose the option to Require external ID and input the “external-id” you got from the Finout console.
Click Next until you reach the review screen.
Configure the review as shown below, with one exception: the role name should be: FinoutMetricsReadOnlyRole (unlike in the screenshot below).
Go to your newly created role.
Copy the Role ARN and paste it into the Finout console.
Click Add permissions and select Create inline policy.
Select JSON, and insert the following. Replace the <BUCKET_NAME> with the name of your newly created bucket or your existing CUR bucket:
Click Next until you reach the review screen, and name the policy finest-access-policy_telemetry_export (or choose your own name).
Please provide Finout with the following information:
External ID
ARN role
Bucket name
Folder name within the bucket
Optional: region
In today's world, it's common for companies to use a multi-cloud strategy. Companies need to expand to more than one cloud for a variety of reasons:
Compliance - Customers that are willing to have their data only on a specific cloud.
Redundancy - In a world where multiple cloud providers can experience critical service outages for a substantial amount of time, businesses must always have a backup plan.
Commercial -If a business can indicate that they have the option to move to another cloud, they are in a much stronger position to negotiate their next cloud commitment.
If we adopt a multi-cloud strategy, we must also consider the implications for a multi-cloud Kubernetes (K8s) architecture. Incorporating K8s into our tech stack is already complex for a single cloud, but using it in a multi-cloud environment can be even more challenging.
K8s has already proven to be difficult on its own and presents various challenges including:
Operation: The ability to configure and orchestrate multiple workloads correctly in milliseconds.
Cost allocation: Understanding the cost of a single pod can be challenging as cloud vendors have their implementation of K8s (EKS, GKE, AKS, etc.) that do not necessarily provide visibility into the cost of a single workload. This often requires purchasing a 3rd party tool.
Security: There are inherent risks associated with managing K8s in a multi-cloud environment.
When it comes to multi-cloud multi-K8s installations, chaos is inevitable. To manage such complexity, users must find the right tools to address these use cases:
MegaBill - A modern FinOps needs to be able to analyze all their costs in a single solution, without switching tabs or using different parts of the tool for different clouds. Dashboards must be built for all cloud providers and specifically for all K8s resources to achieve true multi-cloud cost management.
Cost allocation - After consolidating costs in a single place, users need the ability to allocate and rename costs easily to a single value. Using Namespaces, pod labels and more is great for a single K8s architecture, but once deployed to multiple clouds it becomes difficult. The simplest show-back use case breaks down when your K8s deployment on your two clouds isn't aligned. It's essential to allocate all K8s deployments & namespaces to business logic.
Think about scale (and the added cost) - Multiple cloud vendors running K8s means more clusters, but beware of tools that price by the number of clusters. The pricing of monitoring tools should never influence infrastructure. A complex system requires defining the right configuration and scaling with no issues.
K8s cost monitoring strategy- Not every K8s monitoring tool needs an agent present inside the cluster itself, and this can be a security and operational risk. Instead, why not use existing monitoring tools like DataDog or Prometheus, which we may already be paying for? All that's needed for K8s cost allocation is their usage metrics, and the monitoring tool should work the same way for all clouds.
Cost avoidance and rightsizing - Running on multiple clouds requires a cost governance process. All K8s resources, whether from GCP or Azure, should be in a single place to manage anomalies and make rightsizing decisions. Cost waste is money down the drain, regardless of the cloud provider.
To avoid cost waste, users must have all their Kubernetes resources, regardless of the cloud provider, in a single place to manage anomalies and make right-sizing decisions. In summary, Kubernetes presents challenges in a multi-cloud world, but the right monitoring strategy and cost management tool can help users overcome them.
The Kubernetes MegaBill is a valuable feature within Finout that simplifies cost allocation for users. It enables users to effortlessly view and allocate expenses across all native Kubernetes concepts such as namespaces, k8s labels, and all k8s resource types. This feature streamlines expense tracking and enables effective cost management.
Moreover, the MegaBill allows users to assign costs to organizational concepts such as teams, products/projects, departments, or environments, which provides a more comprehensive way to track and manage expenses. This feature enhances the visibility of spending, empowering organizations to make informed decisions on how to allocate resources.
To help users better understand the metrics presented in the MegaBill, this document provides a detailed explanation of each metric. Additionally, it offers instructions on how to customize the displayed data in the MegaBill to cater to users' specific needs, making expense tracking more efficient.
Overall, the Kubernetes MegaBill is a critical tool for any organization that employs Kubernetes. With its ability to allocate costs across multiple organizational concepts and native Kubernetes concepts, it presents a comprehensive view of an organization's spending, facilitating better decision-making and cost management.
Element
Description
Select View
Select the relevant saved view from the view list or search for a view name in the search bar.
Filter
Filter the costs by adding or excluding any specific costs.
Group By
Group costs by one or several concepts. Add custom labels
Date Range
Will report the last 30 days by default. Pick one of the options to change the range or create a custom date range.
Periodical Range
Will report on a daily basis by default. Manually change to weekly/monthly.
Show Costs As
Will show cost as amortized Cost. Pick one of the options to change the cost type.
Add Widget to Dashboard
Save the current widget to an existing or new dashboard.
Download CSV
You can download your K8’s view to a CSV file.
Choose the relevant view to display from the view list. Apply a filter to find the view that pertains to AWS, GCP, Global, Snowflake, Kubernetes, or Datadog. Alternatively, use the search bar to search for the view by its name.
The filter feature in Kubernetes allows you to include or exclude resources such as namespaces, deployments, clusters, and Kubernetes labels. This helps you analyze increases in spending or identify key cost drivers at different levels of aggregation such as deployments or pods. When you apply a filter, only resources with a matching value will be displayed, while excluded resources will not be shown.
Additionally, these filters can be applied to external out-of-cluster asset tags as well.
Here you can group costs by Kubernetes resources such as namespace, deployment, and cluster or by labels such as node labels and pod labels to see the specific costs in the widget.
Select the date range of the widget by customizing the start and end dates, or by using one of the preset options.
Select the periodical range of the widget by choosing one of the three options: Daily, Weekly, or Monthly.
Select the relevant cost view out of five options: Net Amortized Cost, Amortized Cost, Unblended Cost, Net Unblended Cost, or Blended Cost.
Add the widget straight to either an existing dashboard or a new dashboard. Once you have clicked on the Add to Dashboard option, you will be able to give your widget a name and choose the relevant dashboard or type in a new dashboard name to create a new one.
Once added, you will be able to go straight to the dashboard that includes the added widget.
To edit the widget- you are required to go to the dashboard with the added widget, and there you will be able to edit your widget and customize it.
Download the widget as a CSV file.
Still need help? Please feel free to reach out to our team at support@finout.io.
Finout provides real-time visibility into your costs through your MegaBill and also utilizes your historical data to identify any cost anomalies that may occur. Using machine learning models, Finout automatically detects both increases and decreases in your costs, allowing you to quickly investigate any deviations from your regular spending. You can view these anomalies either in Finout or directly in your Slack channel.
Finout automatically scans your most popular tags and services for all your cost centers and virtual tags. For every newly created virtual tag, an anomaly scan is added, providing full coverage of your data.
Specifically for K8s, The following Kubernetes anomalies are tracked automatically:
Deployment
Demonset
K8s_namespace
Cronjob
Pod labels are not tracked automatically; you must request specific labels to be monitored.
An anomaly can be a result of an unexpected increase or a decrease in cost. You can drill down and see the MegaBill for the costs associated with a specific anomaly. Anomalies can be viewed in Finout or posted as messages to Slack (see How to Configure Sending Anomalies to Slack).
Select Anomalies.
Search for Kubernetes anomalies using the search bar.
To view the MegaBill associated with the deviation, click Investigate.
To delete an anomaly, click the trash can and then click Yes.
To leave a comment on an anomaly, click the comment icon, enter a comment, and then click Save.
Anomalies can be posted as messages to Slack.
To enable anomaly messages:
Create a Slack endpoint (see Create an Endpoint).
Select Use this Endpoint for sending alert notifications.
To learn more about Anomaly Detection, please refer to our main documentation.
To integrate Finout with your ServiceNow instance, designate a user account that Finout will use to make API calls on your behalf. This ensures smooth and secure communication between Finout and your ServiceNow instance.
Note:
You need administrator-level access to your ServiceNow instance. This access is required to configure the user for the integration and to create an OAuth application within your ServiceNow instance, which is essential for the integration.
ServiceNow Configuration Workflow:
In ServiceNow, create or use a dedicated user with the appropriate ACL permission to read incident metadata fields and create incidents. The user should have the following read ACL permissions:
sys_db_object
sys_db_object.*
sys_dictionary
sys_dictionary.*
sys_glide_object
To enable your instance to receive inbound calls from our service, create an OAuth application within your instance to initiate a token exchange process. Follow these steps to set it up:
Fill in the following fields:
Name: <ANY>
Client Type: Integration as a service
Note: Make sure to leave the Redirect URL and Logo URL empty.
Press Submit. You will be redirected to the list of all available apps.
Navigate to the app that you created and press the lock icon next to the Client Secret field. This will reveal the Client secret, which you will need to provide to Finout later.
In Finout, fill in the following information:
ServiceNow Instance URL
ServiceNow Client ID
ServiceNow Client Secret
ServiceNow User Name
ServiceNow User Password
Note: The username and password should belong to the dedicated user created for the integration.
In Finout, navigate to Settings > Integrations.
Note: You can connect with only one instance.
Click Add Integration.
Under ServiceNow, click Connect Now. The ServiceNow Integration wizard appears.
Enter your ServiceNow Instance URL.
Enter the Client ID from the ServiceNow OAuth application.
Enter the Client secret associated with the ServiceNow OAuth application.
Enter the ServiceNow User name for Authentication.
Note: The user should have the following read ACL permissions:
sys_db_object
sys_db_object.*
sys_dictionary
sys_dictionary.*
sys_glide_object
Enter the password for the specified ServiceNow user.
Click Connect.
ServiceNow is now connected.
Next Step: Create a Service Now endpoint. See ServiceNow Incident Endpoint.
How many ServiceNow instances can I connect?
Only one ServiceNow instance.
Can I use the integration if I don't create endpoints?
No, you must have endpoints configured to use the ServiceNow integration.
What happens if the integration is deleted? It will be deleted along with all associated ServiceNow endpoints.
Why are no fields available for selection in the “Additional Fields” dropdown when creating an endpoint?
The integration user lacks authorization and requires the following read ACL permissions:
sys_db_object
sys_db_object.*
sys_dictionary
sys_dictionary.*
sys_glide_object
Budget rules provide a means to set spending limits for your Kubernetes resources. You can create these rules effortlessly using the Budget feature. Budgets can be established for any Kubernetes group, such as namespaces, deployments, and clusters, or by labels like node and pod labels. Once you select the budget group, the budget values will be adjusted automatically based on your selection.
To get started, navigate to the Budget feature in the navigation bar and click the New budget button located in the top right corner.
Then a window will open with the option to create a new budget:
Budget Name: Give your budget a name.
Select a month: Choose the time frame for your budget. You can only select one month at a time, but you'll be able to update it for the rest of the year after creating it.
Budget group: Select the relevant budget group (e.g., namespace, deployment, cluster) for your budget.
Value-Budget: Enter the budget for each value in the budget group.
Budget alerts: By default, alerts will be enabled to notify you when your forecasted costs exceed your set budget.
After entering all the necessary details, click the Create budget button to finalize your budget. Your budget rule will be created and added to the budget list.
Once your budget is created, a new window will appear displaying your budget details:
In the new budget table, choose the relevant drill down to edit and press the edit button as shown in the screenshot below:
Manually add the budget for the rest of the year and click save.
To delete a budget, navigate to the budget main screen and click the Delete button next to the relevant budget.
This will open the Delete Budget window. Confirm the deletion by clicking the Delete button.
A key aspect of FinOps is cost management, which involves tracking, identifying, and optimizing cloud spend and usage. With Finout's centralized dashboard, known as the MegaBill, you can easily visualize your entire cloud spend and usage data in one place, pinpointing areas for cost and usage reduction, and enabling informed decisions on budget allocation and future planning.
This approach aligns with the FinOps principle of financial governance, promoting collaboration between IT and finance teams to enhance visibility, accountability, and control of cloud costs. Furthermore, by gaining a clear understanding of your cloud usage and spending patterns over time, you can identify trends and continuously optimize your cloud usage, reducing costs and aligning with your business objectives. This reflects the principle of continuous optimization, an ongoing process of identifying, implementing, and measuring cost-saving opportunities and improvements.
Tracking Cost and Usage in Finout’s MegaBill
The MegaBill includes the option to toggle between both cost monitoring and usage tracking data views. This dual tracking capability empowers you to not only manage expenses but also understand how resources are being utilized.
For example, consider tracking the running hours of an EC2 family. As part of a savings plan with your cloud provider for that specific EC2 family, you receive a discount, but your usage remains constant. The value of seeing usage data lies in your ability to track how resources are utilized. This helps you maximize the benefits of your savings plan while ensuring efficient resource management.
By default, the MegaBill screen will display a graph and table of cost data for the cloud services and providers integrated with Finout.
To drill down into your MegaBill, you can use the following filtering options:
(Optional) You can select one or more filters to see a list of relevant views. For example, selecting AWS and GCP will show all saved views that include AWS and GCP resources or labels.
(Optional) Click See all to see a list of all the views.
Create a New View: Use the following filter options to best fit the MegaBill view to your needs:
Filters: Select the required cost center, for example, AWS, and select the required drill down, for example, services.
Advanced filters (Optional): Filter the view even further.
Time aggregation: Daily, weekly, monthly, quarterly, half-yearly, or yearly.
Report period.
Data type: Select either cost or usage.
Cost:
Usage:
Choose the unit type.
Choose a Display:
Cost
Note: - When using the Delta view, you won’t see the total cost, share of total cost, and average on top of the graph. - The X-Axis (date) cannot be changed.
X-Axis value: Select the value to be presented on the X-Axis.
Group By: Select the required grouping option.
Filters: Select the required cost center, for example, AWS, and select the required drill down, for example, services.
Advanced filters (Optional): Filter the view even further.
Time aggregation: Daily, weekly, or monthly.
Report period.
Data type: Select either cost or usage.
Cost:
Usage:
Choose the unit type.
Choose a Display:
Cost
Note: - When using the Delta view, you won’t see the total cost, share of total cost, and average on top of the graph. - The X-Axis (date) cannot be changed.
X-Axis value: Select the value to be presented on the X-Axis.
Group By: Select the required grouping option.
Once your MegaBill view has been created, you are presented with a graph and table view of your chosen data.
The following costs/usage data appears above the graph:
Total cost or usage: The total cost or usage for the selected resources and period.
Share of the total cost or usage: The selected filtered costs/usage as a percentage of the total MegaBill cost/usage.
Average daily cost or usage: The average cost/usage per time interval (day/week/month) for the resources selected in the filters for the specified period.
Note: The MegaBill graph view displays the top 30 daily cost values. Any additional values are grouped under "Others."
Note: You can quickly drill down into the costs/usage by clicking an area on the graph.
The following costs/usage data appears in the table:
Total: The total cost/usage for all the selected resources and each resource for the current period (sorted from highest to lowest).
Previous period cost/usage: The costs for the previous period. Values that have decreased appear in green, and values that have increased appear in red. An indication of the percentage increase or decrease in costs/usage appears.
Percentage of cost/usage: The total cost/usage percentage.
Note: The MegaBill table view displays the top 50 daily cost values. Any additional values are grouped under "Others."
Manage your MegaBill by editing, viewing, deleting, downloading, or cloning data to maintain control and optimize costs.
Use a View as a Dashboard Widget: Add a view to a dashboard by selecting Add to Dashboard, providing a widget name, and choosing an existing dashboard or creating a new one.
Edit a View Name:
In MegaBill, select the views dropdown on the top left of the page.
Click the three dots and then choose Rename view.
Clone View:
In MegaBill, select the views dropdown on the top left of the page.
Click the three dots and then click Clone View. The view is copied.
Edit the view as required.
Click Save.
Or alternatively...
Create a view based on an existing one:
In MegaBill, select the required view from the dropdown on the top left of the page.
Update the view filters as required.
Click Save.
If you are creating a new view, enter a view name.
Click Save View.
Copy the view ID:
In MegaBill, select the views dropdown on the top left of the page.
Click the three dots and then choose Copy view ID.
Delete a View:
In MegaBill, select the views dropdown on the top left of the page.
Click the three dots and then choose Delete view.
Note: Deleting a view will remove it for all users in the account.
Remove Recent View:
In MegaBill, select the views dropdown on the top left of the page.
Click the three dots and then choose Remove Recent view.
Download MegaBill Data: Download data from the graph or table in CSV format. To download a CSV of the MegaBill graph:
Navigate to MegaBill.
Note: The MegaBill graph view displays the top 30 daily cost values. Any additional values are grouped under "Others."
To download a CSV of the Megabill table with “Others” values:
a. In MegaBill, scroll to the table section at the bottom of the screen.
Note: The MegaBill table view displays the top 50 daily cost values. Any additional values are grouped under "Others." A downloaded CSV will have up to 1000 values.
Three Dots :
Remove Costs by Date:
In the table view, click the three dots and turn toggle the dates off.
Transpose Data:
Toggle data transposition in the table view by clicking the three dots and turning Transpose on or off.
Question: When there are too many data points on a stacked bar chart, how does FinOut handle them?
Answer: FinOut automatically groups the top values of the various views and the less significant values into the "Others" category.
In the graph view: The top 30 cost values per day are presented, all other values are grouped as “others.”
In the table view: The top 50 cost values per day are presented, all other values are grouped as “others.”
Downloaded Data: The 1000 top cost values are presented, all other values are grouped as “others.”
Question: How does the "Others" category logic work?
Answer: The "Others" category is used when there are too many data points to display individually on the chart. The logic prioritizes displaying the most significant values separately by cost, while less significant values are grouped under "Others."
Question: Can I ungroup the "Others" category when exporting to CSV?
Answer: Yes, when exporting to CSV, you can ungroup the "Others" category so that data points are listed individually rather than being summarized under a single "Others" row. A downloaded CSV will have up to 10,000 values.
Finout's Inform features provide powerful tools for gaining insights into cloud resource usage and cost optimization. By leveraging detailed metrics and customizable reports, Inform helps teams understand their cloud infrastructure more clearly. With advanced visualization and analysis capabilities, users can easily track spending, identify inefficiencies, and make data-driven decisions to optimize costs and resource allocation. Whether it’s forecasting future expenses or identifying waste in unused resources, Inform delivers actionable intelligence to improve financial planning and cloud operations.
Includes the following features:
Predefined K8s dashboards are supplied by the Finout FinOps team, specifically for Kubernetes that provide visualizations and insights into the health, performance, and utilization of a Kubernetes cluster. These dashboards are designed to give users a quick and easy way to monitor the status of their cluster and identify potential issues.
The predefined K8s dashboards provide a wide range of metrics, including cost per cluster, cost per namespace, cost per deployment, cost per node & more to come!
These metrics are displayed in various charts and graphs, making it easy for users to quickly visualize and understand the state of their cluster.
Navigate to System OAuth > Application Registry.
Click New and then click Create an OAuth API endpoint for external clients.
To learn more about budgets, please refer to our on this topic.
Cost data in the MegaBill is available for all cloud providers and services supported by Finout. Usage data is available for AWS, GCP, and Azure. You can learn more about usage types in your data .
Apply a : If you have already saved a set of filters.
Choose the .
Choose a .
Cost Delta By using the delta graph, you can track cost or usage changes over time directly within the MegaBill. This visualization highlights differences between two points in time, helping to identify trends. For example, you can monitor month-over-month cloud spend variations or changes in resource consumption, such as CPU hours.
Cost Type: Select a cost type. See for a detailed explanation.
Choose the .
Choose a .
Cost Delta By using the delta graph, you can track cost or usage changes over time directly within the MegaBill. This visualization highlights differences between two points in time, helping to identify trends. For example, you can monitor month-over-month cloud spend variations or changes in resource consumption, such as CPU hours.
Cost Type: Select a cost type. See for a detailed explanation.
Clear a View: Click the Clear View icon at the top of the MegaBill page. This will revert the MegaBill to the default setting.
Click . A CSV of the MegaBill graph is downloaded.
b. Click and then click Download more values to CSV.
For DevOps teams looking to confirm their Kubernetes monitoring setup works seamlessly with Finout, this concise guide provides the essentials. Learn how to leverage Finout's cronjob support across Prometheus-compatible systems, ensuring your monitoring solution is fully compatible and optimized for use with Finout. This straightforward approach aims to equip DevOps professionals with the knowledge needed to validate their exporter's functionality swiftly.
Before you begin, ensure you have the following prerequisites in place:
Prometheus-compatible system: Your metrics collection system must be compatible with Prometheus. This includes systems such as VictoriaMetrics, Thanos, Cortex, and M3, among others. These systems must support PromQL queries for integration.
Kubernetes cluster: You need an operational Kubernetes cluster where you can deploy the Finout Cronjob.
Connect to Kubernetes Prometheus: Refer to the main documentation for detailed instructions on setting up the Kubernetes Prometheus integration.
Environment variables: Ensure you have the necessary environment variables configured for connectivity. These include SCHEME, HOSTNAME, PORT, PROMETHEUS_USERNAME, PROMETHEUS_PASSWORD, and optionally, PROMETHEUS_AUTH_TOKEN, PROMETHEUS_BEARER_AUTH_TOKEN, and PROMETHEUS_X_SCOPE_ORGID.
Validate metrics export: Ensure that your system exports the correct metrics to Finout. Validate the following queries in your system:
Memory Usage (V2 or Standard):
For Memory Usage V2:
For Standard Memory Usage:
CPU Usage (V2 or Standard):
For CPU Usage V2:
For Standard CPU Usage:
Network Usage (V2 or Standard):
Bytes Received and Transmitted:
For V2:
For standard Bytes Received and Transmitted:
Node Info:
Note: You may omit the cluster_label grouping when testing these queries.
Deploy the Finout Cronjob: Deploy the Finout Cronjob in your Kubernetes cluster. This is essential for scheduling and running the integration tasks.
Configure connectivity: Utilize the environment variables to configure the connectivity between Finout and your Prometheus-compatible metrics system. This setup allows Finout to execute PromQL queries against your metrics database.
Grant Finout permissions: Ensure Finout has the necessary permissions to read your metrics export from your S3 bucket, as detailed in the documentation.
By following these steps and ensuring your Prometheus-compatible system meets the requirements, you can successfully integrate Kubernetes metrics with Finout for enhanced monitoring and management capabilities.
The Optimize documentation in Finout provides comprehensive guidance on reducing cloud costs and improving resource efficiency. Learn how to identify waste, rightsize resources, and implement cost-saving strategies across your cloud infrastructure. From actionable insights to best practices, this section equips you with the tools to maximize the value of every dollar spent on your cloud.
Includes the following features:
Finout directly supports costs for the major cloud vendors and automatically appear in your MegaBill, but what about smaller vendor costs that are managed manually in spreadsheets?
Finout's Custom Costs feature enables you to add these costs directly to your MegaBill in seconds without any complex integration.
With all your costs in one place, you can get a real-time view of your total technology expenses and accurately assign costs to the appropriate reporting categories. Plus, with Finout's reporting capabilities, you can easily track and analyze all your costs by category, giving you invaluable insights into your spending.
Using Finout’s Custom Cost option, you can add a Custom Cost as a one-time expense or a recurring cost for a specific duration.
A cost can be a charge or a refund, and you can tag the custom cost to categorize it. This allows you to view and generate reports based on the relevant categories.
Select Settings.
Select the Custom Cost tab.
Click Create Custom Cost.
In the Choose a vendor field, either select a vendor or enter a new vendor and click Add.
Enter an Amount. You can enter positive values (for costs) and negative values (for refunds).
Enter a Description for the custom costs (mandatory).
Select a Tag key (Project, Team, Features, or Environment) and Tag value.
To add additional tags, click + and select Tag key and Tag value.
Select a date for the cost.
If the cost is recurring, simply toggle on the Recurring option and specify the frequency of the cost (for example, Every 3 months) and the number of occurrences of the cost.
Click Save custom cost.
Note: Custom costs may take up to 24 hours to appear in the filters list.
The custom costs can be used to filter (or group) the costs in the MegaBill, in the Dashboards, as well as in the virtual tags. For more information, see Virtual Tags.
As noted above, it may take up to 24 hours for any updates made to Custom Costs to reflect in your account.
Select Settings.
Select the Custom Cost tab.
For the required custom cost, click Edit custom cost.
To edit a cost entry, click Edit custom cost, double-click on a cost, edit the entry, and then click Save.
To delete a cost entry, click and then click Delete.
Still need help? Please feel free to reach out to our team at support@finout.io.
Relational Virtual Tag enables the breakdown of shared infrastructure costs across multiple dimensions from a single telemetry while preserving the relationships between them.
Imagine your company is managing cloud costs through Finout’s MegaBill. The company uses various shared infrastructures, such as Airflow, which runs on shared cloud instances and runs tasks which can serve multiple teams, applications and workflows. Since resources like EC2 instances are not tied to a single team or workflow, accurately allocating costs becomes challenging.
With Relational Virtual Tags, you can establish connections between multiple attributes—such as Airflow's DAG ID, Team, and Environment—ensuring that costs are properly allocated while maintaining the relationships between these attributes. This advanced tagging method provides deeper insights into shared infrastructure usage and cost allocation.
Meet the Miller family. They track their household expenses and bills meticulously, and electricity usage is no exception. Mike relies on Finout’s MegaBill to monitor costs and consumption, which provides him with the family’s total electricity bill and usage.
One day, he noticed that their electricity costs were steadily increasing, even though their consumption habits hadn’t noticeably changed. Curious to uncover the cause, Mike began digging deeper into the data.
Electricity Usage per Room
Mike set up a telemetry and used Virtual Tag Reallocation to break down electricity usage by room. The results were revealing as the kitchen was the biggest consumer of electricity.
Electricity Usage per Device in the Kitchen
This information was insufficient to pinpoint the root cause of the high costs. Mike decided to analyze the electricity consumption of each kitchen appliance. His findings showed that the dishwasher was the biggest consumer of electricity.
Electricity Usage for the Dishwasher per Household Member
This was still not enough to pinpoint what caused the spike in the dishwasher's electric cost. He installed a motion sensor to monitor the household members’ interactions with the dishwasher and integrated this new data into his analysis. The results were surprising as Olivia, his daughter, was responsible for the highest dishwasher usage.
This family's story reflects the challenges companies face when trying to break down shared cloud infrastructure costs across multiple dimensions. It highlights how deeper data analysis and segmentation can reveal hidden cost drivers.
What is the Challenge with Virtual Tag Reallocation?
Complex and Manual Process: Breaking down costs across multiple dimensions is possible today, but it requires a lot of manual effort. Users must create multiple virtual tags, starting from the lowest level (Household Member → Device → Room).
Virtual Tag Reallocation cannot preserve relationships between dimensions:
You can determine electricity usage by device.
You can determine electricity usage by household member.
But you can’t determine the electricity usage of each device by each household member. For Example: Let's assume that the dishwasher's electricity cost is $40. Breaking it down by household member would assign random costs because regular virtual tags lack the ability to preserve the relationship between the device (the dishwasher) and its usage by each household member, making it difficult to identify the precise sources of cost discrepancies.
Imagine a company is using AWS to manage its cloud costs through Finout’s MegaBill. This company relies on a shared infrastructure, such as Airflow, which operates on cloud instances (like EC2 in AWS) to manage tasks, run DAGs, and store metadata.
Airflow, like Mike’s electricity bill, is a shared resource that requires careful allocation across multiple workflows (DAGs), teams, and developers. The challenge lies in accurately breaking down and reallocating these shared infrastructure costs.
One day, the company noticed an increase in Airflow costs and needed to pinpoint the source, just as Mike used data to understand the drivers of his electricity usage.
This is where the Relational Virtual Tag solution comes in!
Relational Virtual Tags Enables:
Streamlined Setup and Efficiency: Relational Virtual Tags replace the manual creation of multiple virtual tags with a single, unified configuration that uses one telemetry to build all the necessary building blocks to break down a shared infrastructure cost.
Dynamic Cost Allocation and Relationship Preservation: Relational Virtual Tags maintain relationships between dimensions (e.g., team, workflow, developer) and enable dynamic, proportional cost reallocation. This prevents inaccurate cost assignments, improves financial transparency, and provides deeper insights for more informed decision-making and better cost management.
For example: The company has two teams - "Data" and "App".
The company wants to determine the cost of each DAG for the App team. They aim to break down the total cost of the App team by DAG ID for better visibility and allocation.
This is the company's telemetry:
The company created a relational virtual tag, and now they filter by team “App” and group by “DAG_ID.”
Let’s assume that the App team cost is $100. The breakdown would be as follows:
By leveraging Relational Virtual Tags, the company transformed a seemingly unmanageable rise in shared infrastructure costs into clear, actionable data. This deeper level of visibility empowered the company to identify inefficiencies, distribute costs fairly across teams, and optimize their use of shared resources—just as Mike did with his electricity bill.
Spark costs are often lumped together in shared infrastructure, making attributing expenses to specific queries or projects difficult. Without proper tracking, teams struggle to pinpoint cost drivers. Relational Virtual Tags solve this by linking queries to projects, enabling precise cost reallocation.
RDS instances are shared across multiple databases, environments, and teams, making it hard to distribute costs accurately. Without visibility, production, staging, and development usage may be misallocated. Relational Virtual Tags create structured relationships, ensuring fair cost distribution across Database Names, Environments, and Teams.
ClickHouse workloads are distributed across multiple query types, clusters, and applications, making it challenging to track and allocate costs accurately. Without a structured breakdown, teams struggle to optimize resource usage and manage expenses efficiently. Relational Virtual Tags preserve the relationships between these dimensions, ensuring cost allocation across Query Type, Cluster, and Application.
Prerequisite: A telemetry must be set up before Relational Virtual Tag configuration.
To create a relational virtual tag:
In Finout, navigate to Virtual Tags.
Click Create New and then Relational Virtual Tag. The Create Relational Virtual Tag step appears.
Add a name.
Under Cost Filter Selection, select from the following:
Key type:
Select your Telemetry-Based Reallocation.
Pick the Allocation Keys: Choose the Allocation Keys from your selected telemetry. This will allow for the segmenting of the Telemetry data and the calculation of the relevant ratio based on the keys and values.
Note: Relational virtual tags support cost reallocation based on relationships across up to 10 keys.
Select Telemetry filters:
Preview the Relational Virtual Tag. You can simulate the graph preview by choosing a group-by and filters.
Note: By default, the first selected key is displayed in the preview, but this can be edited.
Click Save. The relational virtual tag is created.
Result: You can view your Relational Virtual Tag keys and values in the MegaBill filters component, just like any other keys and values.
Let's go back to the house and electricity bills example. Here's how the Relational Virtual Tag configuration would be set up:
When using Relational Virtual Tag keys or values in MegaBill or any Finout object, you can only filter or group by keys and values from the same Relational Virtual Tag or a connected Virtual Tag.
A Relational Virtual Tag can handle up to 50,000 unique values, with any additional values automatically grouped under “Others.”
You can create an unlimited number of relational virtual tags.
Each relational virtual tag can break down the cost of a single infrastructure (single cost rule).
How is a Relational Virtual Tag different from a Virtual Tag with telemetry-based reallocation?
Unlike Virtual Tag Reallocation, which allocates costs based on a single key from a single telemetry, Relational Virtual Tags support multiple key allocations (up to 10) while preserving the relationships between them.
What happens if I try to group by a Relational Virtual Tag and an unrelated tag?
Grouping by a Relational Virtual Tag while filtering by an unrelated tag (e.g., Airflow DAG ID with an AWS Region) is not supported.
Can I create a Relational Virtual Tag via API?
No, Relational Virtual Tags cannot be created through the Finout API.
Is there a limit on the number of unique values a Relational Virtual Tag can handle?
There is a limit: The system supports up to 50,000 unique values, with any additional values grouped under “Others.”
Can I change a Virtual Tag and convert it to a Relational Virtual Tag?
No, you need to create a new Relational Virtual Tag.
Managing and allocating native tagging systems from various cloud technologies can be complex and frustrating. Inconsistent tags across platforms, like an AWS resource labeled "Team A" corresponding to "Team Alpha" in Snowflake, lead to confusion and inefficiency. Additionally, native tagging lacks retroactive application, leaving historical data fragmented and obscured.
Finout's Virtual Tag feature addresses these challenges with a dynamic, real-time cost allocation solution. Virtual Tags offer a coherent and unified view, enabling the consolidation and analysis of costs across all cloud providers and services. Leveraging advanced filters allows you to segment your cost data into specific segments, creating a structured and comprehensive financial overview without modifying original resource labels. Tailored rules within each Virtual Tag refine cost visualization and management, streamlining how you manage your cloud spending.
A Virtual Tag acts like a funnel from the top down, and each rule further filters the data received after the preceding rule is run.
For example, with Virtual Tags, you can view the costs associated with logical categories:
AWS and Kubernetes are used for different environments, such as development versus production.
Snowflake queries for Data Team 1 versus Data Team 2.
Snowflake, Kubernetes, and the cloud providers (such as AWS and GCP) for the Application, Backend, Data, and Analytics groups.
You can even use Virtual Tags based on other Virtual Tags. So you can aggregate all Data Team's different Virtual Tags together to allocate the entire Data group cost.
Once Virtual Tags are set up, seamlessly use them throughout your entire MegaBill.
Note: Finout also supports Relational Virtual Tags that enable the breakdown of shared infrastructure costs across multiple dimensions from a single telemetry while preserving the relationships between them. See Relational Virtual Tags for more details.
In Finout, navigate to Virtual Tags.
Click Create New and Virtual Tag. The Create virtual tag page appears.
Name the Virtual tag.
You can optionally choose an endpoint to be notified about changes made to this virtual tag.
Create the rules for the Virtual Tags by setting Where conditions and corresponding Then actions.
Important: The order of rules is crucial as it determines their priority. Rule 1 has the highest priority and is assessed first, with its tagging action overriding subsequent rules. Only if a resource does not meet Rule 1's conditions will it be evaluated against Rule 2, and so on.
WHERE:
Select any cost center from the MegaBill.
Select a filter key.
Select an operator (One Of, Not one of, Is, Is not, Contains, Not Contains, Exists, or Not exists).
Depending on the operation, select or enter one or more Filter values.
To add a further criterion to the rule, click +.
Select AND or OR.
Complete the rule row as described above.
THEN: There are two options:
Choose a static value for this portion of your infrastructure by choosing Custom Value and typing it into the text box.
If you already have an appropriate allocation for this portion of your infrastructure in a cloud service provider tag, account name, or resource name, you can select that field using the MegaBill Key option to have those values populated for the Virtual Tag.
Note: when selecting a key from the MegaBill, the key’s values will appear in the MegaBill when filtering or grouping by the Virtual Tag.
Example - Rule 1 includes: Where conditions: The rule is structured to evaluate resources across different cloud providers: AWS, GCP, Azure, and Kubernetes. It will trigger if a resource within these providers has specific tags or labels that match predefined values. For AWS and Azure, the rule triggers for resources with any chosen values in 'environment' tags. For GCP, the rule is triggered if the 'env' label is exactly 'production'. For Kubernetes, it checks against specified 'label_environment' values. Then outcome: If a resource meets any of the 'Where' conditions, the 'Then' action tags it as 'Production'.
You can optionally set a timeframe for the virtual tag, allowing you to specify exact dates for the rule application.
Click Add rule to add additional rules as required.
You can optionally Set the value for the untagged cost field for all unallocated costs not covered by any rules are aggregated under the tag value "untagged." You can enter a custom name for these untagged costs to generate a single value or choose a key from the MegaBill to generate multiple values simultaneously. This feature enables continuous enhancement of Virtual Tag coverage and the creation of rules to reduce untagged costs.
To see a preview, click Preview Virtual Tag. The virtual tag preview appears.
Click Apply Virtual Tag. The virtual tag is created.
Note:
A Virtual Tag is active from the current period onwards.
The Virtual Tags configuration screen is accessible to all users on the account. Contact the Finout support team if you wish to set accessibility limitations for specific users.
Virtual Tags can also be duplicated or deleted as needed.
Managing Virtual Tags allows you to edit, delete, and duplicate virtual tags to better organize and optimize your cloud cost allocation in Finout.
Editing Virtual Tags allows users to refine and update their cloud resource categorization as their infrastructure evolves.
Navigate to Virtual Tags.
Edit Virtual Tag rules: Click on the rule you want to change.
In the Where option, you can change the criteria using the Filter keys dropdown to select different filter types, such as tags or labels, and modify the logical operators as needed.
Adjust the cloud environments by selecting or deselecting them.
In the Then section, update the tag value that will be assigned when the rule's conditions are met.
Add or Delete Rules using the + Add rule button to include new segmentation rules or the – button to remove an existing rule.
Adjust the rule order as desired using the Move rule function, which allows you to change their ranking, since the rules are applied from top to bottom.
Additional edits:
Adjust the time frame.
Edit the values for the untagged costs.
Set up notifications for changes.
Filter by conditions: Utilize the filter values dropdown options to narrow down your Virtual Tag based on specific chosen filters. This is particularly useful when the created Virtual Tag has many rules. Instead of manually searching for the specific item to edit within the Virtual Tag, you can use the filters option to drill down and easily find what you need to edit.
Filter types:
Virtual Tag values: Filter based on the names assigned to the rule in the "Then" section.
Filter keys: Filter based on the keys chosen in your Virtual Tag.
Filter values: Filter based on the exact values that trigger the rule.
Navigate to Virtual Tags.
Warning: This action cannot be undone.
Navigate to Virtual Tags.
Click Delete. The virtual tag is deleted.
You can build widgets in the Dashboards using the Virtual Tags. To use a Virtual Tag, simply select it from the list of filters, and choose whether to include or exclude the associated costs. You can also select which of the categories (rules) of the Virtual Tag to include.
Once a Virtual Tag is created, it is automatically added to the Finout MegaBill as if it was always there.
You can also use a Virtual Tag for grouping.
Creating a Virtual Tag to track your spend across your entire cloud is the first step to truly understanding your spending, once done Finout’s Virtual Tags will allow you daily to under your allocated cost and to gain insight into the actions that happened and will need to happen in the feature to manage and reduce your spend.
If you are still struggling to create your ideal Virtual Tag, please reach out to your Customer Success so we can provide you with all the support you need to achieve 100% cost observability.
Building upon this foundation, Finout takes it a step further with the Shared Cost Reallocation. The reallocation of Virtual Tags enhances the granularity of cost allocation, allowing for a more refined reallocation of shared expenses. Finout’s Shared Cost Reallocation not only addresses the direct challenges of shared cost management but also promotes a deeper understanding of cloud expenditure patterns, allowing you to make more informed financial decisions and strategic planning.
Finout offers four practical strategies for shared cost reallocation:
Cost ratio allocation - Coming soon!
For instructions on setting up telemetry based reallocation in Finout, please refer to the Setting Up a Telemetry Based Reallocation documentation.
When it comes to cost groups, gaining a comprehensive understanding of expenses often requires delving deeper into specific cost elements. While default drill-downs have always been a key component in the MegaBill, we have now gone a step further by providing you with the ability to create your custom drill-downs. With this new edition, you gain the flexibility to explore any cost dimension, tailoring the analysis to match your organization's unique needs. This empowers you to effortlessly visualize any cost dimension at any required level of granularity.
Go to Settings in your Finout account.
Choose Custom Drilldown.
Click on +Add drilldown.
Select the values for your customized drilldown:
From Value/Group- Choose either a whole group or a specific value within the group.
Example- If we take AWS as an example, you can drilldown into the entire Services group.
or we can select a specific AWS service.
To Group- Select the group into which the drilldown takes place.
Save Drilldown
Navigate to MegaBill.
Choose Group By that includes the group or value from which the value you created in the custom drilldown
Apply group by.
The MegaBill chart will now show the Group By that you chose. Click on the area on the graph corresponding to the value/group you selected during custom drilldown creation (e.g., AmazongEC2)
You will see the cost for all values from your drilldown definition group under the chosen value.
Let's say you want to view the cost of all AWS services under the "Virtual Tag - Application" in your MegaBill.
Under Custom Drilldown (in Settings), choose the following:
From Value/Group: Application (Virtual Tag under Dev Group Test).
To Group: AWS Services.
Save your Custom Drilldown.
In the MegaBill:
Click Group By- Virtual Tags - Dev Group Test (Virtual Tag including the Application group).
Click Apply Group By
Click on the Application group to drilldown further.
Now, you'll have a clear view of your MegaBill with the Custom Drilldown we created:
Group By: AWS Services, including the scope of Application, are divided into different AWS services.
This advancement represents a critical phase in your company's FinOps journey, enhancing the granularity of cost allocation and allowing for a more refined reallocation of shared expenses. Effective managing and allocating costs is crucial for businesses leveraging SaaS and cloud services. These should be correctly allocated and assigned across different projects, teams, or departments, especially for shared costs.
This document will guide you through each method, providing a clear understanding of how to implement them effectively in your FinOps practice.
For instructions on setting up Shared Cost Reallocation in Finout, please refer to the How to Use Shared Cost Reallocation documentation.
Finout’s cost allocation layer powered by Virtual Tags streamlines the mapping and analysis of cloud services and providers, ensuring transparent and detailed breakdowns of cloud spending.
Finout's Shared Cost Reallocation solution directly addresses the challenges of showback by facilitating precise and automated reallocation of shared expenses. This advancement represents a critical phase in your company's FinOps journey, enhancing the granularity of cost allocation, allowing for a more refined reallocation of shared expenses.
By this stage, you should have already achieved the following:
Integrated your cloud infrastructure spending into Finout.
Familiarize yourself with Finout’s MegaBill.
Completed the creation of your Virtual Tags, to allocate all your dedicated resources to their right owners tailored to your company's requirements.
But now you are stuck with a portion that isn’t “breakable”, a shared cost that you cannot allocate as a dedicated cost on a resource level.
Building on these initial steps, the Shared Cost Reallocation feature brings a new level of granularity to cost allocation, enabling more precise reallocation of shared costs.
To navigate your shared costs, we offer two strategies to help you break down shared costs:
Finout’s telemetry-based cost reallocation leverages external telemetry data, such as the number of bytes transmitted, length of queries, or even business KPIs, to precisely and equitably distribute shared cloud costs among different use cases (Virtual Tags values). This approach splits costs in a way that reflects the actual consumption of shared resources, ensuring fair attribution according to actual data, enhancing visibility into cloud spending, enabling more accurate financial management.
By utilizing shared costs within Virtual Tags, users can select metrics that may not directly relate to the cost in question but offer a fair basis for further breaking down expenses based on real usage or engagement.
Integrating telemetry data into Finout is streamlined through various methods, including direct exports from an S3 bucket and integrations with Datadog, Snowflake, or Prometheus. This ensures a seamless flow of relevant data into Finout's cost allocation mechanisms, simplifying the process of managing complex cloud expenses and aligning financial responsibilities with measurable contributions.
Analogy: Imagine a family BBQ with a huge, shared salad at the heart of the feast. When it comes time to sort out the bill, rather than arguing over each leaf of lettuce, we glance at how much lemonade everyone guzzled down. Thus, we split the cost of the salad according to everyone's lemonade consumption, making sure each person contributes fairly to the communal pot. It's like using lemonade as a secret code to figure out who ate how much. In the same fun spirit, telemetry-based reallocation slices up shared costs based on different usage patterns. This way, we ensure everyone pays fairly based on their digital "appetite," keeping the financial spread as balanced as a perfectly dressed salad.
For instructions on setting up telemetry based reallocation in Finout, please refer to the Setting Up a Telemetry Based Reallocation documentation.
The customized cost allocation, also known as the fixed percentage method, simplifies the process of sharing costs by evenly dividing them among all involved entities. This approach assumes that each entity, regardless of their individual usage or consumption, benefits equally from the shared resource. Therefore, it distributes the total cost uniformly, ensuring that each party bears an identical fraction of the expense. This method is particularly effective in scenarios where detailed tracking of individual usage is impractical or where the perceived value of the shared resource is equally distributed among the users.
This method additionally offers the flexibility to customize allocation percentages among users, enabling adjustments based on specific criteria to ensure the total cost is accurately divided, covering the full 100% across selected entities. It's particularly suited for customizing cost distribution to accurately reflect each participant's unique usage patterns, contributions, or agreed terms within a group.
Analogy: A family BBQ where the centerpiece is a gigantic salad. When it comes to settling up for this feast, the customized cost reallocation method offers a flexible path, allowing you to tailor the payment process. Option one: everyone chips in equally — no muss, no fuss. Option two: tailor the tab based on everyone's salad saga, like who snatched up the gourmet olives or who barely nibbled on the greens. If cousin Joe wolfed down most of the feta, he tossed a few extra coins into the pot. Similarly, the flexible percentage method lets you slice and dice shared business expenses, from cloud computing feasts to data storage desserts, keeping the financial feast as harmonious as a well-tossed salad.
For instructions on setting up customized cost reallocation, please refer to the Setting Up a Customized Cost Reallocation documentation.
To learn how to set up Shared Cost Reallocation, refer to our step-by-step guide. In this guide, you will learn how to create the different strategy types to help you break down shared costs.
This documentation will guide you through how to create the different strategy types to help you break down shared cost.
Finout’s Telemetry-based cost reallocation leverages external telemetry data, such as # of bytes transmitted, length of queries or even Business KPIs, to precisely and equitably distribute shared cloud costs among different use cases (Virtual Tag values). This approach apportions costs in a way that reflects the actual consumption of shared resources, ensuring fair attribution according to actual data. This enhances visibility into cloud spending and enables more accurate financial management.
Navigate to the Virtual Tags page via the left side menu.
Select the desired Virtual Tag for reallocation.
In the Virtual Tag window, there are two tabs: Tagging and Reallocation. Choose the Reallocation tab.
Choose a Virtual Tag value to reallocate.
For Select reallocation strategy: Use the dropdown to choose a Telemetry-based Reallocation.
Choose Your telemetry metric: From the dropdown menu, select the telemetry metric you wish to use for reallocation.
Pick an Allocation Key: Choose the Allocation Key from your selected telemetry. This will allow segmenting the Telemetry data and calculating the relevant ratio based on the key values.
Add a Description (Optional): You may enter a description for the reallocation strategy, though this is not mandatory.
Note: Once selections are made, the allocation will automatically populate based on the chosen telemetry name and key.
On the left side of the displayed screen, a table is presented including the reallocation details; key name, allocation percentage, a preview of the cost from the total value, and a unit preview (showing allocation per metric unit).
Important: In this method, the allocation percentage is fixed and calculated daily based on the telemetry data and cannot be edited.
On the right side of the displayed screen, a visualization of your cost reallocation is presented. Use the toggle in the top right corner of the visualization to switch between pie and line charts for different views of the reallocation.
If you wish to change the rule to another metric, the preview will automatically change accordingly.
Select Apply Virtual Tag.
Once you’ve applied the Virtual Tag for telemetry-based cost reallocation in Finout, the reallocation view is dynamically updated to reflect any changes, including the addition of new value to the original virtual tag.
The customized cost allocation offers a versatile approach to dividing shared costs. It allows for allocation either by distributing expenses evenly across all values, ensuring each bears an equal share, or by manually adjusting percentages among values for a tailored distribution. This adaptability is ideal for situations where tracking individual usage is challenging or when shared resources are perceived to have equal value to all users.
Step 1: Choose your reallocation method:
Navigate to the Virtual Tags page via the left-side menu.
Select the desired Virtual Tag for reallocation.
In the Virtual Tag window, there are two tabs: Tagging and Reallocation. Choose the Reallocation tab.
Important: You must have at least one defined rule under “Tagging” in order to reallocate costs for this specific Virtual tag. To read more about Tagging.
For the Virtual Tag value to reallocate, select the relevant value defined in Virtual Tag.
For the Select reallocation strategy, use the dropdown to choose Customized Cost Reallocation.
Reallocate costs evenly or manually:
Reallocate Evenly:
Click on the Reallocate Evenly tab.
Input your value(s) and click the + button to include additional values.
The system will automatically display the allocated percentage next to each value.
Reallocate Manually:
Select the Reallocate Manually tab.
Input your value(s) and click the + button to include additional values.
Specify the allocation percentage for each value, ensuring the total equals 100%.
Note: You can enter percentages with up to one decimal place.
Important:
Unallocated percentage: Indicates under-allocation. Please adjust to reach 100%.
Overallocated percentage: Indicates over-allocation. Please adjust to ensure the total is at most 100%.
Fully allocated: Confirms 100% allocation across all values.
To finalize, click Apply Virtual Tag.
Select the Preview Virtual Tag button located in the footer.
A pop-up window will display the selected Virtual Tag's visualization.
Use the toggle button in the top right corner of the pop-up to switch between views: with the reallocation applied and without it.
Selecting the Reset Virtual Tag Changes button in the footer will revert the virtual tag to its previous settings.
Use the toggle button in the top right corner of your window to switch the rule on and off at any time.
A Finout view is how you can save and name a set of filters and the applied group by, allowing you to easily return to view the required data and share this with your team. In addition, the time aggregation (daily, weekly, monthly) and period of the query are also saved as part of the view.
The filters can be applied using out-of-the-box resources such as Azure, GCP, AWS, Datadog, GCP, Global, Kubernetes, Snowflake, or Databricks, as well as virtual tags to view the costs associated with logical categories. You can create as many views as required, and these are shared automatically with all users in your account.
A view can be applied to a cost report or as a Dashboard widget.
Apply the required Filters on the MegaBill page.
Select the required Group By option.
Select whether the data should be calculated as Daily, Weekly, or Monthly, and select the period of the report.
Click Save.
Enter a view name.
If this is a new view, select Save as a new view and then click Save View. If this is an existing view that you are modifying, ensure that the Save as the new view is not selected.
In the Dashboards , click Create Dashboard.
Click Add Widget.
Select a widget or template.
In the Load from saved view dropdown, select the required view.
Configure the other widget options and click Save and return.
In Total Cost, select the views dropdown.
Click the Pencil icon.
Enter the View name.
Click Save View.
In Total Cost, select the views dropdown.
Click the trashcan icon.
Click Delete View. This deletes the view for all users in the account.
In Total Cost, select the required view from the dropdown.
Update the view options as required:
Apply the required Filters.
Select the required Group By option.
Select whether the data should be calculated as Daily, Weekly, or Monthly.
Select the period of the report.
Click Save.
Enter a View name.
Select Save as new view.
Click Save View.
or-
In Total Cost, select the views dropdown.
Click copy Icon (double square). The view is copied.
Edit the view as required.
In Total Cost , select the required view from the dropdown.
Update the view options as required:
Apply the required Filters.
Select the required Group By option.
Select whether the data should be calculated as Daily, Weekly, or Monthly.
Select the period of the report.
Click Save.
Click Save View.
This report details the costs associated with two specific Amazon EKS clusters in your Amazon Web Services account grouped by Kubernetes namespaces. The view shows the daily costs for the past 30 days.
This report details the costs associated with AWS grouped by AWS Sub-Service. The view shows the daily costs for the current month.
Still need help? Please feel free to reach out to our team at support@finout.io.
The Data Explorer feature is a powerful insight-driven tool for data analysis, designed to provide users with maximum flexibility and comprehensiveness when it comes to multi-dimensional report generation. With the ability to create reports that aggregate data across various fields, users can tailor their reports to reflect the exact cost measurements and dimensions they need.
Data Explorer is unique due to its explorative capabilities, which allow for the aggregation of complex data tailored to select cost measurements and dimensions, whether on a daily, weekly, or monthly basis. This level of granularity enables users to gain deeper insights and a more accurate understanding of their costs, ultimately empowering them to make more informed decisions.
Use cases
The Data Explorer feature can be utilized in various scenarios, including but not limited to:
Assess Resource IDs, allowing for an in-depth look at various aspects such as usage types and product families, enhanced by the ability to filter results according to specific services.
Track and analyze the cost-related aspects of sub-services, offering insights into the utilization of resources like S3 storage and NAT gateway, measured in hours and gigabytes.
Identify untagged data, providing essential information to guide the tagging process, which is crucial for improved data management and categorization within an organization.
Measurements vs. dimensions
Measurements- Numerical values or quantitative data used to represent a particular aspect of the analyzed data. These can include numbers such as cost types, and usage.
Dimensions- Categories or classifications that help organize and group related measurements. These can include the service type, region, or any tags. Dimensions provide context to the measurements and allow for deeper analysis and understanding of the data. Dimensions affect the level of detail in the view.
Navigate to Data Explorer in the navigation bar on the left side of the console.
Click New Data Explorer. The Create new explorer side tab appears.
Name: Provide a name for your report.
Description (Optional): Include a description for your report.
Time Frame: Define the relevant dates for your report data.
Filters (Optional): Filter the new Data Explorer using the MegaBill components, such as services, cost centers, or Virtual Tags.
Time Column (Optional): Choose a time column from day, week, or month.
Measurements (Optional): Define measurements-
Specify aggregation activities for the report, choosing from Sum, Average, Minimum, or Maximum.
Select the cost type. See Cost Type definitions.
To add multiple measurements, click ‘+’.
Dimensions (Optional): Add dimensions to a new Data Explorer by using the MegaBill components, such as services, cost centers, or Virtual Tags.
Dimensional Analysis (Optional): Count the number of unique values within a specific dimension or count the total number of entries or occurrences within a dimension, including duplicates. For a full explanation, see the dimension analysis section.
Predefined queries: The Resource Normalized Runtime metric provides a measure of how long resources were operational within a specified timeframe and normalized according to the total hours in that timeframe. For a full explanation, see the predefined queries section.
Columns management (Optional): Reorder or rename selected fields as desired. Drag measurements up or down by clicking on the dots beside each measurement.
Order by- Set the order of the report based on selected measurements.
Click Save to generate the report. Once saved, the report will be displayed with all the chosen data.
In Dimension Analysis, two key concepts are used to gain insights into your data:
Count Distinct Dimensions: Counts the number of unique values within a specific dimension. Use Case #1: Analyzing user tags - Counting distinct dimensions shows how many unique tags exist across all resources. This helps you understand the diversity and categorization within that dimension. Use Case #2: Determine the distinct number of resources for each service per day- Identify the various values for each user tag and check the number of instance types for EC2/RDS or the number of regions per account.
Count Dimensions: Counts the total number of entries or occurrences within a dimension, including duplicates.
Note: This feature is supported for every dimension in Data Explorer and is available for all accounts.
To add dimensional analysis:
Select one of the following:
Count Dimensions - Count the values that are unique from one another based on what was selected above.
Count - Count all the values that have been selected.
Note: If you selected the same dimension as in the report, you will only receive one return per value.
Click Select Dimension. The Dimension window appears.
Mark the dimensions that you want to be used for the analysis and click Apply Group By.
Predefined queries are prebuilt, standardized queries designed to streamline data retrieval and analysis. Created to address common data needs or reporting requirements, they allow for quick access to specific data sets or insights without the need to craft complex queries from scratch.
The Resource Normalized Runtime metric measures the total operational time of resources within a specified timeframe, normalized against the total hours in that period. It is calculated by dividing the total running hours of all resources by the total number of hours in the timeframe.
Note: When grouping by date, each timeframe is set to 24 hours.
Formula:
Resource Normalized Runtime = Total Running Hours / Total Hours in Timeframe
Numerator (Total Running Hours): The cumulative sum of hours all queried resources were active during the specified timeframe.
Denominator (Total Hours in Timeframe): The total number of hours within the specified timeframe.
Note: When grouping by date, this is set to 24 hours.
Example Calculations:
Scenario 1: 5 Resources Over 3 Days
Date
Total Running Hours
Total Hours in Timeframe
Resource Normalized Runtime
2024-07-28
79
24
3.29
2024-07-29
85
24
3.54
2024-07-30
74
24
3.08
2024-07-28:
Total Running Hours: 79 hours (cumulative for all 5 resources)
Total Hours in Timeframe: 24 hours
Resource Normalized Runtime: 79 / 24 = 3.29
Scenario 2: 3 Resources Over 2 Days with Resource IDs
Date
Resource ID
Total Running Hours
Total Hours in Timeframe
Resource Normalized Runtime
2024-07-28
i-abc123
30
24
1.25
2024-07-28
i-def456
40
24
1.67
2024-07-29
i-ghi789
35
24
1.46
i-abc123:
Total Running Hours: 30 hours
Total Hours in Timeframe: 24 hours
Resource Normalized Runtime: 30 / 24 = 1.25
Scenario 3: 4 Resources Over 1 Day
Date
Total Running Hours
Total Hours in Timeframe
Resource Normalized Runtime
2024-08-01
24
24
1.00
2024-08-01:
Total Running Hours: 24 hours (cumulative for all resources running the entire day)
Total Hours in Timeframe: 24 hours
Resource Normalized Runtime: 24 / 24 = 1.00
Scenario 4: Aggregated Resources Over Multiple Days Without Date Column
Resource ID
Total Running Hours
Total Hours in Timeframe
Resource Normalized Runtime
i-abc123
120
240
0.50
i-def456
200
240
0.83
i-ghi789
160
240
0.67
i-jkl012
80
240
0.33
i-abc123:
Total Running Hours: 120 hours
Total Hours in Timeframe: 240 hours (10 days x 24 hours/day)
Resource Normalized Runtime: 120 / 240 = 0.50
Scenario 5: Aggregated Total Running Hours Without Date or Resource ID
Total Running Hours
Total Hours in Timeframe
Resource Normalized Runtime
2100
600
3.50
2400
600
4.00
3000
600
5.00
1800
600
3.00
Entry 1:
Total Running Hours: 2100 hours
Total Hours in Timeframe: 600 hours
Resource Normalized Runtime: 2100 / 600 = 3.50
Resource Normalized Runtime vCPU: This metric calculates the total normalized vCPU runtime used by resources over a specified timeframe. It is determined by multiplying the total running hours of each resource by its vCPU count and dividing by the total number of hours in the timeframe.
Note: When grouping by date, each time frame is set to 24 hours.
Formula:
Resource Normalized Runtime vCPU = Σ (Running Hours x vCPU) / Total Hours in Timeframe
Numerator: The cumulative sum of the product of running hours and vCPU count for each resource.
Denominator (Total Hours in Timeframe): The total number of hours within the specified timeframe. When grouping by date, this is set to 24 hours.
Example Calculations:
Scenario 1: Multiple Resources with vCPUs Grouped by Day
Date
Resource ID
vCPU
Running Hours
Normalized Runtime vCPU
2024-07-28
i-12345678
5
24
5.00
2024-07-28
i-12345677
6
12
3.00
2024-07-28
i-12345676
3
16
2.00
2024-07-28
i-12345675
2
17
1.42
2024-07-28
i-12345674
16
20
13.33
i-12345678:
Calculation: (5 x 24) / 24 = 5.00
The resource consumed 5.00 vCPU days.
Scenario 2: Mixed vCPU Resources Over 2 Days
Date
Resource ID
vCPU
Running Hours
Normalized Runtime vCPU
2024-07-28
i-98765432
8
18
6.00
2024-07-28
i-87654321
4
10
1.67
2024-07-29
i-76543210
2
5
0.42
i-98765432:
Calculation: (8 x 18) / 24 = 6.00
The resource consumed 6.00 vCPU days.
Scenario 3: Aggregated vCPU Resources Over Multiple Days
Date
Resource ID
vCPU
Running Hours
Normalized Runtime vCPU
2024-07-30
i-55555555
10
40
16.67
2024-07-30
i-44444444
6
20
5.00
2024-07-31
i-33333333
3
15
1.88
i-55555555:
Calculation: (10 x 40) / 24 = 16.67
The resource consumed 16.67 vCPU days.
Scenario 4: vCPU Resources Without Date or Resource ID
vCPU
Running Hours
Total Hours in Timeframe
Normalized Runtime vCPU
8
200
600
2.67
4
150
600
1.00
6
240
600
2.40
Entry 1:
Calculation: (8 x 200) / 600 = 2.67
The resources consumed 2.67 vCPU days in the timeframe.
This metric calculates the total running hours of EBS resources within a specified timeframe and tracks the cumulative hours that they have been active.
Formula:
-EBS Running Hours = Sum of Running Hours for EBS Resources in a selected timeframe.
-Total Running Hours: The cumulative sum of hours that individual EBS resources were active within the selected timeframe.
- Per resource: The total hours for each resource are summed based on the timeframe and aggregation type.
- For grouped resources: When multiple resources are grouped, their running hours are summed together to give the total running hours.
Example Calculations:
Scenario 1: Single Resource Over 2 Days, Group by Day
Date
Total Running hours
2024-08-01
22
2024-08-02
18
For 2 days:
Total Running Hours for August 1: 22 hours
Total Running Hours for August 2: 18 hours
The total running hours over these two days for a single resource is 40 hours.
Scenario 2: 3 Resources Over 4 Days, Group by Day
Date
Total Running Hours
2024-09-05
65
2024-09-06
72
2024-09-07
80
2024-09-08
78
For 4 days with 3 resources:
Total Running Hours for September 5 for all 3 resources: 65 hours
Total Running Hours for September 6 for all 3 resources: 72 hours
Total Running Hours for September 7 for all 3 resources: 80 hours
Total Running Hours for September 8 for all 3 resources: 78 hours
The total running hours over these four days is 295.
Scenario 3: 5 Resources Over 1 Month (August)
Date Range
Total Running Hours
2024-08-01 to 2024-08-31
3,000 hours
The total running hours for August for all 5 resources is 3000 hours.
The S3 Number of Objects metric calculates the average number of objects stored in your S3 buckets from the last 24 hours of a selected timeframe. This metric is derived from CloudWatch data and helps monitor object count trends in your S3 buckets, providing insights into storage usage.
Note: The resource ID will be automatically added to your Data Explorer report when selecting this predefined query.
Scenario 1: Number of Objects in S3 Buckets, Broken Down by Virtual Tag Teams
You want to create a report of the number of S3 objects in a bucket over April.
Note: The S3 Number of Objects metric calculates the average number of objects stored in your S3 buckets from the last 24 hours of the selected timeframe. For example, in the table below, Bucket001, Team A, had an average of 1,500,000 objects on April 30th.
Resource ID
Team
Number of S3 Objects
Bucket 001
Team A
1,500,000
Bucket 001
Team B
800,000
Bucket 002
Team A
1,100,000
Bucket 003
Team C
500,000
Bucke t003
Team B
900,000
Scenario 2: Number of Objects in S3 Buckets in Q1 2024, Broken Down by Month
You want to create a report for Q1 with object counts in monthly intervals to monitor the growth of data in your S3 buckets over time.
Resource ID
Month
Number of S3 Objects
Bucket 001
January
1,200,000
Bucket 002
January
900,000
Bucket 001
February
1,500,000
Bucket 003
February
600,000
Bucket 002
March
1,000,000
Bucket 003
March
800,000
Scenario 3: Number of Objects in S3 Buckets, Broken Down by Virtual Tag Teams and by Week
You want to create a report for the previous month with weekly intervals, showing the number of objects in each S3 bucket, broken down by virtual tag teams.
Resource ID
Team
Week
Number of S3 Objects
Bucket 10
Team A
Week 1
11,000
Bucket 10
Team A
Week 2
8,800
Bucket 10
Team B
Week 1
3,000
Bucket 20
Team A
Week 3
21,800
Bucket 20
Team B
Week 2
16,700
Question: What is the difference between the object count from CloudWatch and the object count from AWS CUR
Answer: The CUR alone does not provide object-level or detailed bucket insights without integrating other AWS tools such as S3 Storage Lens (with advanced metrics) or S3 Inventory. Without these, the CUR will only show aggregated S3 storage usage and costs.
Question: How can I get object count data per S3 bucket in the AWS CUR?
Answer: To obtain object count data per S3 bucket in the CUR, you need additional services:
- S3 Storage Lens with advanced metrics- This is required for detailed usage insights.
- S3 Inventory: Provides detailed reports at the object level but does not integrate directly into the CUR.
Edit, Duplicate, and Delete a Data Explorer.
Customize column display.
Cloud service:
Operator:
Values:
Note: Click to add another filter.
Select a Telemetry:
Click on the Virtual Tag you want to edit from the list and then click Edit Virtual Tag. The Edit virtual tag screen opens.
Click on the Virtual Tag you want to edit from the list and then click Duplicate Virtual Tag. The virtual tag is duplicated.
Click on the Virtual Tag you want to edit from the list and then click Delete Virtual Tag.
Click to add another dimensional analysis.
The Operate documentation in Finout offers detailed guidance on monitoring, managing, and maintaining your cloud infrastructure. Discover how to streamline operations, track real-time performance, and ensure reliability across teams and environments. This section provides the tools and best practices you need to stay in control of your cloud resources while optimizing efficiency and uptime.
Includes the following features:
The Finout API provides seamless access to powerful cloud cost management tools, enabling you to integrate, analyze, and optimize your cloud expenses. With endpoints for cost insights, tagging, forecasting, and more, the API empowers teams to automate workflows, track spending, and drive efficiency across their cloud environments.
The following APIs are available:
Finout offers the flexibility to build tailor-made dashboards specifically designed for cloud cost management purposes. Whether you need to track cost trends, analyze cost breakdowns, or monitor cost allocation across different projects or departments, our dashboard customization options have got you covered.
You can create personalized dashboards that cater to the unique requirements of various stakeholders, such as finance teams, IT managers, or executives. Our platform allows you to select from a variety of cost visualization widgets, charts, and forecasts to present cost data in a way that is most meaningful and actionable for you and your stakeholders.
Finout supports the following dashboard widgets:
Cost & Usage: Provides a consolidated view of your cloud services' spending and resource usage. It tracks cost data to analyze spending trends and visualizes usage patterns over time for efficient monitoring and analysis.
Unit Economics: The Unit Economics widget enables users to perform computations between cost and telemetry data, offering a comprehensive view of financial and operational metrics. It provides the ability to define and track business KPIs within the platform, helping businesses monitor performance and make informed decisions.
Text: Provides a space for adding custom text, notes, hyperlinks, or descriptions to your dashboard. This widget is useful for adding context, instructions, URLs, or annotations to your dashboard for better clarity and communication.
Budget: Helps you set and track budget targets for your cloud spending. It allows you to compare actual expenses against planned budgets and forecasts.
CostGuard: Integrates with the CostGuard feature to display insights and alerts on cost-saving opportunities. It highlights areas of potential waste, underutilized resources, and optimization recommendations to reduce cloud costs.
Governance: Designed to provide visibility into your cloud non-compliant costs and resources. This widget allows you to monitor tagging governance, ensuring all resources adhere to your organization's tagging policies and analyze non-compliant costs by Virtual Tags, teams, environments, or cost centers.
Financial Plans: Enables you to plan your company's annual financial plan and expected budgets so that you can allocate accordingly by planning, managing, and monitoring cloud spending. This ensures alignment with business goals and prevents budget overruns. Financial plans enable you to create a budget per unit cost to address the fluctuation of unit-based pricing and cloud spend.
Anomalies: Detects and displays unusual patterns or spikes in your cloud spending or resource usage. This widget is coming soon.
By building tailor-made dashboards for cloud cost management, you can gain better visibility into cost drivers, identify cost-saving opportunities, and make informed decisions to optimize your cloud expenditure. Whether you want to track cost by service, region, or specific resource groups, our customizable dashboards empower you to focus on the metrics and insights that matter most to your organization.
In Finout, navigate to Dashboards.
The Dashboard page appears.
Click on Create Dashboard.
The Create Dashboard page appears.
Click on Add Widget.
The Add Widget sidebar appears.
Choose a widget for your dashboard from a list of available templates or recently saved widgets. Choose from the following widgets:
Governance Go to the specific widget procedure to complete the dashboard setup.
Customize your dashboard to fit your unique needs and preferences. With customizable options, such as widgets, time parameters, and notifications, you can prioritize the most relevant information, creating a more focused and efficient dashboard. Whether you want to highlight key metrics, adjust layouts, or personalize the look and feel, customizing your dashboard empowers you to streamline data visualization and make better-informed decisions.
Simply enter a name that accurately reflects the purpose or content of your dashboard.
Click Add Widget at the top right of the screen.
Choose a widget for your dashboard from a list of available templates or recently saved widgets. Choose from the following widgets:
Governance Go to the specific widget procedure to complete the dashboard setup.
Define the timeframe and interval settings globally for the entire dashboard.
Important: Implementing a dashboard-wide timeframe or interval will override the settings of individual widgets. When these changes are made, you'll receive an alert. A detailed filter overview will also be available to show which widget settings have been affected.
Select the "X" next to the specified timeframe or interval. Once removed, the dashboard widgets will revert to their default settings.
After removing a setting, at any time, you can return to your prior configurations by selecting Back to dashboard settings.
To edit a widget:
Click on the three dots icon and click Edit Widget.
You are brought to the widget builder.
Make the necessary changes.
Note: See the widget types section for all the widget options.
Click on the three dots icon to reveal a dropdown menu of options and select the Duplicate Widget.
The widget is duplicated.
Click on the three dots icon to reveal a dropdown menu of options and select Remove from the dashboard. The widget is removed.
Export a widget to CSV
Click on the three dots icon and select Remove from dashboard.
The widget is removed.
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard. The Dashboard overview appears.
Edit the following fields:
Dashboard Name: Edit the name of your dashboard.
Default Timeframe and Interval:
Time Frame (optional): Select a default timeframe for your dashboard.
Note: Once saved, the chosen parameters will appear at the top of your dashboard.
Time Interval (optional): Select a default time interval for all widgets on your dashboard. Once saved, the chosen parameters will appear at the top of your dashboard.
Important: Implementing a dashboard-wide timeframe or interval will override the settings of individual widgets.
Enable ACL Permissions:
Note: This feature is coming soon
ACL permissions are disabled by default, meaning all users can view or edit based on their specific role or access. See Role-Based Access Control for more information.
Optionally enable ACL permissions to define read and write permissions on a dashboard for specific users and groups. Note: Enabling ACL on a dashboard overrides user role permissions, except for admins. Admins maintain read and write permissions to the dashboard. There are three modes with ACL permissions:
Public: Everyone in your organization has this permission to the object.
Private: Only admins have this permission to the object.
Shared: You must define users and/or groups.
5.Click Save. Your settings are saved.
With Finout, you can set up daily, weekly, or monthly reports based on your dashboards. These reports can be conveniently delivered to your email or shared as Slack messages.
To create a report for a specific dashboard, simply navigate to the dashboard view and click on the Subscribe button. This will initiate the process of setting up a report specifically tailored to that dashboard.
Enter a Report Name.
Enter a Report Description.
Select a dashboard.
In the Choose an endpoint, either select a Slack endpoint or enter an email address.
Select a Report time frame (Daily, Weekly, or Monthly) and the required number of days, weeks, or months.
Select the Interval (daily, weekly, or monthly). This defines how often the report will be sent.
For weekly, select the Day of the Week.
For monthly, select the Day of the Month.
Select the time to Send at and the Time Zone.
Click Save Report.
Under the Dashboard feature, you can access a list of your custom dashboards. You can clone or delete any custom dashboard. To do so, navigate to the dashboard list and click on the three dots for the dashboard you want to clone or delete.
Under the Dashboard feature, you can access a list of your custom dashboards. For any custom dashboard, you have the flexibility to clone or delete it. Simply click on the three dots icon to reveal the respective options.
Finout's cost and usage widgets are designed to assist in effectively monitoring cloud spending and service utilization. The cost widget offers insights into the financial aspects of your cloud services, enabling systematic tracking and analysis of expenditure over time. The usage widget facilitates the visualization of service consumption, aiding in the easy monitoring and analysis of usage patterns and trends.
To create a new cost and usage widget:
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard. The Dashboard overview appears.
Select Add widget. The Add Widget popup appears.
Choose Cost or Usage. The Cost or Usage widget builder appears.
Note: When editing an existing widget, you can reset any changes to revert to the last saved version by clicking Reset changes.
Data type selection: Choose which metric to display: Cost or Usage.
You can enable one of the following layers: Trend Projection or Computational.
Trend Projection Layer
Enables users to generate future-oriented estimations based on past and current data trends. This layer utilizes selected time frames to provide projected trends, helping in strategic planning and decision-making. Functionality:
Trend Identification: Based on the analysis of historical data, the trend line identifies the general direction of the data trend, using linear forecast method.
Forecasting: Using linear forecast algorithm, the trend line extrapolates future data points beyond the available dataset. It generates forecast of future values based on the observed trend, enabling users to anticipate future trends and plan accordingly.
Visualization: See the trend line alongside the actual data points in a visual form, making it easier to identify deviations from the trend and data-driven decisions.
Use cases:
Budget Projections: Users can leverage the trend projection layer to understand future cloud costs based on historical spending trends. By selecting relevant time frames, such as the past month, users can generate estimates of future cost trends and plan resource allocation more effectively.
Capacity Planning: Users can predict future resource utilization and capacity requirements. By analyzing past usage patterns and projecting trends forward, users can anticipate changes in demand, optimize resource allocation, avoid over-provisioning or under-provisioning, and ensure smooth operation of cloud environments.
Cost Optimization Strategies: Users can identify potential cost-saving opportunities by forecasting future cost trends. By analyzing historical cost data and projecting future spending patterns, users can proactively identify areas where cost optimization measures can be implemented. This includes optimizing resource utilization, rightsizing instances, leveraging reserved instances or savings plans, and adopting cost-effective pricing models. To enable a trend projection layer:
Note: This feature is Coming Soon.
Incremental - Represents the cost or usage for each individual period only (e.g., that day, week, or month), adding values from previous periods. Cumulative - Represents the total value accumulated up to that point.
Note: - The trend display is shown in addition to the selected timeframe in the widget. - The trend displays are shown in all visuals except for pie charts.
Computational Layer
The Computational layer allows you to add computation capabilities to define and track business KPIs by setting operators between metrics, enabling comparisons and calculations between costs and usages, or a combination of both. The results of these operations can be visualized directly within your widgets, providing a powerful means for custom analysis and deeper insights. Computations layer combinations: Cost and Cost:
Cost / Cost: Cost Ratio
Cost - Cost: Cost Difference
Cost + Cost: Cost Aggregation
Cost % Cost: Cost Percentage Difference
Usage and Usage:
Usage / Usage: Usage Ratio
Usage - Usage: Usage Difference
Usage + Usage: Usage Aggregation
Usage % Usage: Usage Percentage Difference
Cost and Usage:
Cost / Usage: Price per unit (e.g., dollars per CPU hour).
Usage and Cost:
Usage / Cost: Efficiency measure (e.g., CPU hours per dollar).
To enable a computational layer:
a)Click Computational. The computational layer popup appears.
b) Enter a name for the computational layer.
c) Choose the Cost /Usage computational data points: For Cost:
Choose the filters that you want to use.
Choose cost type. See Cost and Usage Types for an explanation of all the cost types.
For Usage:
Choose the filters that you want to use.
Choose usage and unit type. See Cost and Usage Types for an explanation of all the usage and unit types.
d)Click Save. You are brought back to the configuration page.
8. Widget Main Settings -
Note: The main settings are dynamically adapted based on the chosen widget type (cost/usage) and specialized layer (trend projection/computation layer configurations).
Customize the time frame and interval: Modify the time frame and time interval displayed in the widget to a different range.
Load from view : Select a created and saved view from the MegaBill to use its configuration.
Choose Filters : Select which cost data to view. When loading from view, the filters will be populated automatically.
Group By: Select value to group the cost/usage data by.
X-Axis grouping: For bar, or table visualization, decide whether the X-axis will show dates or values.
Daily Average: Toggle-on to view the daily average over time for Cost or Usage widgets in the bar and table visualizations. When looking at monthly and weekly reports, understanding the daily average cost over time is crucial as it uncovers spending trends that total cost can hide.
Note: - The default mode for visualizations shows the total cost or usage. - Showing the daily average is currently not supported when applying trend or computational layers.
9. Widget Advanced Settings -
Note: The advanced settings are dynamically adapted based on the chosen widget type (cost/usage) and specialized layer (trend projection/computation layer configurations).
Choose a cost type for the widget. See Cost Types and Usage for all of the cost types.
Provide a brief of your cost/usage widget. You can opt to display this description at the bottom of the widget.
10. Select a visualization type (bar, line, pie, table, or numeric) that best suits your cost/usage data.
Note: You can view the daily average over time in the bar and table visualizations.
Your widget is configured.
The Unit Economics widget in Finout is designed to help modern enterprises generate accurate unit economics by linking cloud costs directly to business outcomes. By performing computations between cost and telemetry data, users gain a comprehensive view of both financial and operational metrics. This powerful tool enables businesses to define and track key performance indicators (KPIs) within the platform, providing the insights needed to optimize cloud investments, forecast costs, and make informed decisions at scale.
In the era of advanced FinOps, where precise cost allocation is essential, the Unit Economics widget empowers users to align their cloud spending with business value. Whether tracking metrics like cost per transaction, cost per detection, or cost per document indexed, this widget enables businesses to evaluate profitability, optimize resource allocation, and ensure that cloud investments drive measurable outcomes.
By simplifying the complex task of breaking down costs by usage and aligning shared costs across departments, the Unit Economics widget offers enterprises a streamlined, automated approach to managing cloud spend effectively. To create a new unit economics widget:
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard. The Dashboard overview appears.
Select Add widget. The Add Widget popup appears.
Choose Unit Economics. The Unit Economic widget builder appears.
You can choose between a stand-alone Telemetry widget, or you can enable a specialized layer by clicking Unit Economics. The Unit Economics pop-up appears.
Unit Economics configuration:
Enter the widget name.
Cost:
Load View - Select a created and saved view from the MegaBill to use its configuration.
Filters
Group by
Choose a cost type: See Cost and Usage Types for an explanation of all cost types.
Telemetry: Telemetry refers to any data measurements that users intend to incorporate into Finout. This includes any metrics or data points that can be leveraged to enhance insights, enable monitoring, or assist in managing costs within the platform. See the Telemetry documentation for more information.
Telemetry name
Filters
Telemetry Group by: The Group By selection must match the Cost Group By. If the selections do not align, no data will be displayed.
Click Save. You are brought back to the configurations page.
Widget Main Settings -
Note: The main settings are dynamically adapted based on whether you have chosen the Telemetry or the Unit Economic specialized layer.
Customize the time frame and interval: Modify the time frame and time interval displayed in the widget to a different range.
Telemetry selection: Telemetry refers to any data measurements that users intend to incorporate into Finout. This includes any metrics or data points that can be leveraged to enhance insights, enable monitoring, or assist in managing costs within the platform. See the Telemetry documentation for more information.
Load from view: Select a created and saved view from the MegaBill to use its configuration.
Choose Filters: Select which cost data to view. When loading from view, the filters will be populated automatically.
Group By: Select a value to group the cost/usage data by.
X-Axis grouping: For bar or table visualization, decide whether the X-axis will show dates or values.
Widget Advanced Settings -
Note: The advanced settings are dynamically adapted based on whether you have chosen the Telemetry or the Unit Economic specialized layer.
Choose a cost type for the widget. See Cost Types and Usage for all of the cost types.
Scale Factor
Provide a brief of your cost/usage widget. You can opt to display this description at the bottom of the widget.
Select a visualization type (bar, line, pie, table, or numeric) that best suits your cost/usage data.
Click Save.
Your widget is configured.
Provides a space for adding custom text, notes, or descriptions to your dashboard. This widget is useful for adding context, instructions, or annotations to your dashboard for better clarity and communication.
To create a new text widget:
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard. The Dashboard overview appears.
Select Add Widget. The Add Widget popup appears.
The budget widget builder appears.
Type in the free text, choose a color and select an alignment and font size.
Click Save. The widget is created.
The Budget widget within Finout is a powerful tool designed to assist you in setting and monitoring budget targets for your cloud spending. This feature enables you to compare your actual expenses with your planned budgets and forecasts, providing a clear picture of your financial performance. By utilizing the budget widget, you can gain insights into how your spending aligns with your financial goals, identify areas where adjustments may be needed, and make informed decisions to optimize your cloud expenditure. For more information about budgets, refer to the main documentation.
To create a new budget widget:
Navigate to the Dashboard feature in the navigation bar.
Select Add widget and then choose Budget from the presented options.
From your list of created budgets, choose the one you want to use as the data source for your new widget.
The budget widget builder will be presented.
Budget selection (optional): You can opt to select a different budget for visualization if needed.
Metric selection: Determine which metrics (cost, budget, forecast) to display. You can select more than one metric.
Enable a visualization layer (optional). Budget Visualization Layers
In Finout widgets, users can enhance customization and insights with widget layers, allowing multiple dimensions of data analysis within a single widget. Widget layers offer discrete levels of data manipulation or visualization, representing various types of data interactions such as computational calculations, trend projections, or custom metrics creation. This enables complex and rich data analysis without needing multiple separate widgets.
Benefits of using the widget layers:
Enhanced customization: Tailor your widgets to show exactly what you need, from basic metrics to advanced computational analyses.
Deeper insights: By layering different types of data analysis, gain a nuanced understanding of your metrics and their interrelations.
Efficiency: Consolidate complex data views into single widgets, reducing clutter and improving dashboard readability.
Computational Layer
The Computational Layer allows for the creation of custom ratio metrics. This is achieved by performing mathematical operations, such as division, subtraction, or percentage calculations between any two data points you select. The results of these operations can be visualized directly within your widgets, providing a powerful means for custom analysis and deeper insights.
Functionality:
Build ratios: Combine different data sources to create meaningful ratios, such as cost-to-revenue, to monitor efficiency or other key performance indicators.
Customize metrics: Tailor new metrics that are not readily available, enabling you to analyze specific aspects of your data in a way that suits your unique business needs.
Visualize relationships: See the direct relationship between chosen data points in visual form, making it easier to draw conclusions and make data-driven decisions.
Use cases:
Budget analysis: Calculate and visualize cloud spending as a percentage of your total budget to assess how much of your resources are allocated to cloud services.
Operational efficiency: Create a metric that compares production output to labor hours to determine operational efficiency over time.
ROI tracking: Monitor the return on investment by comparing the revenue generated against the marketing spend for each campaign.
How to use the computational layer:
Choose the two data points you want to use; cost, budget, or forecast.
Select the mathematical operation (division, subtraction, percentage) to apply to your chosen data points.
Once your custom metric is created, it will appear as an additional visualization in your widget.
Example:
You can create a metric to represent cloud spending as a percentage of the total budget. This visualization provides valuable insights by highlighting the proportion of your budget allocated to cloud expenses, helping you evaluate spending efficiency and guide strategic budgeting decisions.
Widget main settings:
Date customization (optional): If needed, you can adjust the budget timeframe displayed in the widget to a different range.
Filter on budget values: Select specific budget values to display. You have the option to group by these values.
X-Axis configuration: For bar, line, or table widgets, decide whether the X-axis will show dates or values. For Numeric widgets, select either sum or average as the calculation method.
Operator configuration: For the numeric widget, select the operator; either the sum of the entire chosen budget date or the average of the chosen budget date.
Widget advanced settings: -Choose a cost type to show the actual cost. -Provide a brief of your budget widget. You can opt to display this description at the bottom of the widget.
Select a visualization type (bar, line, pie, table, or numeric) that best suits your cost/usage data.
Click Save. Your widget is configured.
The CostGuard widget in Finout is a powerful tool designed to help you identify cost optimization opportunities within your infrastructure. Now part of your dashboards, it is positioned as a key focus within your top interest points, making it easier than ever to streamline cost savings. This feature integrates seamlessly with MegaBill, enabling you to pinpoint areas ripe for cost savings across Virtual Tags, teams, environments, and cost centers in one centralized location. By using the CostGuard widget, you can streamline your cost optimization efforts, making it easy to identify and act on potential savings, ultimately maximizing your cloud investment. For more information about CostGuard, refer to the main documentation.
Note: Data is updated on a daily basis.
To create a new CostGuard widget:
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard.
The Dashboard overview appears.
Select Add Widget and then choose CostGuard from the presented options.
The CostGuard widget builder is presented.
Choose a metric:
Waste - historical waste based on internal and external data, wasted cost according to the scan.
Scanned cost - total cost of resources eligible to be scanned for waste (will always have a higher value than the waste value of the same resource).
Both - You can select both metrics.
Note: If both metrics are selected, the pie view won’t be applicable.
Widget main settings:
Select Scans - Select the scans that you would like to drill down:
All (Default)
Idle
Rightsizing
Specific scans from the dropdown
Note: If more than 5 scans are selected, the preview will display data in a "sampled" view. The complete data calculation will occur only upon saving the feature, with an information indicator appearing to notify you.
Load View - Select a created and saved view from the MegaBill to use its configuration.
Choose Filters - Choose filters from the filter component window.
Group By - Choose from the following:
Note: Group By is not supported for the numeric view.
None
MegaBill key
Note: The default MB group is automatically applied by property.
Scans - Group by the scan name.
Resources - Group by the resource ID.
Set time resolution - Daily or Yearly.
Note: This is relevant only for the "Waste" metric type. When The "Scanned Cost" metric type is selected, the "time resolution" is disabled.
Operator - Sum or Average.
Note: This is relevant only to numeric visualization type.
Transpose Table - Change the order of the columns and rows. The rows will become the column keys.
Note: -By default, the transpose table is off. -This is only relevant to table visualization types.
Widget advanced settings:
Add a description to the widget.
Select a visualization type (pie, table, or numeric) that best suits your widget.
Click Save.
Your widget is configured.
The Governance widget is designed to provide visibility into your cloud non-compliant costs and resources. This widget allows you to monitor tagging governance, ensuring all resources adhere to your organization's tagging policies and analyze non-compliant costs by Virtual Tags, teams, environments, or cost centers. For more information about Governance, refer to the main documentation.
To create a new Governance widget:
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard. The Dashboard overview appears.
Select Add Widget. The Add Widget popup appears.
The governance widget builder appears.
Choose a metric: Non-compliant cost - the cost of the non-compliant resources
Widget main settings:
Select Policies - Select the policies that you would like to drill down:
All (Default)
Untagged Resources
Unapproved Values
Specific policies from the dropdown
Note: If more than 5 policies are selected, the preview will display data in a "sampled" view. The complete data calculation will occur only upon saving the feature, and an information indicator will appear to notify you.
Load from View - Select a created and saved view from the MegaBill to use its configuration.
Choose Filters - Choose filters from the filter component window.
Group By - Choose from the following:
Note: Group By is not supported for the numeric view.
None
MegaBill key
Note: The default MB group is automatically applied by property.
Policies - Group by the policy name.
Resources - Group by the resource ID.
Transpose Table - Change the order of the columns and rows. The rows will become the column keys.
Widget advanced settings:
Add a description to the widget.
Select a visualization type (pie, table, or numeric) that best suits your widget.
Table visualization shows:
The chosen metric data
% Non-compliant cost - The percentage of non-compliant costs for the last day of data.
Non-compliant resources - The number of non-compliant resources for the last day of data.
% Non-compliant resources - The percentage of non-compliant resources for the last day of data.
Click Save. Your widget is configured.
Note: This widget will not be impacted by the dashboard's time filter, the widget shows results of the last day of data.
The Financial Plan widget in Finout is a powerful tool to help you set and track financial goals for your cloud spending. It allows you to compare actual expenses with planned budgets and run rates, offering a clear view of your financial progress. With the Financial Plan widget, you can monitor how your spending aligns with your targets, pinpoint areas needing adjustments, and make data-driven decisions to optimize your cloud costs.
For more information about the financial plans, refer to the main documentation.
To create a new financial plan widget:
In Finout, navigate to Dashboards. A list of your dashboards appears.
Select the relevant dashboard. The Dashboard overview appears.
Select Add Widget. The Add Widget popup appears.
Click Financial Plan. The Financial Plan Widget Creation popup appears.
Select a financial plan and click Continue. The financial plan widget builder appears.
Metric selection: Determine which metrics to display. You can select more than one metric. Available metrics:
Note: You can select multiple metrics at the same time.
Budget (selected by default) - displays the financial plan budget values
Cost (Selected by default) - displays the actual cost
Forecast - displays the forecast that was generated during the financial plan creation.
Run Rate - displays the end of month estimated cost based on the past 30 days of spending.
Enable a specialization layer (optional).
Computational layer
The Computational Layer allows for the creation of custom ratio metrics. This is achieved by performing mathematical operations, such as division, subtraction, or percentage calculations between any two data points you select. The results of these operations can be visualized directly within your widgets, providing a powerful means for custom analysis and deeper insights.
With the computational layer you can combine different data sources to create meaningful ratios, such as cost-to-revenue, to monitor efficiency or other key performance indicators
How to use the computational layer:
Choose the two data points you want to use; cost, budget, run rate or forecast.
Select the mathematical operation (division, subtraction, percentage) to apply to your chosen data points.
Once your custom metric is created, it will appear as an additional visualization in your widget.
Example: You can create a metric to represent cloud spending as a percentage of the total budget. This visualization provides valuable insights by highlighting the proportion of your budget allocated to cloud expenses, helping you evaluate spending efficiency and guide strategic budgeting decisions.
Date customization (optional): adjust the financial plan date and interval displayed in the widget.
Filter on financial plan values: Select specific financial plan values to display. You have the option to group by these values.
Group-By financial Plan keys - Allows to group by any of the keys of the financial plan. Once enabled, you must select the key for the group by
X-Axis configuration: For bar, line, or table widgets, decide whether the X-axis will show dates by default.
For Numeric widgets, select either sum or average as the calculation method.
Widget advanced settings: -Choose a cost type to show the actual cost. -Provide a brief of your financial plan widget. You can opt to display this description at the bottom of the widget.
Select a visualization type (bar, line, table, or numeric) that best suits your cost/usage data.
Click Save. Your widget is configured.
Using Finout’s budgeting, you’ll be able to govern cloud expenditure by aligning IT, finance, and business teams, ensuring efficient resource use while managing and forecasting cloud costs.
Finout’s platform provides cost governance for your entire cloud infrastructure, offering native integrations such as AWS, GCP, Azure, Datadog, Databricks, Kubernetes, and Snowflake.
Using Finout's Virtual Tagging, you can allocate budgets with unparalleled precision. Our hierarchical budgeting feature allows organizations to design budgets mirroring their organizational structure, empowering each stakeholder with the appropriate funds to manage
In addition, you can get real-time budget alerts on Slack, ensuring teams can respond instantly. Finout’s budgeting enables a smooth comparison between your budgeted plans and your actual costs.
Types of Budgeting - Basic and Hierarchical
Basic Budgeting in FinOps is a simplified approach, setting a general budget with limited detail and flexibility, ideal for smaller entities.
Hierarchical Budgeting, on the other hand, provides a structured, multi-level budgeting system, allowing detailed resource allocation and expense tracking suitable for larger or more complex organizations.
The basic budget is the option to create a one-level basic budget by choosing a specific budget level based on a selected time period and group value.
Navigate to Budgets.
Click New budget.
3. Click Basic Budget.
4. Enter a Budget name.
5. Select a time period. This defines the time period you can set the budget for. If you select the current year or quarter, the budget amount is automatically set for all the months in the period.
6. Select the required Budget group option. The total cost of the previous month appears for each of the budgets, assisting you when specifying the budgets. Enter the budget amount per budget group value.
7. (Optional) Select Auto populate budget to populate the budget values with the total cost of the previous month.
8. (Optional) Turn off (or on) to hide (or show) a budget group.
9. The Budget alert is automatically turned on. Should the forecasted cost surpass the set budget, an alert is generated and displayed on the Anomaly page. If necessary, you have the option to deactivate the budget alert.
10. Click Create. The budget is created for the specified period.
Select Budgets.
Click the required Basic budget.
In the required budget line item, click the three dots and select Edit inline.
4. Make the required changes, pressing TAB to jump to the next cell (or SHIFT+TAB to return to the previous cell).
5. Click Save or press Enter.
6. To view the budget on the MegaBill page, click and select Go To MegaBill. This enables you to further investigate the cost of the budget and see more granular data related to the budget.
The hierarchy budget is used when you want to generate a budget where actual cost, forecasting, and budget set are all aggregations of a lower level in the org chart. For example, a “group” budget is based on aggregations of all teams composing them. Hierarchy budget allows this kind of creation and is completely based on your Virtual tags mappings.
These layers collectively form the overall company-wide budget. This allows role-based budget review and analysis of the different layers of a budget. For example, a specific team leader wants to review the budget for the specific application layer within the company-wide Hierarchy budget.
Important: For the Hierarchy budget level values to match, the cost mapping is based on the virtual tags mappings of the base budget. So only rules that are using the basic budget rules would be used.
Select Budgets.
Click New budget.
Click Hierarchy Budget.
Enter a Budget name.
Select the required Budget group (Virtual Tags) option- Which Virtual Tags are essential for creating the Hierarchy budget?
Select the required Base budget.
After selecting the relevant budget group and base budget values, a preview will appear, showcasing representative sample data.
The Budget alert is enabled by default. Should the forecasted cost surpass the set budget, an alert will be generated and displayed on the Anomaly page. If necessary, you have the option to deactivate the budget alert.
Click Create.
The Dashboard offers a comprehensive overview of the budget data for your chosen period and specific budget line items, presenting a visual representation and detailed insights into these budgetary components.
You can view the actual cost versus the budget, and see how your expected budget behaves vs. your actual cost.
Actual Cost - The accumulated actual cost for the selected period and budget line items. Presented as an amount ($) and as a percentage of the actual cost out of the total actual cost of the entire budget for the selected filters.
Budget - The accumulated budget for the selected period and budget line items. Presented as an amount ($) and as a percentage of the budget out of the total budget for the selected filters.
Gap (Delta) - The difference between the Actual Cost and Budget for the selected period and budget line items. This appears in green when there is a surplus, and in red when the actual cost exceeds the budget.
The Budget Dashboard includes four different widgets:
Budget vs. actual by months.
Budget vs. actual by values chosen in the filters.
Budget values performance displays the actual versus the budgeted amounts, highlighting the difference for each budget line item.
Month-over-month actual cost trends showcases the fluctuations in actual costs month-over-month trends during the chosen timeframe.
In the budget overview screen, the budget amount is compared to the forecasted cost, highlighting the difference, the delta:
A green display indicates a surplus.
A red display signifies when the forecasted cost exceeds the budget.
The forecast represents the projected actual cost by the end of the month.
Click on a budget entry to examine and adjust monthly allocations.
Click on the values in any of the budget periods to drill down further and view a graph of the budget versus the actual cost, with the forecast projected to month end. In this example, the forecast exceeds the budget around the 21st of the month.
To change the budget period, select an option from the drop-down list.
To filter by budget line items, click and select the required values.
The forecast is the projected actual cost to month end. For the current month, you can view the budget versus the actual cost to date and forecast (projected) cost to month end. The lines intersect if the actual or forecast exceeds the budget.
Select Budgets.
Choose the required budget.
In any of the budget line items, click the required month. In this example, the forecast exceeds the budget towards the end of the month.
4. You can hover over a point in the graph to view the date and forecast, actual cost, or budget.
Select Budgets.
In the required budget, click the three dots and select Remove.
Click Delete. The budget is deleted.
When a budget alert is triggered it appears under your Anomalies.
Navigate to Anomalies in the navigation bar.
To view the budget alerts, from Alert Type, select Budget.
To view the MegaBill associated with the budget, click Investigate.
To delete a budget anomaly, click Delete and then click Yes.
To leave a comment on a budget anomaly, click Comment, enter a comment, and then click Save.
For any questions, please feel free to contact the Finout team at support@finout.io.
The My Commitments feature in Finout provides you with an in-depth view of your cloud commitments.
Note: As of now, this feature supports AWS Reserved Instance commitment types, but eventually it will include all major cloud vendors' commitments. For a deeper dive into these commitments, refer to the main documentation here.
As cloud services continue to grow and diversify, users are frequently navigating numerous commitments, each having its distinct terms. Given this increasing complexity, there's a significant demand for a straightforward, efficient tool that allows users to manage these commitments while optimizing costs and usage.
Key Features:
Monitor all the plans you've opted for from your cloud provider in one place. Currently, Finout supports AWS, but GCP will be coming soon.
Gain a high-level view of your coverage % and your utilization % of all your plans by type or any filter in the MegaBill.
Ability to dig deeper and examine coverage and utilization for each specific plan, refining your cloud management strategy.
This feature is split into three main sections:
The Executive summary provides a concise overview of your AWS commitments, equipping you with key metrics to manage your cloud commitments expenditure optimally.
Note: This is only supported for EC2 instances.
Filters and time frame settings: Filter the executive summary using specific AWS cost data or Virtual Tags. Additionally, select a relevant timeframe for the overview.
Coverage: Represents the percentage of costs saved by not paying on-demand pricing.
It includes the following resources:
EC2 - Compute
RDS - Compute
RDS - Other
ElastiCache
Redshift
AmazonDynamoDB
DynamoDB - On Demand Read
DynamoDB - On Demand Write
DynamoDB - Provisioned Write
DynamoDB - Provisioned Read
SageMaker
Amazon Elastic MapReduce
AmazonES
Lambda
EC2 Container Service - Fargate Memory
EC2 Container Service - Fargate Compute. Why is the coverage rate in Finout different from AWS? Finout focuses on fewer resources and calculates coverage rates using only Reserved Instances (RIs), while AWS includes both RIs and Savings Plans (SPs) across a broader range of resources.
Note: AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level.
Utilization: Indicates how much of your commitments you are using. For example, if the utilization is 80%, it means that you are not using 20% of your commitments for the given period. This is only for EC2 Reserved Instances (RIs).
Savings: The total amount you've saved during the chosen period by using your commitments. This is only for EC2 Reserved Instances (RIs).
Waste: Represents the cost of unused commitments during the set period and filter. To reduce this wastage, you can use Finout’s automated commitment management (learn more about CostGuard). This is only for EC2 Reserved Instances (RIs).
Coverage: Your daily coverage status is based on the selected filters and timeframe. Use the Group By feature to further break down the coverage status according to specific groups by values.
Reserved instance utilization: Showcases the utilization rate of reserved instances, helping identify underutilized commitments.
Hourly usage by purchase options: Your hourly commitment usage versus the on-demand usage, illustrates the frequency at which your commitments are utilized.
On-demand cost by family type: The on-demand costs break down based on the instance family, helping identify potential areas for improved coverage and savings.
To filter by specific cost data, customize your view by selecting specific AWS cost metrics of interest.
To filter by timeframe, select the duration for the data representation.
To group by, and organize data using various aspects of the Finout MegaBill for a targeted review, such as Virtual Tags, cost centers, services, and more (read the full documentation on Finout’s MegaBill).
The Reserved Instances Commitments feature includes a detailed view of your Reserved Instances commitments, highlighting active RI purchases and their performance metrics.
Note: This is only supported for EC2 instances.
Plan ID: A unique identifier for each Reserved Instance.
Instance type: The specific type of Reserved Instance (e.g., m5.large, t3.nano).
Expiration: Date when the Reserved Instance term ends.
Utilization: A visual and percentage representation of how much of the reserved capacity usage.
Net savings: The savings gained by choosing a Reserved Instance over on-demand pricing. Additionally, AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level.
Underutilized waste: Costs for any unused reserved capacity.
Region: The AWS region of the Reserved Instance.
Operating system: The operating system associated with the Reserved Instance.
Reservation term: The duration of the reservation, typically one or three years.
Offering class: Type of Reserved Instance purchased, such as 'Standard' or 'Convertible'.
Payment option: The chosen payment method, such as 'no upfront', 'partial upfront', or 'all upfront'.
Units: Number of Reserved Instances in the commitment.
Increase utilization: Identify Reserved Instances with low usage and implement strategies to increase their utilization.
Renewal: Review expiring Reserved Instances and consider renewal options based on current and projected usage.
Reallocation: Strategically adjust workloads to better align with the specifications of your Reserved Instances to maximize their value and benefits.
The savings plan commitments view is designed to provide users with detailed insights into their active savings plans, helping you monitor and manage them effectively. Additionally, AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level.
In this view, you can filter the savings plans by type, Instance family type, term (1, 3 years), and purchase option (partial upfront, all upfront).
Note: This is only supported for EC2 instances.
Plan ID: A unique identifier for the savings plan.
Savings plan type: Displays the type of savings plan (e.g., Compute).
Instance type family: Shows the category of instances or services covered in the savings plan (if applicable).
Expiration: Indicates when the savings plan will end.
Utilization: Represents the percentage of the committed usage that has been consumed.
Net savings: Reflects the total cost savings achieved through the plan. Additionally, AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level.
Underutilized waste: The amount of financial waste due to underutilization of the committed plan.
Region: The geographical region where the savings plan is applicable.
Term: The duration for which the savings plan is active, typically noted in years or months.
Payment option: The payment method chosen for the savings plan, such as 'no upfront', 'partial upfront', or 'all upfront'.
Hourly commitment: The committed hourly cost as per the savings plan.
Total commitment: The total cost commitment over the term of the savings plan.
Organizations that manually purchase and manage commitments often struggle to align Reserved Instances (RIs) with fluctuating usage patterns, such as nightly spikes. They require hourly insights to compare on-demand usage and rates against RI cost and usage, enabling more accurate commitment management. This includes examining on-demand hourly patterns to identify opportunities for purchasing additional commitments and analyzing RI utilization for optimization of existing commitments.
With RI Explorer, users can track and compare hourly data on instances that are eligible for RI’s using purchase groups. Additionally, AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level.
Note: Purchase groups are collections of resources sharing the same instance family, region, and OS. These groups encompass all possible combinations within an AWS account based on utilized resources, regardless of their billing type (on-demand, RI, SP, etc.).
This granular data empowers organizations to manage manually purchased commitments more effectively and precisely, optimizing both usage and costs while also aiding in the purchase of new commitments.
Graph and metrics that display the cost or usage of RI’s per different purchase groups based on the chosen filters. These groups encompass all possible combinations within an AWS account based on utilized resources, regardless of their billing type (on-demand, RI, SP, etc.).
Note: Purchase groups are collections of resources sharing the same instance family, region, and OS.
Total Cost (per purchase group): This summarizes the cost for each group, regardless of billing type, within the selected period.
Total On-Demand Cost (per purchase group): This represents the total on-demand cost for each group during the filtered period.
Coverage Rate (per purchase group): Calculates the percentage of costs covered by commitments, excluding on-demand costs, for each group within the selected period.
RI Utilization Rate (per purchase group): Measures the percentage of Reserved Instance (RI) usage for each group within the selected period. Utilization indicates how effectively the purchased RIs are being used, helping you identify opportunities for optimization and ensuring commitments are fully leveraged.
On-Demand Baseline (per purchase group): Displays the greatest common denominator for on-demand cost and usage, providing a clear reference point for comparison. This can be used to purchase new commitments or expand existing ones.
Filters by choosing specific MegaBill keys. The chosen keys will affect the presented purchase groups
Time Filter: Choose the timeframe for displaying the data.
Note: The default is for the past seven days.
Choose to display the hourly data by your Cost or Usage.
Note: The default is cost.
Sort the groups by: Total Cost, Total On-Demand, Coverage Rate, RI Utilization, and On-Demand Baseline.
Redirects you to Megabill with the selected prepopulated filters.
How do Finout’s savings per plan calculations differ from AWS?
AWS calculates savings per commitment yearly, whereas Finout provides savings per commitment calculations on a daily level. This allows for more granular tracking and optimization of cloud costs in Finout.
What are the required permissions?
assumeRole
ce:GetReservationUtilization
ce:GetSavingsPlansUtilizationDetails
Note: You need to grant Finout permissions for each AWS payer account for which you want to have commitments in Finout.
What to do if I don’t have permissions?
Permission issues result in no data being displayed in the Reserved Instances Commitment tab.
An N/A appears under the Utilization metric on the RI Explorer tab.
How do I proceed if I don’t have permissions?
For those who utilized CloudFormation during the onboarding process, run the update function.
For manual onboarding, modify the JSON based on the onboarding process.
Every organization manages yearly budgets to plan annual spending. In cloud environments, every small change impacts cost, and it's essential to have the necessary budget data to foresee future costs and plan for your company's yearly budget. Managing cloud spending effectively involves addressing challenges such as uncontrolled costs due to pay-as-you-go models, lack of usage visibility, and complex pricing structures. Additionally, issues like difficulty in cost allocation, inefficient resource management, and decentralized governance further complicate cost management.
Finout’s solution enables you to plan your company's annual financial plan and expected budgets so that you can allocate accordingly by planning, managing, and monitoring cloud spending. This ensures alignment with business goals and prevents budget overruns. Financial plans enable you to create a budget per unit cost to address the fluctuation of unit-based pricing and cloud spend. For example, if your organization has numerous teams and groups that require budget management, you can utilize Finouts virtual tags to create a structured financial plan tailored to your organization and effectively manage the annual budget.
You will learn how to:
Create a Financial Plan - Configure your financial plan, arrange its hierarchy, and set up forecasting models.
Input Data to your Financial Plan - Add budget and forecast values via manual entry or bulk upload.
Manage your Financial Plan - Manage your financial plan by filtering and adding custom lines.
Start creating your financial plan by following the configuration, hierarchy, and forecast steps below.
Note: Only Admins can create a financial plan.
To add a financial plan:
In Finout, navigate to Financial Plans.
Click Add Financial Plan on the top right of the page. The Financial Plan Configuration window appears.
Configure your financial plan:
Financial plan name: Enter a financial plan name.
Financial plan duration: Select the duration of your financial plan by year.
Start period: Select the start period by year and month.
Financial plan cost type: Select a financial plan cost type. For more information, see Cost and Usage Types.
ACL permissions:
ACL permissions are disabled by default, meaning all users can view or edit based on their specific role or access. See Role-Based Access Control for more information.
Optionally enable ACL permissions to define read and write permissions on a financial plan for specific users and groups.
Note: Enabling ACL on an object overrides user role permissions, except for admins.
There are three modes with ACL permissions:
Public: Everyone in your organization has this permission to the object.
Private: Only admins have this permission to the object.
Shared: You must define users and/or groups.
Financial Plan Alert
Click Next. The configuration of your plan is completed. The next step is to structure the hierarchy of your plan.
Click Select Keys. The available keys appear for selection.
Select the desired keys and click Select.
Note: Financial plans support up to 1000 line items. Ensure that the selected keys do not exceed the 1000 line item limit.
The keys appear in the Financial Plan Keys & Hierarchy window.
You can arrange the keys by dragging and dropping each one. This order defines the hierarchy of the keys in the financial plan.
Note: Hierarchy order cannot be changed once the plan is created.
Under Financial Plan Cost Filters, click Filters. The filter component window appears.
Choose to include or exclude the costs of specific items on the financial plan.
Note: Filters cannot be changed once the plan is created.
Hover over a key to include or exclude it in the plan:
Mark an item to include it in the plan.
Exclude an item to remove its cost from the row.
Click Apply Filters.
Note: Excluded filters will still appear in the financial plan's line items, but their costs will be filtered out.
The financial plan hierarchy is complete.
Note: You can skip this step if you prefer to use your own forecasts.
Click Select Period. The period dropdown appears.
You can select one or more months from the past twelve months to establish the baseline forecast for the initial month of your financial plan. This baseline is the initial set of data that serves as a reference point for projecting the first month of each line item in the financial plan.
View the displayed preview, which includes three line items from your new plan and their forecast for the first month.
Forecast Algorithm Overview: The Finout forecasting algorithm leverages historical data to predict future budgets in your financial plan. This algorithm calculates month-over-month percentage fluctuations for each line item over the past twelve months to establish a pattern of seasonal changes. These historical percentage changes are then applied to forecast each month in the upcoming financial plan. Example: It is August 2024, and you are planning for 2025. You want Finout to create a forecast using the baseline reference period from June and July 2024. 1)Baseline Calculation Finout takes the average value of the months chosen to establish the baseline. - Line Item: Sub Service - June 2024 Amount: $9,500 - July 2024 Amount: $10,500 - Baseline: $10,000 2)Monthly Growth Rate Calculation Finout calculates the month-over-month percentage change for each line item based on historical data of the past twelve months (August 2023 to July 2024).
Each month in the forecasted year (2025) is projected using the percentage fluctuation from the corresponding month of the previous year to factor in seasonality. For Example: The percentage fluctuations for line X in the previous year were: - February 2024 : 6% fluctuation - March 2024: 5% fluctuation - April 2024: 4% fluctuation - This continues per month for the rest of the year 3) Forecast Calculation Finout uses the Baseline and percentage fluctuations to project a forecast for 2025 for each line item.
Note: January’s forecast is the calculated baseline.
For Example: The forecast for line X will be calculated as follows: - January 2025 Forecast: $10,000 (Baseline) - February 2025 Forecast: $10,000 + ($10,000 x 6%) = $10,600 - March 2025 Forecast: $10,600 + ($10,600 X 5%) = $11,130 - April 2025 Forcast: $11,130 + ($11,130 x 4%) = $11,575.2 - This calculation is repeated for each subsequent month, using the updated value from the previous month and applying the growth rate to build a complete forecast for 2025.
You can optionally choose the following actions:
Toggle on Automatically fill in the budget values with the forecast numbers.
Click Skip and Create if you would like to add your own forecasts and not rely on Finouts’s automatic forecasting. This is available only if no reference period was selected.
Note: Forecast configuration cannot be changed once the plan is created, but you can always override a forecast and manually add your own forecasts. See Input Data to Financial Plans.
Click Next. The forecast navigation is complete.
The monthly run rate of a given line item projects the estimated end-of-month cost based on the past 30 days of spending.
Run rate alerts notify you when the monthly run rate for any given line item exceeds its budgeted amount, allowing you to make timely adjustments to stay on target with your financial goals. The run rate alerts are evaluated every week, four times a month: on the 4th, the 11th, the 18th, and the 25th.
Enabling Run Rate Alerts is toggled on by default. Toggle off to disable it.
Enable the toggle "Define endpoints per line item" to send alerts to distinct endpoints for each line item. A new Endpoint column appears. Choose an endpoint for each line.
When at least one of the selected keys in the financial plan is a Virtual Tag, you can choose which key's endpoint metadata to use. Endpoint metadata is populated automatically. To learn more about setting endpoint metadata for a virtual tag, see Virtual Tag Metadata API.
Choose a default endpoint for financial plan alerts. If not set, alerts will default to the endpoint configured in the anomalies settings.
You can choose to disable alerts to a specific value.
Note: The run rate alert configuration can be edited after creating a financial plan.
Note: Alerts are sent to configured endpoints based on user configurations and will also appear in the Anomalies Feed, where users can review and access them directly.
Click Create. Your financial plan is created.
After creating your financial plan, you can add budget and forecast values in the following ways:
Inline edit - Manually insert the necessary data per line item.
Bulk upload - Bulk upload data using a CSV. API for this feature is coming soon.
Note: Only an Admin can bulk upload.
Edit budgets in a line item - Editing budgets in a line item within a financial plan allows you to update and manage the financial allocations for specific entries or distribute them evenly throughout each month.
By default, only admins have access to edit financial plans. You can provide edit permissions for users and groups in the following two ways:
Define group permissions by using Virtual Tag Value Metadata API
While all users have read permissions, you can specify who has permission to edit a particular line item within a financial plan. This can be done by determining who can edit line items in a financial plan using your account groups. To use the groups in a financial plan, you need to set group metadata on the values of the lowest virtual tag in your financial plan hierarchy.
Once groups are defined based on the values of the lowest virtual tag, you need to sync your plan to reflect those changes. Once done, only users in the group associated with the line item can edit the line. See Virtual Tag Metadata API. Example: Suppose you have two groups—Group 1 and Group 2.
1) Define Groups: Enrich your virtual tag values with group metadata as follows:
Data is associated with Group 1.
App is associated with Group 2.
2) Set Permissions:
Only users in Group 1 or admins can edit lines associated with Data.
Only users in Group 2 or admins can edit lines associated with App.
Note: You can only view custom metadata added to a value of the lowest virtual tag in your hierarchy.
ACL Permissions
ACL permissions are disabled by default, meaning all users can view, and only admins can edit. You can optionally enable ACL permissions to define read and write permissions on a financial plan for specific users and groups.
Note: Enabling ACL on an object overrides user role and group permissions, except for admins.
Public: Everyone in your organization has this permission to the object.
Private: Only admins have this permission to the object.
Shared: You must define users and/or groups.
To enable ACL permissions:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Toggle on Enable ACL Permissions.
Select one of the three modes in ACL permissions:
Public: Everyone in your organization has this permission to the object.
Private: Only admins have this permission to the object.
Shared: You must define users and/or groups.
Click Save. Your Permissions are updated.
Inline editing enables you to add budget values by manually inserting the necessary data into your financial plan.
To enter edit mode within the financial plan:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Click the rows that you want to edit.
Make your changes and click Apply. Your plan is updated.
Bulk upload data by uploading a CSV to your financial plan. API for this feature is coming soon.
Note: Only an Admin can bulk upload.
To bulk upload data to your financial plan:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Note: The download will only show what is in the current view. You can filter the view to customize the downloaded CSV file.
Enter the budget and forecast values in the downloaded CSV file.
Important: - Financial plans support up to 1000 line items. - Ensure your data matches the downloaded CSV template. - Use full numerical values (Ex: 10,000, not 10K). - In the type column, indicate if the line is custom or not. - In the Status column, indicate whether the line item is ignored or included. - If you want to add a custom line, make sure to mark it as custom in the type column.
Import the CSV file to Finout by clicking Import CSV File. The Import CSV File window appears.
Upload the CSV file.
Note: The values uploaded in the CSV file will override any existing budgets and forecast values. Cost and delta values are not updated.
Click Update. The data from the CSV has been updated in your financial plan.
Various errors can prevent a successful upload of CSV files to financial plans. The following table describes common CSV import errors and solutions to resolve them. By understanding these error messages and their solutions, you can troubleshoot any issue and ensure a smoother import process.
Upload Error Reason
Error Solution
Some cells in your file that are supposed to contain numerical values for budgets or forecasts have text instead.
Ensure that all these cells have only numbers.
The column headers in your uploaded file do not match the headers in the Financial Plan.
Check and ensure that the headers are identical.
The months provided in your file are not within the range specified in the financial plan.
Adjust the months to fall within the correct range.
Some numbers in your file are not in full numerical format.
Ensure that all numbers are fully displayed and formatted correctly.
A custom line item you are trying to upload already exists in the Financial Plan.
Remove or rename the duplicate item.
A line item appears more than once in your CSV file.
A line item appears more than once in your CSV file. Ensure that all line items are unique.
A month is listed more than once in your CSV file.
Each month should be unique and only appear once.
A custom line item is not marked as "Custom" in the Type column.
Ensure that custom items are correctly labeled in the Type column.
Some line items in the Type column are not specified as default or custom.
All line items in the Type column must be either default or custom. Correct the Type column to include only these two options.
Your uploaded file is empty or lacks the necessary data.
Ensure that the file contains the required information.
The file you are trying to upload is too large.
Reduce the file size to within the 2MB limit.
You are trying to upload multiple files simultaneously.
Only one file can be uploaded at a time.
The file type you are trying to upload is not allowed.
Ensure that the file type is in CSV format.
File reading has failed.
Try uploading the file again.
An unknown error has occurred.
Try uploading the file again.
All the line items in your uploaded file are custom.
Change the format of the key cells in the Excel file to a string instead of a number.
Adding new custom line items would exceed the maximum limit of 1,000 line items per plan, preventing the upload.
Ensure that your financial plan does not exceed the 1000 line items limit.
Editing budgets in a line item within a financial plan allows you to update and manage the financial allocations for specific entries or distribute them evenly throughout each month. This ensures that your plan remains accurate and up-to-date.
Note: Updated budgets will override existing budget values.
A budget can be split in two ways:
Split Manually - Manually enter the monthly budget.
Split Evenly - The budget amount of the whole line item will be divided equally across the financial plan period.
To manually split budgets in a line item:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Under the Updated Budget column, enter your updated budget values.
Click Save. The Confirm updates popup appears.
Note: Updated budgets will override existing budget values.
Click Apply. Your new budgets are updated.
To evenly split budgets in a line item:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Click the Spilt Evenly tab.
In Total Budget, enter the total budget for the line you want to be evenly divided across each month.
Optionally press Calculate to see the budget amounts in the Updated Budget column.
Click Save. The Confirm updates popup appears.
Note: Updated budgets will override existing budget values.
Click Apply. Your new budgets are updated.
Managing your financial plan in a streamlined and efficient way by using three key tabs. Utilize these tabs to effectively manage your financial plan and ensure that it is accurate, comprehensive, and aligned with your financial goals.
Financial Plan Details: This is where you manage the budgets and forecasts for your financial plan. You can apply various filters to focus on particular data sets, add custom line items to account for unique or anticipated future expenses, and sync your financial data to ensure all data is up-to-date. This level of detail ensures that your financial plan is comprehensive and tailored to your specific needs.
Dashboard: The dashboard provides a visual representation of your financial plan through widgets that display actual costs and budgets. This view allows you to quickly assess your financial status at a glance, identify any discrepancies between planned and actual expenditures, and make informed decisions based on real-time data. The visual nature of the dashboard makes it easier to understand complex financial information and track your progress.
Plan Completion Rate: This view helps you track the percentage of line items with budget values in your financial plans. By monitoring the completion rate, you can ensure that all necessary items are accounted for and budgeted. This view is essential for maintaining the accuracy and completeness of your financial plan, as it highlights any areas that may need attention or adjustments.
Financial plan details enable you to dive into the specifics of your financial plan. You can apply various filters to focus on particular data sets, add custom line items to account for unique or anticipated future expenses, and sync your financial data to ensure everything is up-to-date. This level of detail ensures that your financial plan is comprehensive and tailored to your specific needs.
Each month in the financial plan details tab consists of the following five columns:
Budget: Represents the financial allocation for a specific month for each line item. It outlines the financial targets set for the selected month, which helps guide financial planning and budgeting.
Forecast: The Finout forecasting algorithm leverages historical data to predict future budgets in your financial plan.
Actual Cost: Reflects the total expenditures accumulated over month and for the applied filters, providing a real-time view of how much has been spent during the specified timeframe.
Run Rate: Projects the estimated end-of-month cost based on the past 30 days of spending. It allows users to monitor whether their projected spend for the month will exceed or stay within budget, providing actionable insights to adjust usage or allocations and ensure better financial management throughout the month.
How the Calculation Works:
- The total cost from the past 30 days is used to estimate the spending trend.
- This trend is then projected forward for the remaining days in the current month, estimating the total expected spend by month-end.
- Once a month ends, the run rate shows the actual end-of-month spend. Example: Suppose a company's total spend for the past 30 days is $45,000. If today is the 20th day of a month with 31 days, then there are 11 days remaining. The total spend for this month is $43,500.
Calculate Daily Average Spend: $45,000/30=$1,500
Estimate Spend for the Remaining Days of the Month: $1,500×11=$16,500
Calculate Total Projected Spend by Month-End: $43,500+$16,500=$60,000
According to the run rate, the estimated end-of-month spend will be $60,000. This projection helps you monitor whether you are on track to stay within the budget or if adjustments are needed.
Delta: Indicates the difference between the budget and run rate for the month and filters. This column helps assess whether you are expected to end the month over or under the allocated budget, enabling quick identification of financial variances.
Search Bar - Free search using keywords to find specific information.
Time frame - Filter for specific months, quarters, halves, or years.
Key Filters - Filter keys that you chose in the configuration process. Keys operate based on cascade filtering and ensure that filters are progressively refined according to the hierarchy established during configuration. When filtering for a specific department, users will only see the relevant groups in the filters. Selecting a department will show only the applicable group names. Example: Imagine the financial plan hierarchy is structured as follows:
Department TLV
NYC
Group Names
If you filter by a specific Department, you will only see the groups within that department (TLV and NYC). If you select TLV, you will only see the following group names in the filter:
TLV Department
Data
Core
This hierarchical approach simplifies filtering data by ensuring that each step is more focused and manageable.
Settings - View and edit your financial plan configurations. See Edit Financial Plan Settings.
Aggregate By - You can aggregate the data by keys you chose in the configuration process.
Export - Download a CSV file of the current view.
Import - Import Data to your financial plans. See Input Data to Financial Plans.
Add a Custom Line Item - Custom line items let you add rows not included in the automatic setup based on your chosen keys. This allows you to anticipate future relevance and budget for these items as part of your financial plan. See Input Custom Line Items.
Note: Custom line items cannot be added if the plan has reached the 1,000 line limit.
Duplicate Plan - Duplicate your financial plan with all its settings and configurations and use it as a basis for making a new customized plan. If a sync is required, you can update the plan by duplicating it. See Duplicate your Financial Plan.
Columns Management - Choose which columns to show or hide.
Show Deltas - Choose to show or hide Delta columns.
Show Actual Costs- Choose to show or hide Actual Cost columns.
Show Forecasts- Choose to show or hide Forecast columns.
Show Run Rates - Choose to show or hide the run rate column.
Show Only Lines with Missing Budgets - Filter for missing budgets only.
Show Only Custom Lines - Filter for customs lines only.
Show Ignored Line Items - Ignore individual or multiple line items to ensure they are not part of your plan.
Edit Budgets in a Line Item - Editing budgets in a line item within a financial plan allows you to update and manage the financial allocations for specific entries or distribute them evenly throughout each month. See Edit Budgets in a Line Item.
Ignore Line Items - Ignore individual or multiple line items to ensure they are not part of your plan. See Ignore Line Items.
Comment on a Line Item - Commenting on a line item lets you add notes, feedback, or explanations directly to individual budget entries within a financial plan. See Comment on a Line Item.
Custom line items allow you to add rows not included in the automatic setup based on your chosen keys. You may add a custom line if you anticipate its relevance in the future and want to budget for it as part of your financial plan.
To add custom line items:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Note: Financial plans support up to 1000 line items. You cannot add custom line items if you have already reached this limit.
Select values for the keys or add your own values, then click Add Line Item.
Note: When adding your own values, you can choose to add values to one or all of the keys.
To show only custom line items:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Toggle off Show Only Custom Lines to return to the full financial plan list.
Ignore individual or multiple line items to ensure they are not part of your plan. The line item is not deleted, but its data will not be included in the financial plan calculation.
Note: Only Admins can ignore items, view ignored items, and reinclude them into the plan.
To ignore one line item:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
In your financial plan, find the line item you want to ignore and toggle it off. The line item and its data are ignored.
Note: Ignored lines are not shown in the view.
To ignore multiple line items:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
In your financial plan, find line items you want to ignore. Mark the checkbox at the beginning of each line item. The Change Status bar appears at the bottom of the financial plan.
Click Change Status. A dropdown appears.
Choose to Ignore the chosen line items. The line items are ignored.
Note: Ignored lines are not shown in the view.
To show ignored line items:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Commenting on a line item enables you to add notes, feedback, or explanations directly to individual line items within a financial plan, facilitating clear communication and better financial management.
To comment on a line item:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Write a comment and then click Save. Your comment is saved.
To edit a comment:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Make your changes to the comment and click Save.
To delete a comment on a line item:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Click Delete. The Delete this comment popup appears.
Click Delete. The comment is deleted.
Edit your plan settings to optimize functionality and meet specific objectives efficiently.
To edit plan settings:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
You can edit the following:
Financial plan name: Enter a financial plan name.
ACL permissions:
ACL permissions are disabled by default, meaning all users can view or edit based on their specific role or access. See Role-Based Access Control for more information.
Optionally enable ACL permissions to define read and write permissions on a financial plan for specific users and groups.
Note: Enabling ACL on an object overrides user role permissions, except for admins.
There are three modes with ACL permissions:
Public: Everyone in your organization has this permission to the object.
Private: Only admins have this permission to the object.
Shared: You must define users and/or groups.
Financial Plan Alert: This feature is coming soon.
Click Save. Your changes are implemented into the plan.
Edit your run rate alerts to notify you when the monthly run rate for any given line item exceeds its budgeted amount, allowing you to make timely adjustments to stay on target with your financial goals. To edit you run rate alert:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Click the Run Rate Alert tab.
Toggle on Enable Run Rate Alert and follow the steps in Run Rate Alerts to edit the alert.
Changes made to virtual tags or Megabill keys can alter the keys that define your financial plan. If the values or the metadata of the virtual tag keys that define this financial plan have changed, a ‘Sync required’ icon will appear. Duplicate your financial plan to enable a sync with all the new key values.
Note:
Only Admins can duplicate or synd financial plans.
Financial plans support up to 1,000 line items. If syncing would cause the plan to exceed this limit, it will not proceed.
To sync your financial plan:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Mark Duplicate and include recent updates; optionally add a new name and click Duplicate. Your financial plan is duplicated and synced.
Sync FAQ:
Question: Why does my financial plan require a sync, and what causes it to be out of sync?
Answer: Changes to virtual tags can alter the line items defined in your financial plan. If a financial plan's virtual tags values or metadata have been changed, a ‘Sync required’ icon will appear, indicating that the plan needs to be updated.
Question: What happens to a line item after a sync if its virtual tag value has been deleted?
Answer: After the sync, the old line item will still appear with the budget value, and the cost will stop populating. For example, if a virtual tag value is removed, the associated line item will no longer accrue costs but will remain visible in the plan.
Question: What happens when renaming a virtual tag value?
Answer: When you rename a virtual tag, a ‘Sync required’ icon will appear, indicating that the plan needs updating. To sync with the new name, you must duplicate your financial plan. After duplicating, the old value will remain, and a new entry will be added for the new name.
Question: Can I remove a line item entry that is not relevant anymore? Scenario:
You have a financial plan with the following keys: - Org - Team - App After syncing, you notice two line items in the financial plan: - Org 1 - Team A - App A (old entry) - Org 1 - Team B - App A (new entry) I want to remove the old entry and only keep the new one. Answer: You can ignore an old line item by toggling it off. The line item data will not be deleted, but its data will not be included in the financial plan calculation. See Input Custom Line Items.
Duplicate your financial plan with all its settings and configurations and use it as a basis for making a new customized plan. This approach saves time and streamlines your workflow, making revising projects, adapting to new scenarios, or optimizing processes more efficient.
Note: Only Admins can duplicate financial plans.
To duplicate your plan:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Choose a financial plan. You are brought to the Financial Plan Details tab.
Add a new name and click Duplicate. The plan is duplicated.
To delete your financial plan:
Navigate to Financial Plans. You are brought to the Financial Plans list.
Click Delete. The Financial Plan is deleted.
The dashboard view provides a visual representation of your financial plan through widgets that display actual costs and budgets. This view allows you to quickly assess your financial status at a glance, identify any discrepancies between planned and actual expenditures, and make informed decisions based on real-time data. The dashboard's visual nature makes it easier to understand complex financial information and track your progress.
Time frame - Filter for specific months, quarters, halves, or years.
Key Filters - Filter keys that you chose in the configuration process.
Aggregate By - You can aggregate the data by keys you chose in the configuration process.
Cost Summary: This enables you to compare actual spending against budgeted targets, track performance, and make informed adjustments to stay within financial goals. This widget includes: -Actual Cost: The total accumulated expenditures for the selected period and filters. It provides insight into how much has been spent within the specified timeframe. -Budget: This displays the total accumulated budgeted amount for the same period and filters. It represents the financial targets set for the selected timeframe. -Delta: Highlights the difference between Actual Cost and Budget for the specified period and filters. This metric indicates whether spending is over or under budget, helping to identify variances and assess financial performance.
The Budget vs Actual (by date) - Provides a visual comparison of your planned budget against actual expenditures over a specified time period. This widget lets you track your financial performance and identify discrepancies between your projected budget and real spending.
The Budget vs Actual (by value) - Provides a visual comparison of your planned budget against actual expenditures per value. This widget lets you track your financial performance and identify discrepancies between your projected budget and real spending per value.
Budget Value Performance—This widget provides a clear overview of your budgets per value by displaying three key metrics: cost, budget, and delta. It shows actual expenditures (cost), the planned, budgeted amount (budget), and the variance between them (delta). This widget lets you track and compare your spending against your financial targets per value, helping you identify discrepancies and make informed adjustments to stay aligned with your budget and financial goals.
Actual Costs Trend - Displays the ratio between the cost of the current month and the cost of the previous month. Tracking these ratios allows you to observe trends and patterns in your spending over time. By visualizing these monthly ratios, you can easily identify periods of significant increases or decreases in spending, assess financial performance, and make data-driven decisions to manage your budget more effectively.
The Plan Completion Rate tab allows you to track the percentage of line items with budget values in their financial plans. This enables you to monitor the status of budgeted line items per quarter. By monitoring the completion rate, users can ensure that all necessary items are accounted for and budgeted, maintaining the accuracy and completeness of their financial plan. This feature provides a clear view of financial planning progress and highlights any areas needing attention or adjustments.
Completion Rate Calculation
The completion rate is calculated using the following formula:
Search Bar - Free search using keywords to find specific information.
Time frame - Filter for specific months, quarters, halves, or years.
Key Filters - Filter keys that you chose in the configuration process.
The keys operate based on cascade filtering and ensure that filters are progressively refined according to the hierarchy established during configuration.
When filtering for a specific department, users will only see the relevant groups in the filters. Selecting a department will show only the applicable group names.
Example: Imagine the financial plan hierarchy is structured as follows:
Department
TLV
NYC
Group Names
If you filter by a specific Department, you will only see the groups within that department. If you select TLV, you will see the following group names in the filter:
TLV Department:
Data
Core
This hierarchical approach simplifies filtering data by ensuring that each step is more focused and manageable.
Aggregate By - You can aggregate the data by keys you chose in the configuration process.
Status Indicators - The completion status percentage of your financial plan is visually represented with colors according to the following thresholds:
Green: 85% - 100%
Yellow: 50% - 90%
Red: 0% - 50%
Once a financial plan is created, you can add custom columns to the financial plan by enriching the virtual tag values with metadata using the Virtual Tag Metadata API.
Note: You can only view custom metadata added to a value of the lowest virtual tag in your hierarchy.
Use Case Example:
Your current virtual tag and values:
You have created a financial plan with a “Dev Teams” virtual tag. This Virtual tag contains the following Values:
Infrastructure
Legacy App
Core
Data
You want to add a new column with metadata for relevant value:
Add Dave as an Owner to the Data value of this virtual tag.
This is done by adding Custom Metadata to the value of the Dev Team virtual tag by using the Virtual Tag Metadata API.
Note: After updating metadata for each value via API, you must sync your plan in order to view the custom metadata column in the financial plan.
Result: A new column appears (Owner) with custom metadata (Dave) attached to a particular virtual tag value (“Data” value of the virtual tag “Dev Teams”).
Custom Column Components
The custom columns feature is configured based on the following components:
Virtual tags - The virtual tag chosen during your financial plan setup.
Virtual tag values - The values in the virtual tag.
Custom metadata - Custom metadata that you want to attach to a particular virtual tag value.
Finout's CostGuard module provides actionable cost optimization insights. CostGuard scans surface idle resources, rightsizing opportunities, and offers commitment purchase recommendations. In order to do this, CostGuard needs read only permissions to certain metrics. The role created during the standard AWS cost data integration has the necessary permissions to perform CostGuard scans and discover linked accounts within the master payer account. However, to run CostGuard scans for resources within linked accounts, you need to create a CloudFormation StackSet that applies the necessary configurations across all linked accounts. This onboarding procedure assumes that the payer AWS account has been onboarded. If it has not, please go through that procedure first as per the instructions in Connect to AWS.
This procedure is relevant for AWS Multi accounts.
Open the AWS CloudFormation console.
Choose StackSet then select Create StackSet. The Specify StackSet details step appears.
For existing Finout AWS integrations: On the Specify template page choose Template is ready, select Amazon S3 URL, specify the following URL, and then click Next.
https://finout-public-assets.s3.amazonaws.com/FinoutMetricsReadOnlyRole.json
Specify a name for the CloudFormation stack (e.g. finout-readonly-role
), add a description, add the External ID in the Parameters section that was provided by Finout, and click Next.
The Configure StackSet options step appears.
Set the Execution configuration to Active in the Configure stackSet options page and click Next.
Specify us-east-1 for the region, set the Deployment options, then click Next.
Acknowledge the IAM notice and click Submit on the Review page to launch the new stack.
Once the StackSets is complete, you can view one of the stacks from the Stack instances and copy the new role ARN from the Outputs tab.
Share the role of ARN with Finout Support.
Use the following JSON file to add permissions manually to your accounts:
The latest IAM policy with details about each statement can be found below.
Note: Finout applies a validation process on IAM policies applied per account, so please make sure to contact us before modifying the policy on your own.
This policy allows Finout read-only permission to Cloudwatch metrics - these are crucial for all recommendations provided by CostGuard (Idle and Rightsizing recommendations).
This section of the policy allows CostGuard to provide recommendations for unattached EBS volumes.
This section allows CostGuard to provide recommendations on all your accounts in the organization.
Finout’s CostGuard is a powerful tool for identifying areas within your infrastructure that are ripe for cost optimization. As cost optimization is always a high priority, CostGuard provides a comprehensive solution that is seamlessly integrated with the MegaBill.
With CostGuard, you can easily identify cost optimization opportunities that are relevant for your Virtual Tags, different teams, environments, and cost centers - All in one centralized location. This makes it easier than ever to streamline your cost optimization efforts and achieve maximum savings.
Moreover, CostGuard continuously scans your resources and costs and identifies potential cost-saving opportunities across a range of use cases. With this feature, you have everything you need to optimize your costs and improve your bottom line:
Almost every organization has resources that were provisioned but are no longer in use. Forgetting to switch off these Idle resources eats away at your tech budget.
Resources that are in use may be underutilized and exceed your current workload performance and capacity requirements. Rightsizing means that you can downsize these resources without compromising on your service levels.
Identifying resources that are regularly in use helps to identify potential savings that can be had by signing up for savings plans. The Commitment to using a resource for a specific amount over the agreed period can safely be made based on the CostGuard scans.
Finout helps guard against resource wastage and provides you with quick access to potential savings. You can drill down into the various scan reports to view a list of the resources that require tweaking to actualize the specific savings. CostGuard gives you the information, and the confidence, to modify your resourcing and save money.
The CostGuard feature is available out of the box and generally requires no configuration. If you need additional scans, please contact Finout.
The following potential cost savings are tracked automatically:
Cost Center
Use Case
Scan Name
AWS
Commitment
EC2 - Compute Commitment
EC2 - Compute Commitment
Idle
EBS - Idle
EC2 - Idle
ElastiCache - Idle
ELB - Idle
RDS - Idle
S3 Idle - Bucket (Requests)
Rightsizing
EBS - gp2
EC2 - Rightsizing
RDS - Rightsizing
Kubernetes
Rightsizing
K8s - CronJob
K8s - DaemonSet
K8s - Deployment
K8s - ReplicaSet
K8s - StatefulSet
GCP - VM
GCP-CloudSQL
GCP - Persistent Disk
GCP-Snapshot
Rightsizing
GCP - VM
DataDog-Custom Metric
DataDog-Logs - idle (Debug)
Snowflake
Rightsizing
Snowflake - Warehouse (Coming Soon)
Select CostGuard.
(Optional) Apply the required Filters.
(Optional) Select whether to view the type of potential savings: Idle, Rightsizing, or Commitment.
(Optional) Select the required Group By option.
To download a list of the potential savings, click and Download CSV. A list of the potential grouped monthly savings and the number of resources per group is downloaded.
To download a table of the monthly scans, in the Scans area, click Download CSV. A list of the monthly scans, with the scan names, cost centers, use cases, potential savings per scan, and number of resources per scan, is downloaded.
To view a specific scan, in the Scans pane, click on the scan report.
The key information appears at the top of the scan report, with the detailed resource information listed in the table below.
Select CostGuard.
Select the required cost scan in the Scans pane.
(Optional) Apply the required Filters.
(Optional) Click Additional Columns, select the required columns, and click Apply.
To sort the resources table, click on the required column name. Click again to sort in reverse order.
To view resources with a specific status, click the required status button. For more information on statuses see How to manage the resource status.
To return to viewing all resources, click All Resources.
Apply any required column viewing options. These column viewing options do not affect the exported cost scan.
You can export the cost scan with the applied filters, visible columns, selected resource status, and in the visible sort order.
Select CostGuard.
Select the required cost scan in the Scans pane.
(Optional) Apply the required Filters.
(Optional) Click Additional Columns, select the required columns, and click Apply.
To view resources with a specific status, click the required status button.
To sort the resources table, click on the required column name. Click again to sort in reverse order.
Click the download icon. A CSV file is downloaded.
You can create a link to a scan report. The link is copied to the clipboard.
Select CostGuard.
Select the required cost scan in the Scans pane.
Click Generate Report. The link is sent to the clipboard.
You can manage the status of each of the resources, allowing you to track whether or not you are working on it, have dismissed it, or are done. A resource starts with a New status. This can be updated to Working on it, Dismissed, or Done. You can view a list of all the resources that you are working on.
CostGuard Statuses:
New - This resource was identified today as applicable for the scan's recommendation, but the recommendation has not been implemented and remains unresolved.
Working on it - The recommendation for this resource is currently being implemented.
Done - The recommendation has been implemented for the resource.
Dismissed - The recommendation for the resource was identified by the user as irrelevant. When applying this status, the resource's recommendation will be archived and removed from the table unless filtering by this status.
The "dismissed" status applies only to the day it was dismissed.
If a recommendation is dismissed and later determined by Finout to be incompatible with the scan's threshold, it will no longer be applicable and will automatically be removed from CostGuard, like all other recommendations.
To manage CostGuard statuses:
Select CostGuard.
Select the required cost scan in the Scans pane.
Select a resource and select a Status from the dropdown.
Select one or more resources and then click Change status and select the required status.
To view a list of all the resources that you are working on, click To Do.
The Finout CostGuard scans help you set the correct allocation of resources for Kubernetes. For detailed information on how Finout calculates the cost of a Kubernetes K8 pod, see How Finout Calculates K8s Costs.
The report allows you to play “what-if” analysis and view the costs and savings if you were to lower the requested memory or CPU to the maximum usage or by 10% (P90) or 20% (P80).
1. Select CostGuard.
2. Scroll down to the list of scans, and click the Cost Center column to easily locate the Kubernetes scans.
3. Click on a K8s scan, for example, K8s - Deployment.
4. Click to select a report.
5. The report covers the period of the last 14 days and includes:
Cost and waste for the resource over the period.
Breakdown of the Memory and CPU usage (Max, Average, and Min) versus the current request over the period.
To view the impact of reducing the requested memory by 10% (P90) or 20% (P80), click P90 or P80. The New waste and Potential savings are updated.
To view the impact of selecting the maximum memory (as recorded in the past 14 days), click Max. The New waste and Potential savings are updated.
Similarly, to view the impact of changing the number of cores, click Max P90 or P80. The New waste and Potential savings are updated.
To view the CPU/memory ratio for the resource, click the information icon.
To copy the configuration with the selected changes, click Copy to copy the JSON snippet to the clipboard.
To use Finout's CostGuard for GCP, Finout needs access to your GCP resource's operational metrics.
Note: Finout uses a 'Monitoring Viewer' role - A read-only permissions role and will not access any sensitive data.
This guide assumes that your account is already integrated with GCP as a cost center and that Finout has access to your GCP billing data. If this is not the case, please refer to the GCP onboarding documentation.
The following steps provide instructions for granting Finout access to the necessary metrics, which will enable CostGuard to generate recommendations. The documentation is organized into two sections: one for onboarding an existing project and another for onboarding a new project.
Finout utilizes a GCP scoping project, granting it access to essential metrics across all relevant projects in your GCP account, with read-only permissions.
Note: A scoping project is a GCP project configured to access metric scopes from all projects that require monitoring.
You need to enable the Finout service account, which is responsible for monitoring your GCP billing, to access the metric scopes of the scoping project.
For this seamless integration, Finout has developed a Terraform script specifically designed for this purpose.
Specifically applicable to new project creation: The Terraform script initiates by creating a new project within your account, designated as the scoping project, following GCP's recommended practices.
Enabling monitoring API: It activates the Stackdriver Monitoring API for the newly created scoping project.
Binding Finout's billing service account to the scoping project: The script assigns the Finout billing service account to the scoping project with the 'Monitoring Viewer' role.
Linking monitored projects to the scoping project: It facilitates the binding of either all or selected projects in your account to the scoping project for monitoring purposes.
Granting Finout access to monitored projects: The script assigns the Finout billing service account to all monitored projects, including the scoping project, with the 'Compute Viewer' role.
Enabling compute engine API: It ensures the activation of the Compute Engine API for all monitored projects, which includes the scoping project as well.
Important: To run the Terraform script, the user must have an Editor role within GCP.
Clone Finout’s shared repository- git clone:
Execute git@github.com:finout-io/finout-onboarding.git to clone Finout’s shared repository.
Terraform script usage:
Use the following Terraform script: gcp/cost-guard/existing-project-onboarding
Edit the Terraform state file configuration:
Modify gcp-cost-guard-onboarding-existing-project/provider.tf file to save the Terraform state file.
Set up a bucket name:
In <BUCKET_NAME> input the name of the bucket for storing Terraform state files. If it does not exist, create a new bucket.
Configure env.tfvars:
Edit gcp-cost-guard-onboarding-existing-project/profiles/env.tfvars as follows:
Use an existing project as the “scoping project” and bind Finout service account to this project:
a. Edit the profiles/env.tfvars as follows:
b. Run the script with additional parameters:
<FINOUT_SERVICE_ACCOUNT> -Retrieve the Finout service account details. Learn how to here.
<SCOPING_PROJECT_ID> - Add the existing project ID. Learn how to here.
<ADD_MONITORED_PROJECTS> - Add monitored projects to the scoping project. The default value is ‘false’. If you intend to add new projects to the monitoring scope, please change the value to ‘true’ and continue to the section below.
<MONITORED_PROJECTS> - Specify which projects will be monitored:
If you wish to define all the organization projects as monitored projects - leave an empty list.
If you wish to define specific projects - fill the "Monitored projected" list with the specific project IDs.
Defining monitored projects in this list will not affect the current projects that are being monitored.
Run the Terraform script.
Validate that the integration is working correctly:
In the GCP Console, check the scoping project under IAM to ensure Finout's service account has the 'Monitoring Viewer' role.
Under Monitoring in the scoping project, verify that all intended projects are added to the Metric Scope.
Send the scoping project ID and account service to Finout.
Note: To send the project ID, please reach out to Finout's support team.
To bind the Finout service account to the scoping project using the Terraform script, we need to be provided with the service account principle:
Navigate to the Google Console.
Choose IAM & Admin.
Provide Finout’s service account principal.
Go to the GCP console to locate your project.
Copy its ID (project_id).
The script enables monitoring API (Stackdriver Monitoring API) for the scoping project.
Employ Finout’s service account with billing query permissions.
Adds 'Monitoring Viewer' role permissions to the desired project.
Binds projects as monitored to the scoping project, either fully or partially.
Links Finout's billing service account with the 'Compute Viewer' role to all monitored projects, including the scoping project.
Enables the compute engine API for all monitored projects, including the scoping project.
To run the Terraform script, you must have an Editor role.
Login to your GCP Cloud with gcloud auth application-default login.
Run the script with the following commands:
terraform init
terraform workspace select <workspace>
terraform apply -var-file "profiles/<environment>.tfvars"
New projects are not automatically added to the Finout scoping project.
After executing the script, you have the option to add more projects as monitored projects based on your preferred method:
If all the organization’s projects are to be monitored, leave the list empty and rerun the script. This will include any new projects automatically.
If specific projects are chosen, add their IDs to the “Monitored Projects” list.
Note: Projects not included will not be monitored.
Clone Finout’s shared repository- git clone: git clone git@github.com:finout-io/finout-onboarding.git
Terraform script usage:
Use the following Terraform script: gcp/cost-guard/new-project-onboarding
Edit the Terraform state file configuration:
Modify gcp-cost-guard-onboarding-new-project/provider.tf file to save the Terraform state file.
Set up a bucket name:
In <BUCKET_NAME> - Input the name of the bucket for storing Terraform state files. If it does not exist, create a new bucket.
Configure env.tfvars:
Edit gcp-cost-guard-onboarding-new-project/profiles/env.tfvars as follows:
Create a new “scoping project” and bind the Finout service account to this project:
a. Edit the profiles/env.tfvars as follows:
b. Run the script with additional parameters:
<FINOUT_SERVICE_ACCOUNT> - Retrieve the Finout service account details. Learn how to here.
<SCOPING_PROJECT_ID> - Add a new ID for the scoping project to be created. Default new project id: finout-scoping-project-xxxxxx.
<ORG_ID> - Retrieve the organization ID. Show me how.
<SCOPING_PROJECT_NAME> - Define a new name for the scoping project to be created. Default new project name: finout-scoping-project.
<MONITORED_PROJECTS> - Specify which projects will be monitored:
If you wish to define all the organization projects as monitored projects - leave an empty list.
If you wish to define specific projects - fill the "Monitored projected" list with the specific project IDs.
Run the Terraform script.
Validate that the integration is working correctly:
In the GCP Console, check the scoping project under IAM to ensure Finout's service account has the 'Monitoring Viewer' role.
Under Monitoring in the scoping project, verify that all intended projects are added to the Metric Scope.
Send the scoping project ID and account service to Finout.
Note: To send the project ID, please reach out to Finout's support team.
Important: This script is designed for onboarding one organization at a time. For multiple organizations, you will need to run the script separately for each organization requiring monitoring.
To bind the Finout service account to the scoping project using the Terraform script, we need to be provided with the service account principle:
Navigate to the Google Console.
Choose IAM & Admin.
Provide Finout’s service account principal (see attached screenshot).
In the Google console, click on the Google Cloud icon in the left upper corner.
Click on the organization name.
Copy the organization ID.
The script creates a new project as a scoping project.
Enables the monitoring API for the scoping project.
Employ Finout’s service account with billing query permissions.
Adds 'Monitoring Viewer' role permissions to the desired project.
Binds projects as monitored to the scoping project.
To run the Terraform script, you must have an Editor role within GCP.
Login to your GCP Cloud with gcloud auth application-default login
Run the script with the following commands:
terraform init
terraform workspace select <workspace>
terraform apply -var-file "profiles/<environment>.tfvars"
To access the metadata of resources, like underutilized persistent disks, the service account must have the 'Compute Viewer' role.
New projects are not automatically added to the Finout scoping project.
After executing the script, you have the option to add more projects as monitored projects based on your preferred method:
If all the organization's projects are to be monitored, leave the list empty and rerun the script. This will include any new projects automatically.
If specific projects are chosen, add their IDs to the “Monitored Projects” list.
Note: Projects not included will not be monitored.
cloudnotifications.activities.list
monitoring.alertPolicies.get
monitoring.alertPolicies.list
monitoring.dashboards.get
monitoring.dashboards.list
monitoring.groups.get
monitoring.groups.list
monitoring.metricDescriptors.get
monitoring.metricDescriptors.list
monitoring.monitoredResourceDescriptors.get
monitoring.monitoredResourceDescriptors.list
monitoring.notificationChannelDescriptors.get
monitoring.notificationChannelDescriptors.list
monitoring.notificationChannels.get
monitoring.notificationChannels.list
monitoring.publicWidgets.get
monitoring.publicWidgets.list
monitoring.services.get
monitoring.services.list
monitoring.slos.get
monitoring.slos.list
monitoring.snoozes.get
monitoring.snoozes.list
monitoring.timeSeries.list
monitoring.uptimeCheckConfigs.get
monitoring.uptimeCheckConfigs.list
opsconfigmonitoring.resourceMetadata.list
resourcemanager.projects.get
resourcemanager.projects.list
stackdriver.projects.get
stackdriver.resourceMetadata.list
compute.googleapis.com/instance/cpu/utilization
compute.googleapis.com/instance/network/received_bytes_count
compute.googleapis.com/instance/network/sent_bytes_count
cloudsql.googleapis.com/database/memory/usage
cloudsql.googleapis.com/database/network/connections
Finout's advanced algorithms analyze historical data to pinpoint cost anomalies within your MegaBill. Finout identifies both cost increases and decreases, allowing you to quickly investigate the reason for any deviations from your regular spending. In addition, you can monitor these anomalies within Finout or receive anomaly updates directly via Slack, MS Teams, ServiceNow (coming soon), or email.
For comprehensive tracking, Finout scans your most frequently used tags, services, cost centers, and virtual tags. Each newly created virtual tag includes an anomaly scan to ensure you get a holistic view of your data.
The following anomalies are tracked automatically:
AWS: Regions, Tags, Sub Service, Account Name, Entity Name, Charge Type, Instance Type
Azure: Service, Meter Region, Meter Sub Category, Service Family, Consumed Service
GCP: Project ID, Labels
Global: Cost Center
Kubernetes: deployment, demonset, k8s_namespace, cronjob, Pod Labels
SnowFlake: query_tag, table_name, cost type, warehouse_name, user name, account
DataDog: Product, organization, Sub-Product
All Virtual Tags
Differentiating between anomaly types:
Pre-defined anomalies: These are anomalies identified by Finout for significant cost groups and filters. You have the option to modify these to better fit your specific requirements. For guidance on customizing these anomalies, please see the manage anomalies section.
Custom anomalies: Customize your cloud cost anomaly detection to meet your team's unique needs. You can set your own rules, thresholds, and patterns to align with your specific cost management strategies. Custom anomalies offer the flexibility to pinpoint and tackle cost inconsistencies that are most pertinent to your team. For instructions on creating custom anomalies, refer to the create custom anomalies secton.
There are three main functions in Anomalies:
In the Anomalies Feed, you can see all of your anomalies and filter, investigate, and manage them.
Filters:
Timeframe
Anomaly threshold: Filter anomalies based on specific thresholds. For example: Set a threshold of over 20% will display all anomalies exceeding this limit.
Anomaly type: Select from pre-defined or custom anomaly types.
Cost center: Select a cost center.
Key: Select a Key.
Value: Select a value.
Search Anomalies: Use free text search to find anomalies based on various terms or descriptions.
Create Anomaly Alert: To create an Anomaly Alert, see Create Custom Anomalies.
Anomaly Settings: Add a default endpoint:
Choose a default endpoint and click Save.
Note: If a default endpoint has been created, all anomaly alerts will automatically be directed to that channel. Should you require a specific alert to be sent to an alternate endpoint, you can customize this preference by adjusting the settings of that particular alert in the edit anomaly section.
To delete a default endpoint:
Click X on the default endpoint you would like to delete.
Clear Anomalies Feed:
Important: Proceed with caution, this action will clear the whole anomalies feed. Clearing the feed will remove these notifications, and they won't be available for future reference.
Anomaly information: Information regarding a single Anomaly Alert.
Investigate: Clicking Investigate opens MegaBill in a new tab with the anomaly configuration (filters) already populated.
Delete an Anomaly:
Click Yes.
Add a Comment:
In the Anomalies Feed, click Add Comment in a select Anomaly.
Write a comment and click Save.
Create a Jira issue.
When setting up a custom anomaly alert in Finout, you have two choices: create a single anomaly for a particular cost dimension or generate multiple anomalies simultaneously with a single action.
Navigate to Anomalies.
Select Create Anomaly Alert.
Assign an Alert Name to your custom anomaly.
Under Alert Values, select a group of values and apply a cost filter to define the parameters of the anomaly detection scan.
Select View: Choose a view from a list of your created views.
Filters: Specify the anomaly using cost filters. For example, setting a filter for ‘us-east-1’ will create an anomaly for AWS services only within that region.
Group by: Select a MegaBill key, creating anomalies for all items within that group. For instance, selecting ‘AWS Services’ will generate anomalies for each AWS service.
Alert Type – Select your preferred cost type for each anomaly for more precise detection. Open the Cost Type dropdown to choose from available options. See Cost and Usage Types for a detailed description of different cost types.
Under Alert Thresholds, select the Sensitivity Threshold to specify the alert trigger based on either a percentage or a specific dollar amount.
Sensitivity Threshold: The sensitivity threshold in anomaly detection is designed to help you fine-tune when alerts are triggered. This threshold enables the definition of anomaly parameters based on your operational norms. Default settings include a $20 minimum for cost changes and a 20% deviation from average costs. To detect smaller fluctuations, you could reduce the dollar threshold below $20 or the percentage below 20%. Alternatively, to focus on more substantial anomalies, increase these thresholds above the default values. Adjust these settings to match the level of sensitivity that aligns with your monitoring needs and cost management strategy.
After defining your group and filters, the associated values will appear. You have the option to activate or deactivate each value, allowing you to refine the anomaly alert parameters, making sure it matches exactly what you're looking for.
A reference point indicating the average daily cost over the last 30 days is provided to guide your threshold setting, reflecting recent spending trends.
An explanatory sentence will provide clarity on the chosen anomaly alerting conditions.
Set an anomaly threshold for every value in the group.
When selecting to create a threshold for each value, you'll have the opportunity to specify the cost change and sensitivity threshold individually for each value.
Alert Endpoints - Easily integrate notifications via Slack, MS Teams, ServiceNow (coming soon), or Email. Select your desired endpoint, ensuring its configuration is completed beforehand, to start receiving anomaly alerts.
Set a default endpoint for this anomaly. If no endpoint is defined for a group-by value, the alert for that value will be sent to this default endpoint. If no default endpoint is set, the alert will be sent to the endpoint specified in the anomalies settings.
Select an endpoint :
Default endpoint - When the toggle is off, all alerts will be sent to the default endpoint you chose in step a.
Selected endpoints and Metadata endpoints -
Click Select Endpoint and add any additional endpoints to send the alert.
If you group by a virtual tag, it will automatically send Alerts to its associated Metadata endpoints.
Time Interval (Coming soon) - Select the time interval to monitor the anomaly.
Note:
Daily - Choosing a day means that an alert is triggered daily.
Weekly - A Week is a weekly alert that notifies you every Tuesday (when you have a full week).
The difference between "last week" and "last 7 days" lies in calculating the timeframes. "Last week" refers to the calendar week immediately before the current one. On the other hand, "last 7 days" refers to the prior 7 days from the selected date, regardless of the day of the week.
a. Define Evaluation Period - Set your preferred time period (Days or Weeks) to check for anomalies. For example, the last 5 days.
b. Set Comparison Period - This compares the total cost of the current period to the average total cost of several previous periods. For example: You choose 20 days (4 periods). This is compared to the current 5-day total cost to the average total cost of the previous 20 days. Use case -
You want to evaluate anomalies over a 2-day period compared to the previous 6 days:
Date: Assume today is August 22nd.
Evaluation Period: Calculates the total cost for the chosen evaluation period: The last 2 days (August 19-20).
Comparison Period: Calculates the average of the evaluation period (2 days) over the chosen comparison period: the preceding 6 days (August 12-18).
Alert: An alert is triggered if the time period cost of the evaluation period exceeds the average cost of the comparison period's total costs from the defined thresholds.
Seasonality Check - The Seasonality Check helps reduce false-positive anomaly alerts by recognizing recurring cost patterns. Instead of flagging every cost spike as an anomaly, it checks whether the increase follows a regular weekly or monthly trend before triggering an alert.
Note: Currently, daily seasonality is supported for an evaluation period of 1 to 6 days.
Weekday Seasonality
Compares the cost on a specific weekday (e.g., Monday) to the average cost of the same weekday over the past few weeks (e.g., the last 4 Mondays).
An alert is triggered only if the cost exceeds the expected range based on your alert settings.
Monthly Seasonality
Compares the cost on a specific date (e.g., the 1st of each month) to the average cost on the same date over the past few months (e.g., the last 4 months).
An alert is sent if the cost surpasses the historical trend beyond the defined threshold.
Click Save to create the anomaly.
After saving the anomaly, your anomaly will appear under the Manage Anomaly tab. This tab displays a comprehensive table of both custom-created and pre-defined anomalies generated by Finout.
Within the table, each anomaly entry provides:
Type: Custom anomaly or pre-defined
Threshold
Interval
Endpoint
Activated or deactivated: Indicating if the anomaly is activated or deactivated.
Deleting, Editing, or Duplicating an Anomaly
Navigate to Anomalies.
Select the Manage Anomalies tab.
Search for the relevant anomaly: Use the search bar for a direct query or apply filters to narrow down results.
Select (⋮) beside the relevant anomaly and choose either Edit alert, Delete alert, or Duplicate alert.
If you choose to duplicate, set a name for the duplicated anomaly and adjust all fields accordingly.
Note: Pre-defined anomalies can be customized to suit your needs. You have the flexibility to edit the group values by toggling them on or off, ensuring they meet your specific requirements.
When you modify a predefined anomaly, a new custom anomaly is created with the revised settings, and the original predefined anomaly is deactivated.
Why does the comparison period need to be a multiple of the evaluation period? The comparison period must be a multiple of the evaluation period to ensure consistency in calculations. This allows Finout to calculate the total cost of each evaluation period within the comparison period and determine an accurate average. For example, if your evaluation period is 3 days, the comparison period could be 9 days (3 evaluation periods) but not 10 days, ensuring reliable and consistent anomaly detection.
Why can’t I choose arbitrary intervals like 3 weeks compared to 4 weeks? To maintain accurate comparisons, the comparison period must align with the evaluation period to ensure equal, consistent time intervals. This alignment ensures anomalies are detected based on reliable averages derived from comparable time intervals.
CostGuard is part of Finout’s cost optimization suite that is responsible for generating cost-saving recommendations by continuously scanning your resources and your entire MegaBill, allowing you to identify and leverage potential cost-saving opportunities across various use cases.
CostGuard recommendations are divided into three different use cases:
Almost every organization has resources that were provisioned but are no longer in use. Forgetting to switch off these Idle resources eats away at your tech budget.
Identifying resources that are regularly in use helps to identify potential savings that can be had by signing up for savings plans. The Commitment to using a resource for a specific amount over the agreed period can safely be made based on the CostGuard scans.
Resources that are in use may be underutilized and exceed your current workload performance and capacity requirements. Rightsizing means that you can downsize these resources without compromising on your service levels.
When you select a CostGuard scan, you will find the query prominently displayed in the top right corner of the screen. This query is customized to your selection, reflecting the specific criteria and filters you have chosen. It serves as a concise summary of the scan's parameters, allowing you to review and verify that the scan aligns with your objectives.
Moreover, the query provides you with valuable insights by presenting all relevant resources identified within the past 7 days. By focusing on recent data, CostGuard ensures that you have access to the most up-to-date information when making informed decisions about cost optimization.
Almost every organization has resources that were provisioned but are no longer in use. Forgetting to switch off these Idle resources eats away at your tech budget.
Scan Name
Sampling Source
Data Sampling
Timeframe
Calculation Interval
Idle Configuration
AWS-EC2
Amazon CloudWatch
Once every 2 weeks
7 days back
Every 2 weeks
- The maximum CPU utilization during the timeframe is under 5%. - Network-in and network-out traffic is below 5M bytes throughout the period.
AWS-EBS
Amazon API that extracts metadata
Every day
7 days back
24 hours
The storage is available during the entire calculated period.
AWS - ELB
Amazon CloudWatch
Every day
7 days back
24 hours
The number of requests transferring this interface is smaller than 100 during the entire calculated period.
AWS-RDS
Amazon CloudWatch
Every day
7 days back
24 hours
There are no DB connections during the entire calculated period.
AWS - Elasticache
Amazon CloudWatch
Every day
7 days back
24 hours
The maximum CPU utilization in the timeframe (in every day included in it) is less than 2%.
AWS - Elastic IP
Amazon CloudWatch
Every day
30 days back
24 hours
The tag originates from AWS.
AWS - S3
Amazon CloudWatch
Every day
7 days back
24 hours
There are no requests involving this bucket during the entire calculated period, this bucket isn’t being used.
AWS - Network
Amazon CloudWatch
Every day
7 days back
24 hours
The number of connections is smaller than 100.
GCP - VM
Cloud Monitoring service
Every day
7 days back
24 hours
-The maximum CPU utilization during the period is under 0.1%. -Network traffic (in and out) is below 10,485,760 bytes for the entire period.
GCP-CloudSQL
Cloud Monitoring service
Every day
3 days back
24 hours
-CPU utilization is under 0.05%.
-Memory utilization is under 0.1%.. -I/O operations (read/write) are fewer than 20.
GCP - Persistent Disk
Cloud Monitoring service
Every day
3 days back
24 hours
Tag that Finout enriches from GCP, which identifies this resource as idle.
GCP-Snapshot
Cloud Monitoring service
Every day
3 days back
24 hours
the creation date of the resource is 90 days or more
DataDog-Custom Metric
DataDog
Every day (as part of the MegaBill)
7 days back
24 hours
This tag isn’t being used in one of the primary DD products, dashboards/alerts.
DataDog-Logs - idle (Debug)
DataDog
Every day (as part of the MegaBill)
7 days back
24 hours
Finout filters the logs’ level. Debug logs are considered idle logs because they were written internally for investigation matters; therefore, they should be immediately removed.
Identifies resources that are regularly in use helps to identify potential savings that can be had by signing up for savings plans. The Commitment to using a resource for a specific amount over the agreed period can safely be made based on the CostGuard scans.
Scan Name
Applicable for
Data Sampling
Timeframe
Calculation Interval
Description
AWS-Commitment Saving Plan
EC2, Fargate, Lambda (across regions, OS, and instance types)
Daily
30 days back
Real-time (when the application runs)
Finout analyzes the organization's On-Demand costs for resources that are not currently covered by a commitment plan and identifies optimization opportunities. If a commitment plan can lower these On-Demand costs, it will be recommended, taking all supported resources into account without differentiation.
AWS Saving Plans
EC2
Daily
30 days back.
Real-time (when the application runs)
Finout analyzes the organization's On-Demand costs for resources that are not currently covered by a commitment plan and identifies optimization opportunities. If a commitment plan can lower these On-Demand costs, it will be recommended, per the supported resources groups.
AWS Reserved Instances
EC2 – specific to region, OS, and instance type
Daily
30 days back
Real-time (when the application runs)
Analyzes On-Demand costs for resources not covered by a commitment and suggests optimization opportunities for relevant resource groups and instance types. It also recommends the number of commitment hours for each instance type.
EC2 Instance Savings Plans unlock savings of up to 72% off on-demand prices by committing to a specific instance family in an AWS Region, regardless of instance size (e.g., m5.xlarge, m5.2xlarge, etc.), operating system (e.g., Windows, Linux, etc.), and tenancy type (Host, Dedicated, Default) within the chosen family and region.
With an EC2 Instance Savings Plan, you retain the flexibility to resize your instances within the selected family (e.g., from c5.xlarge to c5.2xlarge) or switch operating systems (e.g., from Windows to Linux). Even transitioning from dedicated tenancy to default does not affect the discounted rate provided by your EC2 Instance Savings Plan.
As part of CostGuard for EC2 Savings plans, our platform conducts scans across all EC2 instances within your account. We prioritize optimizing EC2-compute and on-demand filters, as these areas are vital in cost optimization. The resource names in the platform will include the respective regions to provide accurate insights and optimization recommendations.
For each region type, we have an analysis model that includes a simulator for savings plans.
To use the savings simulator:
Select the relevant scan.
Set the configuration of the plan: 1-year commitment or a 3-year commitment.
Set the payment option: Select partial upfront, all upfront, or no upfront.
Once the simulator is set based on your scan type, a summary is displayed. It includes the current on-demand spend, estimated monthly spend, and potential savings based on the chosen payment option.
The simulator provides an hourly level comparison with the on-demand rate, indicating the coverage provided by each commitment.
Using the simulator, we recommend the price of an hourly commitment based on the analysis.
We provide the user with the ability to understand the RIs for each one of the instances; how many resources are in each instance (Resources Count), how much of the instances are currently covered by any plan (Current Coverage), the optimal coverage and we provide a recommendation of how many instances, what type of instance family you should purchase and the annual potential savings if you go by the recommendation.
This instance is analyzed on a time frame of the last 30 days.
Compute Savings Plans can lead to savings of up to 66% relative to on-demand prices by committing to specific hourly compute costs. These plans offer maximum flexibility, regardless of the instance family, region, operating system (e.g., Windows, Linux), tenancy type (such as Host, Dedicated, or Default), or product type (EC2, Fargate, Lambda).
Finout’s CostGuard conducts scans across EC2, Fargate, and Lambda compute. Based on your hourly usage, it recommends the best $/hour rate for you.
Scan Breakdown:
Payment options- Upfront, partial upfront, or no upfront.
Saving plan terms- 1 year or 3 years.
From these options, 6 different combination scans are created, each showing how much you could save annually by choosing any one of these options.
For each combination including the payment option and saving plan term, we have an analysis model which includes a simulator for each savings plan.
To use the savings simulator:
Select the relevant scan.
Select the timeframe (based on the past) for the simulator. Either 7, 30, or 60 days (the default is 30 days).
The simulator will provide an hourly level comparison with the on-demand rate. Based on this, CostGuard recommends the optimal $/hourly commitment.
Resources that are in use may be underutilized and exceed your current workload performance and capacity requirements. Rightsizing means that you can downsize these resources without compromising on your service levels.
Scan Name
Sampling Source
Data Sampling
Timeframe
Interval
Description
AWS-EC2
Amazon CloudWatch
Once every 2 weeks
3 days back
Every 2 weeks
The maximum CPU utilization in the timeframe (in every day included in it) is less than 50%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
AWS - EBS
Amazon API that extracts metadata
Every day
1 day back
24 hours
Identifying EBS resources that are using the old gp2 technology, the recommendation in that case is technology transition to gp3 that is considered as more cost-effective.
AWS - RDS
Amazon CloudWatch
Every day
7 days back
24 hours
The maximum CPU utilization in the timeframe (in every day included in it) is less than 50%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
GCP - VM
Cloud Monitoring service
Every day
7 days back
24 hours
Idle configuration: The maximum CPU utilization in the timeframe (in every day included in it) is less than 80%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
K8s - All Scans
K8s metrics (Prometheus/DD - depending on the integration)
Every day (as part of the MegaBill)
14 days back
On the fly (when running the application)
-Data filter: the cluster and the scan type property exist - there’s an active node that uses K8s to search for rightsizing.
-Application calculation based on the data filter - if the formula’s result is bigger than 0 it indicates for underutilized resource.
Snowflake - Warehouse (Coming Soon)
Snowflake Account Usage
Every day
7 days back
24 hours
Analyzes warehouse efficiency based on USED_CREDITS vs. BILLED_CREDITS. If the utilization percentage (USED_CREDITS / BILLED_CREDITS) is consistently low, the warehouse may be oversized, and downsizing is recommended to optimize costs.
In Kubernetes scans, waste and potential savings are two critical metrics for understanding and optimizing resource allocation:
Waste: This represents the difference between the resources requested and the average hourly usage, calculated from minute-by-minute samples. Waste occurs when the requested resources exceed actual usage.
Potential Savings: This is the cost difference between the current resource allocation and a recalculated allocation based on adjusting resource requests to a selected usage percentile. It highlights the monetary savings achievable through rightsizing. Although both metrics reflect cost inefficiencies, waste is typically higher since resource requests remain unchanged unless actively optimized.
This model is based on the historical behavior of your environment. In this scan, Finout assigns a dollar value to CPU and Memory usage based on the associated costs of the pods.
Application Calculation
The Application Calculation formula is applied to detect underutilized resources. If the formula output is greater than 0, it indicates underutilization.
Note: This same calculation is also used to estimate the daily waste price.
New Default Ratios (88% CPU / 12% Memory) Formulas:
Note: The formula changes in accordance to your accounts configuration.
-CPU Formula:
- k8s max resource unit price: Price per resource unit (avg of CPU & memory).
- k8s max node cpu weight: CPU weight in the formula.
- k8s waste cores: Unused cores (value > 0 = rightsizing potential).
- Memory Formula:
- k8s max resource unit price: Price per resource unit (avg of CPU & memory).
- k8s max node mem weight: Memory weight in the formula.
- k8s waste mem: Unused memory (value > 0 = rightsizing potential).
Old Default Ratios (50% CPU / 50% Memory) Formulas:
- CPU Formula:
- cpu weight: The weight assigned to CPU in the formula determines how much of the total cost or resource is attributed to CPU.
- node price: The price of a node typically represents the cost of computing resources on that node.
- node cores: The total number of CPU cores available on the node.
- k8s waste cores: The number of unused CPU cores on the node, representing the potential for rightsizing the resources. If this value is greater than 0, it indicates an opportunity to optimize resource allocation.
- Memory Formula:
- mem weight: The weight assigned to memory in the formula, indicating how much of the total cost or resource is attributed to memory.
-node price: The price of a node, representing the cost of the resources on that node, similar to the CPU formula.
-node ram gb: The total amount of RAM (memory) available on the node, measured in gigabytes.
-k8s waste mem: The amount of unused memory on the node, representing the potential for rightsizing. If this value is greater than 0, it suggests an opportunity for resource optimization.
CPU/Memory Simulator
To propose recommended and new Memory and CPU requests, Finout offers a dynamic calculator. This tool enables the manual discovery of various CPU and Memory scenarios, based on the percentile CPU and Memory usage of the samples. For instance, at the 100th percentile, recommendations are based on the maximum CPU and Memory usage within the selected period. At the 85th percentile, recommendations are based on the CPU and Memory levels where 85% of the samples met the criteria during the chosen period.
The simulator provides two graph types for analysis: Overtime Analysis and Histogram View, offering insights into historical usage patterns.
Overtime analysis: Each graph, representing CPU and Memory, displays four different metrics:
Maximum usage.
Average usage across all pods in the selected scan.
Minimum usage.
Current request levels.
A dotted line that represents the simulated configuration of the chosen percentile.
Histogram view: To help in deciding whether to update your Memory or CPU, a histogram is also available. This visual representation shows the distribution of samples and indicates the number of samples that would fulfill the new request. Histogram Sample- This represents an hourly aggregation of pod usage, determined by calculating the average of samples taken every minute.
Refer to the relevant documentation to understand how K8s costs are calculated.
As Amazon encourages more people to transition to gp3, an advanced resource offering potential savings, Finout offers recommendations to users regarding the resources they should migrate from gp2 to gp3. By making this transition, users can potentially save a significant amount, denoted as "X."
Finout identifies underused RDS instances that can be downsized to a cost-effective alternative. The aim is to select the optimal instance for migration to maximize yearly savings, taking into account metrics like CPU usage and RDS connection count.
In this scan, Finout identifies underutilized instances that should not be shut down but rather moved to a more cost-effective alternative. The objective is to determine the most suitable instance to migrate to achieve the maximum potential savings on an annual basis.
During the VM rightsizing process, Finout analyzes VM CPU utilization data to suggest the most economical machine for optimal cost reduction. Within the calculations, CPU usage is constrained to a maximum of 80%. For predefined machines, we evaluate both standard and custom options. However, with custom machines, we specifically assess the custom configurations.
During the warehouse rightsizing process, Finout analyzes Snowflake warehouse efficiency by comparing actual usage to billed usage to identify potential cost savings. The evaluation is based on the following key metrics:
USED_CREDITS – The number of Snowflake credits actually consumed by the warehouse on a given day.
BILLED_CREDITS – The number of Snowflake credits charged, which may differ from actual usage due to Snowflake’s pricing model.
Utilization Percentage – Calculated as USED_CREDITS / BILLED_CREDITS, representing the warehouse's efficiency.
A warehouse is considered oversized if its utilization percentage is consistently low, meaning it is billed for more resources than it actually consumes. In such cases, Finout recommends downsizing to a smaller warehouse tier to optimize costs while maintaining performance.
The Commitments Log feature within Finout, available to all customers, provides you with a comprehensive audit and monitoring capability for all AWS Reserved Instance (RI) actions. With Finout, you gain more than just cost control - you ensure RI plan transparency and accountability. By leveraging this feature, you can optimize your management of RIs, enhance operational efficiency, and make more informed decisions regarding your AWS RI actions. The system sources its data directly from AWS, presenting all relevant information for user convenience.
Note: RIs will automatically appear from your primary AWS account in the Commitment Log. However, if you have AWS sub-accounts purchasing RIs or savings plans and wish to view their data in the Commitment Log, kindly follow the steps outlined below to integrate these accounts with Finout.
The Commitments Log comes equipped with a multitude of filtering options to allow for targeted viewing:
Time Frame: Filter the log entries based on a specific period or date range. Will filter on any action done in the timeframe.
Please note that the standard time frame is set to 30 days. If no activity occurs within this period, the page will display as empty.
Action Type:
Bought: The purchase of an RI.
Expired: The expiration of an RI term.
Listed: The RI was listed for sale.
Sold: The RI has been successfully sold.
Cancelled: The listing was withdrawn before any action occurred.
Note: The actions "Listed," "Sold," and "Canceled" are only relevant if an account is registered as a seller.
Region: Filter entries based on AWS regions.
Instance Type: View logs based on the type of AWS instance.
Operating System: Filter the logs by the OS type of the instance.
You can access the plan's metadata for an in-depth perspective, providing clarity on the specific details that characterize each plan.
For those who prefer offline or external evaluations, there is an option to download a CSV file, which reflects the view based on the filters chosen.
Tailor the Commitments Log table to your needs:
Rearrange columns to fit your viewing preference better.
Manage columns by adding or removing them, ensuring the table displays only what is relevant.
To view the RI actions from your sub-accounts in Finout, permissions are necessary for the sub-accounts where the RIs were bought, sold, or listed.
If you have any sub-accounts that manage RI purchases and wish to display their data in Finout’s Commitment Log, you must grant permissions for those specific accounts.
There are two methods to link your AWS sub-accounts to Finout:
Use StackSet permissions (recommended approach).
Manually grant sub-account permissions.
Create a CloudFormation StackSet from a template by following the instructions on the AWS website.
Use the following Amazon S3 URL for your Stackset template. You can use the role name you previously used for the Main account or use a new role name.
New role:
https://finout-public-assets.s3.amazonaws.com/FinoutCommitmentsNewRole.json
Existing Role:
https://finout-public-assets.s3.amazonaws.com/FinoutCommitmentsExistingRole.json
provide the role ARN to the Finout team by reaching out through your customer support channel.
Use the following JSON file to add permissions manually to your accounts:
Should you encounter the screen detailed below:
Here's how to proceed:
If the main account handles RI purchases:
For those who utilized CloudFormation during the onboarding process, run the update function.
For manual onboarding, modify the JSON based on the onboarding process.
If sub-accounts manage the RIs purchases:
Please follow the provided guidelines to grant permissions to the sub-account.
Finout API is fully secured using a secret key and client token, which can be managed from your Finout account. Your Finout account allows for five concurrent requests per API key. When you generate the API token, it creates both a secret key and a client ID (token). These parameters will be passed in the Authorization header when invoking any Finout API methods.c
Select your profile from the user dropdown on the top left of any screen in Finout.
Click Admin Portal. The Profile window appears.
Select API Tokens. The API Token screen appears.
Click Generate Token. The Generate Token window appears.
Enter a Description, choose a Role, choose token expiration, and click Create. Your token is generated.
Copy the Client ID and the Secret Key, which won't be accessible later, and then click Done.
Add the Client ID and Secret Key in Headers when invoking any of the Finout endpoints:
x-finout-client-id
x-finout-secret-key
Tag governance ensures consistent and effective resource management across cloud environments. It involves defining, enforcing, and monitoring organizational policies for tagging cloud resources, such as virtual machines, databases, and storage. Tags are metadata labels that categorize and organize resources, providing critical benefits like cloud cost management, operational visibility, and compliance.
However, tagging faces challenges such as inconsistent tagging, manual errors, scalability issues in large environments, and a lack of enforcement. To address this, Finout’s Tagging Governance solution allows you to define tagging policies across multiple cloud environments, offering visibility into non-compliant resources and costs while simplifying resource tracking. By creating a governance policy, you can establish your company’s tagging standards, enabling Finout to identify resources missing required tags or tagged with unapproved values. This helps ensure that resources are correctly associated with virtual tags, facilitates better budget management, and ensures compliance with security and governance standards.
You will learn how to:
Add policy details and define policy conditions.
To create a policy:
In Finout, navigate to Governance.
Add policy details:
Click Add Policy. The Create Policy pop-up appears.
Enter a policy name.
Choose a policy type. There are two types of policies:
Note: The policy type is not editable after creation.
Untagged Resources -
Identifies and tracks resources that are missing required tags.
For example: It ensures that all resources are tagged with a "Team" tag. If a resource lacks this tag, it is flagged as non-compliant.
Unapproved Values -
Tracks resources that are tagged with unapproved or incorrect tag values.
For example: If the approved values for the "Team" tag are "App" and "Data," a resource tagged with "Team: Application" is flagged as non-compliant.
Note: By default, the account's predefined cost type is automatically selected.
ACL permissions:
Optionally enable ACL permissions to define read and write permissions on a policy for specific users and groups.
Note: Enabling ACL on an object overrides user role permissions, except for admins.
There are three modes with ACL permissions:
Public: Everyone in your organization has this permission to the object.
Private: Only admins have permission to the object.
Shared: You must define users and/or groups.
Click Next and proceed to the Policy Configuration step.
Configure your policy:
After adding policy details, you can configure policy criteria and filters for Untagged Resources or Unapproved Values and then click Next.
Under Policy Criteria, select a source and a key.
Note: Available sources for selection are: AWS, GCP, OCI, Azure, or a virtual tag.
Under Filters, click Filters.
The available filters appear for selection.
Limitation: The Untagged Resources policy type does not detect resources labeled as “untagged” within Virtual Tags. To identify resources mapped as “untagged” in a Virtual Tag, users should create a Unapproved Values policy type and approve all valid values except “untagged.” This enables Finout to flag any remaining untagged resources as non-compliant.
Select the desired filters and click Apply Filters. Review your configuration and click Create. You are brought to the Policy Results Columns step.
Click Add Columns. The available filters appear for selection.
Note: The selected columns are saved at the policy level for all users.
Select the desired columns and click Select.
Note: You can select up to 10 columns.
The components appear on the screen.
Drag and drop the columns in the order in which you want to appear in the Policy.
Click Create. Your new policy appears in the policy feed.
Under Policy Criteria, select a source and a key.
Note: Available sources for selection are: AWS, GCP, OCI, Azure, or a virtual tag.
Under Filters, click Filters. The available filters appear for selection.
Select the desired filters and click Apply Filters.
Define approved values in the following two ways:
-Static values - define a static list of approved values.
-Dynamic values (coming soon) - define a regex to identify approved values. Static values - Select values manually by choosing approved values from the list of values available in Finout or by bulk uploading values using CSV. A policy can include up to 10K approved values.
Note: Dynamic values will be available soon.
Note: - The file should list all approved values in a single column, one per row, without headers.
- The values uploaded in the CSV file will override existing ones.
Click Next. You are brought to the Results Column step.
Click Add Columns. The available filters appear for selection.
Note: The selected columns are saved at the policy level for all users.
Select the desired columns and click Select.
Note: You can select up to 10 columns.
The components appear on the screen.
You can drag and drop the columns in the order they should appear in the Policy, and then click Next. You are brought to the Policy Overview step.
Note: -You can view the total number of approved values and the complete list. -To update the list, simply hover over a value and click the trash icon to remove any entries that are no longer approved.
Review your policy and click Create. Your new policy appears in the policy feed.
On the Governance page, you can access a consolidated view of all your policies and their current status, including those with non-compliant resources. This allows you to efficiently observe policy details and track each policy's status.
Name of the policy.
The policy type: Untagged Resources or Unapproved Values.
The cost of the non-compliant resources for the last day of data.
The percentage of non-compliant costs for the last day of data.
The number of non-compliant resources for the last day of data.
The percentage of non-compliant resources for the last day of data.
The source cloud provider.
Edit the policy details. To edit a policy:
In Finout, navigate to Governance. The Governance page appears.
Follow the steps in the pop-up window.
Note: Policy type is not editable after creation.
Delete the policy. To delete a policy:
In Finout, navigate to Governance.
The Governance page appears.
The Delete this Policy pop-up appears.
Click Delete. The policy is deleted.
Duplicate a policy To duplicate a policy:
In Finout, navigate to Governance. The Governance page appears.
Clicking on a policy brings you to this page, which displays a list of all non-compliant resources sorted by the highest cost from the previous day's data.
At the top of the policy page, you'll find the total cost for the non-compliant resources as of the last day of data, the number of non-compliant resources, the missing tag (when the policy type is “Untagged resources”), and the filters applied to the policy. You can also filter and search the resource list.
The table shows a list of non-compliant resources for that policy.
When the policy type is “Untagged resources,” the list shows the resources that are missing the specified tag in the policy configuration.
For example: If the policy scans all resources and searches for the tag “Team,” resources missing this tag will be displayed in the list.
When the policy type is “Unapproved values,” the list shows the resources tagged with values that are not approved in the policy configuration. The table then displays the unapproved value for each resource.
Note: - The list is sorted from the top costly resources down
- The list displays 10K resources, even if there are more than 10K non-compliant resources for that policy.
Table Columns:
Resource ID
Unapproved values - This column appears only when looking at the resources of an unapproved values policy type.
Last Day Cost
Days Since Detected - The number of days the resource is non-compliant with your standards.
Last Identified Date - The date that this non-compliant resource was identified.
Functionalities:
You can export the resources by clicking on Export CSV.
Click on Edit Columns to add additional columns to the ones that appear in the table. This option allows you to add additional data that may be helpful in investigating who is responsible for the resource.
Note: - You can add up to 5 columns. - Edits made to the columns on the resource view are not saved at the policy or user level and will only apply for the duration of the user's session on the resource view.
In the Finout Virtual Tags API documentation, the structure of the filters object can be explained by starting with simpler usage and then detailing more complex scenarios:
Simple Conditions Without Logical Operators:
Use direct condition keys for single-condition requirements.
Example JSON:
Complex Conditions with Nested Logical Operators:
AND and OR keys represent logical operators for grouping multiple conditions.
You can nest multiple layers of AND and OR for intricate conditional logic.
Example JSON:
Note: "displayName" is retrieved in the GET API call. This parameter should not be sent in the POST/PUT API calls.
The following operators can be used in the rule definitions to specify filtering conditions:
oneOf: Matches the resource value if it is equal to any of the specified values.
notOneOf: Matches the resource value if it is not equal to any of the specified values.
is: Matches the resource value if it is exactly equal to the specified value.
isNot: Matches the resource value if it is not equal to the specified value.
contains: Matches the resource value if it contains the specified substring.
notContains: Matches the resource value if it does not contain the specified substring.
exists: Matches the resource value if it exists (not null or empty).
notExists: Matches the resource value if it does not exist (null or empty).
In the example above, the rule engine is configured with two rules. The first rule filters resources with costCenter equal to "virtualTag" and type equal to "virtual_tag" using the oneOf operator, matching the values "Aged", "AllArid", "BidBare", "Calm", or "Coal". The matching resources are then directed to the "Application" destination.
The second rule filters resources with costCenter equal to "virtualTag" and type equal to "virtual_tag" using the contains operator, matching the value "Jet". The matching resources are directed to the "Backend" destination.
In the provided example, the third rule illustrates complex conditional logic using both "AND" and "OR" operators. This rule's filter conditions demonstrate the logic: "(condition 1 AND condition 2) OR (condition 1 AND condition 3)". This showcases how multiple conditions can be intricately grouped within "AND" or "OR" relationships, allowing for the creation of sophisticated filtering logic for virtual tags. This example serves to show the versatility and depth of the filtering system in handling diverse and complex tagging scenarios.
Finout Reports empowers you to create daily, weekly, or monthly reports directly from your dashboards and send them to your email, post them to Slack or MS Teams, ensuring your team stays informed on key metrics. Additionally, reports can be sent to distinct endpoints based on group-by values, allowing you to customize data delivery for each team. This makes it easy to send each team a report filtered with only their specific data to their own endpoint, enhancing relevance and accessibility for all stakeholders.
Note: The group-by functionality is coming soon.
Important:
Slack:
MS Teams:
Make sure that the user has permissions to install apps from Teams marketplace.
Email:
Addresses of non-Finout users: For email addresses not linked to a Finout account, ensure you type the complete address and hit 'Enter' for the system to recognize it.
Using distribution lists: Adding distribution lists is similar to adding individual email addresses. If the list corresponds to Finout users, the autocomplete feature will help you select it. For external lists, type and confirm the full address.
You can create daily, weekly, or monthly reports from your dashboards and send them directly to your email or posted to Slack or MS Teams, ensuring your team stays up-to-date with key metrics.
To create a report:
In Finout, navigate to Reports.
Click Create Report. The Create Report step appears.
Note: You can also create a report by navigating to Dashboard, choosing a Dashboard, and clicking Subscribe at the top right of the page
Enter a Report Name.
Enter a Report Description.
Select a Dashboard.
Report Endpoints - Choose the endpoints to where you want the report to be sent. You can set a default endpoint for the report, or you can choose to 'group by' a specific Megabill key. This allows you to send filtered reports to the corresponding endpoints set for each group-by value.
.
Click Choose Group By. The available options appear for selection.
Note: The group-by functionality is coming soon.
Select the desired group-by and click Apply Group By. The group by values and endpoints table appears.
Note:
Your report can include a maximum of 5,000 values. Reports exceeding this limit cannot be saved.
You can add additional endpoints per value by clicking Choose an endpoint to add an additional Slack, MS Teams, and Email endpoint per value. When a value has multiple endpoints associated, a filtered report for that value is sent to all the associated endpoints.
Note: Click to disable sending reports to the metadata endpoint specified for this value in the virtual tag metadata.
Choose a Default Endpoint (optional when group by is selected)
Choose a Slack/MS Team endpoint or enter an email address.
Click Choose Slack/MS Teams/Email endpoint.
Choose a default endpoint from the dropdown list or type an email address to select an email.
Note: - When no specific endpoint is defined for a group by value, a filtered report of that value will be sent to the default endpoint when set. - Use the left toggle to disable sending a report to a specific value.
3. Report time frame.
Dashboard default settings - choose this option when you want to use the default time frame that is saved in the dashboard settings.
Custom Settings - Choose a timeframe and the intervals:
4. Report Scheduling & Format:
Select the report format: Image or PDF.
Set the Report Schedule: Choose the timeframe, frequency, and time zone for sending the report.
5. Click Test Report.
Note: When using group-by, the user must select both a value and an endpoint to test the report. If no group-by is applied, the report is sent as-is to the chosen endpoint.
6. Click Save Report. Your report is saved and appears on the reports list.
Manage reports from the main reports page.
Search all of your reports.
Create Report.
Report Name.
Created by - Indicates the user that created the report.
Endpoints - The endpoints where you want the report to be sent.
Group by - The selected group-by when set.
Created date - The date the report was created.
Modified date - The date the report was modified.
Schedule information- The schedule of when the reports are incrementally sent.
Active - Indicates if the report is active (Toggle on) or inactive (Toggle off).
Click a report to enable editing.
Select Reports. The reports page appears.
View the report in Slack, MS Teams, or your email. Reports sent to Slack, MS Teams, and email include:
A direct link to the report's dashboard in Finout.
An image/PDF (depending on the report settings) of the report's dashboard for quick reference.
Select Reports. The reports page appears.
Click Clone Report. The Report is cloned.
Select Reports. The reports page appears.
Click Delete Report.
The Delete this report popup appears.
Click Delete.
The report is deleted.
Select Reports. The reports page appears.
Click on the report that you want to edit. You are brought to Edit Report.
Make your changes.
Optionally, click Test Report.
Note: When using group-by, the user must select both a value and an endpoint to test the report. If no group-by is applied, the report is sent as-is to the chosen endpoint.
Click Save Report. Your report is saved and appears on the reports list.
Note: Only cost data is returned when querying a view via the Cost API.
GET
/Views
Description
Prerequisites
You must create a view in the MegaBill before querying the GET view. There is currently no 'Create View' API option.
Request
https://app.finout.io/v1/view
Response
sdvs
Returns a JSON object with the following properties:
name: The names of your account's views.
id: The unique identifier of your account's views.
POST
/Query by view
Description
Prerequisites
You must first GET the view you want to query
Add the GET view ID to the body of the POST query. Example:
You must either specify dates or delete them completely. The query won't work when blank dates are still present. Example:
Request
https://app.finout.io/v1/cost/query-by-view
Body of Request
Response
GET
/Scans
Prerequisite
Request
https://app.finout.io/v1/cost-guard/scans
Response
Returns a JSON object with the following properties:
request Id - The ID of this specific request.
scanName: The names of the scan.
scanId: The unique identifier of the scan.
scanLastRunTime: The last time the scan was run.
scanMetadata: Information about the scan.
type - The scan type.
costCenter - Origin of the scan’s cloud provider.
analysisDays - The number of days on which the scan analysis is based.
POST
/Scan Recommendations
Prerequisites
Add the scan ID to the body of the POST query. Example:
{
"scanId": "scan_id"
}
Request
https://app.finout.io/v1/cost-guard/scans-recommendations
Body of Request
Response
400 - Bad Request
401 - Unauthorized
429 - Too many requests
503 - Server unavailable
504 - Gateway Timeout
Returns a JSON object with the following properties:
requestId -The ID of this specific request.
scanName - The name of the scan.
scanLastRunTime - The last time the scan was run.
scanTotalCost - The sum of resources cost identified by the scan during the analysisDays.
scanTotalWaste - Waste of the scan during the analysisDays.
scanYearlyPotentialSavings - Yearly potential savings for the scan based on the scan's total waste.
scanMetadata - Additional information on the scan:
type - Scan type: rightsizing/idle
analysisDays - The duration in days on which the scan analysis is based
costCenter - scan cloud provider origin
data - All resources in a scan’s results
group - The value of the group. If there is no groupBy value, the value will be “Total”.
groupTotalCost - Cost of the scans during the analysisDays.
groupTotalWaste - Waste of the scan during analysisDays.
groupYearlyPotentialSavings - Yearly potential savings for the group based on the group's total waste.
resources - All resources in a scan’s results.
The details for the AWS, K8S, Datadog, and GCP scan recommendation queries.
EC2 - Idle
resourceMetadata
resourceMetrics
EC2 - Rightsizing
resourceMetadata
resourceMetrics
resourceRecommendations
RDS- idle
resourceMetadata
resourceMetrics
RDS - Rightsizing
resourceMetadata
resourceMetrics
resourceRecommendations
Scans: EBS-Idle, EBS- rightsizing
Metadata
Scans: EBS - gp2
Metadata
resourceRecommendations
Scans: Application Load Balancer - Idle, Network Load Balancer - Idle, Classic Load Balancer - Idle, Gateway Load Balancer - Idle
Metadata
resourceMetrics
Scans: Elastic IP - Idle
Metadata
resourceMetrics
Scans: elasticache - Idle
Metadata
resourceMetrics
Scans: S3 - Idle
Metadata
resourceMetrics
Scans: K8s - Deployment/StatefulSet/CronJob/DaemonSet/ReplicaSet
resourceMetadata
resourceMetrics
Scans: Logs - Idle (debug)
Metadata
Scans: Custom Metrics - Idle
Metadata
VM - Idle
resourceMetadata
resourceMetrics
VM - Rightsizing resourceMetadata
resourceMetrics
resourceRecommendations
Snapshot - Idle
Metadata
Scans: Persistent Disk - Idle
Metadata
SQL - Idle
resourceMetadata
resourceMetrics
Click and then click Dashboard Settings. The Dashboard Settings side-window appears.
Name your widget: Click and add a name.
a)Click Trend Projection. The Trend Projection Settings appears. b)Choose Projection Technique - Choose the method for the projected trend. Currently, only linear forecast is supported. c)Set Lookback period - Set the historical period for calculating projections. d)Set Projection Period - Set the timeframe for displaying projections. e)Set Trend Display Settings: Incremental or Cumulative
The Trend Projection layer is set.
Name your widget: Click and add a name.
Name your widget: Click and add a name.
Name your widget: Click and add a name.
Note: - This widget will not be impacted by the dashboard's time filter, as each CostGuard has its own unique calculation interval. - The configure widget will have a CostGuard button that shows the widgets data filtered in CostGuard.
Name your widget: Click and add a name.
Name your widget: Click and add a name.
Widget main settings:
A Missing Permissions icon appears at the top of the page. Hover on the to see all the missing permissions.
Click by the financial plan name. The Settings popup appears.
Click . Inline editing is enabled for the selected rows.
Click to download the view as a CSV file. A CSV of the financial plan is downloaded to your computer.
Clickfor the line item whose budget you want to edit and click Edit Line’s Budget. The Edit Line’s Budgets popup appears.
Clickfor the line item whose budget you want to edit and click Edit Line’s Budget. The Edit Line’s Budgets popup appears.
In your financial plan click and then click Add Custom Line Item. The Add Custom Line Item window appears.
The line item appears in the financial plan list with an indicator.
In your Financial Plan, click and then toggle on Show Only Custom Lines. Only your custom line items appear in the financial plan.
In your financial plan, click and then toggle on Show Ignored Line Items. Your ignored line items reappear.
In the comment column of your financial plan, click for the line item you want to comment on. The commenting popup appears.
Note: You can sort the column so lines with comments will appear at the top by clicking > Sort Descending by the comments column.
In the comment column of your financial plan, click for the comment you want to delete. The commenting popup appears.
In the comment column of your financial plan, click for the comment you want to delete. The commenting popup appears.
In your financial plan, click next to the financial plan name. The edit settings popup appears.
In your financial plan, click next to the financial plan name. The edit settings popup appears.
In your Financial Plan, click, and then click Duplicate Plan or click at the top right of the plan. The Duplicate Financial Plan window appears.
Clickand then click Duplicate Plan. The Duplicate Financial Plan window appears.
Clicknext to the financial plan you want to delete and then Delete Financial Plan. The Delete Financial Plan pop-up appears.
In the Anomalies Feed, click and then click Anomalies Settings. The Anomalies Settings pop-up appears.
In the Anomalies Feed, click and then click Anomalies Settings. The Anomalies Settings pop-up appears.
In the Anomalies Feed, click and then click Clear anomalies feed.
In the Anomalies Feed, click Delete in a select Anomaly.
Enable sending alerts to endpoints based on group-by values:
Click if you would like to disable the Metadata endpoint for this value.
This feature ensures that anomalies are detected more accurately, minimizing noise from predictable fluctuations. What Happens When You Enable Seasonality? When the Seasonality Check is enabled, Finout automatically filters out alerts identified as seasonal anomalies: - They won’t appear in your anomaly feed. - They won’t be sent to your configured endpoint. This ensures that your alerts focus only on unexpected anomalies, helping you cut through the noise of predictable cost fluctuations.
- Monitor tag coverage across your organization with policy creation.
- Access the details and status of each policy.
Choose a cost type. See for all the possible cost types.
ACL permissions are disabled by default, meaning all users can view or edit based on their specific role or access. See for more information.
Manually select approved values or import approved values using CSV: - Manually select values - Manually select approved filter values. a. Click Filter Values. The value dropdown appears. b. Choose values that are approved for this policy. - Import CSV - Upload a CSV to import approved values. a. Import the CSV file by clicking Import CSV File. The Import CSV File window appears. b. Upload the CSV file.
Potential errors: c. Click Update.
A single policy: Clicking on a policy will navigate you to the .
Click on the policy that you want to edit and then press Edit.
Click on the policy that you want to delete and then press Delete.
Click on the policy you want to duplicate and then press Duplicate. The Policy is duplicated.
To send your report to Slack, configure a Slack webhook and create a Slack endpoint. For information on creating a Slack endpoint, see .
Use the same Microsoft Teams account (user email address) for both the integration setup within the Finout platform and the Finout app installation on Teams. See .
Send the report to endpoints per value (Optional): Enables sending reports to endpoints based on group-by values, filtered accordingly, ensuring each segment receives data relevant to its context. Example: You can generate a cost report filtered by a team. This involves grouping by the virtual tag's team, using the to populate the team's virtual tag with endpoint metadata. The final report will then be sent to each team's designated endpoint.
Note: - If no specific endpoint is set per value, the report will be sent filtered by that value to the default endpoint when set. - When grouping by virtual tag, the endpoints assigned to virtual tag values through the Virtual Tag Values Metadata API are automatically populated. To learn how to set endpoints for each virtual tag value using the API, view the .
When grouping by virtual tag, if virtual tag values include endpoint metadata, they will automatically be populated and updated in the “Metadata Endpoint” Column. To learn how to set endpoints for each virtual tag value using the API, view the .
Click to activate the required report.
Finout Cost API enables you to query and analyze costs using user-defined . You can easily get a list of your views and retrieve the costs for a specified view. You can query the costs for any date range of up to 90 days specified in UTC timestamps. The results are returned in JSON format for easy processing.
Gets a list of all your account views. For more information on views, see
from Finout to add in Headers.
Return all costs for a specified view and date range for up to 90 days. For more information on views, see .
from Finout to add in Headers.
enables you to identify areas within your infrastructure that are ripe for cost optimization. Finout’s CostGuard API lets you retrieve all your and their relevant recommendations. This guide offers comprehensive information on interacting with the API endpoints to retrieve scan data, access recommendations, and manage resources.
Retrieves all CostGuard scan options. For more information, see .
from Finout to add in Headers.
400 - Bad Request
401 - Unauthorized
429 - Too many requests
503 - Server unavailable
504 - Gateway Timeout
Retrieves all resources identified in a scan based on scanId, optional filters, and groupBy. For more information, see .
from Finout to add in Headers.
You must first you want to query
costCenter
string
The cost center associated with the filter.
"AWS" , "GCP", "Kubernetes" , "Snowflake" , "Virtual Tags" , "Datadog" , "Azure" , "Custom Cost"
operator
string
The comparison operator to apply for the filter (e.g., "oneOf", "equal", "greaterThan").
"oneOf"
value
array
An array of values to use the operator against.
["Amazon Web Services EMEA KFIR"]
key
string
The key in Finout filters.
For non-unique keys or specific keys (finrichment), a transform function is applied as follows:
finrichment is returned as f_
plus the Kubernetes key and the node/pod label is returned as nl_<key>/pl_<key>
“1233442423423”
“finrichment_usage_type” -> “f_usage_type”
Use Finout’s Query Language API to get a list of the available keys.
400
Bad Request
401
Unauthorized
429
Too many requests
503
Server unavailable
504
Gateway Timeout
viewId
string
The ID of the view that the user queries
date
object
“unixTimeMillSecondsStart” and “unixTimeMillSecondsEnd” keys
unixTimeMillSecondsStart
Numeric
Start Date represented in Unix Epoch time
unixTimeMillSecondsEnd
Numeric
End Date represented in Unix Epoch time
costType
String
Types of costs: - blendedCost - unblendedCost - netUnblendedCost - amortizedCost - netAmortizedCost See Cost and Usage Types for an explanation of each cost.
400
Bad Request
401
Unauthorized
429
Too many requests
503
Server unavailable
504
Gateway Timeout
Parameter
Type
Description
scanId
string
The ID of the scan.
Example:
{
"scanId":"scan_id"
}
filters
Optional:
For Finout Megabill filters, see the Finout API language query doc.
Example:
"filters": {
"costCenter": "AWS",
"key": "parent_cloud_service",
"operator": "is",
"value": "AmazonAthena"
},
groupBy
Optional:
Group data elements together based on common attributes or values.
For Finout Megabill groupBy, see the Finout API language query doc.
Example:
"groupBy": {
"costCenter": "AWS",
"key": "parent_cloud_service"
}
accountId
string
The account ID of the resource.
“1234”
accountName
string
The account name of the resource.
"finout"
instanceType
string
The type of the instance.
“t2.medium”
productVCPU
number
The core quantity.
“4”
maxEC2CpuUtilization
float
CPU Utilization percentage represents the peak CPU usage within the scan analysisDays. This value is determined by identifying the highest recorded CPU usage during the specified period, expressed as a percentage of the total CPU capacity.
“1.96721311475231”
totalEC2NetworkIn
float
The resource "NetworkIn'' represents the total amount of incoming network traffic within the scan analysis days. This value is determined by aggregating all recorded incoming network traffic data, providing a comprehensive measure of the total network usage for incoming data.
“2847257.3333333335”
totalEC2NetworkOut
float
The resource Networkout-
The resource "NetworkOut" represents the total amount of outgoing network traffic within the scan analysisDays. This value is determined by compiling all outgoing network traffic data recorded and provides a comprehensive measure of the total network usage for outgoing data.
“1976763”
accountId
string
The account ID of the resource.
“1234”
accountName
string
Account of the resource.
"finout"
instanceType
string
The size of the instance.
“t2.medium”
productVCPU
number
The core quantity.
“4”
maxEC2CpuUtilization
float
The maximum CPU usage during the analysis days.
“1.235593220338884”
usedCpu
float
The maximum CPU used during the analysisDays.
“1.235593220338884”
targetCpu
float
Number of vCPU of the target instance.
1
targetMemory
float
The target of the memory.
512
targetInstanceType
string
The recommended instance type.
“t2.nano”
accountName
string
The AWS account ID.
"finout"
instanceType
string
The size of the instance.
“t2.medium”
maxRDSDatabaseConnections
float
The maximum daily total of connections during the scan analysisDays.
0
accountId
string
The account ID of the resource.
“1234”
accountName
string
AWS account ID.
"finout"
instanceType
string
The size of the instance.
db.r5.xlarge”
usedCpu
float
The maximum CPU used during the analysisDays.
“1.235593220338884”
usedMemory
float
The mximum memory that was used during the day's analysis.
“1.235593220338884”
maxRDSCpuUtilization
float
CPU utilization percentage- represents the peak CPU usage within the scan analysisDays. This value is determined by identifying the highest recorded CPU usage during the specified period and expressed as a percentage of the total CPU capacity.
“0.2”
targetInstanceCpu
float
The scan results determined that the CPU of the target machine enables maximum CPU utilization without impacting performance.
1
targetInstanceMemory
float
The memory of the target machine.
512
targetInstanceType
string
The recommended instance type is based on the CPU scan result.
“db.r5.large”
accountId
string
The account ID of the resource.
“1234”
accountName
string
Account of the resource.
"finout"
usageType
string
The type of the EBS.
“EBS:VolumeUsage.gp2”
state
string
The state of the EBS: Available - The EBS volume is not attached to any EC2 instance and is considered idle.
“Available”
accountId
string
The account id of the resource.
“1234”
accountName
string
Account of the resource.
"finout"
usageType
string
The type of the EBS.
“EBS:VolumeUsage.gp2”
targetVolumeType
string
The target volume type for the EBS.
gp3
accountId
string
The account IDof the resource.
“1234”
accountName
string
The account of the resource.
"finout"
apiOperation
string
The type of the Load Balancer.
“Load Balancing”
totalELBRequestCount
float
Indicates the total number of HTTP or HTTPS requests received by the Elastic Load Balancer within the scan timeframe.
0
accountId
string
The account ID of the resource.
“1234”
accountName
string
The account of the resource.
"finout"
region
string
The region of the account.
“us-east-1”
totalIdleHours
float
The total hours of idle Elastic IPs during the analysis period.
722
accountId
string
The account IDof the resource.
“1234”
accountName
string
The account of the resource.
"finout"
instanceType
string
The size of the instance.
“cache.m5.large
maxElastiCacheCpuUtilization
float
CPU utilization percentage represents the peak CPU usage within the scan analysisDays. This value is determined by identifying the highest recorded CPU usage during the specified period and is expressed as a percentage of the total CPU capacity.
“1.21”
accountId
string
The account IDof the resource.
“1234”
accountName
string
Account of the resource.
"finout"
instanceType
string
The size of the instance.
“cache.m5.large
s3AllRequests
float
Represents the total number of requests sent to an S3 bucket. For an idle bucket, the expected result would be 0, indicating no requests have been made.
“0”
cloudOrigin
string
The cloud platform where the Kubernetes resources are running.
“amazon-cur”
maxCpuUsage
float
Resource maximum CPU used during the analysis days.
0.064450918833
maxCpuRequest
float
Resource maximum CPU request during the analysis time frame.
1
avgCpuUsage
float
Resource average CPU used during the analysis time frame.
0.00067
avgCpuRequest
float
Resource average CPU request during the analysis time frame.
1
maxMemoryUsage
float
Resource maximum memory used during the analysis time frame.
521.361
maxMemoryRequest
float
Resource maximum meme request during the analysis time frame.
12980
avgMemoryUsage
Resource average mem used during the analysis days.
322
avgMemoryRequest
Resources average mem request during the analysis time frame.
12980
product
string
Datadog service
“Logs indexed 3day”
service
string
Datadog tag: service
“Internal service”
datadogIndex
string
Datadog tag: index
“production”
status
string
The status of the log is "debug," and is therefore considered idle.
“debug”
product
string
Datadog sub service.
“Timeseries”
wasteType
string
Custom metrics that are not being used in any dashboards.
“idle”
projectId
string
The project ID of the resource.
“1234”
projectName
string
Project of the resource.
"finout"
computeMachineSpec
string
Current machine type.
“n1-standard-4”
computeCores
number
Number of cores on the machine.
6
computeMemory
number
Amount of Memory configured to the machine (In MegaBytes).
30720
maxComputeCpuUtilization
float
The maximum CPU usage during the analysis days.
“1.235593220338884”
avgBytesReceived
float
Average amounts of data received daily by the resource (in bytes) during the analysis timeframe.
889167
avgBytesSent
float
Average amounts of data sent daily by the resource (in bytes) during the analysis time frame.
889167
projectId
string
The project ID of the resource.
“1234”
projectName
string
Project of the resource.
"finout"
computeMachineSpec
string
Current machine type.
“n1-standard-4”
computeCores
number
Number of cores on the machine.
“6”
computeMemory
number
Amount of Memory configured to the machine (In MegaBytes).
30720
maxComputeCpuUtilization
float
Maximum CPU usage during the analysis days (in %).
“4.0”
targetMachineSpec
String
The recommended machine type for rightsizing.
“custom-32-262144”
targetMemory
number
Target of the memory (In GigaBytes).
512
targetCpu
number
Target of the CPU.
2
projectId
string
The project ID of the resource.
“1234”
projectName
string
The project of the resource.
"finout"
projectId
string
The project ID of the resource.
“1234”
projectName
string
Project of the resource.
"finout"
projectId
string
The project ID of the resource.
“1234”
projectName
string
Project of the resource.
"finout"
instanceType
string
The size of the instance.
“t2.medium”
maxSqlCpuUtilization
float
CPU utilization percentage represents the peak CPU usage within the scan analysisDays. This value is determined by identifying the highest recorded CPU usage during the specified period, expressed as a percentage of the total CPU capacity
“1.21”
maxSqlMemoryUtilization
float
The maximum memory used during the scan analysisDays (In GigaBytes).
“4.2”
As modern organizations grow and diversify, managing who can perform each task and access what data and systems becomes an increasingly complex challenge. Traditional methods of manually managing user permissions on an individual basis not only become time-consuming but also introduce multiple pathways for errors and potential security risks. This is where Role-Based Access Control (RBAC), comes into play. RBAC is a systematic approach to managing and granting permissions based on roles within an organization.
RBAC is based on the principle that permissions should be granted according to a user's role in an organization rather than the individual user. By assigning permissions to roles and then roles to users, organizations can ensure a consistent application of access policies, streamlining administration, and enhancing security.
Within Finout, RBAC stands as a pivotal feature. By granting specific permissions based on user roles, RBAC enhances Finout's security, ensuring only authorized individuals make crucial FinOps, financial, and operational decisions. By aligning user roles with specific permissions, RBAC in Finout establishes a professional framework for reliable and efficient cloud cost management, emphasizing the critical principles of accountability, transparency, and control.
Finout implements two major components of RBAC:
Role permissions categorize users and this allows you to assign permissions to users based on their role within the organization. Security is more easily maintained by using roles as there is no need to assign permissions at the user level. Users may be assigned more than one role, in which case they accumulate all the permissions from their assigned roles.
Data access control allows you to assign users to one or more groups to provide them access to only the data they require (and limit their access to any other data). Each group has a filter applied to it, providing access to a subset of the data in the organization. Users have access to all the data across the groups they belong to.
Note: Access control list (ACL) in the roadmap for future release.
Here are all the permissions you can use to create a custom role.
Category
Permission Name
Description
Anomalies
View Anomalies
Grants users access to view the relevant tabs and its associated features within the platform.
View Anomalies Feed
Grants users access to view the 'Anomaly Feed' tab.
View Manage Anomalies
Grants users access to view the 'Manage Anomalies' tab.
Create an Anomalies Alert
Enables users to create and duplicate any anomaly.
Edit Anomalies
Enables you to edit anomalies and access settings, the 'is activated' toggle, and add comments.
Delete Anomalies
Enables users to delete any anomaly from the Anomalies feed.
Clear all anomalies
Enables users to clear all detected anomalies in the Anomalies feed.
Budgets
Edit a budget
Enables users to edit a Budget.
Create and Delete a budget
Enables users to create a new budget and delete an existing budget.
My Commitments
View My Commitments
Grants users access to view the 'My Commitments' tab.
Commitments Log
View My Commitments Log
Grants users access to view the 'Commitments Log' tab.
Dashboards
View Dashboards
Grants users access to view the relevant tab and its associated features within the platform.
Create Dashboard
Enables you to:
Build new dashboards from scratch or clone existing ones.
Offers the ability to create and customize individual widgets that display specific data points or visualizations.
Edit Dashboard
Enables you to:
Dashboard Settings: Adjust layout, visibility, and other configuration options.
Edit Widget: Includes the ability to edit, duplicate, export data to CSV, or subscribe to widget updates.
Delete Widget: Remove unwanted widgets from the dashboard to maintain a clean and organized view.
Share Dashboard: Enables you to share the dashboard with other users or teams.
Delete Dashboard
Enables you to permanently remove an entire dashboard, along with all associated widgets and settings.
Data Explorer
View data explorers
Enables users to access the Data Explorer tab.
Create data explorers
Enables users to create a new explorer and define the relevant parameters.
Edit data explorers
Enables users to edit an existing data explorer.
Delete data explorers
Enables users to delete a data explorer.
EDP
Manage EDP
Enables users to define, edit, and delete EDP rules.
Financial Plans
Create financial plans
Enables users to create financial plans.
Delete financial plans
Enables users to delete financial plans.
Edit financial plan line items
Enables users to edit financial plan items.
Enable/Disable line items
Enables users to enable and/or disable a line item within a financial plan.
Edit Financial Plan Settings
Enables users to edit financial plan settings like name and ACL.
Bulk Upload CSV
Enables users to bulk upload budget and forecast values to the financial plan using a CSV.
Add custom line to Financial Plan
Enable users to add a new custom line item to an existing financial plan under the financial plan permissions.
Edit line item by group
Allows users to edit financial plan line items associated with groups they are part of.
Views
View Report
Grants users access to view Reports tab and its associated feature
Create Report
Enables users to create/duplicate a report
Edit Report
Enables users to edit reports.
Delete Report
Enables users to delete reports
Reports
View Report
Grants users access to view Reports tab and its associated features
Create Report
Enables users to create/duplicate a report.
Edit Report
Enables users to edit reports.
Delete Report
Enables users to delete reports.
Settings
Write account settings
Enables users to access the 'Account Settings' tab (under the Settings tab) and perform actions like enabling options. Select the default cost type to allow all users to see the cost data with EDP adjustments.
View cost center
Enables users to view the 'Cost Centers' tab.
Create cost center
Enables users to create a cost center.
View Custom cost
Enables users to access the 'Integrations' tab.
Connect Custom cost
Enables users to connect a custom cost.
Delete Custom cost
Enables users to delete a custom cost.
View Custom Drill Down
Grants users access to view the '‘Custom Drill Down" tab.
Create Custom Drill Down
Enables users to create a Custom Drill Down.
Edit Custom Drill Down
Enables users to edit a Custom Drill Down.
Delete Custom Drill Down
Enables users to delete a Custom Drill Down.
View Custom Endpoints
Grants users access to view the '‘Endpoints' tab".
Create Custom Endpoints
Enables users to create an Endpoint.
Edit Custom Endpoints
Enables users to edit a an Endpoint.
Delete Custom Endpoints
Enables users to delete an Endpoint.
View Group
Grants users access to view the 'Groups' tab (under the Settings tab) .
Create Group
Enables users to create a Group.
Edit Group
Enables users to edit a a Group.
Virtual Tags
View Virtual Tag
Grants users access to view the relevant tab and its associated features within the platform.
Create Virtual Tag
Create new virtual tags or duplicate existing ones.
Delete Virtual Tag
Permanently remove a virtual tag and all associated configurations.
Edit Virtual Tags
Enables users to edit Virtual Tags.
Finout
Read application
Provides read access to the Finout platform.
Admin Portal
Read groups
Enables users to view a list of all groups (under the Admin Portal).
Read users
Enables users to view a list of all users (under the Admin Portal).
Roles
Read roles
Enables users to access the roles tab.
Write roles
Enables users to create or edit custom roles.
Delete roles
Enables users to delete custom roles.
Governance
Create Policies
Enables users to create or duplicate a policy.
Edit Policies
Enables users to edit policies.
Delete Policie
Enables users to delete policies.
View Policies
Grants users access to view the Governance tab and its associated features.
Resources
View Resources
Grants users access to view the '‘Resources" tab.
Finout’s Endpoint API provides functionalities to query existing endpoints and create new ones effortlessly. You can retrieve a list of current endpoints or create new ones, with all results returned in JSON format for seamless integration and processing.
GET
/Endpoints
Gets a list of all your account endpoints.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/endpoints
Response
Bad Request
Unauthorized
Too many requests
Server unavailable
Gateway Timeout
Returns a JSON object with the following properties:
type: The endpoint type - email or Slack.
name: The name of the endpoint.
configuration: The Slack or email URL that is configured for the endpoint.
to: The destination address or endpoint for the notification.
createdBy: The creator of the endpoint.
createdAt: The time and date the endpoint was created.
id: The unique identifier of your account's views.
requestId: The ID of this specific request.
POST
/Endpoints
Creates an email or Slack endpoint in Finout.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/endpoints
Body of Request
type
string
Email or Slack
name
string
The name of the endpoint.
configuration
Object
The address where notifications or messages are sent. to: The destination address or endpoint for the notification.
Note: For MS Teams - All public channels in a Team will automatically mapped to an endpoint ID in Finout.
Response
Bad Request
Unauthorized
Too many requests
Server unavailable
Gateway Timeout
Returns a JSON object with the following properties:
accountId: The account id of the endpoint.
createdby: The creator of the endpoint.
type: the endpoint type - email or Slack.
name: The name of the endpoint.
configuration: What the endpoint was configured to.
to: The destination address or endpoint for the notification.
createdAt: The time and date the endpoint was created.
updatedAt: The time and date the endpoint was updated.
id: The unique identifier of your account's views.
requestId: The ID of this specific request.
In Finout, groups facilitate efficient data access setup for users. Users can either be manually added to a group or linked via SAML mapping when Single Sign-On (SSO) is enabled. The groups can reflect your organization's structure and determine what data every department or team should be exposed to.
Upon accessing the Group section, the Admin Group is visible. This default group comprises all admin users, providing them with unrestricted app access. While users can be added or removed from this group, at least one member must always remain for full data visibility.
Delete a group that you no longer want to use.
To delete a group:
Log in to Finout as an Admin user.
Navigate to Settings.
Select the Groups tab.
Click on (⋮) option and choose Delete Group.
Click Continue to delete the group.
Understanding Finout’s Roles, Permissions, and User Groups.
What is the significance of having an admin role in terms of data access?
Admin roles do not automatically grant universal data access. An admin who is not part of any group will not have access to any data. In Finout’s RBAC system, being part of specific groups determines access to data, not just the role title itself.
How can I set up a user or group to have access to all data within Finout?
To ensure a user or group has access to all data, they must be included in every relevant group. Alternatively, you can create a group with Discretionary Access Control (DAC) rules that explicitly grant access to every organizational unit or dataset you wish to include, ensuring comprehensive access.
Is it possible to have an “admin” group that sees everything? How does it work?
Yes, you can create an “admin” group with comprehensive access by ensuring it’s part of every necessary group or by setting DAC rules that grant access to all organizational units or datasets. This setup will allow the admin group to see everything across the platform.
Can we set up a read-only group that has access to all data?
Similar to creating an admin group with full access, a read-only group can be established by ensuring it has DAC rules for every organizational unit or dataset. This setup would grant read-only access to all data across the platform to members of this group.
Who has access to dashboards in Finout, and how is data visibility controlled?
In Finout, all users have access to all dashboards, as the platform does not yet support Access Control Lists (ACL) for dashboard accessibility. However, the visibility of data within these dashboards is governed by data access permissions tied to the groups a user is part of. This ensures that while users can view any dashboard, the data displayed is filtered according to their group memberships and the specific permissions those groups have.
Can read-only users modify dashboards in Finout?
No, read-only users cannot edit dashboards in Finout. While they have access to view all dashboards, their permissions are limited to viewing data only. This restriction is in place to prevent unauthorized modifications to dashboards, ensuring that only users with the appropriate permissions can make changes.
If a user belongs to multiple SAML groups that have corresponding groups in Finout, will Finout assign the user to all of these matching groups?
Yes, if a user belongs to multiple SAML groups that have corresponding groups in Finout, Finout will assign the user to all of these matching groups.
The Roles page contains all of your default or custom roles. In Finout, you have two types of roles:
Default roles are out-of-the-box roles provided by Finout, see the roles and permission overview for all default roles and their permissions. Here you can add custom roles or manage your existing roles.
Custom roles are created by selecting permissions that make up the role. A permission specifies which actions a user can perform in Finout. This enables you to assign specific roles to users tailored to your company's needs.
Note: Access to the roles page is restricted to admins and users with the "Read Roles" permission.
Find a particular word or phrase by searching all the data on the Roles page
A specific role with its permissions. You can click on a role to do various actions.
Assign specific roles to users tailored to your company's needs.
To create a new custom role:
In Finout, click on your username at the top right of the console and then select Admin Portal. The account profile appears.
Click Roles. You are brought to the Roles page.
Note: This page is only accessible by Admins.
Click Create New Role. The Create Role pop-up appears.
Add a role name and description.
Optionally toggle on Default role. This allows an Admin to assign any new user this default role by clicking the Copy invite link while inviting a new user. See Inviting a User.
Click Next. You are brought to the Choose permissions step.
Include or exclude permissions to customize your new role and click Create Role. See the list of permissions. Your new role is created and appears on the Roles page.
The Finout Metadata API allows you to query, analyze, and manage metadata associated with virtual tag values. It provides functionalities to retrieve existing metadata lists and add metadata for specific virtual tags. Results are returned in JSON format, facilitating seamless data processing and integration.
GET
/Virtual Tag Metadata
Returns a list of virtual tag values and their corresponding Metadata
Prerequisites
You must obtain the Virtual Tag ID by querying GET/virtual-tags.
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/virtual-tags/virtualtagid/metadata
Response
Bad Request
Unauthorized
Too many requests
Server unavailable
Gateway Timeout
Returns a JSON object with the following properties:
Request Id - The unique identifier for the API request.
Custom Metadata - Any metadata attached to the virtual tag.
PUT
/Virtual Tag Metadata
Enrich your virtual tag values with groups and custom metadata by adding them to your virtual tag and specifying them per value. This metadata is also used with other objects in Finout.
Note:
Currently, using virtual tag values metadata is only available in Financial Plans.
Adding virtual tag metadata using the PUT query overrides the current data in the virtual tag.
Documentation to learn more about utilizing metadata in financial plans is coming soon.
Prerequisites
You must obtain the Virtual Tag ID by querying a GET/virtual-tags.
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/virtual-tags/virtualtagID/metadata
Use Case:
Assume your organization has three teams: App Team, Data Team, and DevOps Team. You need to configure groups for each team and assign an owner name for each team.
Body of Request
Virtual Tag Value
String
customMetadata
Object
Any type of metadata can be attached to the virtual tag’s value. You must specify the custom metadata key and value.
Example:
groups
Array
The group of this specific value. You can use one or more groups.
endpoints
Array
An endpoint of this specific value. You can set one or more endpoints.
Example:
If the virtual tag’s value is "app team," you can provide the endpoint ID of the app team.
{
"endpoint":"endpoint-app-team-id"
}
Response
400
Bad Request
401
Unauthorized
429
Too many requests
503
Server unavailable
504
Gateway Timeout
Returns a JSON object with the following properties:
Request Id - The unique identifier for the API request.
Custom Metadata - Any metadata attached to the virtual tag.
The Users page contains all the users in your company who can access Finout. You can view, create, edit, and delete users and their roles.
Note: Only Admins can manage or invite users.
Search all the data on the User's page for a specific text.
View all the information for a single user.
Invite a user and define its roles.
Edit the roles of this specific user.
Resend an invitation email to this specific user.
Delete a specific user.
In the Roles view, you can edit, delete, and manage various attributes of your roles.
The role name and the number of permissions assigned to this specific role.
View all the permissions assigned to this role.
Edit your role name and description and add a default role.
Delete a specific role.
Include or exclude permissions from your custom role.
Include or exclude permissions to your role and click Save. The permissions for the role are changed.
Click Manage Permissions. The Manage role permissions pop-up for the role appears.
Change the Role Name and Description.
Default role - You can optionally: Toggle on - Toggle this role on to make it a default role. Toggle off - Toggle this role off if it was previously chosen as the default role and you do not want it to be the default anymore.
Note: A default role allows an Admin to assign any new user this default role by clicking the Copy invite link while inviting a new user. See Inviting a User.
Click Save. The role details are changed.
Click Delete Role. The role is deleted, and all users and groups assigned to this role will no longer have it. Users will have read-only permissions for all platform tabs and can only view the Profile tab in the Admin Portal.
Permissions specify the range of actions- Such as viewing, creating, editing, or deleting- that can be executed on Finout's resources. Each role contains a set of these permissions. Roles are assigned to users and a single user can inhabit multiple roles, inheriting the combined permissions of each.
In the Finout app you can find 4 pre-defined roles with their pre-defined list of permissions:
Admin role: Has view, create, edit, and delete permissions.
Read-only role: Has view permissions.
Basic role: Has view permissions, and additional permissions, for example, save, edit, and rename Views, and full access to Slack endpoints.
API token role: Has permissions relevant to using the Finout API.
Based on a user's assigned role, certain actions will be automatically restricted. For instance, under the Costs centers tab in Settings, the Add cost center button is deactivated for users with a 'read-only role'. Users needing additional permissions should reach out to their system admin.
In upcoming updates, we are working on allowing users to establish custom roles tailored to their accounts. For more details, please reach out to our support team at support@finout.io.
Dashboards
View Dashboards
✔
✔
✔
Edit Dashboards
✔
✔
Create Dashboards
✔
✔
Delete Dashboards
✔
✔
Virtual Tags
View V-Tag
✔
✔
✔
Create V-Tag
✔
✔
Edit V-Tag
✔
✔
Delete V-Tag
✔
✔
General
Full access to views
✔
✔
Can only view
Create API tokens
Anomalies
View Anomalies
✔
✔
✔
View Anomalies Feed
✔
✔
✔
View Managed Anomalies
✔
✔
✔
Create Anomalies Alert
✔
✔
Edit Anomaly
✔
✔
Delete Anomaly
✔
Clear all anomalies
✔
Data Explorer
View data explorers
✔
✔
✔
Create data explorers
✔
✔
Edit data explorers
✔
✔
Delete data explorers
✔
✔
Financal Plan
View financial plans
✔
✔
✔
Edit financial plan line items
✔
Edit line item by group
✔
✔
Create financial plans
✔
Delete financial plans
✔
Enable/Disable line items
✔
Edit Financial Plan Settings
✔
Bulk Upload CSV
✔
Add custom line to Financial Plan
✔
✔
Reports
View Report
✔
✔
✔
Create Report
✔
✔
Edit Report
✔
✔
Delete Report
✔
✔
Resources
View Resources
✔
✔
✔
My Commitments
View My Commitments
✔
✔
✔
Commitments Log
View Commitments Log
✔
✔
✔
Settings
View custom Drill Down
✔
Create custom Drill Down
✔
Edit custom Drill Down
✔
Delete custom Drill Down
✔
View custom Endpoints
✔
Create custom Endpoints
✔
Edit custom Endpoints
✔
Delete custom Endpoints
✔
Write account settings
✔
View cost center
✔
Create cost center
✔
View Custom cost
✔
Connect Custom cost
✔
Delete Custom cost
✔
View groups
✔
Create groups
✔
Edit groups
✔
EDP
Manage EDP
✔
Governance
Create Policies
✔
✔
Edit Policies
✔
✔
Delete Policies
✔
✔
View Policies
✔
✔
✔
Views
View views
✔
✔
✔
Create views
✔
✔
Edit views
✔
✔
Delete views
✔
✔
You can add more roles or delete roles from a specific user.
To edit a user’s roles:
In Finout, click on your username at the top right of the console and then select Admin Portal. The account profile appears.
Click Users. You are brought to the Users page.
To edit a role, you can:
Delete a role by clicking the X on the role you want to delete.
Click Update. Your user’s roles are updated.
When creating a new group, you will be requested to define the group’s role and select the group members, either by picking individual members, or via SAML group(s) integration.
Log in to Finout as an Admin user.
Navigate to Settings.
Select the Groups tab.
Choose Create Group.
Input a suitable Group Name.
(Optional) Define the Group Role, e.g., Admin.
Each user in a group inherits the role assigned to that group. A user's permissions are then a union of both their role and the group's role they are a part of.
(Optional) Provide a brief Group Description.
Add individual group members or input a group using the SAML Group mapping. Repeat this process for each user or SAML group you want to include in the group.
Note:
When adding a SAML group in Finout, ensure that the group name is exactly the same as your SAML group name.
Once you add SAML groups, all users within that group will be automatically linked to the new group as soon as they log into Finout.
Once Done, click Create to finalize the group setup.
Note:
SAML Mapping: To use SAML mapping, you need to configure your SSO provider to send the SAML Groups Attribution. Please follow the instructions on your SSO provider to enable SAML Groups Attributes.
See how to Configure Okta to Send the Groups Attribute.
Invite users to Finout by defining their roles or by sending them a link with a predefined default role.
To invite a user to Finout:
In Finout, click on your username at the top right of the console and then select Admin Portal. The account profile appears.
Click Users. You are brought to the Users page.
Click Invite User. The Invite User window appears.
Proceed with one of the following two options:
Manual invitation:
Enter the user's email.
Select a role.
Enter the user's name and optionally add the user's phone number.
Click Invite.
Click Copy invite link to send the new user an invitation link with a default role defined on the Roles page.
Note: If you defined a single or multiple default roles in the Roles page, the invitation link will include these default roles for the new user.
Within the RBAC framework, Data Access Control determines the specific data sets visible to users.
By applying filters to a group, you ensure its members access only filtered data. Please note that users can be members of more than one group. This component ensures users engage only with the data relevant to their roles and responsibilities, avoiding unnecessary data and information visibility.
In Finout, you have the flexibility to create customized user groups, tailoring data access to fit specific requirements. For example, creating a group solely for the R&D team, ensuring access to only those datasets that are related to their work.
Important: Data Access is configured to be 'deactivated' by default. To enable Data access for your account, please contact our support team at support@finout.io.
Data Access Control must be enabled in the organization within Finout to start creating user groups based on specific data filters. This can be done only by a user with an Admin role who has permission to manage groups.
Log in to Finout as an Admin user.
Navigate to Settings.
Select the Groups tab.
Select or deselect Allow data access in my organization.
Click Continue. Once enabled, you can start creating groups and applying filters to them. See How to Edit Data Access.
You can tailor data so your group can be seen by implementing filters.
Log in to Finout as an Admin user.
Navigate to Settings.
Select the Groups tab.
Click on (⋮) next to the desired group and select Edit Group. The Group Settings appear.
In the Data Access tab, activate the Data access status. This action will enable data access for this group.
Customize the group data by choosing the cost filter options for the group:
Select the desired Cost center, for example, AWS.
Select the relevant key, for example, Regions.
Select the relevant operator, for example, Contains.
Specify the necessary Values.
(Optional) Click Add new filter if you wish to add additional filter criteria.
Click Save to apply the changes.
Proper endpoint configuration ensures that your teams are always informed and equipped to act swiftly, keeping operations running smoothly and costs under control. It also ensures that alerts reach the right teams or individuals without delay. Configure the following endpoints to send Alerts and Notifications:
Finout provides flexibility in managing group members. Whether you're creating a new group or updating an existing one, you can easily add or remove users and SAML groups.
Log in to Finout as an Admin user.
Navigate to Settings.
Select the Groups tab.
Click on (⋮) and select Edit Group.
Navigate to the Users & SAML Mapping tab.
To add users to the group, select the new users from the drop-down under Select group member.
To remove a member from this group, click on (⋮) and select Remove user.
In the Users and SAML mapping tab, use the free text option to input the desired SAML mapping and click + ADD.
The added SAML group will be displayed in a table under the SAML group tab.
Note: A numeric indication next to the group name indicates the number of groups added.
To add more SAML groups, simply repeat step 5 for each group.
To remove a SAMK mapping group, click the three dots and select Remove SAML group.
Log in to Finout as an Admin user.
Navigate to Settings.
Select the Groups tab.
Click on (⋮) and select Edit Group.
Select the Group settings tab.
In the Group settings, you have the option to edit the group name, role, and description.
Configure the profile claims and Group Attribute Statements.
The object that defines the value for the virtual tag. This can be of any value. Limitation: Virtual tag values in this specific endpoint cannot include dots. For more information, see .
If you want to assign an owner to a virtual tag’s value, you can set "owner" as the custom metadata key and "owner_name" as the custom metadata value. For more information, see .
To get account group IDs, contact your customer success representative. For more information, see .
To learn how to get a list of your account's endpoints, see . See to learn how to send reports to various endpoints.
Click and then click Edit Role Details. The Edit Role Details pop-up appears.
In the Roles view, click and then click Delete Role. The Delete Role pop-up appears.
Click and then click Edit Roles. The Edit Roles pop-up appears.
Add a role by clicking and then choose a new role for the user.
To seamlessly integrate Datadog metrics with Finout, start by linking your Datadog API with Finout. This connection is crucial for Finout to fetch daily telemetry data, enhancing your insights into unit economics and enabling more accurate shared cost reallocation.
Why should I connect a Datadog external metric to Finout?
To reallocate shared costs more effectively.
Creating unit economics using our unit economics widget.
Ensure your Datadog API is integrated within Finout, a step necessary for both tracking Datadog-related expenses and importing metrics. For a metrics-focused integration without the cost monitoring component, ensure your Datadog API key is enabled for timeseries_query permissions. While integrating Datadog's cost center is recommended for a holistic view, it is optional for metrics-only scenarios.
Please refer to Finout's Datadog integration guide for complete setup instructions.
Note: While the guide discusses cost integration, the same principles apply for metric data integration.
Choose and format the Datadog metric you wish to export to Finout by determining the appropriate aggregation function, metric name, filters, and grouping parameters. This process involves selecting the specific Datadog metric, applying the correct aggregation function, and setting relevant filters and group parameters to refine your query.
Example queries:
For counting instances: "query": "sum:my_metric{status:200} by {host}.as_count()",
To summarize over time: "query": "avg:my_metric{*} by {region}.rollup(sum, 3600)",
Important: Additional Information: The data retrieved will be documented with daily granularity, capturing all associated tags with the metrics. This ensures a detailed and flexible use of metrics within Finout.
Please provide Finout with the following information:
Formulated query string
Custom metric name
The data will be captured daily and include all metric tags, enriching your Finout analyses and decision-making capabilities.
The MegaBill filter API allows users to query and retrieve metadata for building filters on a huge dataset. This API provides endpoints to fetch MegaBill keys, values, virtual tags, and specific metadata for individual keys. This API is used to understand the different building blocks of Finout’s MegaFilter, and the information needed to build Virtual Tags and views.
GET
/Keys
Retrieves all MegaBill keys.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/megabill/query-language/keys
Response
Returns a JSON object with the following properties:
keys
array
An array of key metadata objects.
requestId
number
The ID of the request in the Finout system.
accountId
number
The ID of the account that made the request.
The key_metadata array has the following fields:
costCenter
string
The cost center associated with the key (display name).
"databricks"
key
string
The unique identifier in Finout.
"a3ViZXJuZXRlczpsYWJlbF9zcGFya19zcGFya19leGVjX2lk"
displayName
string
The external name identifier in Finout, is only used in Finout’s app.
"job-id"
GET
/KeyValues
Retrieve all values associated with a specific key. A successful response allows you to construct a virtual tag condition based on the key values and operators.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
You must first GET the key you want to query and then find the "cost center and "key".
Request
http://app.finout.io/v1/megabill/query-language/values/{costcenter}/{key}
Path Parameters
cost_center
string
The ID of the cost center.
key
string
The ID of the key.
Response
Connect Finout to your Snowflake account to gain detailed insights into your Snowflake costs. Choose from two secure authentication methods—key-pair authentication or password-based—to integrate your data seamlessly. This setup allows you to visualize and analyze your expenses precisely, offering a clear view of cost trends and allocations within your Snowflake environment.
What you will do for the Snowflake configuration: 1. Create permissions in Snowflake 2. Authenticate Snowflake into Finout
Log into your Snowflake account using your login credentials.
Create a Finout Permissions in Snowflake:
Open a new worksheet in your Snowflake console.
To set up a dedicated warehouse, role, and user for Finout, paste the following query, ensure secure access by restricting the connection to specific IP addresses used by Finout, and then run the following command:
Note: If you choose to use Key-pair authentication, you do not need to set a password when creating the user.
Navigate to Settings > Cost Centers and click Add Cost Center. The Connect Accounts window appears.
In Snowflake, click Connect Now. The Connect Snowflake wizard appears.
Enter the following details:
Cost Center Name: Enter the name of the cost center associated with this Snowflake account.
Username: Provide the username of the dedicated Finout user created in Snowflake.
Snowflake URL: Enter your Snowflake account URL.
Warehouse: Specify the warehouse (finout_warehouse) that was created for Finout.
Credits Cost: Enter the Snowflake credits per the compute and storage services.
Role: Enter the role (finout_role) created for Finout in Snowflake.
Database: Specify the Snowflake database where your cost data resides.
Add the price per TB of storage and the price of compute credit.
Note: This is only for multiple organization accounts. Single organization accounts are automatically created when credit cost data is provided
Click Next. You are brought to the Authentication Method step.
To connect Finout to Snowflake, you can authenticate using key-pair authentication or password-based authentication.
Key-Pair Generation: Finout will generate the key pair for you. We will securely store the private key, and you will receive the public key.
1.Update Your Snowflake User Table:
Open a worksheet in your Snowflake console.
Use the public key provided by Finout to update your Snowflake user permissions/authentication method:
ALTER USER <your_username> SET RSA_PUBLIC_KEY='<public_key>';
Replace <your_username> with your Snowflake username.
Replace <public_key> with the public key provided by Finout.
2.Complete the Setup in Finout: Return to the Finout console, mark I have completed the ALTER USER command in Snowflake, and click Next. Snowflake is onboarded and you will see Snowflake data in Finout within 24 hours.
Password Authentication: Connect Finout to Snowflake without leaving the Finout console.
You might choose the password option if:
Your environment doesn’t require the advanced security of key-pair authentication.
You’re looking for a simpler, faster setup with minimal configuration.
You prefer not to manage private keys or want to avoid the additional steps involved in generating key pairs.
Enter your password that was created in Snowflake (Step 1).
Click Next. Snowflake is onboarded, you will see Snowflake data in Finout within 24 hours.
Which Snowflake services are currently supported by Finout?
Snowflake - Warehouse Reader Credits (Compute)
Snowflake - Warehouse Credits (Compute)
Snowflake - Warehouse Credits (Cloud Services)
Snowflake - Storage
Snowflake - Serverless Task Credits
Snowflake - Search Optimization Credits
Snowflake - Replication Credits
Snowflake - Pipe Credits
Snowflake - Materialization Credits
Snowflake - Auto Clustering Credits
I already have a Snowflake Cost Center (CC) with password authentication. How can I change it to key-pair authentication?
Follow these steps to switch from password to key-pair authentication:
Request the public key: Contact Support to obtain the public key.
Update the Snowflake user: Insert the provided public key in your Snowflake console using the ALTER USER command. (See Update Your Snowflake User Table in step 2 > 5 > 1.)
Notify Support: Contact Support once you’ve added the public key so they can update the authentication method in Finout from password to key-pair.
Change or deactivate the password: Change or deactivate the password only after Support confirms that everything is working correctly.
Does Finout support granting nested roles in Snowflake?
No, at the moment, Finout does not support granting nested roles. The Finout role must have all the required permissions assigned directly.
Can I connect custom cost centers via Snowflake?
Yes, see Custom Cost Centers for more information.
How do Snowflake storage costs work?
To display daily costs, Finout calculates a derived daily rate by dividing the monthly storage cost per TB by the number of days in that month. Since months like February have fewer days, the daily rate appears higher, even though the total monthly cost remains unchanged. For a full breakdown of Snowflake’s storage pricing, refer to the official Snowflake documentation.
The cost of a Kubernetes (K8s) pod can vary depending on various factors, such as the size of the pod, the resources allocated to it, the duration of its usage, and the cloud provider or infrastructure used to run the pod. To accurately calculate the cost of a K8s pod, it is essential to consider the resources consumed by the pod, including CPU, memory, storage, and network bandwidth. The cost of these resources may differ depending on the cloud provider or infrastructure used.
Finout provides multiple ways to integrate your K8s clusters with MegaBill, including Datadog or with a cronjob that queries your Prometheus. Metrics are gathered from the source frequently, including CPU usage, memory usage, CPU request, memory request, and network usage.
Once the data is received, it is processed to determine how much of the allocated resources the pod has used per hour. The usage metrics are processed as follows:
Memory and CPU: This is done by identifying the maximum value of either the usage or request during the hour. For example, if the maximum request during the hour is 3 CPU units and the maximum usage is 1 CPU unit, the cost is based on 3 CPU units. If during the hour, the usage was 4 CPU units, the cost is based on 4 CPU units This is calculated for both CPU and memory for each hour and each pod.
Network usage: Finout calculates the total number of bytes per pod (both received and transmitted) per hour.
One of the unique features of Finout is that your cost data is fetched from all major cloud vendors. Finout can consume, for example, the AWS Cost and Usage Report (CUR) and determine the exact cost of a single node, accounting for special pricing and discounts, such as Saving Plans, Reserved Instances (RIs), Spot Instances and if needed your EDP. This allows Finout to calculate the hourly node cost accurately.
To calculate the cost of a pod, Finout uses the hourly CPU, memory, and network allocations (step 2), along with the hourly node cost (step 3), to determine the pod's CPU and memory cost, respectively.
CPU & memory
The hourly node cost is reported as a total cost and represents the cost for CPU and memory resources. The problem is that the cloud provider does not provide a CPU/memory breakdown. To apportion the costs to CPU and memory costs correctly, Finout specifies a configurable CPU/memory ratio for each resource, cluster or namespace.
The following formulas are used for calculating the cost of CPU and memory within the node are used to derive this ratio:
Old Ratio:
The old 50:50 CPU-to-memory ratio for existing accounts is being enhanced to provide better accuracy in cost distribution. This balanced split was ideal for average workloads but could result in inaccurate financial reporting when actual resource configurations differ.
The CPU/Memory pricing of the old ratio is calculated using the following formulas:
1. Hourly Pod Price - This refers to the cost of the pod per hour, which is the total price without distinguishing between memory and CPU usage. It is derived directly from the bill and represents the node price, or the cost of the underlying infrastructure. The following formulas are used for calculating the cost of CPU and memory within the node are used to derive this ratio.
2. CPU Calculation - The data is used to determine how much of the node was allocated to CPU. See the full explanation about parsing the metrics per pod in step 2.
3. Hourly Pod CPU Price - Calculates the CPU cost out of the total node cost, using the allocation ratio, considering the actual time the node was active and in use.
4. Memory Calculation - The data is used to determine how much of the node was allocated to Memory. See the full explanation about parsing the metrics per pod in step 2.
5. Hourly Pod Memory Price - Calculates the Memory cost out of the total node cost, using the allocation ratio, considering the actual time the node was active and in use.
Refined Ratio:
Finout offers an 88% CPU and 12% memory ratio for more precise cost allocation, reflecting real-world usage where CPU is usually more expensive than memory.
The CPU/Memory pricing of the refined ratio is calculated using the following formulas:
These formulas calculate the price of a single CPU or memory unit within the node. To determine the total CPU or memory cost for the entire node, multiply the result by the number of cores or GB available in the node.
Formula Explanation:
Instance Price Per Hour = the hourly price of the node. See the Hourly pod price explanation in the Old Ratio.
CPU Count = number of cores within the pod
CPU Ratio = 88% by default
RAM (GB) = the number of GBs within the pod
Memory Ratio = 12% by default
Note: - The data is sampled at a one-minute resolution every 30 minutes, with the 30-minute interval being configurable per account.
- This ratio can be changed per account. Contact Finout support for more assistance. - The refined ratio is the default calculation for all new accounts.
- Accounts existing before November 2024 will have the old ratio, but they can transition to the refined ratio by contacting support@finout.io.
For each node, Finout can calculate the data transfer hourly cost, based on the information supplied by the cloud provider. To calculate the network cost for each pod, Finout uses the network received and network transmitted metrics per pod and divides the cost of the node up into the pods based on these network metrics.
The unallocated cost at the node level is also calculated, which is the difference between the hourly node cost and the sum of hourly pod costs running on that node. This helps identify any unallocated costs associated with idle or underutilized nodes.
With Finout's comprehensive cost calculation and reporting capabilities, you can gain better visibility into the cost of running K8s pods and optimize your cloud costs effectively. Our CostGuard dashboards provide valuable insights to help you make informed decisions and implement cost optimization efforts for your K8s workloads.
Custom Dashboards are user-defined visualizations that display specific metrics and data relevant to a Kubernetes cluster. These dashboards are highly customizable and can be tailored to a specific use case, allowing users to create visualizations that are meaningful and actionable.
To begin, go to the Dashboard feature in the navigation bar, and then click the Create Dashboard button located in the top right corner.
Once the new dashboard has been created, you will need to assign it a name and start adding widgets to it (you can add up to 20 widgets to each dashboard).
Two options for creating widgets:
Create a new widget
Use a previously saved widget
To create a widget in Kubernetes, follow these steps:
Widget type: Choose a widget type such as a Line chart, Bar chart, Pie chart, Table chart, or Free text.
Select a component: Choose between cost or unit economics. The business matrix will be available soon.
Data visualization: Select the visualization for the widget, such as Line chart, Bar chart, Pie chart, Table chart, or Bubble map.
Data Type: Select the data type for the widget, such as Cost, Total coverage, Saving plan coverage, Reserved instance coverage, Spot coverage, or On-demand coverage.
Filters: Choose your Kubernetes costs and select relevant Kubernetes drill-downs.
Group By: Group costs by Kubernetes resources such as namespace, deployment, and cluster or by labels such as node labels and pod labels to see specific costs in the widget.
Periodical Range: The widget will report daily by default, but you can manually change it to weekly or monthly.
Widget name: Give the new widget a name.
Advanced Settings: Give your widget a description if relevant or choose a cost type.
Once you have added widgets to your custom dashboard, you have several options to manage them. You can edit a widget, duplicate it, download it as a CSV file for further analysis, or delete it.
The Virtual Tags API allows you to create, retrieve, update, and delete Virtual Tag configurations. Virtual Tags organize and categorize data based on custom rules and filters.
Note: The Reallocation and MegaBill Key segmentation are currently unsupported in the Virtual Tag API.
GET
/Virtual Tags
Retrieves all virtual tag configurations.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/virtual-tags
Response
400 - Bad Request
401 - Unauthorized
403 - Forbidden
404- Not Found
429 - Too Many Request
500 - Internal Server Error
Unprocessable Request
POST
/Virtual Tag
Create a new virtual tag.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Request
https://app.finout.io/v1/virtual-tags
Body parameters
name
string
The name of the virtual tag.
rules
array
defaultValue
string
The defaultValue object.
Response
PUT
/Virtual Tags
Update a current virtual tag.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Get a virtual tag ID.
Request
https://app.finout.io/v1/virtual-tags/{id}
Path parameter
ID
String
The ID of the Virtual Tag is to be updated.
Request Body Parameters
name
string
The name of the Virtual Tag.
rules
array
defaultValue
string
The defaultValue object.
Response
GET
/Virtual Tag By ID
Retrieves the specified Virtual Tag configuration.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Get a virtual tag ID.
Request
https://app.finout.io/v1/virtual-tags/{id}
Path Parameter
id
String
The id of the Virtual Tag to retrieve.
Response
DELETE
/Virtual Tag
Deletes the specified Virtual Tag.
Prerequisites
Generate a Client ID and Secret Key from Finout to add in Headers.
Get a virtual tag ID.
Request
https://app.finout.io/v1/virtual-tags/{id}
Path parameter
id
string
The id of the Virtual Tag to delete.
Response
The Virtual tag is deleted.
The Virtual Tags object represents a configuration used for resource allocation and filtering. It contains the following fields:
accountId
string
The unique identifier of the account is associated with the Virtual Tag.
"e12498cc-594a-4740-94a5-8324e7399bb2"
name
string
The name of the Virtual Tag.
"nir test"
rules
array
An array of RULE objects that defines the filtering criteria for the Virtual Tag.
createdBy
string
The name of the user who created the Virtual Tag.
"Nir"
updatedBy
string
The name of the user who last updated the Virtual Tag.
"Asaf Liveanu"
defaultValue
string
An object defining the default value for the Virtual Tag.
“untagged”
createdAt
string
The date and time when the Virtual Tag was created.
"Tue May 16 2023 13:15:53 GMT+0000 (Greenwich Mean Time)"
updatedAt
string
The date and time when the Virtual Tag was last updated.
"Sat Jun 10 2023 16:06:25 GMT+0000 (Greenwich Mean Time)"
id
string
The unique identifier of the Virtual Tag.
"b11c9be2-b7a0-4209-a00e-44ac2ccce0f7"
“Rules” object definition
Field
Type
Description
Example Value
to
string
The destination or target for the filtered data.
"Data Team"
filters
object
An object containing the filter conditions for the rule.
The API returns standard HTTP error codes to indicate the success or failure of a request. The following common HTTP errors may be returned:
400 Bad Request: The request is malformed or missing the required parameters. Check the request structure carefully for syntax typos and resubmit the request.
401 Unauthorized: The request lacks valid authentication credentials. Ensure that you have added your credentials to the request header and resubmit your request. If this still doesn't work, contact Finout Support.
403 Forbidden: The request is understood, but the server refuses to fulfill it due to access restrictions. Contact Finout Support.
404 Not Found: The requested resource is not found. Resubmit the request with a valid resource ID.
429 Too Many Requests: The user has sent too many requests in a given period.
422 Unprocessable Request: Check the virtual tag composition and structures.
500 Internal Server Error: An unexpected error occurred on the server.
An array of rules defines the filters and conditions for the virtual tag. See
An array of rules defines the filters and conditions for the virtual tag. See .
See for more information.
See for more information.
A Slack notification endpoint is a webhook that enables you to send notifications from Finout to a specific Slack channel or user. When a notification endpoint is configured, Finout can send messages to the specified Slack channel or user by sending a POST request to the endpoint URL.
These notifications can include alerts, updates, or other relevant information that needs to be communicated to team members in real-time.
By utilizing Slack notification endpoints, teams can streamline their communication processes and ensure that important information is always delivered to the right people, at the right time, and in the right format
If you want to send your report to Slack, configure a Slack webhook and create a Slack endpoint. You can test your endpoint when you create it.
Configure a Slack webhook as described in Slack Documentation.
Select Settings > Endpoints.
Click Add endpoint.
Enter an Endpoint name.
Enter a Description.
Enter a Slack webhook URL.
To test the endpoint, click Test Endpoint.
Click Add Endpoint.
For more information about endpoints and how to connect to a report, please refer to the Reporting documentation.