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.

Discover Finout

Configuration and Administration

Finout Demo

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.

What is a Cost Type?

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.

Cost Type Definitions

• 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.

Cost Type Mapping Across Providers

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 References

• https://aws.amazon.com/blogs/aws-cloud-financial-management/understanding-your-aws-cost-datasets-a-cheat-sheet/

• https://docs.aws.amazon.com/cost-management/latest/userguide/ce-advanced.html

• https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/con-bill-blended-rates.html#Blended_S3_Stand_Storage

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.

Inform

Optimize

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:

1. Discount Percentage- Represents the percentage of the discount.

2. Discount Rate- Represents a change in the actual rate itself.

Who Can Benefit from Finout's EDP Feature?

• 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​​.

Set Up Your EDP

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:

1. In Finout, navigate to Settings and click EDP Setup. ​
2. Configure you EDP:

   • If this is your first time setting up an EDP in Finout, click Add new EDP.
3. 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. ​

4. Click Apply EDP Tag. After applying the EDP tags, you will see a preview of your configurations.

Manage your EDP

Manage your EDP by enabling EDP adjustments and specific cost types.

Enable EDP Adjustments

Enable this EDP to allow all users to see the cost data with EDP adjustments on all Finout pages.

To enable EDP adjustments:

1. In Finout, navigate to Settings. You are brought to the Account Settings tab. ​
2. 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.

Enable EDP for Specific Cost Types

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:

1. In Settings, navigate to the Account Settings tab.
2. 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.
3. Click Apply. EDP is applied to cost types as default to all views.

Incorporate EDP into MegaBill

After EDP Is set up, you can instantly see it in your MegaBill by toggling the Show cost with EDP.

Still need help? Please feel free to reach out to our team at support@finout.io.

Overview

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 a View

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

FAQs

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.

Introduction

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.

Challenges and Solutions

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.

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.

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

FairShare and Amortized Cost Comparison

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.

1. 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.
2. 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.
3. 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.
4. 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.

Use Cases

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.

How Does It Work?

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.

FairShare Cost Calculation

1. 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.

1. 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 ​

1. 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

1. 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)

Net FairShare Formula: (Relative Group Net Cost × Group-Level Commitments) + (Relative Global Net Cost × Global Commitments)

Technical Use Case

Resources

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

Commitments

• 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 ​

FairShare Cost Calculation for a Resource in Group A

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 ​ ​

FairShare Cost Calculation for a Resource in Group B

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

FAQs

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.

Adding a New Finout User

1. Log into your Finout account with Admin role credentials.
2. Click on your username, then select Admin Portal.
3. Navigate to the Users section.

1. Choose Invite User. The Invite User popup appears.

1. Provide the new user’s Email.

3. Fill in the user’s Full Name.

4. Optionally enter the user’s Phone Number.

5. Optionally copy the invite link and forward it directly to the user.

6. 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.

Account Activation for New Users

As a new user of Finout, account activation is a necessary step before diving in. To activate your Finout account:

1. Access the Activate Your Account email.
2. Click on Activate my account.
3. Set a New password and Confirm new password.

4. Click Activate. Following this, you are all set to explore Finout.

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:

• Confluent

• Databricks

• Snowflake

• Jira

• Datadog

• Microsoft Teams

• ServiceNow

• Custom Cost Centers

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:

• AWS

• Azure

• Oracle

• GCP

SSO Overview

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.

Connect Your ​​SSO Providers to Finout

Follow this procedure to integrate your SSO provers with Finout.

To connect SSO providers to Finout:

1. In Finout, navigate to the Admin Portal.
2. In the Admin Portal navigation bar, click SSO.
3. Click on Setup SSO connection. The Setup SSO connection appears.

1. Select the SSO provider with which you wish to connect with Finout.

   Note: It is recommended to choose the SAML integration.

2. Follow the onscreen instructions for the chosen SSO provider. You are redirected to the Self-service SAML configuration/SSO configuration.
3. 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.
4. 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.
5. Assign default roles to all SSO users by adding one or more account roles from your list of predefined roles.

6. 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.
7. Click Done and save the connection.

8. Login into Finout using the SSO to ensure that it is enabled.

   Note: For more information, see Frontegg documentation.

FAQs

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.

Azure Integration Overview

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:

1. Create a Service Principal for Finout

2. Create the Billing Export

3. Grant Finout Read-Only Permission from the Export Storage

4. Integrate Azure with Finout

1. Create a Service Principal for Finout

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.

a. Create a service principal using the CLI

1. From the CLI, type the following:

az ad sp create-for-rbac -n "finout"

1. You will receive an output similar to the following:

{
  "appId": "3c666g0g6-8cb8-8b33-cba6-abc7676a8989",
  "displayName": "finout",
  "password": "789************************",
  "tenant": "6666b777-ba88-44a9-a4aa-666ccb222a91"
}

b-1. Create a service principal using the Azure portal

1. From your Azure portal, search for and select Azure Active Directory.

2. Select App registrations, then click New registration.
3. Name the application (For example, "Finout").

4. Leave the default values in the rest of the parameters and click Register.

5. 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

b-2 Set up the authentication

For the Finout integration, use the password-based authentication (application secret) method by following these steps: ​

1. Select Certificates & secrets from the left-hand menu on the app registration page.
2. Click + New client secrets to create a new client secret.

3. 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.

4. Copy the Value from the Client secret to the Application secret field in the Finout console (step 4).

2. Create the Billing Export

In this step, create the export for the billing scope and grant Finout read-only access to these export files.

Create the report exports on the billing scope:

The reports must be exported twice, once for each of the following cost types:

1. Actual cost

2. 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:

1. In Azure, navigate to Cost Management.
2. Click Exports in the left-hand menu.
3. From the Export screen, click + Create. The New export page appears.
4. 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.
5. 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

6. Click Next. You are brought to the Review and Create tab.

7. Review the summary and click Create.

8. After the export is created, select it from the export page and click Run now.

3. Grant Finout Read-Only Permission from the Export Storage

Grant read-only permission by using Azure CLI or the Azure portal.

Grant permissions using Azure CLI

• Type the following command in your CLI and fill in the parameters according to the role and storage details:

  Copy

  az role assignment create --assignee <app_id> --role "Storage Blob Data Reader" --scope /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Storage/storageAccounts/<storage_account_name>/blobServices/default/containers/<container_name>

Grant permissions using the Azure portal

1. From your Storage account page, click Containers and select the export container.

2. Select Access control (IAM).

3. Click +Add and then click Add role assignment.

4. Search for Storage blob data reader, select it, and then click Next.

5. Click + Select members and find the Finout service principal.

6. Select the Finout service principal and click Select.

7. Click Review + Assign.

4. Integrate Azure with Finout

1. Navigate to Settings > Cost Centers and click Add cost center. The Connect Accounts window appears.
2. In Azure, click Connect Now. The Azure integration window appears.
3. Add the details saved from step 1 and click Next. You are brought to the Create the billing export page.
4. Add the details saved from step 2 and click Next. The integration is complete.

Oracle Integration Overview

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.

1. Create a New Group for Finout

Access permissions in Oracle are assigned to groups. Create a separate group for Finout to ensure access only to the necessary billing resources.

1. Go to the OCI navigation menu → Identity & Security → Domains → <Finout domain> → Groups (in the right-hand menu).

1. Click Create Group.

1. Fill in the Group Name and add some Description.

1. Click Create.

2. Add the Group a Policy to Access the Cost Reports

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.

1. Go to the OCI navigation menu → Identity & Security → Policies.
2. Click Create policy.

3. Choose a name for the policy that clearly indicates its purpose for accessing cost reports.

4. 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

5. Click Create.

3. Create a User for Finout

1. Go to the OCI navigation menu → Identity & Security → Domains → Users.
2. Click Create User.
3. Fill in the name and email of the Finout user.

4. Assign the user to the new Finout group you created in step 1 by selecting the appropriate box under the Groups section.

1. Click Create.

4. Generate an API Key

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:

1. Ensure an administrator user is logged into Oracle, as only administrators can perform these steps.

2. Navigate to Identity & Security → Domains → <Finout user domain> → Users, and click the Finout user to access their profile.
3. Navigate to the Resources section in the bottom left screen and select API keys.
4. Make sure that the Generate API key pair is chosen.

5. Click Download Private Key and save the key in a local directory.

6. Click Add.
7. 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).

5. Integrate Oracle with Finout

1. In Finout, navigate to Settings > Cost Centers and click Add cost center. The Connect Accounts window appears.
2. In OCI, click Connect Now. The Connect to OCI window appears.
3. 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.

4. Click Next. The cost center is created.

AWS Integration Overview

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:

1. Configure a CUR in AWS

2. Verify that your tags are activated

3. Obtain External ID from Finout

4. Grant Finout Access to Your CUR Bucket

5. Add bucket details to Finout

1. Create a CUR in the AWS Console

To begin using Finout to monitor the cost of your cloud bill, Finout needs access to your Amazon Cost and Usage Report (CUR).

​To create a CUR in AWS:

1. Sign in to your AWS console and create a new CUR.
2. Mark Legacy CUR export.
3. In Export name, enter a report name. Example: yourcompanyname-billing-reports

4. Export content:

   - In Additional export content, mark the following:

   1. Include resource IDs - Ensure that this is marked for successful configuration.

   2. 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.

5. Data export delivery options:

   1. Ensure the time granularity is marked Hourly.

   2. Choose either Create new report version or Overwrite existing report. Both report versioning types are supported.

   3. Choose the Parquet compression type

6. Data export storage settings:

   1. • Create the destination bucket to store the cost and usage data:

        1. Add a bucket name. Save it for future use in step 5.

           1. Choose a region. Save it for future use in step 5.

           2. Mark The following default policy will be applied to your bucket.

           3. Click Save. Your bucket is created.

   2. Add your S3 path prefix. Save it for future use in step 5.

7. Click Next and then Review and Complete. The report is created within a few hours.

2. Verify Tag Activation

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:

1. Go to the cost allocation tags screen: https://console.aws.amazon.com/billing/home#/tags

2. Ensure that all the tags you want Finout to analyze, both now and in the future, are activated.

3. Obtain External ID from Finout

Get the external ID in order to Grant Finout Access to Your CUR Bucket.

1. Navigate to Settings > Cost Centers and click Add cost center. The Connect Accounts window appears.
2. In AWS, click Connect Now. The Connect to AWS window appears. ​
3. Copy the External ID and continue to grant Finout access to your CUR bucket.

4. Grant Finout Access to Your CUR Bucket

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.

To grant access using CloudFormation:

1. Create a CloudFormation Stack from a template by following the instructions on the AWS website. ​

2. Use the following Amazon S3 URL for your Stack template. ​
3. Complete the steps by adding the “external-id” (obtained in step 3) and the bucket name created for your CUR (step 1).

4. Click Next and then Submit. ​You are brought to the Stack details page.
5. Click Output and copy the ARN IAM role value to add in Finout (step 5). ​

To grant access manually:

1. Click on creating a new cross-account role in IAM to create a role for another AWS account.
2. In the account ID, enter: 277411487094.

3. Paste the Require external ID and enter the “external-id” (obtained in step 3).
4. Click Next. ​The Review step appears.
5. Add a Role name: FinoutMetricsReadOnlyRole and then configure the role. A new role is created.

6. Go to your new role in Summary.
7. Copy the Role ARN and save it for use in Finout (step 5).

8. Click on Add permissions and choose Create inline policy.

9. 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:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"tag:GetTagKeys"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "arn:aws:s3:::<CUR_BUCKET_NAME>/*"
},
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "arn:aws:s3:::<CUR_BUCKET_NAME>"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances*",
"ec2:GetReservedInstances*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"savingsplans:DescribeSavingsPlan*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action":[
"organizations:ListAccounts",
"organizations:ListTagsForResource"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ce:GetReservationUtilization",
"ce:GetSavingsPlansUtilization",
"ce:GetSavingsPlansUtilizationDetails",
"ce:GetCostAndUsage",
"ce:GetCostAndUsageWithResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["ec2:DescribeVolumes"],
"Resource": "*"
}
]
}

1. Click Next until the Review step, and name it finout-access-policy.

2. Click Create policy. Your IAM role is finalized and created.

5. Adding AWS Bucket Details to Finout

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:

1. Navigate back to the Finout console that you used in step 3.
2. Fill in the following fields:

   1. Add a personalized Cost Center Name.

   2. Add the Role ARN from step Grant Finout Access to Your CUR Bucket. The Amazon Resource Name (ARN) specifies the role.

   3. 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.

   4. 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.

   5. Add the Region from Create a CUR in the AWS Console step 7.

3. Click Continue. After verifying the information entered, Finout will create a new cost center.

Connect AWS China to Finout Billing

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.

Frequently Asked Questions About CUR Integration

• 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.

Datadog Overview

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.

Datadog Integration

1. Create an API Key

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.

2. Create an Application Key

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).

3. Finout Console Integration

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.

Connect ​​Confluent to Finout

1. Navigate to confluent cloud home.
2. Select the menu on the right and choose Cloud API keys.
3. Click on Add key.
4. Choose Granular access.
5. Select Create a new one, input a new service account name and description, and proceed (a new service account will be created).

6. Once the key is generated, an option to describe it appears. Click Download and continue.

Grant permissions to the cloud API key

1. On the right menu, select Accounts and Access.
2. Navigate to Service Accounts under Accounts.

3. Search for the newly created service account and select it.
4. Select Add role assignment under organization.
5. Choose BillingAdmin and confirm this choice.
6. Provide Finout with the generated API key and secret.

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.

On-Demand vs. Commitment Costs

Datadog on-demand costs

These represent pay-as-you-go expenses, accruing and displaying on the relevant days when on-demand usage occurs.

Datadog commitment costs

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.

Finout’s Model for Commitment Costs Across the Month

API Cost (“Unblended Costs”)

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.

“Amortized” Costs

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.

Reasoning for Infra host, APM hosts, and Timeseries cost spikes on the 1st of the month

1. 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.

2. 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.

Overview

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.

Prerequisites

Before starting the integration process, ensure the following prerequisites are met:

• Consistent Tenant
• App Installation Permissions

Integration WorkFlow

Step 1: Initiate Integration from Finout

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.

1. 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.

Step 2: Install Finout Application on Microsoft Teams

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.

Step 3: Setup Notification Endpoints

• 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.

FAQ

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:

1. Delete Finout app from Teams.

2. 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.

Security Considerations

• 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.

Grant Finout Access To Your Bucket

After creating the bucket, you need to grant Finout access to your bucket by creating an IAM role.

1. Copy your “external-id” from the Finout console, or use a random one, preferably in the format of finout-XXXXXXX

3. In the Account ID field, enter: 277411487094.

4. Select the Require external ID option, and enter the “external-id” you got from the previous section.
5. Click Next until the review screen is displayed. Then configure it as shown below and click Next.
6. Go to your newly created role.
7. Copy the Role ARN and paste it into the Finout console.

8. Click Add permissions and select Create inline policy.

9. 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)

1. Click Next until the review screen is displayed, then name it finout-access-policy.

2. Click on Create policy to have your policy created for the IAM role.

3. Send Finout the following details:

   1. The newly created role

   2. The external ID

   3. Bucket name

   4. Path in the bucket

   5. Region

4. Provide Finout with the cost per DBU for each Databricks service.

Basic Datadog Integration

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

Enhanced Datadog Integration- Cost Per Tag Visibility

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:

• Default Datadog set of tags per product

  For example, the tags for Indexed Log- "service", "status", "datadog_index"

  Required scopes: metrics_read, timeseries_query

• Custom tags set by the customer

  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

Enhanced Datadog Integration - CostGuard

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

Enhanced Datadog Integration- Kubernetes Cost and Unit Metrics

Required scopes: not scoped

GCP Integration Overview

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.

1. Billing Export from GCP

1. In the Google Cloud account, select Billing.
2. Choose Billing export.
3. Make sure that the Detailed usage cost is enabled.

2. Granting Finout access to GCP

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:

1. Search for Service Accounts, and click Create New.
2. Configure these three roles:

   BigQuery Data Viewer BigQuery Job User BigQuery Read Session User

1. Leave section 3 blank and click Done.

2. From the context menu, select Manage Keys.
3. Click Add Key and Create New Key.
4. Choose JSON and paste the JSON in Finout's console:

GCP Credit Types

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.

FAQs

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

Jira Overview

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.

Connect ​​Jira to Finout

Step 1: Generate an API token in the Jira Cloud

1. Sign in to your Jira Cloud account.

2. Navigate to Account Settings and select Security.

3. Under API token, select Create and manage API tokens.

4. Select Create API token, provide the API with a name for easy identification, and securely save the generated token.

Step 2: Gathering necessary information for the Finout integration

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.

Step 3: Setting up the integration in Finout

1. In Finout, navigate to Settings.

2. Go to the Integrations.

3. Choose Create Jira Integration.

4. Enter the details from step 2: User Email, URL, and API Token.

5. Click Submit.

Selecting the Appropriate Jira Email Address

• 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.

Using a Dedicated Service User for the Integration

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.

Create a dedicated service user in Jira Cloud

Step 1: Create a new user account

1. Navigate to the user management section in Jira.

2. Create a new user, designated for the integration. Provide a clear user name such as integration_service_user, for easy recognition.

Step 2: Assign necessary permissions

• Provide the new user with the necessary permissions for tasks such as issue creation and management.

  Note: Avoid giving administrative rights unless necessary.

Step 3: Generate an API token

Advantages of using a dedicated service user

• 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.

Key points to consider

• 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.

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:

• Connect to Kubernetes Prometheus

• How Finout Calculates K8s Costs

• Kubernetes Megabill

• Kubernetes Budgeting

• Kubernetes Custom Dashboards

• Kubernetes Predefined Dashboards

• Ensure Compatibility of Your Kubernetes Monitoring with Finout

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.

If the data can be integrated into Finout using this format, it can be used as a telemetry source in Finout’s abilities.

Utilizing Telemetry Data for Shared Cost Breakdown

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.

Methods for Integrating Telemetry Data into Finout

To integrate your telemetry data with Finout effectively, please utilize one of the supported methods listed below.

1. 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.

2. Datadog- If your telemetry data is collected and managed via Datadog, integrate directly with Finout to import metrics.

3. Snowflake - Connect your Snowflake data warehouse directly with Finout. Documentation is coming soon.

4. 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.

Snowflake - Connect custom cost centers using the Snowflake table containing cost data.

Connect Custom Cost Centers via CSV

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.

Connect Custom Cost Centers Via Snowflake

The following table structure in Snowflake could be used for us to ingest custom data from:

create or replace TABLE FINOUT_COST_EXPORT ( SOURCE VARCHAR(100), USAGE_DATE DATE, SERVICE_NAME VARCHAR(1000), COST FLOAT, METADATA OBJECT );

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:

1. 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.

1. Add a policy to a K8s node worker to enable the CronJob to write permissions to your S3 bucket.

2. Create a CronJob to export the data from Prometheus to your S3 bucket.

1. Connect a S3 Bucket

The S3 bucket consists of the K8s data extracted from Prometheus. This bucket will have read-only permissions for Finout.

2. Add the K8s Worker Node Role Policy

If you have more than one cluster, repeat steps 2 and 3 for all of your clusters.

1. 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.

   Copy

   '{
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "VisualEditor0",
              "Effect": "Allow",
              "Action": "s3:ListBucket",
              "Resource": "arn:aws:s3:::<BUCKET_NAME>",
              "Condition": {
                  "StringEquals": {
                      "s3:delimiter": "/"
                  },
                  "StringLike": {
                      "s3:prefix": "k8s/prometheus*"
                  }
              }
          },
          {
              "Sid": "VisualEditor1",
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:GetObject",
                  "s3:DeleteObject"
              ],
              "Resource": "arn:aws:s3:::<BUCKET_NAME>/k8s/prometheus/*"
          }
      ]
   }'

2. 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: ​

   1. args: ​

   2. --port=8080

   3. --metric-labels-allowlist=pods=[*],nodes=[*]

3. Create and Configure the CronJob

1. 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.

2. Run the command in a namespace of your choice, preferably the one where the Prometheus stack is deployed: ​kubectl create -f <filename>

3. 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.

CronJob Yaml configuration example

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:

env:
  - name: QUERY_<QUERY_NAME>
    value: "<custom_query_value>"
  - name: TIME_FRAME
    value: "3600"
  - name: BACKFILL_DAYS
    value: "3d"

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

apiVersion: batch/v1
kind: CronJob
metadata:
 name: finout-prometheus-exporter-job
spec:
 successfulJobsHistoryLimit: 1
 failedJobsHistoryLimit: 1
 concurrencyPolicy: Forbid
 schedule: "*/30 * * * *"
 jobTemplate:
   spec:
     template:
       spec:
         containers:
           - name: finout-prometheus-exporter
             image: finout/finout-metrics-exporter:1.23.0
             imagePullPolicy: Always
             env:
               - name: S3_BUCKET
                 value: "<BUCKET_NAME>"
               - name: S3_PREFIX
                 value: "k8s/prometheus"
               - name: CLUSTER_NAME
                 value: "<CLUSTER_NAME>"
               - name: HOSTNAME
                 value: "<PROMETHEUS_SERVICE>.<NAMESPACE>.svc.cluster.local"
               - name: PORT
                 value: 9090
         restartPolicy: OnFailure

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.

Grant Finout Access to a S3 Bucket

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:

1. Go to your newly created role.

2. Click Add permissions and select Create inline policy.

3. Select JSON, and paste the following (change the <BUCKET_NAME> to the bucket you created or to your existing CUR bucket):

   Copy

   "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "tag:GetTagKeys"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:Get*",
                   "s3:List*"
               ],
               "Resource": "arn:aws:s3:::<BUCKET_NAME>/*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:Get*",
                   "s3:List*"
               ],
               "Resource": "arn:aws:s3:::<BUCKET_NAME>"
           }
       ]
   }

4. Click Next until the review screen appears, and name the policy finest-access-policy_K8S.

5. Click Create policy to create your policy for the IAM role.

6. Fill in all the details in the Finout console​.

FAQs

The following troubleshooting FAQs explain common integration issues and how to easily resolve them.

• Finout could not assume the role

  Finout could not assume the rolele that was created on your AWS console, review the role created for Finout and verify the trust policy. Also, verify that the external ID is the one provided by Finout.

• Finout could not access the provided bucket

  Review the relevant policy on the bucket according to the documentation and verify the region.

• S3 bucket doesn't exist

  Finout could not locate the provided S3 bucket. Make sure that the bucket provided exists.

• Finout could not read from your S3 bucket

  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:

"Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "tag:GetTagKeys"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::<BUCKET_NAME>/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::<BUCKET_NAME>"
        }
    ]
}

• Ensure Kubernetes Monitoring Compatibility with Finout and Prometheus

  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:

  1. Validate that your system exports the correct metrics, including memory, CPU, network usage, and node info.

  2. Deploy the Finout cronjob in your Kubernetes cluster.

  3. Configure connectivity with the necessary environment variables.

  4. Ensure Finout has the required permissions to access your metrics export.

  For detailed instructions and requirements, refer to the Finout integration documentation.

• The CronJob cannot find the Prometheus host

  Make sure the host and port are correct (using “kubectl get service”) and configure these as the HOST / PORT ENV VARS in the CronJob.

• The CronJob has no write permissions to the S3 bucket

  Apply the correct policy on the node worker or the pod. See instructions here.

• Missing memory metrics in Finout

  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.

1. 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.

2. Add or update the rule: If the rule is absent or improperly configured, add or amend it within your Prometheus configuration settings.

3. Reload the configuration: Implement the new or modified rule by reloading Prometheus’s configuration.

   1. Access the configuration: Open the Prometheus configuration, either directly through the file or via the UI.

   2. 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.

   3. 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.

• Finout exporter timeout with large Kubernetes clusters

  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.

• Monitoring various Kubernetes clusters using distinct tools within a single AWS environment for the Finout integration

  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.

• Missing metrics and deployment visibility

  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.

• Metrics exporter ran out of memory

  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.

• What should I do if the exporter is slow or failing due to high load?

  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.

• How can I collect additional metrics that Finout doesn’t include by default?

  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.

• How do I integrate Prometheus with Finout using Google GKE or Azure AKS?

  Finout currently supports ingesting metrics from AWS S3 only. You have two options:

  1. 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.

  2. 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.

1. Generate CSV Export

Generate a daily CSV export by selecting from two approaches for your CSV exports:

1. Maintain a single CSV that receives updates daily with new data entries.

2. 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.

2. Prepare CSV Format

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.

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

3. Create a Folder in the Bucket

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.

4. Set up an S3 Bucket

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.

1. Copy your “external-id” from the Finout console, or use a random one, preferably in the format of finout-XXXXXXX.

2. Click on create a new cross-account role in IAM to create a role for another AWS account.

3. Enter the AWS Account ID associated with the S3 bucket in the Account ID field.

4. Choose the option to Require external ID and input the “external-id” you got from the Finout console.
5. Click Next until you reach the review screen. ​

6. Configure the review as shown below, with one exception: the role name should be: FinoutMetricsReadOnlyRole (unlike in the screenshot below).
7. Go to your newly created role. ​

8. Copy the Role ARN and paste it into the Finout console.

9. Click Add permissions and select Create inline policy.
10. Select JSON, and insert the following. Replace the <BUCKET_NAME> with the name of your newly created bucket or your existing CUR bucket:

    Copy

    "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "tag:GetTagKeys"
                ],
                "Resource": "*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:Get*",
                    "s3:List*"
                ],
                "Resource": "arn:aws:s3:::<BUCKET_NAME>/*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:Get*",
                    "s3:List*"
                ],
                "Resource": "arn:aws:s3:::<BUCKET_NAME>"
            }
        ]
    }

11. Click Next until you reach the review screen, and name the policy finest-access-policy_telemetry_export (or choose your own name).

5. Provide Data to Finout

Please provide Finout with the following information:

• External ID

• ARN role

• Bucket name

• Folder name within the bucket

• Optional: region

Intro to Finout’s MegaBill - Multi-Cloud K8s Management

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:

1. Compliance - Customers that are willing to have their data only on a specific cloud.

2. 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.

3. 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:

1. Operation: The ability to configure and orchestrate multiple workloads correctly in milliseconds.

2. 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.

3. 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Finout Kubernetes MegaBill

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.

Select view

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.

Filter

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.

Group by

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.

Date range

Select the date range of the widget by customizing the start and end dates, or by using one of the preset options.

Periodical range

Select the periodical range of the widget by choosing one of the three options: Daily, Weekly, or Monthly.

Show costs as

Select the relevant cost view out of five options: Net Amortized Cost, Amortized Cost, Unblended Cost, Net Unblended Cost, or Blended Cost.

Add a widget to a dashboard

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 CSV

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.

How to Review Anomalies

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).

1. Select Anomalies.

2. Search for Kubernetes anomalies using the search bar.

3. To view the MegaBill associated with the deviation, click Investigate.

4. To delete an anomaly, click the trash can and then click Yes.

5. To leave a comment on an anomaly, click the comment icon, enter a comment, and then click Save.

How to Configure Sending Anomalies to Slack

Anomalies can be posted as messages to Slack.

To enable anomaly messages:

1. Create a Slack endpoint (see Create an Endpoint).

2. Select Use this Endpoint for sending alert notifications.

To learn more about Anomaly Detection, please refer to our main documentation.

Overview

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.

ServiceNow Configuration Workflow:

1. Choose a User

2. OAuth Authentication

3. Add ServiceNow credentials to Finout

1. Choose a User for the Integration

1. 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:

   1. sys_db_object

   2. sys_db_object.*

   3. sys_dictionary

   4. sys_dictionary.*

   5. sys_glide_object

2. OAuth Authentication

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:

3. Fill in the following fields:

   1. Name: <ANY>

   2. Client Type: Integration as a service

      Note: Make sure to leave the Redirect URL and Logo URL empty.
4. Press Submit. You will be redirected to the list of all available apps.

5. 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.
6. In Finout, fill in the following information:

   1. ServiceNow Instance URL

   2. ServiceNow Client ID

   3. ServiceNow Client Secret

   4. ServiceNow User Name

   5. ServiceNow User Password

3. ServiceNow Configuration in Finout

1. In Finout, navigate to Settings > Integrations.

   Note: You can connect with only one instance.
2. Click Add Integration.
3. Under ServiceNow, click Connect Now. The ServiceNow Integration wizard appears.

   1. Enter your ServiceNow Instance URL.

   2. Enter the Client ID from the ServiceNow OAuth application.

   3. Enter the Client secret associated with the ServiceNow OAuth application.

   4. Enter the ServiceNow User name for Authentication.

      Note: The user should have the following read ACL permissions:

      1. sys_db_object

      2. sys_db_object.*

      3. sys_dictionary

      4. sys_dictionary.*

      5. sys_glide_object

   5. Enter the password for the specified ServiceNow user.

4. Click Connect.

   ServiceNow is now connected.

FAQs

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.

Creating a Budget

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:

Create budget rules

• 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:

Editing a budget

In the new budget table, choose the relevant drill down to edit and press the edit button as shown in the screenshot below: