A claims file lands in an S3 bucket as a scanned PDF. Next to it sits a phone photo of a damaged bumper, a two minute voicemail, and a dashcam clip. Four modalities, one case, and until recently four separate pipelines to stand up before any of it became a row in a database.

Amazon Bedrock Data Automation, which I will call BDA from here, is the managed service that collapses those four pipelines into one API call. This part covers what it extracts, how a job runs, what it costs, and where I would not use it.

What Bedrock Data Automation actually does

BDA is a Bedrock feature that reads unstructured content and writes back structured results you can query. A blueprint is a schema: a named list of fields you want pulled out, plus natural language instructions for each. A project is the container that holds your output settings for each modality and any blueprints attached to it. You point a job at a project, and the project decides what comes back.

There are two output shapes. Standard output is the predefined set of insights for a modality: page text and markdown for documents, chapter summaries and a full transcript for video, a transcript with speaker labels for audio, captions and detected logos for images. You get it with almost no configuration. Custom output runs a blueprint so the JSON contains only the fields you asked for, each with a confidence score and an explainability record that tells you where on the page the value came from.

That confidence and explainability payload is the part people underuse. On the driver license sample in the AWS walkthrough, the extracted expiration date carries a confidence near 0.93 and the issue date near 0.79. Those numbers are your routing signal. Anything under a threshold you set goes to a human queue instead of straight into the system of record.

How a job runs end to end

Everything runs through one runtime operation, InvokeDataAutomationAsync, on the bedrock-data-automation-runtime client. You pass an input S3 location, an output S3 location, the project ARN, and one parameter people miss on their first try: dataAutomationProfileArn. Since general availability that profile ARN is required, and it encodes the cross region inference profile, for example us.data-automation-v1. Leave it out and the call fails validation.

To get plain standard output without building anything, point the project ARN at the public default project: arn:aws:bedrock:REGION:aws:data-automation-project/public-default. The call returns an invocationArn. From there you either poll GetDataAutomationStatus in a loop or, better in production, subscribe to the EventBridge notification and skip the polling entirely. When the status leaves Created and InProgress, the result JSON is sitting in your output bucket.

import boto3, time

REGION = 'us-east-1'
ACCOUNT = boto3.client('sts').get_caller_identity()['Account']
bda = boto3.client('bedrock-data-automation-runtime', region_name=REGION)

resp = bda.invoke_data_automation_async(
    inputConfiguration={'s3Uri': 's3://my-bucket/in/claim.pdf'},
    outputConfiguration={'s3Uri': 's3://my-bucket/out/'},
    dataAutomationConfiguration={
        'dataAutomationProjectArn':
            f'arn:aws:bedrock:{REGION}:aws:data-automation-project/public-default'
    },
    dataAutomationProfileArn=(
        f'arn:aws:bedrock:{REGION}:{ACCOUNT}:'
        'data-automation-profile/us.data-automation-v1'
    ),
)

arn = resp['invocationArn']
while True:
    status = bda.get_data_automation_status(invocationArn=arn)['status']
    if status not in ('Created', 'InProgress'):
        break
    time.sleep(2)
print(status)  # Success

Expected output: Success, then a job metadata JSON under s3://my-bucket/out/. Failure mode: drop dataAutomationProfileArn and the SDK raises a ValidationException before any work starts.

Standard output or a custom blueprint?

Reach for standard output when you want the content itself: the full text of a contract, a transcript of a call, a summary of a video. Reach for a blueprint when you want specific fields in a fixed shape: policy number, claim amount, incident date. The split is content versus fields, and it decides your cost as much as your code.

Here is what each modality supports today.

A single project can carry standard settings for every modality plus up to 40 document blueprints, so one project can route a mixed folder.

What does it cost?

Pricing is per unit of content, not per token, which makes it easy to forecast once you know your volumes. Documents bill per page, video and audio per minute, images per image. The custom path costs more than standard because a blueprint runs extra extraction.

Figures from the Amazon Bedrock pricing page. Confirm current numbers and your Region before you commit, since BDA prices have moved as Regions were added.

Blueprints and instruction optimization

A blueprint is where the accuracy work lives. You start from a sample blueprint, for example a driver license or an invoice, duplicate it because samples are read only, and then edit the fields. Each field has a name, a type, and an instruction in plain language such as the total amount due including tax. BDA uses that instruction to find and, where needed, compute the value. A project holds up to 40 document blueprints, and BDA matches the incoming document to the right one and reports which blueprint matched with a confidence score.

The newer lever is blueprint instruction optimization. You give BDA a handful of example documents with the correct answers labeled, and it rewrites the natural language instructions to raise extraction accuracy, no model training involved. It is the difference between hand tuning prompts for a week and handing over ten labeled samples. If your extraction accuracy is stuck in the low nineties, this is the first thing to try before you reach for a fine tuned model. For the training path instead, see Part 16.

Wiring BDA into a Knowledge Base

BDA is not only a standalone service. It can act as the parser for a Bedrock Knowledge Base, which is the managed RAG path we covered in Part 12. Instead of the default text extractor, BDA reads your PDFs, slides and images, produces clean structured text with layout preserved, and that becomes the material your Knowledge Base chunks and embeds. Scanned documents and slide decks that used to come through as garbage now index cleanly.

This is the connection back to grounding quality. Retrieval is only as good as the text you fed it, which is the whole argument of Part 20 on data prep. If you have been fighting bad answers from a Knowledge Base built on complex documents, swapping in BDA as the parser is often the single highest return change you can make. For the vendor neutral view of why grounding beats model size, the GenAI Series makes the general case.

Throughput, quotas, and where jobs stall

BDA is asynchronous by design, and that shapes how you scale it. Each account has a concurrency limit on in flight jobs and a request rate on the runtime API, both raiseable through a Service Quotas increase. A single call handles one input asset, so a batch of ten thousand documents is ten thousand invocations that you fan out and throttle rather than loop over tightly. A multi page PDF counts as one asset but bills per page, so a 60 page report is one job and 60 pages of standard output. Very large PDFs are worth splitting so a single slow file does not hold up a whole chapter of your pipeline, and because BDA processes each asset independently, one corrupt file fails only its own job and leaves the rest of the batch untouched.

The most common stall I see is not the model, it is permissions. The role that calls InvokeDataAutomationAsync needs read on the input bucket, write on the output bucket, and if either bucket uses a customer managed KMS key, decrypt and generate data key on that key. Miss the KMS grant and the job does not throw at call time. It runs, then lands in a failed status with a service error buried in the job metadata, which sends people hunting in the wrong place. Read the status payload first. The second stall is Region drift: the profile ARN Region, the client Region, and the bucket Region should line up, or you pay cross Region transfer and sometimes hit an access error. Wire an EventBridge rule to a dead letter path so failed jobs page you instead of vanishing into an output prefix nobody checks.

Start with standard output, add blueprints only where fields matter

Here is the recommendation. Stand up standard output against the public default project first, on a real sample of your files, and read the JSON. For most content extraction and for feeding a Knowledge Base, standard is all you need, and it is the cheapest path at 0.010 per document page. Add a custom blueprint only for the subset of documents where you need named fields in a fixed schema, and use instruction optimization before you assume you need anything heavier.

When would I not use BDA? If your volume is a few files a day, a direct multimodal model call is simpler and you skip the S3 round trip. And if you have a hard residency requirement outside the supported Regions, check the current list before you build. Validate three things on a pilot: extraction accuracy on your worst documents, the confidence threshold that cleanly splits auto from review, and the real per month cost at your projected volume.

Pull a hundred of your messiest real documents and run them through standard output this week. The JSON will tell you fast whether you need blueprints at all.

On dense, inconsistent documents like scanned invoices or claim forms, standard output gets you a usable structured result faster than most people expect, and the place it falls down is not accuracy on clean fields but the confidence threshold where auto-approve starts hiding errors.

References

• AWS News Blog: BDA generally available
• Amazon Bedrock Data Automation User Guide
• InvokeDataAutomationAsync API reference
• Amazon Bedrock pricing

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts