Recommendations for AWS

Identify Clusters that are about to be charged on Extended Support charges or already charged to avoid unexpected costs and plan upgrades effectively.

Algorithm:

• Anodot's algorithm extracts the extended support calendar periodically.
  • EKS extended support release calendar by using the Standard Support Pricing Window field.
• Anodot's algorithm extracts the exact cluster version using the List clusters API. Note: To use the API a 'eks:ListClusters' permission should be given. The policy is applied in the onboarding but there might be cases where the permission wasn't set and the recommendation won't be available in that case.
• The algorithm then scans each cluster version against the release calendar versions.
  • in case the extended support for this version is going to be applied in the next 30 days a recommendation will be triggered.
  • In case extended support is already applied a recommendation will be triggered.
  •  
• The recommendation specifies:
  • The current and recommended version
  • The extended support start date.
  • Additional enrichment fields.

Suggest using latest generation of instances to get the best performance and pricing.

Preferences:

• Exclude Graviton.
• Same Physical Processor Only.

Savings Algorithm

Hourly Usage Basis:

When calculating cloud cost savings, we base our analysis on the actual hourly usage of each instance. This approach ensures that savings are accurately aligned with the precise consumption patterns of your infrastructure.

For example:

• If an instance runs for 10 hours in a day, only those 10 hours are factored into the cost savings calculation, rather than the full-day cost.
• This allows us to identify potential savings by considering factors such as underutilized instances, reserved instance commitments based on actual runtime.

By using this method, we provide a more detailed and actionable view of your cost savings opportunities, reflecting real-world usage rather than static, time-independent estimates.

Identify EC2 instances using low CPU and recommend to switch the instance type to a more suitable one which will cost less within the same family type.

Based on usage within the past 21 days (subject to preferences) where max actual memory usage and max actual cpu usage was less than 80% and potential saving is larger than 5% of the cost in AWS.

The recommendation algorithm will examine your memory utilization if you will enable your AWS CloudWatch agent, more details on the required memory metrics can be found here.

Savings Algorithm

Hourly Usage Basis:

When calculating cloud cost savings, we base our analysis on the actual hourly usage of each instance. This approach ensures that savings are accurately aligned with the precise consumption patterns of your infrastructure.

For example:

• If an instance runs for 10 hours in a day, only those 10 hours are factored into the cost savings calculation, rather than the full-day cost.
• This allows us to identify potential savings by considering factors such as underutilized instances, reserved instance commitments based on actual runtime.

By using this method, we provide a more detailed and actionable view of your cost savings opportunities, reflecting real-world usage rather than static, time-independent estimates.

Preferences:

The following preferences should be qualified in order to be taken into account for the recommendation.

• Days To Check: Resource should be at least “days to check” old (example: Do not check resources that were launched in the last 14 days). (Default= 30)

• Activity Period:The resource’s Minimum Active Days should be evaluated within this period (Example: Check resources activity in the last two months)(Default=14)

• Min Active Days:The minimum cumulative number of active days for the resource within the Activity Period, not consecutive (Example: Only recommend on servers running at least 15 days in the period). (Default= 10)

Note: In cases where the EC2 instance doesn't exist in the invoice the recommendation consumed from AWS will be filtered out.

AWS charges 0.005 per IP, per hour for all public IPv4 addresses, whether it's attached to AWS service or not.

 Preferences:

The following preferences should be qualified in order to be taken into account for the recommendation.

• Minimum potential saving (%): Define the minimum annual potential saving percentage to qualified (Default= 5 %).
• Minimum potential saving ($):Define the minimum annual potential saving cost to qualified (Default= 10$).

RDS Right-sizing

'rds-class-change'

Identify if the RDS instances have cheaper suitable alternatives considering the instance's current utilization + CPU spare capacity on top.

Algorithm:

1. Pricing- the Potential saving is calculated basing on On demand pricing.
2. The saving amount that is taken into account once the recommendation is implemented is the potential saving of option number 1. Hourly Usage Basis:

   When calculating cloud cost savings, we base our analysis on the actual hourly usage of each instance. This approach ensures that savings are accurately aligned with the precise consumption patterns of your infrastructure.

   For example:

   • If an instance runs for 10 hours in a day, only those 10 hours are factored into the cost savings calculation, rather than the full-day cost.
   • This allows us to identify potential savings by considering factors such as underutilized instances, reserved instance commitments based on actual runtime.

    

3. Billed instances - filter in only billed instances based on the following RDS states, where RDS State=Billed.
   Refer to the RDS billed states list.
   
4. Idle Instances - Check the instance is not idle (connections == 0) for a defined  number of days to check for activity, and if the instance activity is sufficient to be a recommendation:
   

   • RDS was created 60 days ago (Days To Check). The instance creation and CloudWatch metrics are used to determine the creation date.

   • The instance has been running in 10 days (Resource Min Up Time) out of the last 14 days (Resource Startup Period). 
     
     

5. Alternatives - In order to get alternatives for the current instance class the following requirements are set:

   • Engine and Region - The target product is with the same database engine and is available in the same region.

   • CPU - minimum CPU units. The CPU criteria is calculated by the current P95 of the Max utilization + Spare capacity (default 40%).

   • Memory - minimum memory units. The memory criteria is calculated by the current p95 of the Max utilization +  5% Spare capacity (not the spare capacity preference).

   • Multi AZ - same deployment_option as the current instance.

   • Hourly On Demand Cost - maximum hourly_on_demand_cost. This parameter is taken from the current instance product price.

   • Deployment Model - same deployment_model.

   • Family Type - if the same_family_type_only flag is enabled, the target alternative has to be from the same instance type family.

   • Database edition - same database edition.

   • Current Generation - if the current_generation_only is enabled, search only if the target alternative is yes.

   • License Model - same license model unless the target license model is free of charge.

   • Storage Type - same storage family type supported 5. Potential saving - any recommended alternative.

6. Potential saving < min_potential_saving preference setting (5%).
7. Alternatives Order - sorted by the Potential saving (saving opportunity) amount and then instance type RI coverage = Yes.

Preferences

The following preferences should be qualified in order to be taken into account for the recommendation:

• Days To Check: Resource should be at least “days to check” old (example: Do not check resources that were launched in the last 14 days). (Default= 60)

• Activity Period:The resource’s Minimum Active Days should be evaluated within this period (Example: Check resources activity in the last two months)(Default=14)

• Min Active Days:The minimum cumulative number of active days for the resource within the Activity Period, not consecutive (Example: Only recommend on servers running at least 15 days in the period). (Default= 10)

• Spare Capacity ( % ): The additional instance capacity (%) needed to be taken into account beyond the existing CPU utilization (P95). The default is 40%. For example:

  • CPU units - 16

  • CPU utilization P95 - 20% (0.2)

  • Spare capacity 25% (0.25)

  • Target CPU calculation = cpu units * cpu utilization + (cpu units * cpu utilization) * spare capacity ceil (16 * 0.2) + ceil ((16*0.2)*0.25) = 4 + 1 = 5.

• Min Potential Saving ( % ): Indicates the minimal calculated potential saving needed for the displaying recommendation. The default is 5%.
• Current Generation Only- Does the recommended instance type belong to the current instance type generation? The default is No.
• Same Family Type Only- Does the recommended instance type will be within the same Family type? The default is No.
• CPU Utilization aggregation function- The daily aggregation function that will be performed on top of the hourly Max CPU Utilization and will be used for the Estimated CPU calculation. Optional Values: 95th percentile (default), Max, 99th percentile.
• Min Potential Saving (%)- Minimum potential saving that will be used as the threshold for the recommendation filtering, default 5%.
• Max DataBase Connections(#)- Max Database Connections, RDS with higher database connection will be filtered and the recommendation won’t take them into consideration, default 100.

RDS Provisioned IOPS

'rds-iops-change'

Decrease Provisioned IOPS.

Algorithm:

1. Pricing- the Potential saving is calculated basing on On demand pricing.
2. Billed instances - filter in only billed instances based on the following RDS states, where RDS State=Billed. Refer to the RDS billed states list.
   
3. Idle Instances - Check the instance is not idle (connections == 0) for a defined  number of days to check for activity, and if the instance activity is sufficient to be a recommendation:
   

   • RDS is created 60 days ago (Days To Check). The instance creation and CloudWatch metrics are used to determine the creation date.

   • The instance is running in 10 days (Resource Min Up Time) out of the last 14 days (Resource Startup Period).

   • Spare Capacity ( % ): The additional instance capacity (%) needed to be taken into account beyond the existing CPU utilization (P95). The default is 40%. For example:

     • CPU units - 16

     • CPU utilization P95 - 20% (0.2)

     • Spare capacity 25% (0.25)

     • Target CPU calculation = cpu units * cpu utilization + (cpu units * cpu utilization) * spare capacity ceil (16 * 0.2) + ceil ((16*0.2)*0.25) = 4 + 1 = 5.

4. The instance has Provisioned IOPS.
5. The instance type Provisioned IOPS is minimal to the class type.
6. The IOPS utilization < IOPS utilization preference setting (40%).
7. Potential Savings >Min Potential Saving preference setting (5%).
8. Recommended IOPS= current max(p95) IOPS + spare capacity IOPS.

9. Savings Algorithm

   Hourly Usage Basis:

   When calculating cloud cost savings, we base our analysis on the actual hourly usage of each instance. This approach ensures that savings are accurately aligned with the precise consumption patterns of your infrastructure.

   For example:

   • If an instance runs for 10 hours in a day, only those 10 hours are factored into the cost savings calculation, rather than the full-day cost.
   • This allows us to identify potential savings by considering factors such as underutilized instances, reserved instance commitments based on actual runtime.

    

Preferences

The following preferences should be qualified in order to be taken into account for the recommendation:

• Days To Check: Define how many days to check back for the resource. (Default= 60)

• Activity Period:How many days should have passed from the time the resource was created. (Default=14)

• Min Active Days: How many days within the "Resource Startup Period" the resource was up, not consecutive. (Default= 10)

• Spare Capacity ( % ): The additional instance CPU capacity (%) needed to be taken into account beyond the existing CPU utilization (P95). The default is 40%. For example:

  • CPU units - 16

  • CPU utilization P95 - 20% (0.2)

  • Spare capacity 25% (0.25)

  • Target CPU calculation = cpu units * cpu utilization + (cpu units * cpu utilization) * spare capacity ceil (16 * 0.2) + ceil ((16*0.2)*0.25) = 4 + 1 = 5.

• CPU Utilization aggregation function- The daily aggregation function that will be performed on top of the hourly Max CPU Utilization and will be used for the Estimated CPU calculation. Optional Values: 95th percentile (default), Max, 99th percentile.
• IOPS Utilization- The maximum Provisioned IOPS utilization to be included in the recommendation population. The default is 40%.
• Min Potential Saving (%)- Minimum potential saving that will be used as the threshold for the recommendation filtering, default 5%.
• Max DataBase Connections(#)- Max Database Connections, RDS with higher database connection will be filtered and the recommendation won’t take them into consideration, default 100.

Suggest using the latest generation of instances to get the best performance and pricing.

Savings Algorithm

Hourly Usage Basis:

When calculating cloud cost savings, we base our analysis on the actual hourly usage of each instance. This approach ensures that savings are accurately aligned with the precise consumption patterns of your infrastructure.

For example:

• If an instance runs for 10 hours in a day, only those 10 hours are factored into the cost savings calculation, rather than the full-day cost.
• This allows us to identify potential savings by considering factors such as underutilized instances, reserved instance commitments based on actual runtime.

By using this method, we provide a more detailed and actionable view of your cost savings opportunities, reflecting real-world usage rather than static, time-independent estimates.

Identify RDS Clusters/Instances that are about to be charged on Extended Support charges or already charged to avoid unexpected costs and plan upgrades effectively.

Algorithm:

• Anodot's extracts the exact RDS cluster/instance version.

• Anodot's extracts the RDS's extended support status, and considering only these that have 'RDS Extended Support' = 'Enabled'.

• Anodot's extracts the extended support calendar periodically.

  • Release calendar for Aurora PostgreSQL by using the 'Aurora end of standard support date' field.
    

  • Release calendar for Aurora MySQL major versions by using the 'Aurora end of standard support date' field.

  • Release calendars for Amazon RDS for PostgreSQL by using 'RDS end of standard support date' field.
    

  • Supported MySQL major versions on Amazon RDS by using 'RDS end of standard support date' field.

• The then scans each RDS version against the release calendar versions.
  • in case the extended support for this version is going to be applied in the next 30 days a recommendation will be triggered.
  • In case extended support is already applied a recommendation will be triggered.
• The recommendation specifies:
  • The current and recommended version
  • The extended support start date.
  • Additional enrichment fields.

The RDS storage type change recommendation analyzes your current database storage configuration and suggests migrating to a more cost-effective or performance-aligned storage option. The recommendation process considers the following preferences:

1. Minimum Potential Saving: Specifies the minimum savings threshold for the recommendation to be relevant. If the cost savings from the storage change do not meet or exceed this value, the recommendation is not presented to avoid unnecessary adjustments.

2. Days to Check: Determines the time frame over which storage performance and usage data are evaluated. This ensures that recommendations are based on consistent patterns rather than temporary spikes or anomalies in workload.

Supported volume types:

• Move from General Purpose (gp2) to gp3: Reduce costs while achieving customizable performance.
• Move from io1 to gp3: Gain equivalent or better performance at a lower cost with flexible throughput and IOPS provisioning.

This recommendation identifies Amazon Aurora clusters where switching to the I/O-Optimized configuration can reduce costs for I/O-heavy workloads. The analysis is based on the last 30 days of usage, comparing current costs (instance, storage, and IOPS) with projected costs under the I/O-Optimized model, and recommending only if the new model is profitable.

ECS Fargate Right-sizing

'fargate_rigthsize'

Identify if the ECS Fargate instances have cheaper suitable alternatives considering the instance's current utilization.

Prerequisite

• AWS Compute Optimizer service opted-in.
• The services should have at least 24 hours of CloudWatch and Amazon ECS utilization metrics in the past 14 days.
• No step scaling policy is attached.
• No target scaling policy is attached to CPU and memory. If a target scaling policy is attached to the CPU, Compute Optimizer will provide recommendations to memory, if a target scaling policy is attached to memory, Compute Optimizer will provide recommendations to CPU.
• The service run status is SteadyState or MoreWork.

  See more details here:

  https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-ecs-fargate

• Activate 'Receive Amazon EC2 resource recommendations' in the Cost Explorer preferences page. There should be at least 14 days of service data.

Algorithm:

The recommendation is to explore the ECS utilization metrics in the past 14 days. 

S3 Versioning

(New)

The recommendation is applicable when saving >5%.

We recommend transitioning to more cost-efficient and performance-optimized EBS volume types:

1. Move from io1 to gp3: Gain equivalent or better performance at a lower cost, with flexible provisioning of IOPS and throughput tailored to your workload needs.
2. Move from gp2 to gp3: Reduce costs by approximately 20% while benefiting from consistent baseline performance and the ability to customize IOPS and throughput independently of storage size.

Note that in contrast to the other recommendations, the chart displayed for this service is called IOPS PERFORMANCE. An additional chart called THROUGHPUT PERFORMANCE is shown with the following metrics:

• Max Read Throughput
• Max Write Throughput
• Actual Read Throughput
• Actual Write Throughput

Identifying EBS outdated Snapshot age that is more than 21 days (subject to preferences).

Anodot identifies snapshots that have high (costs ±42$ per year) and is not connected to any image.

Algorithm:

1) Retrieve the existing snapshot date from the API.

2) Validate that there's not connected to any existing AMI at this point

3) Retrieve the average daily cost.

4) Multiply the average daily cost by the number of days that the snapshot exists until the recommendation creation. 

Identifying EBS snapshots created for AMIs that are no longer in use. An “orphaned AMI” means that the AMI itself has been deleted, but its associated snapshots still remain, incurring ongoing storage costs without serving any active purpose. 

Anodot identifies snapshots that have high (costs ±42$ per year) and is not connected to any image.

Algorithm:

1) Retrieve the existing snapshot date from the API.

2) Validate that there's not connected to any existing volume at this point

3) Retrieve the average daily cost.

4) Multiply the average daily cost by the number of days that the snapshot exists until the recommendation creation. 

Identifying VPC interface endpoints that are running but not actively transmitting data, which could represent unnecessary costs. This recommendation specifically evaluates the usage of VPC Interface Endpoints (not Gateway Endpoints) based on the following logic:

1. Data Signals Evaluated:

   • VpcEndpoint-Hours: Indicates the total hours the endpoint has been active.
   • VpceEndpoint-Bytes: Tracks the amount of traffic passing through the endpoint.

2. Algorithm:

   • If an endpoint shows activity (VpcEndpoint-Hours > 0) but no data transfer (VpceEndpoint-Bytes = 0 or diffrent value set in the recommendation preference) for a defined period, it is considered idle.

3. Recommendation Trigger:

   • The recommendation is generated only when an endpoint is consistently running without any traffic over the specified analysis window.

The recommendation process considers the following preferences:

• Days to Check:

  • Default = 30 days.
  • Specifies the evaluation period to monitor endpoint activity. Over this time, the endpoint's traffic and uptime are analyzed to determine if it is idle.

• Traffic Amount Through Endpoint:

  • Default = 0 bytes.
  • Sets the threshold for identifying idle endpoints. If traffic is equal to or below this value over the evaluation period, the endpoint is flagged as idle.

• Minimum Annual Cost:

  • Default = $10.
  • Ensures recommendations focus on endpoints that incur meaningful costs. Endpoints with annual costs below this threshold are not flagged, even if idle, to avoid unnecessary focus on negligible savings.

By identifying idle interface endpoints, this recommendation helps reduce unnecessary costs by prompting users to remove or decommission unused endpoints.