Bedrock's cost isn't controlled by picking the cheapest model -- it's controlled by designing the architecture so every token you pay for delivers value.
Bedrock charges mainly through two paths: on-demand, per input and output token processed (with different prices per model -- output tokens always cost more than input tokens), and Provisioned Throughput, capacity reserved by the hour or month measured in "model units" that guarantees constant performance at a fixed cost regardless of exact traffic volume. There's also batch inference mode, which processes asynchronous jobs from S3 at a significant discount over on-demand pricing, with no low-latency guarantee.
Before optimizing, identify which regime you're spending in: if 80% of the cost is output tokens from long responses, the main lever is reducing output length or switching models; if the cost is input tokens from repeated context, the lever is prompt caching.
When an application resends the same extensive context on every call -- a long system prompt, reference documents, tool definitions -- Bedrock lets you cache that prefix with `cache_control` (available on Claude models via Anthropic's native API, and on other models depending on provider support). Tokens read from cache cost a fraction of the price of a token processed for the first time.
In Agents or RAG architectures where the same document context gets reused across many consecutive invocations, prompt caching can cut input token cost by 70-90% after the first invocation within the cache's validity window.
If the use case doesn't need a real-time response -- mass classification of historical tickets, generating summaries for thousands of documents, extracting data from an entire archive -- Bedrock's batch mode (`CreateModelInvocationJob`) processes the entire batch from S3 at a noticeably lower per-token cost than on-demand. The tradeoff is processing time that's not guaranteed in minutes, but in a range of hours -- acceptable for most back-office flows.
Many architectures use a single expensive model for every task when they could actually segment: a cheap, fast model for initial intent classification (is this query simple or complex?), and only escalate to the higher-capacity model for the subset of requests that actually need it. This "model cascade" pattern can cut a conversational architecture's total cost by 40-60% without degrading perceived experience, because most real queries in a customer-service system are simple.
Provisioned Throughput guarantees a fixed processing capacity at a fixed price, regardless of the actual volume processed within that capacity. It makes sense when traffic is predictable and sustained and volume is high enough that the effective per-token cost of the reserved capacity is lower than the on-demand equivalent -- generally starting at tens of millions of sustained monthly tokens, though the exact break-even point depends on the model and the commitment term (1 or 6 months). For intermittent or uncertain-growth traffic, on-demand remains financially safer.
Tag every Bedrock invocation by project, team, or application using resource tags and, where applicable, the request metadata parameter in calls, so Cost Explorer can break down spend by business unit. Set up CloudWatch alarms on invocation metrics (number of invocations, tokens processed) to catch anomalous consumption spikes before they show up in the monthly bill -- a bug in a retry loop without backoff can multiply an endpoint's cost within hours without anyone noticing until the billing cutoff.
Before scaling any Bedrock architecture to production, check: are you using the cheapest model that clears the quality bar per task segment? Are you caching repeated context with prompt caching? Are non-interactive workloads running in batch instead of on-demand? Do you have spend alarms configured? Have you run expected volume against the Provisioned Throughput break-even point? These five questions capture most of the real savings opportunities without sacrificing response quality.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel