Research-backed calculator guide

Amazon Bedrock Batch Inference Pricing: When the 50% Discount Is Actually Usable

Understand Amazon Bedrock batch inference pricing, test whether the 50% discount fits your model and latency needs, and calculate a defensible batch-versus-on-demand estimate.

What Amazon Bedrock batch inference pricing includes

Batch is an inference mode for independent records, not a faster queue. AWS's user guide says you can format records with either the InvokeModel or Converse API format, upload the input files to S3, submit one batch job, and retrieve output files from S3 after completion. ^[2] This changes both the cost calculation and the product decision: you are pricing a dataset run rather than a single synchronous request.

The 50% figure applies to the model's eligible inference price. It does not mean that every request is half the price of every other Bedrock path. A region-specific on-demand price, cross-Region inference profile, model-specific input/output meter, or another capacity option can change the comparison baseline. Start with one exact model ID and one Region. Record the price basis as “per 1 million input tokens” and “per 1 million output tokens.” Do not combine a rate from one Region with a workload running under a different profile.

The model list is also a moving dependency. AWS's supported page reports single-Region, cross-Region profile, and custom-model support separately. A model being available in Bedrock does not by itself prove that it is eligible for batch in your selected Region. ^[3] Treat the support table as a gate in your estimate, not as a footnote after the arithmetic.

What is outside the token estimate?

A defensible budget should show the token estimate and a separate exclusions list. At minimum, review these items:

• S3: input and output storage, request charges, lifecycle policy, and any transfer or replication pattern.
• Job control: Lambda, Step Functions, EventBridge, DynamoDB, or another scheduler if you queue jobs or reconcile status.
• Observability: logs, metrics, alerts, and retained payloads. Payload logging can have both a cost and a data-governance impact.
• Retries and invalid records: a failed or repeated record may consume more tokens than the first-pass estimate.
• Other Bedrock features: guardrails, knowledge retrieval, agents, embeddings, or evaluation calls may have their own meters.
• Engineering and review: validation, schema checks, manual review, and downstream storage are operating costs even when the model line is discounted.

The result is a cost range, not a promise that the AWS invoice will equal the token calculation. The token line answers “what would eligible inference cost under these volumes and rates?” The full workload estimate answers “what will this pipeline cost to operate?” Keep those answers separate.

When the discount is actually usable

1. The model and Region pass the eligibility test

Open the supported-model page for the exact model ID and check the column that matches your deployment: single Region, cross-Region inference profile, or custom model. ^[3] Then open the AWS pricing table for the same model and pricing basis. Save the checked date because model catalogs and prices change.

Do not use a generic “Claude,” “Llama,” or “Nova” label in a finance worksheet. Use the deployed model ID, source Region, input rate, output rate, and whether the job uses a cross-Region profile. This prevents a common error: applying a remembered 50% rule to a model or profile that is not eligible for batch.

2. The deadline is compatible with best-effort processing

AWS characterizes batch as suitable for large-scale, non-time-sensitive processing. Its capacity guidance says on-demand requests are prioritized over batch, completion is best effort, and a job has a 24-hour default timeout that can be configured up to 168 hours. ^[5] That is a scheduling constraint, not just a latency detail.

Batch fits overnight summaries, offline classification, embeddings, evaluation sets, document enrichment, and other work that can tolerate a completion window. It does not fit a checkout response, an interactive agent turn, or a page that must return a result in a few seconds. Model-token savings can be economically irrelevant if a missed deadline triggers a fallback call, a delayed human workflow, or a duplicate run.

Write the deadline as a measurable requirement: for example, “95% of nightly jobs available by 06:00 UTC,” not “fast enough.” If you need that kind of service-level objective, test queue delay and job duration with representative records. The 50% rate does not create a completion-time guarantee.

3. The request shape is supported

Batch requires an S3-based dataset and the associated permissions. AWS lists preparing the dataset, creating an output bucket, and setting IAM permissions as prerequisites. ^[4] The practical cost question is whether your existing records can be converted to the required JSON Lines structure without a large preprocessing or validation system.

Tool use needs special care. AWS says Converse-format batch records that include toolConfig fail with a 400 error. It also says tool calling can be used with batch when the job uses the InvokeModel invocation type and each modelInput follows the model's native request format. ^[2] So “batch cannot do tools” is too broad, while “batch supports my agent loop” is too strong. Test the exact API shape, model schema, tool result handling, and retry behavior.

Provisioned models are another hard boundary: AWS's batch guide says batch inference is not supported for provisioned models. ^[2] If your capacity or latency design depends on provisioned throughput, compare that path directly rather than applying the batch percentage.

4. The pipeline cost is visible

AWS's reference pipeline describes S3 input and output, status tracking, a scheduled poller, and a queue that submits jobs as capacity is available. ^[6] You may not need that exact architecture, but it shows why a token-only comparison can be incomplete. A recurring workload has scheduling, state, error handling, and reconciliation work.

For a one-off small dataset, a simple job and a short-lived script may be enough. For a daily feed, budget the control plane and decide who owns failed records. If the pipeline submits a job again after an ambiguous timeout, your effective cost can exceed the neat 50% arithmetic. Track a record ID, attempt number, model ID, input and output token counts, and final status so the batch estimate can be reconciled to the bill.

Worked cost example

Assume a support team processes 10,000 conversations every night. Each record averages 2,000 input tokens and 200 output tokens. The model and Region have been verified as batch-supported, but the rates below are deliberately scenario assumptions, not a vendor quote for a named model. Assume standard on-demand pricing of $3.00 per million input tokens and $15.00 per million output tokens. The illustration isolates model-token cost.

At 30 identical runs, the token-only estimate is $2,700 per month on the assumed on-demand basis versus $1,350 for batch. The modeled saving is $1,350 per month, or 50% of the eligible token line. It is not a forecast of the invoice. Add S3, orchestration, logs, retries, validation, and any downstream processing before calling it a monthly pipeline budget.

The example also shows why input and output must be separate. If output tokens are much more expensive than input tokens, a small change in output length can dominate the total. If a summarizer starts returning 400 tokens instead of 200, the batch output line doubles from $15 to $30 under these assumptions. A volume-only calculator that ignores output tokens will understate the change.

A repeatable Bedrock batch-versus-on-demand method

1. Freeze the workload definition. Record records per run, average and p95 input tokens, average and p95 output tokens, schedule, deadline, and expected retry rate. Use measured token counts when available; label estimates when they are not.
2. Freeze the price basis. Record model ID, source Region, inference profile, currency, date checked, and separate input/output rates. Use AWS's pricing page as the vendor reference. ^[1]
3. Check support before multiplying. Verify the exact model and Region on the batch support page. ^[3] A missing eligibility check invalidates the discount scenario.
4. Calculate eligible token cost. Multiply millions of input tokens by the input rate and millions of output tokens by the output rate. Apply the 50% batch factor only after support is confirmed.
5. Add non-token lines. Include S3, job control, monitoring, retries, and downstream work. Keep them visible rather than hiding them in a guessed percentage.
6. Test the failure path. Validate malformed JSONL, empty output, throttling, job timeout, partial records, and safe resubmission. Cost per successful record is more useful than cost per submitted record.
7. Compare the deadline-adjusted option. If batch misses the requirement and invokes on-demand fallback, compare the blended cost: successful batch tokens plus fallback tokens plus pipeline overhead. The nominal discount may disappear.

For a broader model comparison, link this estimate to the Model pricing comparison. If the workload includes retrieval, compare its embedding, vector, and generation layers with the RAG, embedding and vector database cost calculator. For a tool-using product, the AI agent development cost estimator can keep implementation and operating work visible. If the alternative is self-hosting, the Self-hosted GPU inference cost calculator can provide a separate infrastructure baseline rather than pretending AWS batch and a GPU reservation have the same cost structure.

Common decision mistakes

Applying 50% to every Bedrock request. The discount is for select foundation models and must be checked against the model and Region. It is not a universal account-level coupon. ^{[1] [3]}

Treating batch as a throughput or SLA upgrade. Batch lowers an eligible token rate but runs behind on-demand capacity and is best effort. Keep an on-demand or other fallback path if the business deadline is strict. ^[5]

Comparing a batch token estimate with a fully loaded on-demand system. If the on-demand number includes monitoring and the batch number does not, the comparison is biased. Put equivalent scope on both sides.

Assuming agent compatibility from a successful text test. A plain text JSONL test does not prove Converse tool configuration, native InvokeModel payloads, multi-turn state, or retries are correct. Test the production request shape.

Using a third-party table as the final quote. Third-party pages are useful for discovering scenarios and arithmetic patterns, but a dated AWS model/Region price check should control the budget. Keep a source URL and checked date in the worksheet.

FAQ

Is Amazon Bedrock batch inference always 50% cheaper?

No. AWS describes 50% lower pricing for select foundation models compared with on-demand inference. Confirm the exact model, Region, and pricing basis first. If the model is not batch-supported, the 50% calculation is not applicable. ^{[1] [3]}

Does Bedrock batch inference support tool calling?

It depends on the invocation format. AWS says Converse batch records containing toolConfig fail with a 400 error. Tool calling can be used with the InvokeModel invocation type when each input uses the model's native request format. Test the actual model payload rather than relying on a broad yes or no. ^[2]

How long does a Bedrock batch job take?

There is no single guaranteed duration in the pricing rule. AWS says on-demand requests are prioritized, batch completion is best effort, and the default job timeout is 24 hours, configurable up to 168 hours. Treat your own measured queue delay and run time as workload data. ^[5]

What does the Bedrock batch cost calculator need as inputs?

At minimum, it needs input tokens per run, output tokens per run, runs per month, the exact input and output rates, model ID, Region, and the batch-support result. A useful version also asks for retry rate, S3 and orchestration costs, and fallback volume. Keep the 50% factor as a conditional output, not a fixed assumption.

Can I use batch inference with a provisioned model?

No. AWS's batch guide states that batch inference is not supported for provisioned models. Compare provisioned throughput and batch as different deployment choices with different capacity and billing models. ^[2]

Is S3 included in the 50% discount?

The 50% statement concerns eligible model inference pricing. S3 storage and requests, plus pipeline services used to create and monitor jobs, should be modeled separately. AWS lists S3 input/output preparation and IAM setup as batch prerequisites. ^[4]

What is the best workload for Bedrock batch pricing?

A good candidate has independent records, a known deadline measured in hours rather than seconds, verified model and Region support, and a repeatable S3-based workflow. Examples include offline classification, embeddings, evaluation, enrichment, and overnight summarization. A user-facing agent turn is usually a poor candidate because queue delay and best-effort completion can outweigh the token discount.