What Is Amazon Bedrock Data Automation? Pricing per Page, Blueprints, boto3 Code, Sync vs Async, and BDA vs Textract

Amazon Bedrock Data Automation (BDA) is a managed service that turns documents, images, audio and video into structured data with generative AI, without you choosing or prompting a model. It has two kinds of output: standard output (text, Markdown, tables, summaries, transcripts, chapter breakdowns) and custom output, where a blueprint (your list of fields, such as invoice number, supplier, total, line items) defines exactly what gets extracted. Pricing is per unit: documents cost $0.010 per page for standard output and $0.040 per page for custom output with up to 30 fields ($0.0005 for each extra field); custom output on images is $0.005 per image; standard audio is $0.006 per minute and standard video $0.050 per minute. In boto3 you configure a project with bedrock-data-automation, then run files through bedrock-data-automation-runtime: invoke_data_automation_async() for S3 files (results land in S3), or invoke_data_automation() for a quick synchronous call. Below: what BDA does, how it compares with Textract and calling a model yourself, worked cost examples, complete boto3 code, blueprints, knowledge base parsing, IAM and the errors you will meet.

The shop's accounts team typed supplier invoices into the bookkeeping system by hand: forty a week, each in a different layout. Jake tried plain OCR first and got the words, but not which number was the total and which was the VAT. Ethan set up a BDA project with an invoice blueprint, and the output became the same JSON for every supplier, whatever the layout.

New to Bedrock? The cards below cover Bedrock itself, knowledge bases, pricing, the API endpoints and a free OCR alternative.

What is Bedrock Data Automation?

What is Bedrock Data Automation, in one sentence? It is "send a file, get back clean data", where AWS chooses and runs the AI models in between. You do not write prompts or pick a model; you choose what output you want, and BDA handles splitting multi-document files, reading layouts, transcribing speech and filling in your fields.

How it works, end to end:

1. Create a project: the settings for one kind of job (what standard output to produce, which blueprints to apply).
2. Put your file in S3 (or pass the bytes for a small synchronous call).
3. Invoke the project on the file, naming a data automation profile (which also decides the Regions BDA may process in).
4. BDA detects the type (document, image, audio or video), splits it into logical parts (three invoices in one PDF become three results), and matches each part to a blueprint where one fits.
5. Results land in S3 as JSON (and optionally Markdown, HTML or CSV), and an EventBridge event can tell your code it is done.

Where it fits: invoices and receipts into accounting, ID documents and forms into onboarding, product photos into catalog fields, call recordings into summaries and topics, and training or marketing videos into chapters and searchable transcripts. Our plain-English Bedrock guide places it among Bedrock's other building blocks.

Jake: "So I don't pick a model at all?"

Ethan: "No. You pick the fields. BDA decides how to get them, and it charges you per page instead of per token."

Intelligent document processing on AWS: where BDA fits

"Intelligent document processing" (IDP) is the industry name for what the accounts team wanted: documents come in, the right values come out, and a person only looks at the doubtful ones. On AWS, IDP is a pipeline of steps rather than one product, and Bedrock Data Automation now covers several of those steps in a single call. Knowing the steps shows you what BDA replaces and what you still build yourself.

People also search "what is AWS IDP" as if it were a service you switch on. There is no single product by that name: AWS uses "IDP" for the pattern above, for its guidance on building it, and for an open-source accelerator you can deploy (covered in the GitHub section below).

Before BDA, a typical invoice pipeline chained four or five services with glue code between each one, plus a set of rules for every supplier layout. With BDA, classify, extract and normalize collapse into one call and one per-page price. What stays yours is the trigger that starts each job, the business rules (does this supplier exist in your system, does the total match the purchase order), the review screen for doubtful values, and the code that writes the results where they belong. That split is worth knowing before you estimate a project: the BDA part is usually a day of work, and the rules and review flow take the rest of the week.

Jake: "So IDP isn't a product I can buy?"

Ethan: "It's the job. BDA is the biggest single piece of it; the S3 inbox, the checks and the review screen are still ours."

Standard output vs custom output

Choose standard output when you need the content (for search, RAG or a human to read); choose custom output when a program needs specific values in a fixed shape. One project can produce both, and a document that matches no blueprint still gets its standard output.

Images, audio and video: what BDA does with them

Most searches about BDA are about documents, but the same project can take images, audio and video, and each type has its own standard output settings. A project holds one standard output configuration per data type, so the invoice project can also say what to do when someone drops a photo or a voicemail into the inbox. Blueprints work for these types too, so you can ask for your own fields from a photo or a call.

• Images: a description of the image, the text found in it, logo detection and content moderation results. Typical uses are product photos into catalog fields (color, category, visible defects), photos of damaged deliveries into a claim, and screenshots into searchable text. Custom output costs $0.005 per image.
• Audio: a transcript with speaker labels, a summary and the topics discussed. Typical uses are call recordings, voicemails and meeting recordings. Standard output costs $0.006 per minute, and a blueprint can answer questions such as "did the customer ask for a refund?" or "what follow-up did the agent promise?"
• Video: a full summary, chapters with their own summaries, the transcript and the text that appears on screen. Typical uses are training libraries, webinars and marketing videos you want people to search. Standard output costs $0.050 per minute.

Some quick media costs for planning: 500 product photos through a small blueprint come to 500 × $0.005 = $2.50; an hour-long webinar is 60 × $0.050 = $3.00; a month of voicemail at 300 minutes is 300 × $0.006 = $1.80. Media jobs run on the asynchronous API, and long videos take a while, so the EventBridge pipeline further down matters more here than it does for one-page receipts. Check the current file format and size limits for each type before you send a large batch, and convert odd formats first so a whole run does not fail on the first unusual file.

Jake: "Delivery drivers send us photos of damaged boxes. Can it fill in the claim form?"

Ethan: "A small image blueprint: damage type, which side of the box, is the label readable. Half a cent a photo."

Bedrock Data Automation pricing, with worked examples

BDA is priced per page, image or minute, by output type. The rates you will use most:

Worked examples for your own planning:

• The shop's invoices: 40 a week, two pages each, custom output with a 20-field blueprint. About 350 pages a month × $0.040 = $14 a month, against several hours of typing.
• A document archive for search: 100,000 pages, standard output only: 100,000 × $0.010 = $1,000, once.
• A big blueprint: 1,000 pages with a 40-field blueprint: 1,000 × ($0.040 + 10 × $0.0005) = $45.
• Support calls: 2,000 minutes a month of recordings, standard output: 2,000 × $0.006 = $12 a month.
• Training videos: 50 hours (3,000 minutes), standard output: 3,000 × $0.050 = $150.

Two cost habits that matter: send only the pages you need (a 40-page contract where you want page one costs 40 pages), and keep blueprints under 30 fields when you can. Storage for inputs and outputs in S3 is billed separately at normal S3 rates. Our Bedrock pricing guide compares this with paying per token.

BDA vs Textract vs calling a model yourself

"Bedrock Data Automation vs Textract" is the comparison people search for most, and the third option, sending the file to a model with the Converse API, belongs in it too:

• Amazon Textract: classic document OCR. It returns text, forms (key-value pairs), tables, and specialized results for receipts, invoices and IDs, all with exact positions. It is deterministic and cheap at very high volumes for plain text detection. It does not normalize values ("Total due" vs "Amount payable" stay as written), and it does not do audio or video.
• Bedrock Data Automation: generative AI on top of OCR. It understands the document, splits and classifies multi-document files, fills your schema with normalized, typed values, and handles images, audio and video in the same service. You pay per page, not per token, and do not maintain prompts.
• A model through Converse: you attach the PDF as a document block and ask for JSON. Most flexible, priced per token, but prompts, schema validation, page splitting and retries are your job.
• Local OCR: when documents must never leave your machines, free open models can do the text step on a PC; our Indra OCR guide compares one with Textract.

A sensible rule: raw text at volume, Textract; "the same fields from many layouts", BDA; a one-off or unusual task, a model call; strict on-premises rules, local OCR.

Bedrock Data Automation alternatives

If you are weighing BDA against everything else, here is the wider field in one table, including options outside AWS:

Three questions settle most choices. First, where does your data have to stay? If the answer is "on our own machines", the cloud services drop out and a local OCR model plus your own rules is the route. Second, how many layouts do you face? One or two fixed forms suit Textract with a few rules; dozens of supplier layouts that keep changing are where BDA's blueprints save the most time. Third, do you need audio or video in the same flow? Only BDA (and some models through Converse) handle those next to documents.

If you already run a Textract pipeline that works, switching is a cost question more than a technology one. Add up the hours your team spends each month adding rules for new layouts and fixing broken ones, and compare that with the difference in per-page price. For a stable set of forms, Textract usually stays cheaper; for a mixed, changing inbox, BDA usually wins once those hours are counted.

Jake: "We nearly built per-supplier rules on top of Textract."

Ethan: "Forty suppliers, forty rule sets, and a new one every month. The blueprint is one page of descriptions."

Bedrock Data Automation in boto3: project, invoke, status, results

Two clients do the work: bedrock-data-automation for setup (projects and blueprints) and bedrock-data-automation-runtime for processing files. Our Bedrock endpoints guide explains why Bedrock has several clients.

Step 1: create a project (once). This one asks for Markdown text per page and lets blueprints run:

import boto3

bda = boto3.client("bedrock-data-automation", region_name="us-east-1")

project = bda.create_data_automation_project(
    projectName="supplier-invoices",
    projectStage="LIVE",
    standardOutputConfiguration={"document": {
        "extraction": {"granularity": {"types": ["PAGE", "ELEMENT"]},
                       "boundingBox": {"state": "DISABLED"}},
        "generativeField": {"state": "ENABLED"},
        "outputFormat": {"textFormat": {"types": ["MARKDOWN"]},
                         "additionalFileFormat": {"state": "DISABLED"}},
    }},
    customOutputConfiguration={"blueprints": [
        {"blueprintArn": "arn:aws:bedrock:us-east-1:111122223333:blueprint/invoice-shop-v1", "blueprintStage": "LIVE"},
    ]},
)
PROJECT_ARN = project["projectArn"]

Step 2: process a file in S3 and wait for it:

import time

runtime = boto3.client("bedrock-data-automation-runtime", region_name="us-east-1")
PROFILE_ARN = "arn:aws:bedrock:us-east-1:111122223333:data-automation-profile/us.data-automation-v1"

job = runtime.invoke_data_automation_async(
    inputConfiguration={"s3Uri": "s3://shop-invoices-in/2026/10/acme-0193.pdf"},
    outputConfiguration={"s3Uri": "s3://shop-invoices-out/2026/10/"},
    dataAutomationConfiguration={"dataAutomationProjectArn": PROJECT_ARN, "stage": "LIVE"},
    dataAutomationProfileArn=PROFILE_ARN,
    notificationConfiguration={"eventBridgeConfiguration": {"eventBridgeEnabled": True}},
)

while True:
    status = runtime.get_data_automation_status(invocationArn=job["invocationArn"])
    if status["status"] not in ("Created", "InProgress"):
        break
    time.sleep(5)

if status["status"] == "Success":
    print("Results:", status["outputConfiguration"]["s3Uri"])
else:
    print(status["status"], status.get("errorType"), status.get("errorMessage"))

Step 3: read the results. The S3 location in the status points to the job's metadata file, which lists where each segment's standard output and custom output JSON were written. Read it, then read the result files it names:

import json
from urllib.parse import urlparse

s3 = boto3.client("s3")
def read_json(uri):
    u = urlparse(uri)
    return json.loads(s3.get_object(Bucket=u.netloc, Key=u.path.lstrip("/"))["Body"].read())

metadata = read_json(status["outputConfiguration"]["s3Uri"])
print(json.JSONEncoder(indent=2).encode(metadata))      # shows the result file paths for each segment

In production, skip the polling loop: with EventBridge notifications on, an EventBridge rule can start a Lambda function when each job finishes, and that function reads the results and writes them to your database. Our EventBridge explainer covers rules, and if you trigger jobs from S3 uploads, our S3 trigger guide helps when the first step does not fire.

Jake: "Every supplier's PDF came back with the same keys. Even the one that calls the total 'Balance payable'."

Ethan: "That's the blueprint doing its job. The accounting import doesn't care about layouts any more."

A production pipeline: S3 inbox to database, no polling

The polling loop in step 2 is fine for a script on your laptop, but in Lambda it bills you for every second the function sits waiting. The production version splits the work into two small functions joined by EventBridge:

1. A file lands in the inbox bucket. An S3 event notification starts the first Lambda function.
2. The first function starts the BDA job with EventBridge notifications switched on, and records the job in a DynamoDB table keyed by the input file.
3. BDA finishes and sends an event to the default EventBridge bus: Bedrock Data Automation Job Succeeded, or one of the two failure events.
4. An EventBridge rule starts the second function, which looks up the job, reads the results from S3 and writes them where they belong, or marks the job as failed.

The starter function (triggered by S3). The conditional write stops a duplicate S3 event from starting the same job twice:

import os
import urllib.parse
import boto3
from botocore.exceptions import ClientError

runtime = boto3.client("bedrock-data-automation-runtime")
jobs = boto3.resource("dynamodb").Table(os.environ["JOBS_TABLE"])

def handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])
        input_uri = f"s3://{bucket}/{key}"
        try:
            jobs.put_item(Item={"input_uri": input_uri, "state": "STARTING"},
                          ConditionExpression="attribute_not_exists(input_uri)")
        except ClientError as e:
            if e.response["Error"]["Code"] == "ConditionalCheckFailedException":
                continue                      # this file already has a job
            raise
        job = runtime.invoke_data_automation_async(
            inputConfiguration={"s3Uri": input_uri},
            outputConfiguration={"s3Uri": f"s3://{os.environ['OUT_BUCKET']}/results/"},
            dataAutomationConfiguration={"dataAutomationProjectArn": os.environ["PROJECT_ARN"], "stage": "LIVE"},
            dataAutomationProfileArn=os.environ["PROFILE_ARN"],
            notificationConfiguration={"eventBridgeConfiguration": {"eventBridgeEnabled": True}},
        )
        jobs.update_item(Key={"input_uri": input_uri},
                         UpdateExpression="SET #s = :s, invocation_arn = :a",
                         ExpressionAttributeNames={"#s": "state"},
                         ExpressionAttributeValues={":s": "RUNNING", ":a": job["invocationArn"]})

The EventBridge rule. BDA events come from the source aws.bedrock; this pattern catches the success event and both failure events:

{
  "source": ["aws.bedrock"],
  "detail-type": [
    "Bedrock Data Automation Job Succeeded",
    "Bedrock Data Automation Job Failed With Client Error",
    "Bedrock Data Automation Job Failed With Service Error"
  ]
}

The event's detail carries the job ID, the status, the modality and both S3 locations, shaped like this:

"detail": {
  "job_id": "25010344-03f7-4167-803a-837afdc7ce98",
  "job_status": "SUCCESS",
  "semantic_modality": "Document",
  "input_s3_object": {"s3_bucket": "shop-invoices-in", "name": "2026/10/acme-0193.pdf"},
  "output_s3_location": {"s3_bucket": "shop-invoices-out", "name": "results/..."},
  "error_message": ""
}

The finisher function (the rule's target). It finds the job by its input file, then reads the status for the results location:

import os
import boto3

runtime = boto3.client("bedrock-data-automation-runtime")
jobs = boto3.resource("dynamodb").Table(os.environ["JOBS_TABLE"])

def set_state(input_uri, state, extra_name, extra_value):
    jobs.update_item(Key={"input_uri": input_uri},
                     UpdateExpression=f"SET #s = :s, {extra_name} = :x",
                     ExpressionAttributeNames={"#s": "state"},
                     ExpressionAttributeValues={":s": state, ":x": extra_value})

def handler(event, context):
    detail = event["detail"]
    src = detail["input_s3_object"]
    input_uri = f"s3://{src['s3_bucket']}/{src['name']}"
    item = jobs.get_item(Key={"input_uri": input_uri}).get("Item")
    if item is None:
        print("No job record for", input_uri)          # started outside this pipeline
        return
    if "invocation_arn" not in item:
        raise RuntimeError("job record not ready yet")  # Lambda retries the event
    if event["detail-type"] != "Bedrock Data Automation Job Succeeded":
        set_state(input_uri, "FAILED", "error_message", detail.get("error_message", ""))
        return
    status = runtime.get_data_automation_status(invocationArn=item["invocation_arn"])
    metadata_uri = status["outputConfiguration"]["s3Uri"]
    # read the metadata and the result files it lists (step 3 above),
    # then write the fields to your database or accounting system here
    set_state(input_uri, "DONE", "results", metadata_uri)

Why the DynamoDB table? The event names the input and output files, but its resources list is empty, so the table is what links an event back to your job. It also gives you a free dashboard: every file in the inbox, with its state of STARTING, RUNNING, DONE or FAILED.

Three production details to add before real traffic:

• A sweeper for lost events. EventBridge delivery for these events is best effort, so a scheduled function every 30 minutes should find items still RUNNING after an hour and call get_data_automation_status on them.
• Re-uploads of the same file name. The conditional write skips a file whose key already exists in the table; add the upload date or a version to the key, or delete the item once the results are stored, if suppliers resend files under the same name.
• Permissions per function. The starter needs the invoke permission, S3 access as in the IAM section below, and DynamoDB put and update; the finisher needs bedrock:GetDataAutomationStatus, read access to the output bucket, and DynamoDB get and update.

For bursts (a scanner that drops 500 files at 9 a.m.), put an SQS queue between the S3 notification and the starter function, and set the function's concurrency to a number that fits your BDA quota. The queue holds the backlog and retries throttled starts for you, so a busy morning slows down instead of failing.

Jake: "So nothing waits anywhere?"

Ethan: "The starter runs for a second, the finisher runs for a second, and BDA does the slow part on its own time. We pay for two seconds of Lambda per invoice."

GitHub samples and the GenAI IDP Accelerator

If you would rather start from working code than from a blank Lambda function, two places on GitHub are worth your time.

The GenAI IDP Accelerator. This is an open-source, MIT-licensed serverless solution from AWS, in the aws-solutions-library-samples organization (repository accelerated-intelligent-document-processing-on-aws). It deploys a complete document pipeline into your own account: Step Functions orchestrate the steps, Lambda functions call BDA or Textract and Bedrock models, and the stages run from ingestion through OCR, classification, extraction, validation, summarization and human review to export, with a web UI on top. It offers a BDA mode, where Bedrock Data Automation does the extraction, and a pipeline mode built on Bedrock models for documents that need custom logic. This is the repository behind the "aws idp accelerator github" searches. An AWS Marketplace listing with a similar "IDP Accelerator" name comes from a partner and is a different product, so check the publisher before you click.

Sample notebooks. Search GitHub for "bedrock data automation" to find AWS sample notebooks that walk through each modality and the blueprint API. Check the last commit date and the boto3 version each one pins, since older samples may use parameter names from before later API changes.

Which start suits you?

• The accelerator, when you need the whole pipeline (review UI, tracking, several document types) quickly, someone on the team is comfortable deploying infrastructure-as-code stacks, and you are happy to run more services than the two-function design above.
• The two-function pipeline, when you have one or two document types, one destination and a small team; it is about a hundred lines you can read in one sitting.
• The notebooks, when you are still deciding whether BDA fits and want to see real output on your own files before building anything.

The synchronous API: invoke_data_automation

For a small file where you want the answer in the same request (an upload form, a chat app), use invoke_data_automation(). It accepts the file's bytes directly and returns the output in the response:

with open("receipt.jpg", "rb") as f:
    result = runtime.invoke_data_automation(
        inputConfiguration={"bytes": f.read()},
        dataAutomationConfiguration={"dataAutomationProjectArn": SYNC_PROJECT_ARN, "stage": "LIVE"},
        dataAutomationProfileArn=PROFILE_ARN,
    )

print(result["semanticModality"])                      # DOCUMENT, IMAGE, AUDIO or VIDEO
for segment in result["outputSegments"]:
    print(segment.get("customOutputStatus"))           # MATCH or NO_MATCH against your blueprints
    print(segment.get("customOutput") or segment.get("standardOutput"))

Create the project you use here with projectType="SYNC". Keep synchronous calls for small, quick inputs; long PDFs, audio and video belong on the asynchronous API, which writes results to S3 and does not hold your request open while it works.

When to choose which:

• Synchronous: a customer uploads a receipt in your app and expects the fields to appear in the form straight away; a support agent drops a screenshot into a tool and wants its text.
• Asynchronous: batches from an S3 inbox, anything over a few pages, every audio or video file, and any job where a retry later is fine.
• Either way, the same project settings and blueprints apply, so you can prototype synchronously and move the volume to the asynchronous API without changing what you extract.

The blueprints parameter on either call lets you override the project's blueprints for one request, which is handy for testing a new blueprint version on live traffic samples.

Blueprints: define the fields you want

A blueprint is a schema in plain English: field names, a description of each, and a type. You can start from the sample catalog (invoices, receipts, bank statements, pay slips, ID documents and more), describe what you want in natural language in the console and let BDA draft the fields, or write the schema yourself. Good blueprints share three habits:

• Describe each field the way a person would: "Total amount due including tax, as a number" beats "total".
• Ask for normalized values: dates as YYYY-MM-DD, amounts as numbers, currency as a three-letter code, so your code never parses a European-style "1.234,50" by hand.
• Keep to 30 fields or fewer where possible; above that, each extra field adds to the per-page price.

To build and test your first blueprint:

1. Collect 5-10 real samples of the document type, including the awkward ones (scans, two-column layouts, a different language).
2. Start from a catalog blueprint if one is close, or describe the fields in the console and let BDA draft them.
3. Run the samples in the DEVELOPMENT stage and compare every field with what a person would type.
4. Tighten the descriptions of fields that came back wrong, then re-run the same samples.
5. Promote the blueprint to LIVE once the samples pass, and keep them as a regression test for future changes.

Jake: "The VAT number kept landing in the supplier name field."

Ethan: "So say what the supplier name is: the company issuing the invoice, usually at the top, not a tax number. Descriptions are the whole trick."

Blueprints have DEVELOPMENT and LIVE stages, like projects, so you can test a change on sample files before production traffic uses it. Several blueprints can sit in one project; BDA picks the matching one per document segment, which is how one inbox can take invoices, receipts and delivery notes together. For infrastructure as code, CloudFormation has resource types for data automation projects and blueprints.

Confidence scores and human review

Every field in custom output comes with a confidence score: BDA's estimate, as a percentage, of how likely that value is right. BDA's models are tuned for calibration (low Expected Calibration Error), which in plain terms means that across many documents, fields scored around 80% should be right about 80% of the time. That is what makes the scores usable for routing work to people.

A practical starting point for the bands:

• 90-100% (high): post automatically.
• 70-89% (medium): post, but run a rule check or a weekly spot check.
• Below 70% (low): send to a person before anything is posted.

To set up review for your own documents:

1. Pick the fields that matter. Total, supplier, invoice number and due date decide whether money moves; a low score on a "notes" field should not hold up a payment.
2. Set a threshold per field. Start at 70% for most fields and higher, such as 90%, for amounts and bank details.
3. Add plain rule checks. Line items should add up to the subtotal, tax should equal subtotal times the rate, the supplier should exist in your system, and the invoice number should be new. These catch mistakes that a high confidence score can still hide.
4. Route failures to a reviewer. Amazon Augmented AI (A2I) with a private workforce of your own staff gives you a ready review task UI; for a small team, a "needs review" state in the jobs table and a simple internal page works just as well.
5. Write the corrected values back and keep each corrected file with its right answers; they become your test set for the next blueprint change.
6. Tune with real numbers. After a month, count how often each band was wrong and move the thresholds; your documents decide the right line, not a default.

Jake: "One in twenty goes to review. Mostly handwritten delivery notes."

Ethan: "Good. The rest post themselves, and the review pile tells us which blueprint description to fix next."

BDA as a parser for knowledge bases

When you build a Bedrock knowledge base over PDFs full of tables, charts and scans, the default text extraction can lose structure. You can choose Bedrock Data Automation as the knowledge base's parser: it reads layouts, tables and figures into clean text before chunking, which usually improves answers on complex documents. In that mode BDA produces and charges for standard output, at the per-page rate above, during ingestion. Our knowledge base guide covers the other parsing and chunking choices.

Is it worth it? Weigh it page by page:

• Plain text documents (policies, articles, emails as PDF): the default parser is usually fine, and free.
• Tables, forms, charts and scans (price lists, spec sheets, annual reports): BDA parsing is where the answer quality improves most.
• Images and slides: BDA describes figures in text, so questions about a diagram can find it.
• Cost check: a 5,000-page document set costs about $50 to parse with BDA; every re-ingestion of changed files is charged again, so only re-sync what changed.

Jake: "The price list PDFs finally answer 'how much is the blue jacket in large'."

Ethan: "Because the table came through as a table. The default parser had flattened it into one long line."

IAM permissions

The identity that runs your code needs:

• Permission to invoke data automation on the project and the data automation profile (the bedrock:InvokeDataAutomationAsync action, or the synchronous one), and to read job status.
• s3:GetObject on the input files and s3:PutObject on the output prefix.
• For setup scripts, the actions that create and update projects and blueprints.
• If your buckets use a customer managed KMS key, kms:Decrypt and kms:GenerateDataKey on that key, or pass the key in encryptionConfiguration.

Access errors on the output prefix are the most common first-run failure: the job runs, then cannot write its results. A few habits keep this tidy:

• Separate buckets or prefixes for input and output, so a bug cannot overwrite the originals and a lifecycle rule can expire old outputs.
• Least privilege on the runtime role: invoke on the one project and profile it uses, read on the input prefix, write on the output prefix, nothing else.
• Personal data: ID documents and pay slips are sensitive; encrypt with a KMS key you control, and restrict who can read the output bucket.
• Region: the profile decides where processing may happen; pick a profile for the geography your data rules allow (for example a US or EU profile).

Before you go live: a cost and accuracy checklist

Run through this list before the first big batch. Each item has saved someone a surprise bill or a week of bad data:

1. Build a test set of 50-100 real files with the right answers typed by a person. Include scans, phone photos, two-column layouts and your strangest suppliers, not just the clean PDFs.
2. Measure accuracy per field, not per document. "Supplier 99%, total 97%, due date 91%" tells you exactly which field description to rewrite; "94% of documents correct" does not.
3. Price the real page count. Count pages, not files: a supplier who attaches eight pages of terms to every invoice makes each one cost nine pages. Strip pages you never read before sending, where your process allows it.
4. Pick the output type per project. A search index only needs standard output at $0.010 a page; paying $0.040 for custom output there buys fields nobody reads.
5. Keep blueprints at or under 30 fields. If a document truly needs 60 fields, consider whether two document types with two blueprints would be clearer as well as cheaper.
6. Set an AWS Budgets alert on Bedrock spend before the first batch, and run a 1% sample of any backlog first to check the cost per file against your estimate.
7. Expire old outputs. Once results are in your database, an S3 lifecycle rule on the output prefix keeps the results bucket from growing forever.
8. Version your blueprints. Change them in DEVELOPMENT, re-run the test set, and promote to LIVE only if no field got worse.
9. Alarm on failures. Alert on the two failure events, and on any job that stays RUNNING in your table for more than an hour.

The 1% sample is the step people skip and regret. A backlog of 200,000 archived pages at the custom rate is $8,000; a 2,000-page sample costs $80 and tells you whether the blueprint is ready before you spend the rest.

Errors and fixes

• Status ClientError: something about the request or the file: an unsupported or corrupt file, an S3 URI that does not exist, no permission to read the input or write the output. Read errorType and errorMessage in the status.
• Status ServiceError: a failure on the service side; retry the job.
• AccessDeniedException: missing invoke permission on the project or profile, or on the S3 locations. Our ClientError guide shows how to read the code in Python.
• ValidationException: a wrong ARN format (project or profile), a profile in another Region from the client, or a sync call against an asynchronous project.
• ThrottlingException or ServiceQuotaExceededException: too many concurrent jobs; queue them (SQS works well) and raise the quota if you need more.
• Custom output is empty, customOutputStatus is NO_MATCH: no blueprint matched that document; check the blueprint stage, add a blueprint for that document type, or improve its description.
• Wrong values in a field: make the field description more specific, and add the expected format; test in the DEVELOPMENT stage before going LIVE.

Frequently asked questions

The supplier invoices now arrive in an S3 inbox, BDA fills a 20-field invoice blueprint, and a small Lambda function posts the JSON into the bookkeeping system. The accounts team checks the few that come back with low-confidence values, about one in twenty, instead of typing all forty. The monthly bill is smaller than one hour of anyone's time.

Revision note. Written October 20, 2026, with the per-page and per-minute rates in effect that day.