A city library assistant sees only occasional evening questions and must minimize idle cost while still calling Amazon Bedrock. Which deployment approach best fits that sparse workload?
Select an answer to reveal the explanation.
Short Explanation
A quiet branch does not rent a full-time generator that hums all night—it flips the light when a patron walks in. On-demand Bedrock is that light switch for a low-traffic library bot. Paying for provisioned capacity around the clock wastes the book budget.
Full Explanation
A city library assistant with only occasional evening questions should minimize idle cost while still calling Amazon Bedrock via on-demand invocation: the city pays for inference when requests arrive rather than for reserved capacity sitting idle overnight. Sparse, unpredictable municipal traffic matches on-demand economics; provisioned throughput and always-on fleets fit steadier or peak-shaped demand patterns. Purchasing maximum provisioned throughput for all hours including idle overnight periods burns budget with little utilization for a quiet branch workload. Running a continuously warm dedicated GPU fleet sized for Black Friday traffic is over-provisioning disconnected from actual library chat volume. Fine-tuning and hosting a private model cluster solely to avoid any on-demand API adds operations burden and fixed cost without matching the sparse-workload need. Exam caveat: sparse or idle-cost stems select on-demand Bedrock—not max provisioned throughput or dedicated fleets “just in case.” Operational check: use on-demand model invocation for the library skill, set budgets and anomaly alerts on monthly spend, revisit provisioned throughput only if sustained concurrency appears, and keep prompts and eval sets ready so a future traffic shift does not require rebuilding the whole stack.