How to Match Bedrock Pricing to Workload Rhythm

The situation

Two production services on Bedrock, both calling Claude Sonnet 4.6, both running into the limits of on-demand. Sonnet 4.6 has no in-Region on-demand option in either team’s Region, so both already call it through the us.anthropic.claude-sonnet-4-6 cross-Region inference profile.

Service A: the customer-facing assistant. Runs 24/7. Peak traffic is 8 requests per second (US and EU business hours overlapping); trough is around 2 requests per second (overnight in both regions). Median request consumes 1,500 input tokens and produces 200 output tokens. Runs ~10 million requests per month. Latency matters, product has a p95 SLA of 2 seconds end-to-end; Bedrock latency is most of that budget. The service has started hitting on-demand throttling during peak, seeing occasional ThrottlingException errors that the retry logic masks but that add latency spikes.

Service B: the weekly report generator. Runs for about 6 hours every Sunday morning. Generates ~80,000 reports in that window, each consuming ~3,000 input tokens and producing ~800 output tokens. Rest of the week, zero traffic. Latency per request doesn’t matter, reports aren’t interactive, but the job has to finish before downstream distribution kicks off on Sunday afternoon.

Plain on-demand fits neither well. What shape of pricing suits each, and what, if anything, to commit?

What actually matters

Inference pricing for managed foundation models comes in two shapes. Pay-as-you-go charges per tokenTokenThe unit of text an LLM actually sees – usually a short character sequence, not a whole word., input at one rate and output at several times that, with no commitment, under account-level requests-per-minute and tokens-per-minute quotas set per modelModelA trained set of weights plus the architecture that makes them useful – the thing you load up and run inference against.. Committed capacity reserves a slab of throughput at a fixed monthly price, billed flat whether or not it is used, with traffic above the reservation falling back to pay-as-you-go rather than failing.

Throttling does not track the token counts on the invoice. Bedrock deducts input tokens plus max_tokens from the TPM quota at the start of every request, adjusts once the response finishes, and burns output tokens down at a multiple. That multiple is 5x on Claude models at version 4.7 and below, 10x on Claude Sonnet 5, Opus 5, Opus 5.5 and Fable 5.1, and 15x on version 4.8. Cache reads don’t count against the quota; cache writes do. A service well inside its TPM on billed tokens can still return ThrottlingException all afternoon, and an over-generous max_tokens is the usual reason.

Whether to commit at all turns on utilisation rather than hours of use, and the Reserved rate is published, so the sum does not wait on the account team. Claude Sonnet 4.6 reserved through a geographic profile costs USD$0.198 per hour per 1K input tokens-per-minute on a 1-month term. A thousand tokens a minute held for an hour is 60,000 tokens, and 60,000 input tokens at the Standard rate of USD$3.30 per million is the same USD$0.198. A reservation therefore matches pay-as-you-go when it is fully used and costs more below that; a 3-month term takes 10% off. What it delivers is prioritised capacity and the uptime target, not a smaller bill. A workload running a few hours a week would hold a month of reserved capacity idle for most of it. Sizing is the second half of the same decision: cover the full peak and most of the reservation idles overnight, cover less and the excess falls back to pay-as-you-go at pay-as-you-go rates. A commitment is also rigid for its term. If traffic doubles next quarter the reservation needs resizing; if it halves, the monthly bill does not move.

Which pricing shapes a model offers is set per model and published on its model card, not negotiated per account. Claude Sonnet 4.6 offers Standard and Reserved, and neither Priority nor Flex. Claude Sonnet 5 offers Standard alone. Amazon Nova Pro offers Standard, Priority and Flex, and not Reserved. No model offers all four, so the shortlist narrows before any of the trade-offs above get weighed.

Latency behaves differently across the two shapes. Pay-as-you-go runs on shared capacity, while a reservation is prioritised compute and targets 99.5% uptime for model response. AWS publishes no latency figures for either, so how far the tail tightens is something to measure rather than assume. CloudWatch carries InvocationLatency, TimeToFirstToken and InvocationThrottles per model, and the ResolvedServiceTier dimension shows which tier actually served a request. EstimatedTPMQuotaUsage is an approximation, and AWS says not to plan capacity from it alone.

What we’ll filter on

1. Offered on the model we’re actually calling?
2. Latency predictability, p50, p95 and p99 under peak load?
3. Monthly cost at expected usage?
4. Cost when actual usage deviates from plan?
5. Commitment flexibility, mid-term?
6. Operational overhead, what changes day to day?

The landscape

Bedrock’s runtime API takes an optional service_tier parameter, set to reserved, priority, default or flex. Four of the options below are that one parameter. Batch is a separate API, and Provisioned Throughput is a separate purchase.

1. Standard tier (the default). Pay per token, no commitment, subject to the account’s RPM and TPM quotas for the model. Latency varies with load. Requests that omit service_tier land here, as does anything sent with default.

2. Standard plus a quota increase. Raise the model’s RPM and TPM quotas through a Service Quotas request. The per-token rate doesn’t change and neither do the latency characteristics; there is simply more headroom before throttling. The on-demand quota is shared across the Standard, Priority and Flex tiers.

3. Standard plus cross-Region inference. Call a geo profile (us., eu., au., jp.) or the global profile instead of a bare model ID, and Bedrock routes the request to a Region with capacity. That absorbs bursts without a commitment, and adds cross-Region network time. For many current models, Sonnet 4.6 in most Regions included, it is the only way to reach the model on demand rather than an optimisation on top.

4. Flex tier. service_tier: "flex" takes 50% off the Standard per-token rate in return for longer processing times. Same shared quota, no commitment. Fits model evaluations, summarisation sweeps, and agentic background work that is online but not urgent.

5. Priority tier. service_tier: "priority" carries a 75% premium over Standard and is served ahead of Standard and Flex requests. No reservation, no commitment. Fits customer-facing flows whose latency pain is real but whose volume doesn’t justify reserving capacity around the clock.

6. Reserved tier. A capacity reservation arranged through the AWS account team. Input and output tokens-per-minute are set separately, with minimums of 100,000 input TPM and 10,000 output TPM, at a published price per 1K TPM per hour, billed monthly on a 1-month or 3-month term. On Sonnet 4.6 through a geographic profile the rate is USD$0.198 per hour per 1K input TPM and USD$0.99 per 1K output TPM on a 1-month term, 10% less on three. A geographic profile carries a 10% premium over the global one, in the reserved rate as in the per-token rate. It targets 99.5% uptime for model response, and traffic above the reservation overflows to Standard automatically. Two details to plan around: CacheWriteInputTokenCount counts toward the input reservation alongside InputTokenCount, and billing runs until the account manager deletes the reservation.

7. Batch inference. A separate asynchronous API at 50% of the Standard per-token rate. Write the prompts as JSONL to S3, submit a job, collect the results from S3. AWS publishes no turnaround target; what it publishes is timeoutDurationInHours, set per job between 24 and 168 hours, which bounds the worst case rather than the typical one. Batch supports neither tool calling nor structured output, and each record is processed independently.

8. Provisioned Throughput. The older reservation construct, bought in Model Units and billed hourly, on a no-commitment, 1-month or 6-month term. Its supported-model list stops several generations back (nothing newer than Claude 3.5 Sonnet v2 on the Anthropic side), and what remains of its everyday use is serving customised models, which require it. For a current foundation model the Reserved tier is the equivalent lever.

Evaluation

Side by side

Service A and Service B, placed

The solution

Service A: Reserved tier, 1-month term. The traffic shape, steady daily pattern and stable week to week, fits a monthly reservation. Peak works out to 720,000 input TPM and 96,000 output TPM (8 rps at 1,500 in and 200 out), both well above the tier’s minimums. Reserve about 75% of that, 540,000 input and 72,000 output TPM, rather than 100%. Covering the full peak leaves capacity idle two-thirds of the day, and traffic above the reservation overflows to Standard automatically at Standard rates, which is what those hours cost today. Size from InputTokenCount plus CacheWriteInputTokenCount in CloudWatch rather than from input tokens alone, because cache writes count against the input reservation.

Reserved pricing is published per 1K TPM per hour, so the comparison is arithmetic rather than a negotiation. At USD$0.198 and USD$0.99 an hour, 540,000 input and 72,000 output TPM comes to USD$178.20 an hour, about USD$130,000 across a 730-hour month, against roughly USD$76,000 of Standard spend for the traffic it absorbs. It costs more because the reservation runs under 60% utilised on this traffic shape. The extra USD$54,000 a month is for the prioritised capacity and the 99.5% uptime target. Run the same sum against last quarter’s traffic as well as next quarter’s forecast, since the term is fixed once signed.

Two things change alongside. Peak requests run on prioritised capacity rather than shared capacity, and the tier targets 99.5% uptime for model response. The throttling that the retry logic has been masking is worth attacking separately: max_tokens is deducted from the TPM quota upfront, so a request configured for 8,192 tokens that returns 200 holds down quota it never uses. Trimming max_tokens towards the real completion length, and raising the model’s TPM quota, both help before any reservation lands. Priority tier would be the lighter fix on a model that offers it. Sonnet 4.6 does not.

Service B: batch inference. A reservation covering 6 active hours in a 168-hour week idles for the other 162. Batch runs at 50% of the Standard rate with no commitment: write the 80,000 records as JSONL to S3, submit one job, collect the output from S3. AWS publishes no completion-time target, only a per-job timeout set between 24 and 168 hours, so the deadline needs margin and an event rather than a clock: submit Saturday evening rather than Sunday morning, and start distribution on the job-completed event. Check one constraint first. Batch supports neither tool calling nor structured output, and each record is processed on its own with no multi-turn exchange, so a generator that calls tools mid-report has to stay on the synchronous API. Flex would be the near-miss on a model that offers it, and still the wrong shape, because this job is a manifest rather than online traffic.

What stays where. Ad-hoc queries and experimentation notebooks stay on Standard, which is the tier designed for them. Evaluation runs go to batch alongside the reports, since Flex isn’t offered on this model.

Rollout. Service A moves to the Reserved tier through the account team over two weeks. Week one, reserve half the target and watch utilisation and Standard overflow in CloudWatch, where the ServiceTier and ResolvedServiceTier dimensions show which tier actually served each request. Week two, true up once the numbers hold. Service B’s submit-and-collect code is a sprint: the real-time invocation loop becomes a batch-job state machine, driven off EventBridge job-state-change events rather than polling.

Worked example

Current monthly spend, all Standard on-demand. Both services call the us. geographic profile, which lists at USD$3.30 per million input tokens and USD$16.50 per million output tokens; the global profile is USD$3.00 and USD$15.00:

Service A (24/7 assistant):
  15B input + 2B output tokens/month
  15,000 x USD$3.30  +  2,000 x USD$16.50  =  USD$82,500/month

Service B (weekly reports):
  240M input + 64M output tokens/week, x4 weeks
     960 x USD$3.30  +    256 x USD$16.50  =   USD$7,392/month

After the changes:

Service A: reserve 540K input + 72K output TPM (75% of peak), 1-month term
  540 x USD$0.198/hr  +  72 x USD$0.99/hr  =    USD$178.20/hour
  across a 730-hour month                       USD$130,086
  Standard overflow above the reservation         ~USD$6,600
  -> USD$136,700 against USD$82,500 all-Standard
  (a 3-month term brings the reservation to      USD$117,077)

Service B: batch inference, at half the Standard rate
     960 x USD$1.65  +    256 x USD$8.25    =   USD$3,696/month

Service B’s half is arithmetic, and lands the week it ships: USD$7,392 down to USD$3,696. Service A moves the other way. The reservation is a 66% increase on the Standard bill, for capacity that runs under 60% utilised. It answers the p95 SLA that started this, not the bill.

What’s worth remembering

1. Check the model card for tiers. Sonnet 4.6 offers Standard and Reserved; Sonnet 5 Standard alone; Nova Pro Standard, Priority and Flex.
2. Priority and Flex are one parameter. service_tier takes priority (75% premium) or flex (50% off); no commitment, one on-demand quota shared with Standard.
3. Throttling counts reserved, not billed, tokens. Input plus max_tokens is deducted upfront; output burns quota at 5x to 15x depending on the Claude model.
4. Reserved is not a discount. USD$0.198 an hour per 1K input TPM equals the Standard rate fully used; idle reserved capacity costs more.
5. Batch halves the rate. AWS publishes a 24-to-168-hour job timeout, not a turnaround target; tool calling and structured output are unsupported.
6. Provisioned Throughput now serves customised models. Billed hourly in Model Units; no Anthropic model newer than Claude 3.5 Sonnet v2.