Anodot cost intelligence documentation

Recommendations for Azure

 

  Recommendation Logic source Description  
1

Disk Unattached

 Anodot
Identifying disk that is active, but no longer attached to any instance.

  
2

Virtual Machine Reserved-Instance

 Native + Anodot validation (Detailed validation logic)

RI purchase recommendations are based on customer historical usage. These recommendations are calculated by analyzing all incurred usage eligible to be covered by an RI (e.g. On-Demand usage) and using our unique algorithms to simulate possible combinations of RI’s that would cover that usage.

 

The current cost is retrieved from Azure as part of the recommendation as a current monthly cost and we multiply it by 12 on Anodot side.

  
3

VM Right Sizing

 Native + Anodot validation (Detailed validation logic)

Identifying VM instance that is underutilized and recommend using a more suitable instance type that will cost less and be more appropriate for the usage. 

  • The recommendation is driven from Azure advisor, Anodot does not generate recommendations on a resource unless it was triggered from Azure advisor

  • Anodot is using the following data sources to determine the actual savings and VM utilization:

    1. Azure recommendation information collected from Azure Advisor

    2. Azure resource information collected from Azure management

    3. Azure statistical metrics on the resource

    4. Cost and usage information from Anodot billing information

    5. Azure pricing information

  • Savings & Cost Calculations:
    • Current Cost: 
      • In an MCA/CSP Export Amortize account type the potential savings and current cost are calculated based on the Effective Cost (RI price).
      • In an MCA/CSP Export Unblended account type the potential savings and current cost are calculated based on the List Price (on demand).
      • In an EA API account type the potential savings and current cost are calculated based on the list Price (on demand).
    • Total cost recommended: The saving is calculated as follows:
      1) In case the recommended target model has reservations, the savings calculation takes into account the target reservation rate and the current model usage (with demand/reservation ratio) for the overall calculation.
      2) Currency exchange rate corresponding to the invoice date.
    • Potential Savings: Current Cost - Total cost recommended
    • New Annual Cost: (Current Cost-Potential Savings)*12

  • Anodot is filtering original Azure recommendations in the following use cases:

    1. VM has less than 7 active days in the last month or not present in Anodot billing information

    2. VM actual cost is lower than expected cost of the recommended VM - this can be caused by special rates or low usage during the month

    3. Potential saving is less than 1%

    4. Target machine pricing is unknown

    5. CPU Percentile 95 threshold as configured in Azure Advisor

  
4

Database Reserved-Instance

 Native + Anodot validation (Detailed validation logic)

RI purchase recommendations are based on customer historical usage of the past 30 days (subject to preferences). These recommendations are calculated by analyzing all incurred usage eligible to be covered by an RI (e.g. On-Demand usage) and using our unique algorithms to simulate possible combinations of RI’s that would cover that usage.
** supported only for EA accounts

  
5

MySQL Idle

 Anodot Identifying resource as idle, based on storage used that is less or equal to 1 based within the past 14 days.

  
6

Cosmos DB Idle

 Anodot Identifying the resource as Idle if the number of requests is no more than 1 within the past 14 days.

  
7

Maria DB idle

 Anodot Identifying resource as idle, based on storage used that is less or equal to 1 based within the past 14 days.

  
8

PostgreSQL Idle

 Anodot Identifying resource as idle, based on storage used that is less or equal to 1 based within the past 14 days.

  
9

SQL Idle

 Anodot Identifying resource as idle, based on storage used that is less or equal to 1 based within the past 14 days.

  
10

Idle Virtual Machine

 Anodot Identifying VM instances with low CPU. For example when the daily average CPU is less than 1% and network traffic in/out is lower than 10MB.

  
11

Virtual Machine Stopped

Anodot

Identify VMs that are stopped for at least 7 days (subject to preferences) but still carry additional charges.

  
12

Idle Load Balancer

 Anodot Identifying resource as idle, if not connected to any IP.

  
13

Disk Type Change

 Anodot Based on 7 days back of Average disk usage, suggest a more suitable disk type (based on checking its actual usage).

  
14

IP Unattached

 Anodot Review all IPs and checking if attached to any VM. if not - recommend to terminate.

  
15

Cosmos DB Right Sizing

 Anodot Based on throughput (number of connections and read and write requests) when resource is over provisioned or under provisioned, we recommend adjusting its type.

  
16

Snapshot Migration

 Native + Anodot validation (Detailed validation logic) Identifying Snapshots that are stored in premium storage and recommend to migrate from premium to standard storage.

  
17

Outdated Snapshot

 Anodot Identifying disk outdated Snapshot age that is more than 21 days (subject to preferences). To avoid unnecessary costs, it is recommended to delete a snapshot after this time period.

  
18

Cosmos DB Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity if applicable, to optimize costs.

  
19

Data Explorer Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity, if applicable, to optimize costs.

  
20

MySQL Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity to optimize costs.

  
21

PostgreSQL Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity to optimize costs.

  
22

Redis Reserved Capacity

 Native + Anodot validation Analyzing the usage on past 30 days and recommending to purchase reserved capacity to optimize costs.

  
23

SQL Data Warehouse Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity to optimize costs.

  
24

SQL Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity to optimize costs.

  
25

App-Service Reserved Capacity

 Native + Anodot validation (Detailed validation logic) Analyzing the usage on past 30 days and recommending to purchase reserved capacity to optimize costs.

  
26

Kusto Unused Data

 Native + Anodot validation (Detailed validation logic)    
27

AKS K8s Workload Rightsizing

 Anodot

Detailed recommendation explanation.

 
28

SQL Database Rightsizing

 Anodot validation

Analyzing the SQL database usage metrics (e.g., DTU, CPU utilization).

Recommendation algorithm: 

  1. DTU: Take from CUE where: “service” = “SQL Database” and “meter_name” LIKE “%DTU%”
  2. vCore: “service” = “SQL Database” and “meter_name” = “vCore”
  3. Filtering vCore databases covered by RI.
  4. DB information:
    - identify that the DB is a ‘single DB type’
    - For DTU identity the service tier and type (e.g S4)
    - For vCore identify the hardware type and amount of vCore (e.g DC-series 6vCore) https://learn.microsoft.com/en-us/rest/api/sql/databases/list-by-server?view=rest-sql-2014-04-01&tabs=HTTP 
  5. Each recommended option is being validated to meet the original Storage.
  6. vCore purchase type:

    - We will recommend only within the same hardware type.
    - We do not take into consideration the memory.

    Example: Let's say I have 12 vCore under ‘DC-series’, we utilize 40%. We can recommend moving to 4 vCore.

Recommendation Flow: 

Identify relevant resources (for vCore type we need to make sure RI does not cover it)
⬇

Collect utilization data + IOPS for DTU type 

⬇

Identify un-utilized database according to the defined preferences

⬇
Trigger recommendation

 

Savings Calculation

  1. DTU purchase type:
  • Current costs: As the customer can have a discount for his SQL and we do not have the discount numbers, we will take the current costs as ‘List Price’. (for comparison, we are doing it for VM right-sizing recommendation as well)
  • New costs: from public pricing
  1. vCore purchase type:
  • Current costs: As the customer can have a discount for his SQL and we do not have the discount numbers, we will take the current costs as ‘List Price’. (for comparison, we are doing it for VM right-sizing recommendation as well)
  • New costs: from public pricing

Recommendations Preference

  1. Days to check - default 30
  2. DTU/ vCore utilization aggregation function - the options are: average, max.The default is average
  3. Minimum potential savings (%) - default value is 5
  4. Un-utilization threshold - what is the minimum threshold we define in order to define a database as un-utilized. The default is 60%.

 
 

Anodot validation for Azure native recommendations

Anodot recalculates the savings for the originated Azure recommendations and filters low-saving recommendations based on the threshold mentioned per each recommendation in the table above.

 

Anodot's savings calculations take into account the actual cost while Azure is PAYG rate-based (In the VM right Sizing recommendation there might be scenarios where the saving will be PAYG rate-based). This means that Azure recommendation savings will still be calculated as if they have used the full cost even if a customer has only utilized half of the hours. Anodot acknowledges the need to reduce it by half to calculate the savings accurately. Similarly, any special rates or discounts that Anodot considers in the actual savings amount are not taken into account by Azure.