A SaaS startup runs nightly Bedrock on-demand calls to summarize 500k support tickets, with heavy repeated system prompts and a 6-hour latency tolerance. Costs spiked 4x and throughput is throttled at peak. Which Bedrock cost optimization for AI inference batching and caching should the architect select?

The correct design uses Bedrock batch inference because the workload is a large offline summarization with a six-hour tolerance: batch jobs are priced below on-demand, run from S3 input files through managed queues, and avoid the peak-time throttling of synchronous calls. Because the same long system prompt is sent with every ticket, shortening and standardizing that prompt (and keeping only the ticket-specific text variable) directly cuts input tokens across all 500k records. The design that pairs batch inference with prompt caching looks ideal but fails on a documented limit: Bedrock prompt caching is supported only for on-demand inference and is not supported with the batch inference API, so the cache would never be used. Provisioned throughput with caching reserves hourly model-unit capacity for latency-sensitive traffic, forfeits the batch discount, and turns delay tolerance into unnecessary spend. On-demand processing with prompt caching does reduce repeated-prefix cost, but it keeps on-demand pricing and the same throttling at peak, so it does not remove the cost spike or capacity problem that batch queues absorb. For the exam, remember that batch solves cost-efficient deferrable throughput, provisioned throughput solves guaranteed latency, and prompt caching applies only to on-demand inference. In practice, confirm job completion inside the nightly window and track input-token trends in Cost Explorer.