FREE TOOL

Bedrock Batch Inference Validator

Check an Amazon Bedrock batch inference JSONL file before the job runs: every record's modelInput against the body the model takes, the record counts and sizes against the quotas, the S3 layout and the job's settings.

  • Your data never leaves your browser: everything is calculated by JavaScript on this page, not on a server.
  • Nothing you enter is uploaded, processed on a server or stored. Check it in your browser's developer tools (Network tab).
  • Once the page has loaded, the tool works without an internet connection.

Model

The Region the job runs in and the model it calls - only the models AWS lists for batch inference there.

Records

Paste JSONL records, or choose the .jsonl files of the job - they are read in your browser, line by line. An output file (.jsonl.out) or a job's failure message works too.

Job

Where the records are and where the results go. The input is a folder or one .jsonl file; every .jsonl file in a folder is part of the job.

See the check ↓
Calling AWS APIs, S3 permissions and service roles are core AWS Developer Associate topicsTry free DVA-C02 practice questions with answers and explanations.DVA-C02 questions →

The batch inference JSONL format

A batch inference job reads JSONL files: one JSON object per line, each with a recordId and a modelInput. With the InvokeModel invocation type - the default - the modelInput is the body you would send to InvokeModel for the job's model, as an object rather than a string. With the Converse type (modelInvocationType), it is a Converse request without the modelId, the same for every model.

{"recordId": "CALL0000001", "modelInput": {"anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [{"role": "user", "content": [{"type": "text", "text": "Summarize ..."}]}]}}
{"recordId": "CALL0000002", "modelInput": {"anthropic_version": "bedrock-2023-05-31", "max_tokens": 1024, "messages": [{"role": "user", "content": [{"type": "text", "text": "Summarize ..."}]}]}}
  • AWS's documentation prints each record over several lines to be read; in the file, each record is one line.
  • The recordId is optional - Bedrock adds one in the output - but the output's order is not guaranteed to be the input's, so an ID of your own is how you match each answer to its record.
  • Batch inference does not support tool calling or structured output (response_format): each record is answered once.
  • When a job is validated, Bedrock checks that the files are .jsonl and each line is a JSON object with the right fields - not that the modelInput matches the model. A body in another model's format passes validation and then fails record by record, with the error in the output file. That is the check this tool adds; the InvokeModel body generator writes the body each model takes.

S3 layout: input, output and objects the records point to

The job's input location is a folder or a single .jsonl file; Bedrock processes every .jsonl file in a folder, and the record quotas count across all of them. Records may point to S3 objects instead of carrying them - a video for Amazon Nova, for example. Then every object must be in the same bucket and folder as the input, and the input has to be that folder, not the .jsonl file. S3 paths are case-sensitive.

The API takes S3 URIs whose keys use letters, digits and -!_*'(). only, so a Hive-style prefix such as date=2026-10-02/ is refused. The output location is a folder: Bedrock creates a folder named after the job ID in it, with a .jsonl.out file for each input file - the record, and its modelOutput or an error - and a manifest.json.out with the record and token counts.

The job's service role needs s3:GetObject, s3:PutObject and s3:ListBucket on both buckets, and with an inference profile bedrock:InvokeModel on the profile and the model in every Region it routes to. A bucket in another account needs a bucket policy for the role, and the job has to be created through the API.

Batch inference quotas

Each model has its own batch quotas per Region. By default a job needs at least 100 records and takes up to 100,000 per file and per job, files of up to 1 GB and 5 GB in all - 100 GB for Amazon Nova Lite and Pro - and each account can have 100 jobs per model submitted or in progress. The record counts can be raised in Service Quotas, the sizes cannot. The panel above shows the selected model's values, read from AWS's quota table; the tool counts sizes in GB of 109 bytes.

Frequently asked questions

Which models support batch inference, and in which Regions?

The model list above follows AWS's table of batch inference support: some models take batch jobs with their own model ID in a Region, others only through a cross-Region inference profile - the chips under the model show which. Batch inference is not available for Provisioned Throughput.

What does batch inference cost?

Batch is priced per token like on-demand inference, at about half the Standard price for most models in the Price List. The Bedrock pricing calculator compares them with every other way to run the same workload.

Is what I paste or choose sent anywhere?

No. Pasted records and chosen files are read in your browser. The page only counts that it was used, with what the check found, never the records.

References

Format and upload your batch inference data (Amazon Bedrock User Guide)
Supported Regions and models for batch inference (Amazon Bedrock User Guide)
View the results of a batch inference job (Amazon Bedrock User Guide)
Create a custom service role for batch inference (Amazon Bedrock User Guide)
CreateModelInvocationJob (Amazon Bedrock API Reference)
Amazon Bedrock endpoints and quotas (AWS General Reference)