CostGuard - Scans
Last updated
Was this helpful?
Last updated
Was this helpful?
is part of Finout’s cost optimization suite that is responsible for generating cost-saving recommendations by continuously scanning your resources and your entire MegaBill, allowing you to identify and leverage potential cost-saving opportunities across various use cases.
CostGuard recommendations are divided into three different use cases:
Almost every organization has resources that were provisioned but are no longer in use. Forgetting to switch off these Idle resources eats away at your tech budget.
Identifying resources that are regularly in use helps to identify potential savings that can be had by signing up for savings plans. The Commitment to using a resource for a specific amount over the agreed period can safely be made based on the CostGuard scans.
Resources that are in use may be underutilized and exceed your current workload performance and capacity requirements. Rightsizing means that you can downsize these resources without compromising on your service levels.
When you select a CostGuard scan, you will find the query prominently displayed in the top right corner of the screen. This query is customized to your selection, reflecting the specific criteria and filters you have chosen. It serves as a concise summary of the scan's parameters, allowing you to review and verify that the scan aligns with your objectives.
Moreover, the query provides you with valuable insights by presenting all relevant resources identified within the past 7 days. By focusing on recent data, CostGuard ensures that you have access to the most up-to-date information when making informed decisions about cost optimization.
Almost every organization has resources that were provisioned but are no longer in use. Forgetting to switch off these Idle resources eats away at your tech budget.
Scan Name
Sampling Source
Data Sampling
Timeframe
Calculation Interval
Idle Configuration
Scan Type
AWS-EC2
Amazon CloudWatch
Once every 2 weeks
7 days back
Every 2 weeks
- The maximum CPU utilization during the timeframe is under 5%. - Network-in and network-out traffic is below 5M bytes throughout the period.
Net Amortized
AWS-EBS
Amazon API that extracts metadata
Every day
7 days back
24 hours
The storage is available during the entire calculated period.
Net Amortized
AWS - ELB
Amazon CloudWatch
Every day
7 days back
24 hours
The number of requests transferring this interface is smaller than 100 during the entire calculated period.
Net Amortized
AWS-RDS
Amazon CloudWatch
Every day
7 days back
24 hours
There are no DB connections during the entire calculated period.
Net Amortized
AWS - Elasticache
Amazon CloudWatch
Every day
7 days back
24 hours
The maximum CPU utilization in the timeframe (in every day included in it) is less than 2%.
Net Amortized
AWS - Elastic IP
Amazon CloudWatch
Every day
30 days back
24 hours
The tag originates from AWS.
The account's default cost type.
AWS - S3
Amazon CloudWatch
Every day
7 days back
24 hours
There are no requests involving this bucket during the entire calculated period, this bucket isn’t being used.
Net Amortized
AWS - Network
Amazon CloudWatch
Every day
7 days back
24 hours
The number of connections is smaller than 100.
Net Amortized
GCP - VM
Cloud Monitoring service
Every day
7 days back
24 hours
-The maximum CPU utilization during the period is under 0.1%. -Network traffic (in and out) is below 10,485,760 bytes for the entire period.
Net Amortized
GCP-CloudSQL
Cloud Monitoring service
Every day
3 days back
24 hours
-CPU utilization is under 0.05%.
-Memory utilization is under 0.1%.. -I/O operations (read/write) are fewer than 20.
Net Amortized
GCP - Persistent Disk
Cloud Monitoring service
Every day
3 days back
24 hours
Tag that Finout enriches from GCP, which identifies this resource as idle.
Net Amortized
GCP-Snapshot
Cloud Monitoring service
Every day
3 days back
24 hours
the creation date of the resource is 90 days or more
Net Amortized
DataDog
Every day (as part of the MegaBill)
7 days back
24 hours
This tag isn’t being used in one of the primary DD products, dashboards/alerts.
The account's default cost type.
DataDog
Every day (as part of the MegaBill)
7 days back
24 hours
Finout filters the logs’ level. Debug logs are considered idle logs because they were written internally for investigation matters; therefore, they should be immediately removed.
The account's default cost type.
Snowflake - Idle Tables (Coming soon)
Snowflake AccountUsage (ACCESS_HISTORY table)
Every day
7 days back
24 hours
If no queries are executed on a table during the entire analysis period, the table is flagged as idle, indicating it isn't actively used and may be generating unnecessary storage costs.
The account's default cost type.
Identifies resources that are regularly in use helps to identify potential savings that can be had by signing up for savings plans. The Commitment to using a resource for a specific amount over the agreed period can safely be made based on the CostGuard scans.
Scan Name
Applicable for
Data Sampling
Timeframe
Calculation Interval
Description
Cost Type
AWS-Commitment Saving Plan
EC2, Fargate, Lambda (across regions, OS, and instance types)
Daily
30 days back
Real-time (when the application runs)
Finout analyzes the organization's On-Demand costs for resources that are not currently covered by a commitment plan and identifies optimization opportunities. If a commitment plan can lower these On-Demand costs, it will be recommended, taking all supported resources into account without differentiation.
The account's default cost type.
AWS Saving Plans
EC2
Daily
30 days back.
Real-time (when the application runs)
Finout analyzes the organization's On-Demand costs for resources that are not currently covered by a commitment plan and identifies optimization opportunities. If a commitment plan can lower these On-Demand costs, it will be recommended, per the supported resources groups.
The account's default cost type.
AWS Reserved Instances
EC2 – specific to region, OS, and instance type
Daily
30 days back
Real-time (when the application runs)
Analyzes On-Demand costs for resources not covered by a commitment and suggests optimization opportunities for relevant resource groups and instance types. It also recommends the number of commitment hours for each instance type.
The account's default cost type.
EC2 Instance Savings Plans unlock savings of up to 72% off on-demand prices by committing to a specific instance family in an AWS Region, regardless of instance size (e.g., m5.xlarge, m5.2xlarge, etc.), operating system (e.g., Windows, Linux, etc.), and tenancy type (Host, Dedicated, Default) within the chosen family and region.
With an EC2 Instance Savings Plan, you retain the flexibility to resize your instances within the selected family (e.g., from c5.xlarge to c5.2xlarge) or switch operating systems (e.g., from Windows to Linux). Even transitioning from dedicated tenancy to default does not affect the discounted rate provided by your EC2 Instance Savings Plan.
As part of CostGuard for EC2 Savings plans, our platform conducts scans across all EC2 instances within your account. We prioritize optimizing EC2-compute and on-demand filters, as these areas are vital in cost optimization. The resource names in the platform will include the respective regions to provide accurate insights and optimization recommendations.
For each region type, we have an analysis model that includes a simulator for savings plans.
To use the savings simulator:
Select the relevant scan.
Set the configuration of the plan: 1-year commitment or a 3-year commitment.
Set the payment option: Select partial upfront, all upfront, or no upfront.
Once the simulator is set based on your scan type, a summary is displayed. It includes the current on-demand spend, estimated monthly spend, and potential savings based on the chosen payment option.
The simulator provides an hourly level comparison with the on-demand rate, indicating the coverage provided by each commitment.
Using the simulator, we recommend the price of an hourly commitment based on the analysis.
We provide the user with the ability to understand the RIs for each one of the instances; how many resources are in each instance (Resources Count), how much of the instances are currently covered by any plan (Current Coverage), the optimal coverage and we provide a recommendation of how many instances, what type of instance family you should purchase and the annual potential savings if you go by the recommendation.
This instance is analyzed on a time frame of the last 30 days.
Compute Savings Plans can lead to savings of up to 66% relative to on-demand prices by committing to specific hourly compute costs. These plans offer maximum flexibility, regardless of the instance family, region, operating system (e.g., Windows, Linux), tenancy type (such as Host, Dedicated, or Default), or product type (EC2, Fargate, Lambda).
Scan Breakdown:
Payment options- Upfront, partial upfront, or no upfront.
Saving plan terms- 1 year or 3 years.
From these options, 6 different combination scans are created, each showing how much you could save annually by choosing any one of these options.
For each combination including the payment option and saving plan term, we have an analysis model which includes a simulator for each savings plan.
To use the savings simulator:
Select the relevant scan.
Select the timeframe (based on the past) for the simulator. Either 7, 30, or 60 days (the default is 30 days).
The simulator will provide an hourly level comparison with the on-demand rate. Based on this, CostGuard recommends the optimal $/hourly commitment.
Resources that are in use may be underutilized and exceed your current workload performance and capacity requirements. Rightsizing means that you can downsize these resources without compromising on your service levels.
Scan Name
Sampling Source
Data Sampling
Timeframe
Interval
Description
Cost Type
AWS-EC2
Amazon CloudWatch
Once every 2 weeks
3 days back
Every 2 weeks
The maximum CPU utilization in the timeframe (in every day included in it) is less than 50%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
Net Amortized
AWS - EBS
Amazon API that extracts metadata
Every day
1 day back
24 hours
Identifying EBS resources that are using the old gp2 technology, the recommendation in that case is technology transition to gp3 that is considered as more cost-effective.
Net Amortized
AWS - RDS
Amazon CloudWatch
Every day
7 days back
24 hours
The maximum CPU utilization in the timeframe (in every day included in it) is less than 50%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
Net Amortized
GCP - VM
Cloud Monitoring service
Every day
7 days back
24 hours
Idle configuration: The maximum CPU utilization in the timeframe (in every day included in it) is less than 80%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
Net Amortized
K8s - All Scans
K8s metrics (Prometheus/DD - depending on the integration)
Every day (as part of the MegaBill)
14 days back
On the fly (when running the application)
-Data filter: the cluster and the scan type property exist - there’s an active node that uses K8s to search for rightsizing.
-Application calculation based on the data filter - if the formula’s result is bigger than 0 it indicates for underutilized resource.
The account's default cost type.
Snowflake - Warehouse
Snowflake Account Usage
Every day
7 days back
24 hours
Analyzes warehouse efficiency based on Used Warehouse Credits vs. Total warehouse Credits. If the maximum day of utilization percentage (Used Warehouse Credits / Total warehouse Credits) is lower then 50% (by default, this can be configured), the warehouse may be oversized, and downsizing is recommended to optimize costs.
The account's default cost type.
In Kubernetes scans, waste and potential savings are two critical metrics for understanding and optimizing resource allocation:
Waste: This represents the difference between the resources requested and the average hourly usage, calculated from minute-by-minute samples. Waste occurs when the requested resources exceed actual usage.
Potential Savings: This is the cost difference between the current resource allocation and a recalculated allocation based on adjusting resource requests to a selected usage percentile. It highlights the monetary savings achievable through rightsizing. ​ Although both metrics reflect cost inefficiencies, waste is typically higher since resource requests remain unchanged unless actively optimized.
This model is based on the historical behavior of your environment. In this scan, Finout assigns a dollar value to CPU and Memory usage based on the associated costs of the pods.
Application Calculation
The Application Calculation formula is applied to detect underutilized resources. If the formula output is greater than 0, it indicates underutilization.
New Default Ratios (88% CPU / 12% Memory) Formulas:
-CPU Formula:
- k8s max resource unit price: Price per resource unit (avg of CPU & memory).
- k8s max node cpu weight: CPU weight in the formula.
- k8s waste cores: Unused cores (value > 0 = rightsizing potential).
- Memory Formula:
- k8s max resource unit price: Price per resource unit (avg of CPU & memory).
- k8s max node mem weight: Memory weight in the formula.
- k8s waste mem: Unused memory (value > 0 = rightsizing potential).
Old Default Ratios (50% CPU / 50% Memory) Formulas:
- CPU Formula:
- cpu weight: The weight assigned to CPU in the formula determines how much of the total cost or resource is attributed to CPU.
- node price: The price of a node typically represents the cost of computing resources on that node.
- node cores: The total number of CPU cores available on the node.
- k8s waste cores: The number of unused CPU cores on the node, representing the potential for rightsizing the resources. If this value is greater than 0, it indicates an opportunity to optimize resource allocation.
- Memory Formula:
- mem weight: The weight assigned to memory in the formula, indicating how much of the total cost or resource is attributed to memory.
-node price: The price of a node, representing the cost of the resources on that node, similar to the CPU formula.
-node ram gb: The total amount of RAM (memory) available on the node, measured in gigabytes.
-k8s waste mem: The amount of unused memory on the node, representing the potential for rightsizing. If this value is greater than 0, it suggests an opportunity for resource optimization.
CPU/Memory Simulator
To propose recommended and new Memory and CPU requests, Finout offers a dynamic calculator. This tool enables the manual discovery of various CPU and Memory scenarios, based on the percentile CPU and Memory usage of the samples. For instance, at the 100th percentile, recommendations are based on the maximum CPU and Memory usage within the selected period. At the 85th percentile, recommendations are based on the CPU and Memory levels where 85% of the samples met the criteria during the chosen period.
The simulator provides two graph types for analysis: Overtime Analysis and Histogram View, offering insights into historical usage patterns.
Overtime analysis: Each graph, representing CPU and Memory, displays four different metrics:
Maximum usage.
Average usage across all pods in the selected scan.
Minimum usage.
Current request levels.
A dotted line that represents the simulated configuration of the chosen percentile.
Histogram view: To help in deciding whether to update your Memory or CPU, a histogram is also available. This visual representation shows the distribution of samples and indicates the number of samples that would fulfill the new request. ​ Histogram Sample- This represents an hourly aggregation of pod usage, determined by calculating the average of samples taken every minute.
Finout identifies underused RDS instances that can be downsized to a cost-effective alternative. The aim is to select the optimal instance for migration to maximize yearly savings, taking into account metrics like CPU usage and RDS connection count.
In this scan, Finout identifies underutilized instances that should not be shut down but rather moved to a more cost-effective alternative. The objective is to determine the most suitable instance to migrate to achieve the maximum potential savings on an annual basis.
During the VM rightsizing process, Finout analyzes VM CPU utilization data to suggest the most economical machine for optimal cost reduction. Within the calculations, CPU usage is constrained to a maximum of 80%. For predefined machines, we evaluate both standard and custom options. However, with custom machines, we specifically assess the custom configurations.
During the warehouse rightsizing process, Finout analyzes Snowflake warehouse efficiency by comparing actual usage to billed usage to identify potential cost savings. The evaluation is based on the following key metrics:
Used Warehouse Credits – The number of Snowflake credits actually consumed by the warehouse on a given day.
Total warehouse Credits – The number of Snowflake credits charged, which may differ from actual usage due to Snowflake’s pricing model.
Utilization Percentage – Calculated as Used Warehouse Credits / Total warehouse Credits, representing the warehouse's efficiency.
A warehouse is considered oversized if the maximum day of utilization percentage (Used Warehouse Credits / Total warehouse Credits) is lower then 50% (by default, this can be configured). In such cases, Finout recommends downsizing to a smaller warehouse tier to optimize costs while maintaining performance.
DataDog-Custom Metric Note: This scan is not available for accounts using .
DataDog-Logs - idle (Debug) Note: This scan is not available for accounts using .
Finout’s conducts scans across EC2, Fargate, and Lambda compute. Based on your hourly usage, it recommends the best $/hour rate for you.
Refer to the to understand how K8s costs are calculated.
As Amazon encourages more people to transition to , an advanced resource offering potential savings, Finout offers recommendations to users regarding the resources they should migrate from gp2 to gp3. By making this transition, users can potentially save a significant amount, denoted as "X."
