# Bedrock Provisioned Throughput Below Break-Even

> Bedrock Provisioned Throughput endpoints averaging under 1,000 invocations per day over 30 days may cost more than on-demand InvokeModel. ZopNight validates that low-traffic signal but abstains from recommending today: on-demand per-token rates are not yet resolvable, so the break-even between PT monthly cost and projected token spend cannot be computed.

Source: https://zop.dev/integrations/aws/recommendations/bedrock-provisioned-throughput-below-break-even
Updated: 2026-08-19

---

## Active throughput sitting under the invocation floor

- resource.Type: bedrock-pt
- MetricsAware: Invocations Sum-stat datapoints, read from [the invocation series Bedrock publishes to CloudWatch](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html) (must show activity; idle handled by RC-1601)
- pricing: per-PT monthly cost

## The 1,000 invocations per day floor

```text
bedrockPTToOnDemandLookbackDays=30, bedrockPTToOnDemandInvocationsPerDayFloor=1000
```

## Why the missing on-demand token rate blocks break-even

concrete-or-abstain (Category discount: switching PT→on-demand InvokeModel is a rate-model change, a cost lever; re-keying to "advisory" to dodge shouldDropLowSavings was advisory-dumping and is banned). The detection signal (activity present but daily invocations below the floor) is validated, but the rule currently abstains (returns nil), because the break-even saving = PT monthly cost − projected on-demand cost (input/output tokens × [the published per-token rates](https://aws.amazon.com/bedrock/pricing/)) cannot be computed. PRODUCER-GAP (partial): this PR's producer now resolves the PT per-MU-hr rate (aggregator extractBedrockKey returns the bedrock-pt-raw|\<displayToken> sentinel for the no-commit PT SKU, resolved to a real rate in FetchRates), so the PT-cost side is available. What's still missing is the on-demand token side: extractBedrockKey returns "" for the on-demand InputTokens/OutputTokens SKUs, so the projected on-demand cost can't be computed and the rule still abstains. When that on-demand token-rate producer lands, the rule re-keys to compute the real break-even from InputTokenCount/OutputTokenCount × rates vs cost and emits a concrete "discount" rec; until then it never emits a $0 rec.

## Shifting sporadic traffic to on-demand InvokeModel

1. Verify the workload is sporadic vs sustained
2. Estimate on-demand cost from input/output token volumes × per-token rates
3. Migrate to direct InvokeModel if on-demand cost is lower
4. Delete the PT once traffic has shifted

## Invocations as the sustained-use signal

Invocations (30-day lookback, Sum-statistic)