This recommendation identifies if the provisioned Model Units (MUs) can be adjusted based on actual usage trends. Reduce provisioned throughput where utilization is consistently low, where persistent throttling or performance lag is observed.

Key Decision Factors

1. Throttling Detection: Any throttled requests trigger scale-up recommendations
2. Utilization Threshold: Usage below 50% triggers scale-down recommendations
3. Savings Threshold: Only recommendations with ≥5% potential savings are included
4. Capacity Buffer: Scale-down recommendations include 10% spare capacity

1. Resource Discovery and Filtering Data Sources

   • AWS Cost Explorer for Bedrock costs
   • CloudWatch metrics for usage and performance data
   • AWS Bedrock API for provisioned throughput allocations

2. Key Metrics Calculation

   A. Throttling Analysis- Identifies when the current provisioned throughput is insufficient, causing requests to be throttled.
   Calculation Method:

   • Extract total throttled invocations from CloudWatch metrics
   • Calculate throttle ratio: throttled_invocations / (total_invocations + throttled_invocations)
   • This ratio indicates what percentage of requests are being rejected due to capacity constraints

   B. Utilization Analysis- Measures how efficiently the provisioned capacity is being used relative to the allocated model units.
   Calculation Method:

   • Calculate total invocations across the analysis period
   • Determine the number of data points (days) in the analysis
   • Calculate actual throughput: total_invocations / number_of_data_points / 24 (converts daily to hourly rate)
   • Calculate utilization: (actual_throughput / current_model_units) × 100
     Threshold: Minimum utilization threshold (default: 50%)
     Decision Logic:
     • If utilization is lower than minimum_threshold, the system recommends scaling down
     • Low utilization indicates over-provisioning and potential cost savings

   C. Model Units Calculation- Determines the optimal number of model units needed based on actual usage patterns.

   For Scale Down Recommendations:

   • Target utilization = minimum_threshold + 10% (adds 10% spare capacity)
   • Recommended model units = max(1, round(actual_throughput × 100 / target_utilization))
   • Ensures the new allocation provides adequate capacity with some buffer

3. Rightsizing Decision Logic

   Triggers:

   • Utilization is lower than minimum_utilization_threshold (default: 50%)

   • Indicates current capacity is over-provisioned

     Action:

   • Reduce model units to target utilization + 10% spare capacity

   • Formula: recommended_mus = actual_throughput × 100 / (min_utilization + 10)

   • Balances cost savings with maintaining adequate capacity

Key Decision Factors Summary

1. Throttling Detection: Any throttled requests trigger scale-up recommendations
2. Utilization Threshold: Usage below 50% triggers scale-down recommendations
3. Savings Threshold: Only recommendations with ≥5% potential savings are included
4. Capacity Buffer: Scale-down recommendations include 10% spare capacity
5. Proportional Scaling: Scale-up recommendations are proportional to throttling experienced

**Min Utilization Threshold**: Calculate actual throughput (invocations per hour) for utilization, default is 50%.
* **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=14)

Umbrella.

No.

bedrock:ListProvisionedModelThroughputs.

This recommendation analyzes your usage patterns and provisioned throughput of Bedrock model endpoints to identify opportunities to commit to a lower, cost-effective level of provisioned throughput without impacting performance, helping reduce unnecessary spend.

Provisioned throughput Overview:

Provisioned throughput pricing is designed for situations where you need rock-solid, consistent performance. With this model, you reserve capacity ahead of time, which guarantees throughput and smooth performance. You’re billed hourly per model unit.
With provisioned throughput pricing, you can choose between 1-month and 6-month commitments. The longer the commitment, the better the rate.

One good use case for a provisioned throughput model is a machine translation service that constantly processes a high volume of data. Here’s a pricing example:

• Workload: Predictable, at 1,000,000 input tokens per hour
• Commitment: You make a 1-month commitment for 1 unit of a model, which costs $39.60 per hour.

Provisioned throughput pricing gives you the peace of mind of consistent performance at a predictable cost–great for large, steady workloads.

When purchasing Provisioned Throughput, you can choose from the following commitment durations:

• No Commitment: Pay hourly with the flexibility to delete the provisioned throughput at any time.AWS Documentation
• 1-Month Commitment: Lower hourly rates compared to no commitment. You cannot delete the provisioned throughput until the one-month term concludes.AWS Documentation
• 6-Month Commitment: Offers the most significant discount per hour. The provisioned throughput cannot be deleted until the six-month term ends.

These commitments are beneficial for workloads with consistent, high-volume inference needs, providing cost efficiency and guaranteed throughput

A commitment recommendation is suggested when the following conditions are met:

• Stable Utilization (Min Stability) - The usage pattern shows consistent behavior over time, such as steady token throughput or invocation volume.
• Minimum Daily Tokens (Min Daily Tokens)- The average daily token usage meets or exceeds a defined threshold, indicating a meaningful and sustained level of consumption.
• Permission - This recommendation cannot be generated without the required permission (list_provisioned_model_throughputs) because we can't reliably detect when a customer switches from On-Demand (foundation model) to Provisioned Throughput. While the model may still appear in the CUE (Cost and Usage Explorer), it could be listed under a user-defined name, making it hard to identify. To accurately track completion status and generate the recommendation, we need additional permission to get this information directly.

• Min Daily Tokens, default 50000.
  • Min Stability: Calculate stability score (0-100%) based on token usage variance, default 49.
  • 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= 14)

Umbrella.

No.

bedrock:ListProvisionedModelThroughputs.