One File Over 50MB Stops the Pipeline Cold: Designing a Managed RAG Migration Gate for Bedrock

What changed in the managed path: agentic retrieval

In June 2026, AWS shipped the fully managed option for Amazon Bedrock Knowledge Bases (AWS's own announcement). The path bundles multi-hop agentic retrieval by default — it plans sub-queries for a single question, evaluates interim answers, and re-ranks before returning a result. Teams no longer have to run the vector store themselves, but the ingestion limits underneath are still theirs to manage.

Graph reasoning stays optional

If a workload needs to trace relationships between entities, Bedrock Knowledge Bases supports GraphRAG on Amazon Neptune Analytics, which AWS took generally available on March 7, 2025. You can spin up a new graph store with Quick Create in the console, or wire the knowledge base to a Neptune Analytics graph you already run. Managed agentic retrieval and GraphRAG are not guaranteed to be the same toggle on the same knowledge base, so check which query shape dominates your logs before you design around either one.

Migration checklist: start with the ingestion limits

Before migrating, write your operating targets down as numbers. Set a 0% ingestion failure rate, hold p95 latency on multi-hop queries to a fixed ceiling, and cap how long a new document takes to show up in retrieval. Without numbers, a migration review tends to end at "it feels faster" instead of a real comparison.

Data source design belongs in this same step. AWS's own documentation caps each source file at 50MB, and JPEG/PNG images at 3.75MB, for Bedrock Knowledge Base ingestion. Files over that limit get filtered out at ingestion time — and without a dedicated alert, a team can go a long time before noticing that one document silently never made it in.

Failure tends to show up two ways. First, scanned PDFs or image-heavy documents quietly drop out once they cross the 50MB or 3.75MB ceiling. Second, teams that migrate to the managed path first sometimes only discover in production that a meaningful share of their queries needed graph relationships after all. Neither failure is easy to catch without reviewing query logs and source file sizes before the cutover.

Recovery starts the moment a gap is caught. For a document dropped by the size limit, compress or split it and re-ingest, then scan the rest of that data source for files near the same size. For queries that turn out to need graph relationships, don't roll back all traffic at once — branch just that query type to the GraphRAG path and validate it on its own before deciding anything broader.

The pre-launch checklist runs scenario tests first: feed in sample files close to 50MB and images close to 3.75MB, confirm ingestion actually rejects them, and confirm the rejection shows up in your observability logs. Log fields should include source filename, size, ingestion result, and failure reason, so a gap is traceable from the logs alone. Any source carrying PII should be masked before ingestion, on either path.

Run the improvement loop weekly. Tally how many files hit the size limit and what share of queries needed graph relationships that week, and watch whether the mix is shifting. Keep the migration decision itself in a change log rather than treating it as a one-time call — that's what lets the next review start from the reasoning you used the first time, not from scratch.

The migration gate at a glance

Moving to the managed path is less about a raw performance comparison and more about ingestion limits and query shape. Build the 50MB file cap and 3.75MB image cap into your pre-migration capacity check, validate the GraphRAG path separately whenever graph-relationship queries show up in your logs, and you catch the silent drops before they reach production instead of after.

Reference Links

Amazon Bedrock Managed Knowledge Base is now generally available — AWS

Prerequisites for your Amazon Bedrock knowledge base data — AWS