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 and Opus 5, and 15x on Claude Opus 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 hours of use. A workload running 24/7 at volume spends enough on tokens that a well-sized commitment can undercut pay-as-you-go. 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 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 latency reflects shared queueing at peak, while reserved capacity is prioritised and targets 99.5% uptime for model response, so p50 stays similar and p95 and p99 tighten. 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 fixed price per 1K TPM billed monthly on a 1-month or 3-month term. 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 targets a typical job inside 24 hours, as best effort rather than a guarantee. 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 quoted per 1K TPM by the account team and isn’t published, so the comparison runs against your own numbers. Work out the Standard-tier spend for the traffic the reservation would absorb, and treat that as the figure the quote has to beat. Run it against last quarter’s traffic as well as next quarter’s forecast, since the term is fixed once signed.

Two things change alongside. p95 latency tightens, because reserved capacity is prioritised rather than queued behind other tenants at peak, 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. The 24-hour figure is a target and not a guarantee, so submit Saturday evening rather than Sunday morning, which leaves the whole night as margin before Sunday afternoon distribution. 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, at Claude Sonnet 4.6 list prices of USD$3.00 per million input tokens and USD$15.00 per million output tokens:

Service A (24/7 assistant):
  15B input + 2B output tokens/month
  15,000 x USD$3.00  +  2,000 x USD$15.00  =  USD$75,000/month

Service B (weekly reports):
  240M input + 64M output tokens/week, x4 weeks
     960 x USD$3.00  +    256 x USD$15.00  =   USD$6,720/month

After the changes:

Service A: reserve 540K input + 72K output TPM (75% of peak)
  Standard spend the reservation would absorb  ~USD$56,000/month
  Standard overflow above the reservation      ~USD$19,000/month
  -> the quote has to land under USD$56,000 to be worth signing

Service B: batch inference, at half the Standard rate
     960 x USD$1.50  +    256 x USD$7.50    =  USD$3,360/month

Service B’s half is arithmetic, and lands the week it ships: USD$6,720 down to USD$3,360. Service A’s depends on a quote, with roughly USD$19,000 of Standard overflow on top of it either way.

What’s worth remembering

1. Which tiers a model offers is fixed per model and published on its model card. Claude Sonnet 4.6 offers Standard and Reserved, Claude Sonnet 5 offers Standard alone, Amazon Nova Pro offers Standard, Priority and Flex. Read the card before designing around a tier.
2. Three tiers are one API parameter: service_tier set to priority (75% premium), default, or flex (50% discount), with no commitment and one shared on-demand quota between them.
3. Throttling counts reserved tokens, not billed ones. Input plus max_tokens is deducted upfront, and output tokens burn down at 5x on Claude 4.7 and below, 10x on Sonnet 5 and Opus 5, 15x on Opus 4.8.
4. Reserved runs on a 1-month or 3-month term through the account team, with minimums of 100,000 input and 10,000 output TPM priced per 1K TPM. Reserve 70-80% of peak, let the rest overflow to Standard, and count CacheWriteInputTokenCount on the input side.
5. Batch inference runs at 50% of Standard against a best-effort 24-hour target rather than a guarantee, and supports neither tool calling nor structured output.
6. Provisioned Throughput is the older Model-Unit construct, billed hourly on no-commitment, 1-month or 6-month terms, and its newest Anthropic model is Claude 3.5 Sonnet v2.