CostGuard - Scans

CostGuard is part of Finout’s cost optimization suite that is responsible for generating cost-saving recommendations by continuously scanning your resources and your entire MegaBill, allowing you to identify and leverage potential cost-saving opportunities across various use cases.

CostGuard recommendations are divided into three different use cases:

Idle	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.
Commitment	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.
Rightsizing	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.

Idle

Almost every organization has resources that were provisioned but are no longer in use. Forgetting to switch off these Idle resources eats away at your tech budget.

Scan Name	Sampling Source	Data Sampling	Timeframe	Calculation Interval	Idle Configuration
AWS-EC2	Amazon CloudWatch	Once every 2 weeks	7 days back	Every 2 weeks	- The maximum CPU utilization during the timeframe is under 5%. - Network-in and network-out traffic is below 5M bytes throughout the period.
AWS-EBS	Amazon API that extracts metadata	Every day	7 days back	24 hours	The storage is available during the entire calculated period.
AWS - ELB	Amazon CloudWatch	Every day	7 days back	24 hours	The number of requests transferring this interface is smaller than 100 during the entire calculated period.
AWS-RDS	Amazon CloudWatch	Every day	7 days back	24 hours	There are no DB connections during the entire calculated period.
AWS - Elasticache	Amazon CloudWatch	Every day	7 days back	24 hours	The maximum CPU utilization in the timeframe (in every day included in it) is less than 2%.
AWS - Elastic IP	Amazon CloudWatch	Every day	30 days back	24 hours	The tag originates from AWS.
AWS - S3	Amazon CloudWatch	Every day	7 days back	24 hours	There are no requests involving this bucket during the entire calculated period, this bucket isn’t being used.
AWS - Network	Amazon CloudWatch	Every day	7 days back	24 hours	The number of connections is smaller than 100.
GCP - VM	Cloud Monitoring service	Every day	7 days back	24 hours	-The maximum CPU utilization during the period is under 0.1%. -Network traffic (in and out) is below 10,485,760 bytes for the entire period.
GCP-CloudSQL	Cloud Monitoring service	Every day	3 days back	24 hours	-CPU utilization is under 0.05%. -Memory utilization is under 0.1%.. -I/O operations (read/write) are fewer than 20.
GCP - Persistent Disk	Cloud Monitoring service	Every day	3 days back	24 hours	Tag that Finout enriches from GCP, which identifies this resource as idle.
GCP-Snapshot	Cloud Monitoring service	Every day	3 days back	24 hours	the creation date of the resource is 90 days or more
DataDog-Custom Metric	DataDog	Every day (as part of the MegaBill)	7 days back	24 hours	This tag isn’t being used in one of the primary DD products, dashboards/alerts.
DataDog-Logs - idle (Debug)	DataDog	Every day (as part of the MegaBill)	7 days back	24 hours	Finout filters the logs’ level. Debug logs are considered idle logs because they were written internally for investigation matters; therefore, they should be immediately removed.

Commitment

Identifies resources that are regularly in use helps to identify potential savings that can be had by signing up for savings plans. The Commitment to using a resource for a specific amount over the agreed period can safely be made based on the CostGuard scans.

Scan Name	Applicable for	Data Sampling	Timeframe	Calculation Interval	Description
AWS-Commitment Saving Plan	EC2, Fargate, Lambda (across regions, OS, and instance types)	Daily	30 days back	Real-time (when the application runs)	Finout analyzes the organization's On-Demand costs for resources that are not currently covered by a commitment plan and identifies optimization opportunities. If a commitment plan can lower these On-Demand costs, it will be recommended, taking all supported resources into account without differentiation.
AWS Saving Plans	EC2	Daily	30 days back.	Real-time (when the application runs)	Finout analyzes the organization's On-Demand costs for resources that are not currently covered by a commitment plan and identifies optimization opportunities. If a commitment plan can lower these On-Demand costs, it will be recommended, per the supported resources groups.
AWS Reserved Instances	EC2 – specific to region, OS, and instance type	Daily	30 days back	Real-time (when the application runs)	Analyzes On-Demand costs for resources not covered by a commitment and suggests optimization opportunities for relevant resource groups and instance types. It also recommends the number of commitment hours for each instance type.

EC2 - Savings plans

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:

1. Select the relevant scan.

2. Set the configuration of the plan: 1-year commitment or a 3-year commitment.

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

EC2 - Reserved Instances

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

Compute Savings Plans can lead to savings of up to 66% relative to on-demand prices by committing to specific hourly compute costs. These plans offer maximum flexibility, regardless of the instance family, region, operating system (e.g., Windows, Linux), tenancy type (such as Host, Dedicated, or Default), or product type (EC2, Fargate, Lambda).

Finout’s CostGuard conducts scans across EC2, Fargate, and Lambda compute. Based on your hourly usage, it recommends the best $/hour rate for you.

Scan Breakdown:

• Payment options- Upfront, partial upfront, or no upfront.

• Saving plan terms- 1 year or 3 years.

From these options, 6 different combination scans are created, each showing how much you could save annually by choosing any one of these options.

For each combination including the payment option and saving plan term, we have an analysis model which includes a simulator for each savings plan.

To use the savings simulator:

1. Select the relevant scan.

2. Select the timeframe (based on the past) for the simulator. Either 7, 30, or 60 days (the default is 30 days).

3. The simulator will provide an hourly level comparison with the on-demand rate. Based on this, CostGuard recommends the optimal $/hourly commitment.

Rightsizing

Resources that are in use may be underutilized and exceed your current workload performance and capacity requirements. Rightsizing means that you can downsize these resources without compromising on your service levels.

Scan Name	Sampling Source	Data Sampling	Timeframe	Interval	Description
AWS-EC2	Amazon CloudWatch	Once every 2 weeks	3 days back	Every 2 weeks	The maximum CPU utilization in the timeframe (in every day included in it) is less than 50%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
AWS - EBS	Amazon API that extracts metadata	Every day	1 day back	24 hours	Identifying EBS resources that are using the old gp2 technology, the recommendation in that case is technology transition to gp3 that is considered as more cost-effective.
AWS - RDS	Amazon CloudWatch	Every day	7 days back	24 hours	The maximum CPU utilization in the timeframe (in every day included in it) is less than 50%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
GCP - VM	Cloud Monitoring service	Every day	7 days back	24 hours	Idle configuration: The maximum CPU utilization in the timeframe (in every day included in it) is less than 80%, that means that the instance isn’t utilizing its capacity potential, it is partially active.
K8s - All Scans	K8s metrics (Prometheus/DD - depending on the integration)	Every day (as part of the MegaBill)	14 days back	On the fly (when running the application)	-Data filter: the cluster and the scan type property exist - there’s an active node that uses K8s to search for rightsizing. -Application calculation based on the data filter - if the formula’s result is bigger than 0 it indicates for underutilized resource.

K8s- Rightsizing

In Kubernetes scans, waste and potential savings are two critical metrics for understanding and optimizing resource allocation:

• Waste: This represents the difference between the resources requested and the average hourly usage, calculated from minute-by-minute samples. Waste occurs when the requested resources exceed actual usage.

• Potential Savings: This is the cost difference between the current resource allocation and a recalculated allocation based on adjusting resource requests to a selected usage percentile. It highlights the monetary savings achievable through rightsizing. ​ Although both metrics reflect cost inefficiencies, waste is typically higher since resource requests remain unchanged unless actively optimized.

  This model is based on the historical behavior of your environment. In this scan, Finout assigns a dollar value to CPU and Memory usage based on the associated costs of the pods.

Application Calculation

The Application Calculation formula is applied to detect underutilized resources. If the formula output is greater than 0, it indicates underutilization.

Note: This same calculation is also used to estimate the daily waste price.

New Default Ratios (88% CPU / 12% Memory) Formulas:

Note: The formula changes in accordance to your accounts configuration.

-CPU Formula:

- k8s max resource unit price: Price per resource unit (avg of CPU & memory).

- k8s max node cpu weight: CPU weight in the formula.

- k8s waste cores: Unused cores (value > 0 = rightsizing potential).

- Memory Formula:

- k8s max resource unit price: Price per resource unit (avg of CPU & memory).

- k8s max node mem weight: Memory weight in the formula.

- k8s waste mem: Unused memory (value > 0 = rightsizing potential).

Old Default Ratios (50% CPU / 50% Memory) Formulas:

- CPU Formula:

- cpu weight: The weight assigned to CPU in the formula determines how much of the total cost or resource is attributed to CPU.

- node price: The price of a node typically represents the cost of computing resources on that node.

- node cores: The total number of CPU cores available on the node.

- k8s waste cores: The number of unused CPU cores on the node, representing the potential for rightsizing the resources. If this value is greater than 0, it indicates an opportunity to optimize resource allocation.

- Memory Formula:

- mem weight: The weight assigned to memory in the formula, indicating how much of the total cost or resource is attributed to memory.

-node price: The price of a node, representing the cost of the resources on that node, similar to the CPU formula.

-node ram gb: The total amount of RAM (memory) available on the node, measured in gigabytes.

-k8s waste mem: The amount of unused memory on the node, representing the potential for rightsizing. If this value is greater than 0, it suggests an opportunity for resource optimization.

CPU/Memory Simulator

To propose recommended and new Memory and CPU requests, Finout offers a dynamic calculator. This tool enables the manual discovery of various CPU and Memory scenarios, based on the percentile CPU and Memory usage of the samples. For instance, at the 100th percentile, recommendations are based on the maximum CPU and Memory usage within the selected period. At the 85th percentile, recommendations are based on the CPU and Memory levels where 85% of the samples met the criteria during the chosen period.

The simulator provides two graph types for analysis: Overtime Analysis and Histogram View, offering insights into historical usage patterns.

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

2. 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. ​ ​ Please refer to the relevant documentation to understand how we calculate K8s costs.

   

AWS- Rightsizing

EBS - gp2

As Amazon encourages more people to transition to gp3, an advanced resource offering potential savings, Finout offers recommendations to users regarding the resources they should migrate from gp2 to gp3. By making this transition, users can potentially save a significant amount, denoted as "X."

RDS

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.

EC2

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.

GCP- Rightsizing

VM

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.