Amazon Bedrock Provisioned Throughput
Does ZopNight manage Amazon Bedrock Provisioned Throughput?
Bedrock Provisioned Throughput bills per model unit per hour from purchase until deletion, with 1-month and 6-month commitments locking the rate in. Idle units burn at full price around the clock. ZopNight reads 90 days of Bedrock CloudWatch metrics and flags throughput whose invocation volume never approaches its reserved capacity.
Rules that fire on Amazon Bedrock Provisioned Throughput
No active rule family targets Amazon Bedrock Provisioned Throughput today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, metrics, cost tracking, and recommendations only. |
Bedrock Provisioned Throughput reserves dedicated model capacity in units billed per hour, often under one- or six-month commitments. It is one of the largest fixed costs in generative AI accounts, and underused throughput units burn money at a fixed rate around the clock.
Reserved tokens, hourly rent
Provisioned Throughput converts inference from a variable cost into a fixed one: each model unit guarantees a defined token throughput for a specific model and bills per hour whether invocations arrive or not. Commitment terms of one or six months lower the hourly rate in exchange for paying it for the full term regardless. A no-commitment purchase can at least be deleted when the workload disappears; a committed one cannot be escaped, only used. Against the on-demand alternative, where tokens bill as consumed and idle costs nothing, provisioned capacity is a bet that traffic will be high and steady enough to beat per-token pricing.
Utilization against the reservation
ZopNight discovers provisioned throughput through its dedicated Bedrock provider on the 6-hour cycle, reads hourly CloudWatch metrics from the Bedrock namespace with a 90-day lookback, and attributes cost from Cost Explorer or CUR 2.0. The utilization recommendation compares invocation volume against what the purchased units could serve: throughput bought for a launch that plateaued, capacity sized to a peak that happens one hour a day, or units serving a model version the application has since moved off. Ninety days of history separates a quiet fortnight from structural overprovisioning.
Fixed-capacity mistakes in generative AI
The recurring shapes: provisioned units bought during on-demand throttling incidents and kept long after quota increases resolved the pressure; capacity for a custom model whose product was shelved, still billing because the commitment outlived the roadmap; and no-commitment units that could be deleted tonight, surviving on the assumption that someone else is using them.
Where purchases are visible
The Bedrock console’s Provisioned Throughput view lists purchases with model, units, commitment type, and expiry. Invocation metrics per provisioned model against its rated throughput give the utilization ratio, the one number that says whether the reservation earns its rent.