When do provisioned throughput units make sense?
Why B is the answer
For steady, high-volume workloads
Provisioned capacity is held for you whether or not you use it, so sustained volume justifies it.
In detail
- Provisioned capacity pays off when use is steady and high.
- Measure usage before you commit.
Use case
An illustrative scenario, not a real incident.
A customer app has heavy traffic all day, so reserved capacity costs less than paying per token, and latency is steady.
See it in different ways
flowchart TD
A{"Traffic pattern"} -->|"Variable or low"| B["Serverless API or standard"]
A -->|"Steady and high"| C["Provisioned throughput"]mindmap
root((GenAIOps))
Prompts
In Git
Variants
Models
Fit on your data
Gradual rollout
Capacity
Standard
Provisioned
Evaluation
In CI/CD
On production tracesmindmap
root(("Throughput"))
n1["Provisioned"]
n2["Steady"]
n3["High volume"]
n4["Standard"]
n5["Variable"]
n6["Lower volume"]Key point: Provisioned throughput suits steady volume.
Why the other options are wrong
- A. For workloads with no latency requirements
- Its benefit is predictable latency.
- C. For a prototype used by one developer
- A prototype does not need reserved capacity.
- D. For a workload that runs once a month
- Monthly use leaves it idle.