This recommendation identifies Bedrock foundation models running in your account that are approaching Legacy status or nearing End-of-Life (EOL), and recommends migration to the current Active version. Staying on legacy or EOL models exposes workloads to premium pricing, reduced performance, and eventual service disruption.
Key Decision Factors

1. Lifecycle state: Models in Active, Legacy, or EOL state are evaluated for migration.
2. Days-to-Legacy threshold: Active models within N days of transitioning to Legacy trigger a migration recommendation.
3. Days-to-EOL threshold: Legacy models within N days of EOL trigger a migration recommendation.
4. Active workload detection: Only models with observed usage (production or custom workloads) are recommended for migration.
5. Replacement availability: A recommended Active replacement model must exist for the family.

1. Resource Discovery and Filtering Data Sources

   • AWS Bedrock Model Lifecycle metadata (modelLifecycle field via the Bedrock APIs)
   • Bedrock model catalogue - list of Active, Legacy, and EOL models
   • Usage and instance configuration telemetry
   • CUR / billing data correlated by model version

2. Trigger Conditions

   A recommendation is generated when any of the following are true for a model with observed usage:

   • A foundation model version is approaching Legacy status (within the configured Days before Legacy trigger).
   • A model is in Legacy state and nearing EOL (within the configured Days before EOL trigger).
   • Custom or production workloads continue to run on models that are deprecated or scheduled for retirement.

3. Optimization Options

   • Migrate to the latest Active model - update application configurations to use the newest Active model with full support and best performance.

4. Estimated Savings

   Estimated Savings = Current monthly spend on the legacy model - Projected spend on the recommended Active model at the same usage level.

Reference: AWS Bedrock Model Lifecycle documentation.

• Days before Legacy trigger: How far in advance to flag Active models approaching Legacy status.
  • Days before EOL trigger: How far in advance to flag Legacy models approaching EOL.

Umbrella.

No.

• bedrock:ListProvisionedModelThroughputs
• bedrock:GetModelInvocationJob

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.