A county expects a sharp midday surge in its permitting-season chatbot and needs predictable Bedrock capacity without relying on on-demand throttling. Which deployment approach best fits that requirement?
Select an answer to reveal the explanation.
Short Explanation
Peak permitting season is like a county fair—everyone shows up at once, so you reserve seats instead of hoping walk-up capacity appears. Provisioned throughput on Bedrock does that: locked-in capacity for the busy window so the chatbot stays responsive when applications flood in.
Full Explanation
Amazon Bedrock provisioned throughput reserves dedicated model capacity so a county permitting chatbot can absorb a known midday surge without depending on shared on-demand headroom. When seasonal application volume concentrates into predictable peaks, locking in provisioned units gives the municipality consistent inference throughput and latency for resident Q&A—exactly the capacity-planning posture civic ops need when the permitting calendar is known in advance. On-demand alone may throttle under concurrent countywide load, which turns a forecastable busy window into citizen-facing failures at the counter and on the web. Keeping only on-demand invocation and raising Lambda concurrency until Bedrock stops throttling fails by concept: Lambda concurrency does not create Bedrock model capacity. You can scale the caller while the foundation-model API still returns throttling under shared on-demand limits, so the chatbot remains brittle during the surge. Fine-tuning a smaller classical ML classifier on SageMaker and retiring the foundation model for the season fails because a classical classifier does not replace generative chatbot behavior for open resident questions; it answers a different problem class and removes the GenAI capability the county still needs. Moving all resident chats to a nightly batch job fails operationally and civically: permitting questions are interactive midday work, not overnight batch. Deferring live answers breaks the service-level expectation residents have during office hours. Exam caveat: provisioned throughput is a commitment to capacity and cost. Buy what the peak forecast justifies, monitor utilization, and plan scale-down after the season so the county is not paying for idle reserved units year-round. Also distinguish Bedrock provisioned throughput from application autoscaling—both matter, but only provisioned units address model-side capacity. Operational check: Confirm the chosen foundation model supports provisioned throughput in the target Region; size model units from peak concurrent tokens and requests observed in prior seasons; set alarms on throttling and invocation latency during the midday window; and document a post-season deprovision or downsize review so finance and AI ops stay aligned.