Route Bedrock Requests to Provisioned Throughput via the Model ARN
Short answer
B Replace the modelId string with the provisioned model ARN returned by CreateProvisionedModelThroughput so requests route to provisioned capacity.
Question
The company uses the CreateProvisionedModelThroughput API to purchase provisioned throughput. Amazon CloudWatch metrics show that the provisioned capacity is unused while on-demand requests are being throttled. The company finds the following code in the application:
python response = bedrock_runtime.invoke_model(modelId="anthropic.claude-v2", body=json.dumps(payload))
The company needs the application to use the provisioned throughput and to resolve the throttling issues.
Which solution will meet these requirements?
Key Takeaways
The test is whether you know that Bedrock selects on-demand versus provisioned endpoints solely from the modelId value, so the trap is fixing capacity or retries instead of the routing identifier.
This AIP-C01 scenario tests how Amazon Bedrock routes traffic between on-demand and provisioned endpoints. Passing the provisioned model ARN returned by CreateProvisionedModelThroughput instead of the base model ID consumes purchased capacity and removes on-demand throttling (B).
Common mistake: Option A — buying or increasing model units looks like a capacity fix, but the provisioned endpoint is never invoked while the code still passes anthropic.claude-v2, so the extra units stay idle.
Expert Analysis
The governing principle: routing follows the identifier you pass
Amazon Bedrock addresses a request by the identifier in the modelId field. Passing a base model ID such as anthropic.claude-v2 sends the call to the on-demand endpoint, whose shared quota is subject to the account's InvokeModel request rate limits. Provisioned throughput is a separate, dedicated inference endpoint, and Bedrock only dispatches to it when the request carries the provisioned model ARN returned by CreateProvisionedModelThroughput. This is why CloudWatch shows purchased capacity idle while on-demand calls throttle — the two signals describe one root cause, not two.
Mapping the scenario to option B
The code snippet still passes modelId="anthropic.claude-v2", so every call bypasses the provisioned endpoint. Replacing that value with the provisioned model ARN routes the 10,000 requests per hour onto the purchased model units and eliminates the on-demand throttling in a single change. This matches AWS guidance that provisioned throughput is consumed only by requests addressed to the provisioned model ARN.
Why the other options fail
Option A adds model units to capacity that is never reached — CloudWatch already proves the bottleneck is routing, not capacity, so spending more money changes nothing. Option C wraps the symptom in exponential backoff; retries still hit the shared on-demand quota and add latency without ever touching provisioned capacity. Option D merely switches to streaming (InvokeModelWithResponseStream); streaming changes the response format, not the endpoint selection, and the same on-demand limits still apply. A comment arguing for C as "the only logical solution" overlooks that retry logic cannot redirect traffic to an already-purchased endpoint.
Bottom line
Option B is the only change that both consumes the provisioned throughput and resolves the throttling.
Official Reference
https://docs.aws.amazon.com/bedrock/latest/userguide/provisioned-throughput.html
This link opens the official vendor documentation in a new tab.
Exam Strategy
When a question pairs "unused purchased capacity" with "throttling of normal calls," treat it as a routing question and look for the identifier that names the target endpoint before considering scaling or retry options. Eliminate any option that changes volume, resilience, or response format without changing how the request is addressed, because those leave the endpoint selection untouched. Confirm the correct choice by checking that its change alone would shift traffic onto the capacity CloudWatch shows as idle.
Frequently Asked Questions
Why does provisioned throughput stay unused while on-demand calls throttle?
Does adding model units or retry logic fix Bedrock throttling here?
Where do I get the identifier needed to use provisioned throughput?
Community Votes
86% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 7
-
GiorgioGss 👍 3 Answered BWhen you use a standard model ID like "anthropic.claude-v2", Bedrock routes the request to the OnDemand endpoint. Ondemand throughput is shared across all AWS customers.
-
eesa 👍 2 Answered BOpción B - SOLUCIÓN CORRECTA: ✅ Resuelve el problema raíz: La capacidad provisionada está sin usar porque el código usa el model ID base en lugar del ARN del modelo provisionado ✅ Uso correcto de throughput provisionado: Para usar capacidad provisionada, debes especificar el ARN del modelo provisionado, no el model ID base ✅ Elimina throttling: Al usar el ARN correcto, las requests usarán la capacidad provisionada en lugar de on-demand
-
Chibuzo1 👍 2 Answered BThe application is using a generic model ID, which routes all requests through the on-demand endpoint — completely bypassing the provisioned throughput that was already purchased. The fix is to replace that model ID with the Provisioned Model ARN returned by CreateProvisionedModelThroughput:
-
ArunRav 👍 2 Answered BOption B as that will help to use the provisioned capacity
-
Chibuzo1 👍 1 Answered BThe application purchased provisioned throughput but is still routing every request to the on-demand endpoint by using the base model ID string. Provisioned capacity sits idle while on-demand requests pile up and get throttled — exactly what CloudWatch confirms. The application purchased provisioned throughput but is still routing every request to the on-demand endpoint by using the base model ID string. Provisioned capacity sits idle while on-demand requests pile up and get throttled — exactly what CloudWatch confirms.
Show 2 more comments
-
vedratna 👍 1 Answered Bthroughput gets provisioned at Model level and to utilise provisioned throughput; need to use provisioned Model ARN instead of direct Model ID.
-
67bdb19 👍 1 Answered CI'd bet my certification on C. It's the only logical solution presented.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All AIP-C01 Questions
Access 110 questions with complete answers and detailed explanations.
View Full AIP-C01 Practice Test →