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

Pricing- the Potential saving is calculated based on On-demand pricing.
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:

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

2. This allows us to identify potential savings by considering factors such as underutilized instances, reserved instance commitments based on actual runtime.

   • Billed instances - filter in only billed instances based on the following RDS states, where RDS State=Billed.
     Refer to the RDS billed states list.

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

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

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

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

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

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

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

   4. Multi AZ - same deployment_option as the current instance.

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

   6. Deployment Model - same deployment_model.

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

   8. Database edition - same database edition.

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

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

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

   • Alternatives Order: sorted by the Potential saving (saving opportunity) amount and then instance type RI coverage = Yes.
   • Potential saving higher than min_potential_saving preference setting (5%).

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.

• Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

No.

Suggest using the latest generation of instances to get the best performance and pricing. The recommendation is applicable only for resources that aren't covered by RI.

Filter resources that have RI coverage (RI coverage is true for even an hour).

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.

• Minimum Potential Savings (%), default $5.
  • Exclude Graviton, default exclude.
  • Same Physical Processor Only, default same physical processor only.
  • Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

Yes.
Since we dont cant access AWS using APIs we rely on the invoice only, hence the recommendation has different behaviour:

• Recommend the newest generation based on the vCPU and Memory of the current instance from the CUR.
• We compare the extracted instance type vCPU and Memory to the pricing page and recommend upgrading based on cost.
• The alternative present data that existing in the CUR and Pricing.
• Preference are applicable also for GovCloud.
• Note: The recommended instance_type can't be validated against the current EngineVersion as it is not available in the CUR data.

This recommendation identifies Provisioned IOPS that can be decrease .

1. Pricing- the Potential saving is calculated based 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 for 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 should be lower than IOPS utilization preference setting (40%).
7. Potential Savings should be higher than Min Potential Saving preference setting (5%).
8. Recommended IOPS= current max(p95) IOPS + spare capacity IOPS.
9. Savings logic:

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, and reserved instance commitments based on actual runtime.

• Days To Check: Define how many days to check back for the resource, default 60 days.
  • Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

No.

This recommendation recommend on RI purchase and is based on customer historical usage.
Note: We do not recommend on AWS RDS Serverless

These recommendation analyze 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.
Recommendations are generated at the resource rather than by individual instance type.

For example, if an RDS cluster consists of multiple instances with partial Reserved Instance (RI) coverage, multiple recommendations may be produced. Each recommendation reflects different commitment options (e.g., various term lengths and upfront payment models).

• Num Of Days, default 21 days.
• Preferred Plan, default standard 1 year no upfront.
• Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

Yes.

This recommendation identifies RDS instances with consistently low utilization, indicating they may be idle or over-provisioned.

Identifying RDS instances with no more than 1 connection (DatabaseConnections) within the last 7 days and recommending to terminate the instance (subject to preferences).

• Days To Check, default 7 days.
  • Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

No.

This recommendation identifies RDS storage type that can be changed, the recommendation analyzes your current database storage configuration and suggests migrating to a more cost-effective or performance-aligned storage option.

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.

Supported volume types:

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

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, default $5.

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, default 30 days.

3. Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

Yes.

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.

Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

No.

This recommendation identifies RDS Clusters/Instances that are about to be charged on Extended Support charges or already charged to avoid unexpected costs and plan upgrades effectively. The recommendation provides an early detection before you get charged, and by default, is set to be triggered 30 days before the extended support is effective. Using the recommendation preferences, you can tune the configuration and set it to receive a much earlier detection.

Umbrella extracts the exact RDS cluster/instance version.

• Umbrella extracts the RDS's extended support status, and considering only these that have 'RDS Extended Support' = 'Enabled'.
• Umbrella extracts the extended support calendar periodically once a month.
  • 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 on Amazon RDS by using 'RDS end of standard support date' field.
• Each RDS version is scaned against the release calendar versions.
  • In case the extended support for this version is going to be applied in the next x days (subject top the preference) 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.

Special handling:

• Once recommendation created based on minor version the potential saving will be 0, as it's an operational recommendation and not cost savings for minor versions.
• Once the version is deprecated and removed from the calendar no recommendation will be triggered and the recommendation will be marked as not_applicable and wont be presented in the UI.

• Days Before Expiration, default 30 days.
  • Minor Version, trigger recommendations for minor versions as well, default Disable.
  • Cluster Access Level (Read/ Write/ Read + Write)

Umbrella.

Yes.
Since we cant access AWS using APIs we rely on the invoice only, hence the recommendation has different behaviour:

• The extended support is based on the invoice data. The recommendation version is based on the latest version available in the USE1 region as we dont have the versions in Gov.
• The early notification preference isn't relevant for the GovCloud instances as we don't have the version from the API for early detection, therefore we know only after the extended support is effectlvly being charged.
• Once we detect that there's a cost where Service=RDS and Usage Type like 'ExtendedSupport' we will trigger a recommendation.