Bedrock Provisioned Throughput reserved on an older model generation with a cheaper successor
What does ZopNight detect here?
ZopNight flags Amazon Bedrock Provisioned Throughput bought for an older model generation, such as `anthropic.claude-v2` or `meta.llama2-70b-chat-v1`, when the same-family successor has a lower no-commitment rate per model unit hour. The saving is the rate difference applied to the throughput's monthly cost, and committed 1-month or 6-month terms are skipped.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1610 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | successor rate per model unit hour lower than current |
| Source | ZopNight |
| Permissions used | bedrock:ListProvisionedModelThroughputs · bedrock:GetProvisionedModelThroughput · bedrock:ListFoundationModels |
Old model generations keep their hourly price
Provisioned Throughput is billed by the hour, and AWS sets the hourly price from the model, the number of model units and the commitment term. For a custom model the price is that of the base model it was customized from. So a throughput reserved for an early Claude, Titan, Jurassic, Command or Llama 2 model keeps paying that model’s rate even after the vendor ships a newer generation that is cheaper per unit.
Old models also have a shelf life. Under the Bedrock model lifecycle a model moved to Legacy stays there for at least 6 months before its end-of-life date, and for end-of-life dates after February 1, 2026 part of that period is extended access, when AWS says to expect higher pricing set by the provider.
Checking which model each throughput runs
aws bedrock list-provisioned-model-throughputs \ --query 'provisionedModelSummaries[].[provisionedModelName,foundationModelArn,modelArn,modelUnits,commitmentDuration]' \ --output table
aws bedrock list-foundation-models \ --query 'modelSummaries[].[modelId,modelLifecycle.status]' --output tableThe first lists each throughput with the model it serves and its term. The second shows whether
that model is ACTIVE or LEGACY.
Older models the rule knows a successor for
ZopNight matches both the model and the base foundation model, so a custom model built on an old base is caught too. The pairs are same-family steps:
| Older model | Successor priced against |
|---|---|
| Claude v1, v2, v2.1 | Claude 3.5 Sonnet |
| Claude Instant v1 | Claude 3.5 Haiku |
| Titan Text Express v1 | Titan Text Premier |
| Titan Text Lite v1 | Titan Text Express |
| Jurassic-2 Mid, Jurassic-2 Ultra | Jamba 1.5 Mini, Jamba 1.5 Large |
| Command, Command Light | Command R |
| Llama 2 13B Chat, Llama 2 70B Chat | Llama 3 8B Instruct, Llama 3 70B Instruct |
Throughputs that are not flagged
A throughput on a 1-month, 6-month or other committed term is skipped before any pricing, because the rate ZopNight holds is the no-commitment one and the committed price is different. It also stays silent when either rate is missing for the Region, or when the successor is not cheaper. Rates are matched to model IDs exactly; no guessed mapping is used.
The rate difference as the saving
saving = monthly cost x (1 - successor rate per MU-hour / current rate per MU-hour)Both rates are the published no-commitment Provisioned Throughput rates per model unit hour, so the saving reflects the same number of model units on the newer model. Throughput per unit can differ between generations, which is worth checking before you size the replacement.
Moving the reservation to the newer model
- Benchmark the successor on representative prompts for quality and output length.
- Buy a new throughput for it:
aws bedrock create-provisioned-model-throughput --model-id NEW_MODEL_ID --provisioned-model-name my-pt-v2 --model-units 1 - Point your application at the new provisioned model ARN and watch latency and errors.
- Delete the old one with
aws bedrock delete-provisioned-model-throughput.