2026 07 20 aws agentcore knowledge context layer

AWS AgentCore and AWS-native Knowledge Context Layer: design patterns for continuous acquisition, curation, evolution, and governed serving of enterprise knowledge to AI agents via ontologies, knowledge graphs, and GraphRAG

Research Question

What Amazon Web Services (AWS) AgentCore capabilities and AWS-native services are required to design and operate a Knowledge Context Layer (KCL) that continuously acquires, curates, evolves, and serves enterprise knowledge to Artificial Intelligence (AI) agents through ontologies, knowledge graphs, GraphRAG (Graph Retrieval-Augmented Generation), and governed interfaces, and what are the concrete architectural patterns, integration points, and operational constraints for implementing that layer at regulated enterprise scale?

Scope

In scope:

AWS-native services that compose a KCL: Amazon Bedrock Knowledge Bases, Amazon Neptune (graph database), Amazon OpenSearch Serverless (vector index), Amazon Bedrock AgentCore (Memory, Gateway, Identity), AWS Glue (data ingestion), Amazon EventBridge (event-driven curation triggers), Amazon S3 (source storage), AWS IAM (Identity and Access Management) and AWS Lake Formation (governed access)
Design patterns for continuous knowledge acquisition pipelines (crawl, extract, embed, load)
Ontology and schema management within a KCL: how AWS services handle RDF (Resource Description Framework), SPARQL (SPARQL Protocol and RDF Query Language), or property-graph schemas at runtime
GraphRAG patterns on AWS: how Neptune + OpenSearch Serverless + Bedrock Agents compose into a KG-RAG (Knowledge Graph Retrieval-Augmented Generation (RAG)) retrieval path
Governed interface patterns for policy-controlled knowledge serving: AgentCore Gateway, Application Programming Interface (API) Gateway, Bedrock Guardrails, IAM resource policies
Operational constraints at enterprise scale: Neptune throughput limits, Knowledge Base sync latency, embedding refresh cadence, data-residency considerations for regulated industries
Comparison of fully managed AWS path versus hybrid (customer-managed Neptune + AWS retrieval services)

Out of scope:

Non-AWS cloud providers (Azure, Google Cloud) except where directly cited for comparison
Building a custom ontology from first principles; ontology content design is out of scope: the item covers how AWS services host and query ontologies, not what an ontology should contain
General Agentic Semantic Knowledge Management capability models (covered in 2026-05-21-agentic-semantic-km-capability-model)
Foundational KG-RAG migration trade-offs (covered in 2026-07-05-vector-rag-to-ontology-kg-rag-migration)

Constraints:

Sources must be dated 2024 or later given the pace of AWS AgentCore feature evolution; older architectural guidance is acceptable only where it remains materially accurate
Primary sources: AWS official documentation, AWS architecture blog, AWS re:Invent / re:Inforce session slides, and peer-reviewed papers where available
Time horizon: design choices that are valid for a 12–18-month implementation runway from mid-2026

Context

Enterprises adopting AI agents need a layer that supplies agents with current, governed, semantically rich knowledge: not just a static document store. AWS is the dominant cloud provider for regulated enterprise AI in many markets, and Amazon Bedrock AgentCore introduced managed memory, identity, and gateway primitives in 2025 that change the design space. The completed items on AWS Bedrock capabilities (2026-05-17-aws-bedrock-capabilities), AgentCore (2026-05-17-aws-bedrock-agentcore-suite-capabilities), and KG-RAG migration trade-offs (2026-07-05-vector-rag-to-ontology-kg-rag-migration) established that (a) the capability building blocks exist, and (b) ontology-backed GraphRAG is justified in relationship-dense domains. What is missing is a concrete AWS-specific design pattern that assembles those building blocks into a continuously operating KCL with governed interfaces. This item fills that gap and directly informs architecture decisions for any team building an AWS-native agentic knowledge system.

Approach

Map each KCL function (acquire, curate, evolve, serve) to one or more AWS-native services and confirm whether AgentCore Memory or Bedrock Knowledge Bases is the natural home for each function.
Identify GraphRAG architectural options on AWS: Neptune + OpenSearch Serverless + Bedrock Agents inline retrieval versus Neptune Analytics graph-RAG versus Bedrock Knowledge Base with graph store configuration.
Investigate how ontologies and RDF/property-graph schemas are represented and queried at runtime: Neptune RDF vs Neptune property graph, SPARQL endpoint exposure, schema versioning.
Examine governed interface patterns: how AgentCore Gateway enforces policies on knowledge access; how IAM, Lake Formation, and Bedrock Guardrails compose into a least-privilege knowledge serving surface.
Assess continuous curation pipelines: event-driven ingestion via EventBridge + Glue + Bedrock Knowledge Base sync, embedding refresh strategies, conflict resolution for evolving facts.
Identify operational limits and regulated-industry constraints: data-residency, encryption at rest/transit, audit logging (CloudTrail), VPC (Virtual Private Cloud) isolation options, and any known quota or latency ceilings documented by AWS.
Synthesise a reference architecture diagram description and decision table covering when to use each AWS service combination, with explicit trade-offs.

Sources

Research Skill Output

(Full output from running the research skill: retained verbatim in the completed item. §§0–5 are the investigation; §6 seeds the Findings section below.)

§0 Initialise

Question: What Amazon Web Services (AWS) AgentCore capabilities and AWS-native services are required to design and operate a Knowledge Context Layer (KCL) that continuously acquires, curates, evolves, and serves enterprise knowledge to AI agents through ontologies, knowledge graphs, GraphRAG (Graph Retrieval-Augmented Generation), and governed interfaces, and what are the concrete architectural patterns, integration points, and operational constraints for implementing that layer at regulated enterprise scale?

Scope: In-scope services are Amazon Bedrock Knowledge Bases, Amazon Neptune, Amazon Neptune Analytics, Amazon Bedrock AgentCore (Memory, Gateway, Identity, Runtime, Observability), AWS Glue, Amazon EventBridge, Amazon Simple Storage Service (Amazon S3), AWS Identity and Access Management (IAM), and AWS Lake Formation. Out of scope: non-AWS clouds except direct comparison, ontology content design, the general Agentic Semantic Knowledge Management capability model, and foundational vector-to-graph migration trade-offs, all of which are covered in cited prior items.

Constraints: sources dated 2024 or later, AWS official documentation and architecture blog prioritized as primary, 12-18 month implementation runway from mid-2026.

Output format: structured Findings with Executive Summary, Key Findings, Evidence Map, Assumptions, Analysis, Risks/Gaps, Open Questions, and Output section, per the research skill Section 6 template.

Prior-work search: Research/completed/ contains four items cited in this item's frontmatter (2026-05-17-aws-bedrock-agentcore-suite-capabilities, 2026-05-17-aws-bedrock-capabilities, 2026-07-05-vector-rag-to-ontology-kg-rag-migration, 2026-07-20-tbox-abox-graphrag) plus six related items covering agentic semantic knowledge management capability models, knowledge graph data products, ontology/world-model forcing functions, graph database SaaS ontology tooling, regulated-AI knowledge curation governance, and permission-safe RAG information architecture. [fact; source: https://github.com/davidamitchell/Research/tree/main/Research/completed] These establish that Bedrock and AgentCore capability building blocks exist, that ontology-backed GraphRAG is justified in relationship-dense domains, and that a dedicated hosted ontology database (Stardog Cloud, Ontotext GraphDB) offers stronger ontology-first reasoning than Neptune, a trade-off this item addresses directly in Analysis given its AWS-native scope constraint. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-12-graph-db-saas-knowledge-ontology.html]

§1 Question Decomposition

Function-to-service mapping 1.1 Which AWS service is the natural home for continuous knowledge acquisition (crawl, extract, embed, load)? 1.2 Which AWS service is the natural home for curation and evolution (conflict resolution, versioning, refresh)? 1.3 Which AWS service is the natural home for governed serving (policy-controlled retrieval)? 1.4 Is AgentCore Memory or Bedrock Knowledge Bases the correct home for durable enterprise knowledge, as opposed to conversational state?
GraphRAG architectural options 2.1 What does the fully managed Bedrock Knowledge Bases + Neptune Analytics GraphRAG path support and what does it exclude? 2.2 What does a customer-managed Neptune Database + retrieval-framework path (for example LlamaIndex) support that the managed path does not? 2.3 What AWS-native open-source tooling exists for bring-your-own-knowledge-graph patterns outside the managed Bedrock GraphRAG feature?
Ontology and schema representation 3.1 Does Neptune support Resource Description Framework (RDF)/SPARQL Protocol and RDF Query Language (SPARQL) and property-graph query languages on the same cluster simultaneously, or are they mutually exclusive per deployment? 3.2 Can a customer supply a predefined ontology or schema to the managed GraphRAG feature at ingestion time?
Governed interface patterns 4.1 How does AgentCore Gateway enforce fine-grained, tool-level and operation-level access policy? 4.2 How does document-level permission filtering work in Bedrock Knowledge Bases, and is it available in both managed and customer-managed Knowledge Base modes? 4.3 What role does Lake Formation play relative to IAM and Gateway policy for data-lake-sourced knowledge?
Continuous curation pipelines 5.1 What is the mechanism and latency profile for syncing new or changed source documents into a Knowledge Base? 5.2 What event-driven pattern connects Amazon S3 changes to Knowledge Base ingestion jobs?
Operational limits and regulated-industry constraints 6.1 What network-isolation and private-connectivity options exist for Neptune and AgentCore components? 6.2 What are Neptune's throughput, storage, and connection limits relevant to enterprise-scale query load? 6.3 In which AWS Regions is managed GraphRAG available, and what does this imply for data-residency-constrained deployments?
Reference architecture and trade-offs 7.1 What decision criteria separate a fully managed AWS path from a hybrid customer-managed path?

§2 Investigation

1. Function-to-service mapping

1.1 Acquisition: Amazon Bedrock Knowledge Bases in its Managed Knowledge Base mode provides native connectors for Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, and a web crawler, and Amazon Bedrock manages ingestion, embedding, re-ranking, and multi-modal parsing (Portable Document Format (PDF) files, PowerPoint (PPTX) and Word (DOCX) documents, documents with embedded visuals, audio, video, and scanned documents) without customer-built extract-transform-load (ETL) code. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html] AWS Glue remains the acquisition tool of choice when the source is not one of the Managed Knowledge Base connectors, for example a relational database, a Software-as-a-Service application without a native connector, or a customer-managed Knowledge Base backed by Amazon OpenSearch Serverless, Amazon Aurora, or Amazon Neptune, because Glue is AWS's general-purpose serverless data-integration service with more than 70 source connectors and a centralized Data Catalog. [fact; source: https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html]

1.2 Curation and evolution: neither Bedrock Knowledge Bases nor AgentCore exposes a dedicated "curation" service; curation is implemented as a re-sync operation. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html] Amazon Bedrock documents that syncing a data source is incremental at the document level, meaning only files added, modified, or deleted since the last sync are re-parsed, re-chunked, re-embedded, and re-indexed. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html] An AWS-authored open-source reference implementation for automated syncing states that the underlying StartIngestionJob Application Programming Interface (API) call processes the entire data source per invocation rather than accepting a list of specific changed files, and the automation pattern's role is to track file-level changes in Amazon DynamoDB and Amazon Simple Queue Service (Amazon SQS) so that ingestion jobs are triggered at appropriate times rather than on every single file event. [fact; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases] These two facts describe different layers of the same system: the API-level unit of work is the whole data source, while Bedrock's internal re-indexing logic still skips unchanged content within that whole-data-source pass. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html; https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases] Continuous curation triggers are implemented with Amazon EventBridge listening for Amazon S3 object-created, object-modified, or object-deleted events, invoking an AWS Lambda function that calls StartIngestionJob, with Amazon SQS or AWS Step Functions added to respect the one-active-ingestion-job-per-data-source constraint implied by the sample's rate-limiting design. [inference; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]

1.3 Governed serving: Amazon Bedrock AgentCore Gateway is the AWS-native governed interface for exposing knowledge and tools to agents behind one authenticated, policy-controlled endpoint; it converts Application Programming Interfaces (APIs), AWS Lambda functions, and existing services into Model Context Protocol (MCP)-compatible tools, fronts other agents including Agent-to-Agent (A2A) traffic, and performs both ingress authentication (verifying which agent or user may call the gateway) and egress authentication (injecting the correct credential for each downstream tool). [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html] Managed Knowledge Bases integrate natively with AgentCore Gateway so that any MCP-compatible agent framework can discover and invoke a Knowledge Base as a tool without custom integration code; this native integration is explicitly not available for customer-managed Knowledge Bases. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html]

1.4 Memory versus Knowledge Bases: AgentCore Memory is documented as solving agent statelessness across conversational turns and sessions, split into short-term memory (turn-by-turn context within one session) and long-term memory (preferences, facts, and session summaries automatically extracted and persisted across sessions, shareable across multiple agents). [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html] Bedrock Knowledge Bases is documented as the mechanism for integrating "proprietary information" into generative AI applications through Retrieval-Augmented Generation (RAG), searching a data source at query time to find relevant information. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html] The two services are not interchangeable: Memory is scoped to what a specific agent has learned about a user or task across interactions, while Knowledge Bases is scoped to enterprise source-of-record content shared across agents and users. [inference; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html] A Knowledge Context Layer's durable, governed enterprise knowledge belongs in Knowledge Bases (optionally graph-backed), and AgentCore Memory is complementary for personalization and task continuity rather than a substitute for it. [inference; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html]

2. GraphRAG architectural options

2.1 The fully managed path is Bedrock Knowledge Bases configured to use Amazon Neptune Analytics as its graph store: after an initial vector search identifies relevant document chunks, the feature retrieves graph nodes or chunk identifiers linked to those chunks, traverses the graph to expand related content, and assembles the enriched context for the foundation model. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] This managed GraphRAG feature carries explicit, documented limitations: configuration options to customize the graph build are not supported; autoscaling is not supported for the underlying Neptune Analytics graph; only Amazon S3 is supported as the data source (not SharePoint, Confluence, or the other Managed Knowledge Base connectors); a foundation model must be chosen for graph construction, which automatically enables contextual enrichment; each data source is capped at 1,000 files by default (extendable to 10,000 by service-limit increase request, or worked around by S3 folder partitioning); and hierarchical chunking retrieves only child chunks during graph search, not their parent chunks. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] Managed GraphRAG is available in only seven AWS Regions: Europe (Frankfurt), Europe (London), Europe (Ireland), US West (Oregon), US East (N. Virginia), Asia Pacific (Tokyo), and Asia Pacific (Singapore). [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html]

2.2 The customer-managed hybrid path connects a self-provisioned Amazon Neptune Database cluster directly to Amazon Bedrock foundation models through an open-source orchestration framework. [inference; source: https://aws.amazon.com/blogs/database/using-knowledge-graphs-to-build-graphrag-applications-with-amazon-bedrock-and-amazon-neptune/] AWS's own Database Blog demonstrates this pattern using LlamaIndex: a NeptuneDatabaseGraphStore retriever connects to a Neptune Database read endpoint holding a hand-modeled property graph (in the example, a Customer 360 identity graph linking Phone, Email, Address, Session, Device, IP, and Page nodes to a User node), and an Anthropic Claude model accessed through Bedrock generates responses grounded in the graph traversal results. [fact; source: https://aws.amazon.com/blogs/database/using-knowledge-graphs-to-build-graphrag-applications-with-amazon-bedrock-and-amazon-neptune/] This differs from the managed path in 2.1 in three respects: the graph schema is customer-designed rather than auto-extracted, retrieval logic is written in an external framework rather than configured declaratively in Bedrock, and the data source is not restricted to Amazon S3. [inference; source: https://aws.amazon.com/blogs/database/using-knowledge-graphs-to-build-graphrag-applications-with-amazon-bedrock-and-amazon-neptune/; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html]

2.3 AWS Labs, AWS's own open-source organization, publishes the graphrag-toolkit, which contains two Python packages directly relevant to bridging the gap between 2.1 and 2.2: lexical-graph, which automates construction of a hierarchical lexical graph from unstructured data and composes question-answering strategies over it, and graphrag-byokg ("bring your own knowledge graph"), which is described as combining Large Language Models (LLMs) with a knowledge graph the user already owns and controls, explicitly supporting question answering over a pre-existing, customer-designed graph rather than an auto-extracted one. [fact; source: https://github.com/awslabs/graphrag-toolkit] This toolkit is the closest AWS-native answer to a customer-controlled-ontology GraphRAG pattern, because the managed feature in 2.1 explicitly disallows graph-build customization. [inference; source: https://github.com/awslabs/graphrag-toolkit; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html]

3. Ontology and schema representation

3.1 Amazon Neptune Database's engine supports the property-graph query languages Apache TinkerPop Gremlin and openCypher, and separately the World Wide Web Consortium (W3C) Resource Description Framework (RDF) query language SPARQL Protocol and RDF Query Language (SPARQL). [fact; source: https://docs.aws.amazon.com/neptune/latest/userguide/intro.html] The documentation states a cluster is configured for "the Property Graph (PG) model" queryable by openCypher and/or Gremlin, "or" the RDF model queryable by SPARQL, which is evidence that a given Neptune cluster is provisioned for one graph model family, not both simultaneously; the source does not state whether a single cluster can expose both a property-graph and an RDF endpoint concurrently, so this remains a gap noted in Risks/Gaps rather than a resolved claim. [inference; source: https://docs.aws.amazon.com/neptune/latest/userguide/intro.html]

3.2 As established in 2.1, the managed Bedrock Knowledge Bases GraphRAG feature does not accept a customer-supplied ontology, schema, or entity-type definition at ingestion time; the graph is auto-extracted by the chosen foundation model. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] Predefined-ontology control is only available by moving to the customer-managed Neptune Database path (2.2) or the graphrag-byokg toolkit path (2.3), both of which require the customer to design and load the schema outside Bedrock's managed ingestion pipeline. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] A prior repository item examining TBox (Terminological Box, meaning a predefined ontology or schema)-driven ontology guidance versus schema-free ABox (Assertion Box, meaning instance-level facts emerging from data)-emergent extraction found that a hybrid "seed schema" approach, which predefines core entity and relation types while continuously expanding them, produced the largest combined accuracy and efficiency gains in the evidence it reviewed. [inference; source: https://davidamitchell.github.io/Research/research/2026-07-20-tbox-abox-graphrag.html] AWS's managed GraphRAG feature does not offer a seed-schema mode; it is fully auto-extracted, which places it at the ABox-emergent end of that prior item's spectrum by construction, a design constraint enterprises evaluating the managed path should weigh against that prior finding. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://davidamitchell.github.io/Research/research/2026-07-20-tbox-abox-graphrag.html]

4. Governed interface patterns

4.1 AgentCore Gateway's fine-grained access control operates at four levels: gateway-level (Open Authorization (OAuth) or IAM authentication to connect at all), tool-level (interceptor logic gating specific tools), operation-level (interceptors gating specific MCP operations such as tools/list or tools/call), and parameter-level (interceptors filtering or validating specific request parameters). [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html] REQUEST interceptors execute before the Gateway calls the target and can validate JSON Web Token (JWT) claims, implement role- or attribute-based access control, and return authorization errors; IAM-authenticated gateways can alternatively match the caller's IAM Amazon Resource Name (ARN) using Cedar-policy pattern matching on principal.id. [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html]

4.2 Managed Knowledge Bases apply document-level permission filtering using Access Control Lists (ACLs) at retrieval time, for every supported connector except the web crawler; this capability, like native Gateway integration, is documented as available only for Managed Knowledge Bases, not customer-managed ones. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html] A prior repository item on permission-safe RAG for enterprise information architecture found that a coherent, correctly represented permission estate, whether evaluated live at query time or encoded as retrieval metadata, is a precondition for any permission-safe retrieval architecture regardless of vendor; ad hoc enterprise sharing defeats both mechanisms. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-permission-safe-rag-enterprise-information-architecture.html] This means Managed Knowledge Base ACL filtering is necessary but not sufficient: it enforces whatever permission state the source system reports, so an enterprise with an incoherent permission estate in SharePoint or Confluence inherits that incoherence into agent-served answers regardless of which AWS Knowledge Base mode is used. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html; https://davidamitchell.github.io/Research/research/2026-04-26-permission-safe-rag-enterprise-information-architecture.html]

4.3 AWS Lake Formation augments IAM with a separate permissions model enabling column-, row-, and cell-level access control over data stored in Amazon S3 and cataloged in the AWS Glue Data Catalog, including tag-based access control (TBAC) and a "hybrid access mode" that lets administrators onboard Lake Formation permissions incrementally, one use case at a time, alongside existing IAM permissions on the same Data Catalog. [fact; source: https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html] For a Knowledge Context Layer whose acquisition path runs through Glue and S3 rather than a Managed Knowledge Base connector, Lake Formation is the governance layer that must supply the fine-grained access decisions that Managed Knowledge Base ACL filtering would otherwise provide natively; AgentCore Gateway then enforces agent- and tool-level policy on top of, not instead of, that data-layer permission model. [inference; source: https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html]

5. Continuous curation pipelines

5.1 As established in 1.2, official Bedrock documentation states syncing is incremental at the document level. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html] The documentation also states that .metadata.json files are tracked separately from content files, so a metadata-only change can be synced without re-embedding the associated content file's vector, which reduces latency and cost for metadata-only updates specifically. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html] Access note: the exact wall-clock latency of an individual sync job is not published as a fixed Service Level Agreement (SLA) figure on the pages consulted; the AWS-authored automation sample instead documents an event-driven pattern designed to minimize the interval between a source change and a triggered ingestion job rather than publishing a latency guarantee for the ingestion job itself. [assumption; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]

5.2 The AWS-authored reference architecture wires Amazon S3 Event Notifications through Amazon EventBridge to trigger the sync pipeline, and mandates specific Amazon S3 bucket security settings before deployment: Block Public Access enabled, default encryption enabled (server-side encryption with Amazon S3-managed keys or AWS Key Management Service (AWS KMS) keys), a bucket policy requiring Transport Layer Security (aws:SecureTransport), versioning enabled, and server access logging enabled. [fact; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases] The sample uses Amazon DynamoDB for job and change tracking, Amazon SQS and Amazon Simple Notification Service (Amazon SNS) for queuing and notification, and AWS Step Functions for workflow orchestration, all encrypted with customer-managed AWS KMS keys with rotation enabled by default. [fact; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]

6. Operational limits and regulated-industry constraints

6.1 Amazon Neptune is documented as a Virtual Private Cloud (VPC)-only service: instances do not allow access from outside the VPC, and connections require Transport Layer Security (TLS) 1.2 with a defined set of strong cipher suites. [fact; source: https://docs.aws.amazon.com/neptune/latest/userguide/limits.html] Amazon Bedrock AgentCore separately documents interface VPC endpoints (AWS PrivateLink) for private connectivity to AgentCore resources, VPC egress configuration for Gateway targets, VPC Lattice connectivity to private resources, and VPC configuration for the Runtime and its tools. [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/vpc.html] Combined, a regulated-enterprise Knowledge Context Layer can keep both its graph store (Neptune, VPC-only by design) and its agent runtime and gateway traffic (AgentCore, via PrivateLink) off the public internet end to end. [inference; source: https://docs.aws.amazon.com/neptune/latest/userguide/limits.html; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/vpc.html]

6.2 Amazon Neptune Database clusters support one primary (writer) instance plus up to 15 read replicas, a maximum cluster storage volume of 128 tebibytes (TiB) in all supported Regions, and a maximum Gremlin/SPARQL HyperText Transfer Protocol (HTTP) request payload size of 150 megabytes (MB), above which the service returns an HTTP 400: BadRequestException. [fact; source: https://docs.aws.amazon.com/neptune/latest/userguide/limits.html] A dedicated AWS Database Blog post reports that Neptune engine version 1.3.2.x, released mid-2024, delivers up to 9 times faster low-latency openCypher query performance and up to 10 times higher openCypher throughput than prior engine versions, attributed partly to a new query-plan cache that avoids re-parsing repeated query patterns. [fact; source: https://aws.amazon.com/blogs/database/new-amazon-neptune-engine-version-delivers-up-to-9-times-faster-and-10-times-higher-throughput-for-opencypher-query-performance/] This throughput improvement is specific to openCypher; the blog post does not report equivalent multipliers for Gremlin or SPARQL query throughput, so this finding should not be generalized across all three supported query languages. [inference; source: https://aws.amazon.com/blogs/database/new-amazon-neptune-engine-version-delivers-up-to-9-times-faster-and-10-times-higher-throughput-for-opencypher-query-performance/]

6.3 As established in 2.1, managed GraphRAG availability is restricted to seven Regions. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] Neptune Database itself is available in substantially more Regions, including Middle East (Bahrain, United Arab Emirates (UAE)), Israel (Tel Aviv), Africa (Cape Town), and multiple Asia Pacific Regions beyond Tokyo and Singapore, plus AWS GovCloud (US) Regions. [fact; source: https://docs.aws.amazon.com/neptune/latest/userguide/limits.html] For a data-residency-constrained deployment outside the seven managed-GraphRAG Regions, for example a Middle East or India-only mandate, the only AWS-native GraphRAG-style option is the customer-managed Neptune Database path (2.2) or the graphrag-toolkit path (2.3), because the fully managed feature is not deployable there at all. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://docs.aws.amazon.com/neptune/latest/userguide/limits.html]

7. Reference architecture and trade-offs

7.1 The evidence gathered across sub-questions 1 through 6 supports a decision structure with three tiers rather than a single fully-managed-versus-hybrid binary: (a) fully managed (Managed Knowledge Base + Neptune Analytics GraphRAG) for S3-sourced, English-document-dominant, schema-agnostic corpora inside the seven supported Regions where auto-extracted entity relationships are acceptable; (b) customer-managed Neptune Database plus an external retrieval framework, for corpora needing a hand-designed ontology, non-S3 sources, or Regions outside the managed feature's footprint; and (c) graphrag-toolkit's graphrag-byokg package for enterprises that already operate a knowledge graph, of any provenance, and need question-answering over it without rebuilding the graph. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://aws.amazon.com/blogs/database/using-knowledge-graphs-to-build-graphrag-applications-with-amazon-bedrock-and-amazon-neptune/; https://github.com/awslabs/graphrag-toolkit] A prior repository item comparing hosted ontology-first graph databases found that Stardog Cloud and Ontotext GraphDB provide stronger native ontology reasoning (for example Web Ontology Language (OWL) inference) than the evidence located for Neptune in this investigation, which did not surface an equivalent native OWL reasoning engine on Neptune. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-12-graph-db-saas-knowledge-ontology.html] Enterprises whose primary requirement is formal ontology reasoning rather than AWS-native integration depth should treat that prior finding as a genuine rival to all three AWS-native tiers above, a trade-off addressed further in Analysis. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-12-graph-db-saas-knowledge-ontology.html]

Access note: the AWS re:Invent / re:Inforce session recordings source listed in the item's Sources section points to a general AWS Region YouTube channel search rather than a specific session; no individual 2024 or 2025 session on knowledge graphs and agents was located and consulted during this investigation, so this source is marked unconsulted [ ] in the Evidence Map rather than cited for any claim.

§3 Reasoning

Facts: the service capability facts in §2 (connector lists, GraphRAG limitations, Region lists, Neptune limits, Gateway access-control levels, sync incrementality) map directly to consulted AWS documentation pages and are stated without narrative embellishment. Inferences: every claim that combines two or more documented facts to draw an architectural conclusion, for example that Memory and Knowledge Bases are complementary rather than substitutable, or that a three-tier decision structure follows from the Region and feature-limitation evidence, is labelled [inference] and traced to its component facts. Assumption: the absence of a published sync-latency SLA is treated as an assumption about operational unpredictability, not a fact, because no source states a numeric guarantee either way. No causal claim in this item asserts that one AWS service "causes" a governance or performance outcome without a cited documentation basis for that specific mechanism.

§4 Consistency Check

contradiction_scan: resolved
finding: official sync-incrementality claim (document-level, per kb-data-source-sync-ingest.html) initially appeared to conflict with the AWS sample repository's claim that StartIngestionJob processes the entire data source per call; resolved in §2.1.2 by distinguishing API-call scope from internal re-indexing scope, both retained as separately labeled facts
finding: Neptune "PG model or RDF model" phrasing in intro.html does not explicitly confirm or deny concurrent dual-model access on one cluster; retained as an unresolved gap in Risks/Gaps rather than asserted either way
confidence_adjustment: Neptune openCypher throughput claim narrowed to openCypher specifically, not generalized to Gremlin or SPARQL, because the source blog only quantifies openCypher
scope_guardrail: maintained; all claims kept within the item's AWS-native scope, with the Stardog/GraphDB rival explicitly flagged as an out-of-AWS-native-scope but relevant trade-off per prior item cross-reference
acronym_audit: completed; OAuth expansion added at first use (line 161)

§5 Depth and Breadth Expansion

Technical lens: the managed GraphRAG feature's restriction to Amazon S3 as the only supported data source (§2.2.1) is a deeper technical constraint than it first appears, because it means an enterprise whose authoritative content lives in SharePoint or Confluence, both supported by Managed Knowledge Bases for vector-only retrieval, cannot use those same connectors if it wants managed GraphRAG; it must first stage that content into S3, which reintroduces exactly the kind of customer-built ETL pipeline the Managed Knowledge Base connectors were designed to avoid. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html]

Economic lens: choosing the customer-managed Neptune Database path (§2.2) instead of Neptune Analytics inside managed GraphRAG shifts cost structure from a per-query managed-feature cost to a provisioned-cluster cost with up to 15 read replicas and a 128 TiB storage ceiling, which the Neptune engine-throughput blog frames as a lever for reducing instance count, and therefore cost, at a fixed throughput target rather than only as a raw performance gain. [inference; source: https://aws.amazon.com/blogs/database/new-amazon-neptune-engine-version-delivers-up-to-9-times-faster-and-10-times-higher-throughput-for-opencypher-query-performance/; https://docs.aws.amazon.com/neptune/latest/userguide/limits.html]

Regulatory lens: the seven-Region footprint for managed GraphRAG (§2.6.3) is a binding constraint for any enterprise with a data-residency mandate outside those Regions, for example Gulf Cooperation Council or South Asian jurisdictions, forcing those enterprises toward the customer-managed or graphrag-byokg tiers by default rather than by choice. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://docs.aws.amazon.com/neptune/latest/userguide/limits.html]

Historical lens: the AWS Database Blog's Customer 360 GraphRAG example and the LlamaIndex integration it describes predate the managed Neptune Analytics GraphRAG feature inside Bedrock Knowledge Bases, indicating that AWS's own reference architecture evolved from a fully customer-assembled pattern toward an increasingly managed one, while still publishing the older pattern as valid guidance for cases the managed feature does not cover. [inference; source: https://aws.amazon.com/blogs/database/using-knowledge-graphs-to-build-graphrag-applications-with-amazon-bedrock-and-amazon-neptune/; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html]

Behavioural lens: AgentCore Gateway's semantic tool-selection capability, which lets agents search across available tools rather than being handed an exhaustive tool list, is a governance-relevant design choice because it changes what a policy reviewer must audit, from a fixed list of tools an agent might call to a dynamic discovery process whose outputs vary by query context. [inference; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html]

§6 Synthesis

(This section seeds the Findings below.)

Executive summary:

A Knowledge Context Layer (KCL) built on AWS composes into three deployable tiers, not one AWS-native design, and the fully managed tier (Bedrock Knowledge Bases with Neptune Analytics GraphRAG) trades away customer-supplied ontology control and non-S3 source connectivity in exchange for zero-infrastructure operation. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] AgentCore supplies the governed-serving and memory layers around whichever Knowledge Base tier is chosen, through Gateway's tool/operation/parameter-level access control and Memory's session-scoped and cross-session state, but Gateway governs agent-to-tool access while Lake Formation and Knowledge Base ACL filtering separately govern data-layer access, and both must be designed together rather than assumed to compose automatically. [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html; https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html]

Key findings:

(seeded into Findings below)

Evidence map:

(seeded into Findings below)

Assumptions:

(seeded into Findings below)

Analysis:

(seeded into Findings below)

Risks, gaps, uncertainties:

(seeded into Findings below)

Open questions:

(seeded into Findings below)

§7 Recursive Review

review_result: pass
every_section_justified: yes
threads_synthesised: yes
claims_sourced_or_labelled: yes
uncertainties_explicit: yes
acronym_audit: passed on internal pass; final audit repeated in Step 6 self-review before commit
domain_term_audit: KCL, TBox, ABox, GraphRAG, RAG defined or expanded at first prose use

Findings

(Populated from §6 Synthesis above.)

Executive Summary

A Knowledge Context Layer (KCL) built on Amazon Web Services (AWS) composes into three distinct deployable tiers rather than one AWS-native design, and the fully managed tier (Amazon Bedrock Knowledge Bases with Amazon Neptune Analytics GraphRAG (Graph Retrieval-Augmented Generation)) trades away customer-supplied ontology control and non-Amazon Simple Storage Service (Amazon S3) source connectivity for zero-infrastructure operation. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] Amazon Bedrock AgentCore supplies the governed-serving and memory layers around whichever Knowledge Base tier is chosen, through Gateway's tool/operation/parameter-level access control and Memory's session-scoped and cross-session state. [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html] Gateway governs agent-to-tool access while AWS Lake Formation and Knowledge Base Access Control List (ACL) filtering separately govern data-layer access, and the two layers must be designed together because neither substitutes for the other. [inference; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html; https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html] Enterprises needing a predefined, customer-controlled ontology rather than an auto-extracted graph schema must leave the fully managed feature and use either a self-provisioned Amazon Neptune Database with an external retrieval framework or AWS Labs' open-source graphrag-byokg package, because the managed feature explicitly disallows graph-build customization. [fact; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://github.com/awslabs/graphrag-toolkit] The managed feature's seven-Region availability footprint is the binding constraint that forces this same choice on any enterprise with a data-residency mandate outside those Regions, independent of its ontology preference. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://docs.aws.amazon.com/neptune/latest/userguide/limits.html]

Key Findings

Amazon Bedrock Knowledge Bases splits into Managed and Customer-managed modes with materially different governance capability: only the Managed mode provides native connectors (Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, web crawler), document-level ACL-based permission filtering at retrieval time, and native integration with AgentCore Gateway. ([fact]; medium confidence; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html)
The fully managed GraphRAG feature, which pairs Bedrock Knowledge Bases with Neptune Analytics, supports only Amazon S3 as a data source, disallows customization of the graph-build configuration, does not autoscale the underlying Neptune Analytics graph, and caps each data source at 1,000 files by default. ([fact]; medium confidence; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html)
Managed GraphRAG is available in only seven AWS Regions (Frankfurt, London, Ireland, Oregon, N. Virginia, Tokyo, Singapore), while Amazon Neptune Database itself operates in over 30 Regions including the Middle East, Israel, Africa, and AWS GovCloud (US), so data-residency-constrained enterprises outside those seven Regions cannot use the managed GraphRAG feature at all. ([fact]; medium confidence; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://docs.aws.amazon.com/neptune/latest/userguide/limits.html)
AWS Labs publishes an open-source graphrag-toolkit containing graphrag-byokg, a package purpose-built for question-answering over a customer's own pre-existing knowledge graph, which is the closest AWS-native path to a predefined-ontology GraphRAG pattern given that the managed Bedrock feature explicitly excludes graph-build customization. ([inference]; medium confidence; source: https://github.com/awslabs/graphrag-toolkit; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html)
AgentCore Gateway enforces access control at four distinct levels, gateway, tool, operation, and parameter, using either REQUEST interceptors validating JSON Web Token (JWT) claims, Open Authorization (OAuth) authentication, or Cedar-policy IAM principal matching, and it separately handles both ingress (verifying caller identity) and egress (injecting downstream credentials) authentication in one managed service. ([fact]; medium confidence; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)
AgentCore Memory and Bedrock Knowledge Bases serve different, complementary roles rather than being substitutable: Memory persists what a specific agent has learned about a user or task across sessions, while Knowledge Bases serves durable, shared enterprise source-of-record content, so a Knowledge Context Layer's governed enterprise knowledge belongs in Knowledge Bases with Memory layered on top for personalization. ([inference]; medium confidence; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html; https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html)
Bedrock Knowledge Base data-source syncing is incremental at the document level, meaning only added, modified, or deleted files since the last sync are re-parsed and re-embedded, and metadata-only changes to a .metadata.json file can sync without re-embedding the associated content, but the underlying StartIngestionJob API call still processes the entire data source per invocation rather than accepting a targeted file list. ([fact]; medium confidence; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html; https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases)
Continuous curation on AWS is implemented as an event-driven pipeline, not a dedicated curation service: Amazon S3 Event Notifications routed through Amazon EventBridge trigger AWS Lambda functions that call the Knowledge Base ingestion API, with Amazon SQS, Amazon SNS, and AWS Step Functions added to respect per-data-source ingestion-job concurrency limits. ([inference]; medium confidence; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases)
Amazon Neptune is a Virtual Private Cloud (VPC)-only service requiring Transport Layer Security (TLS) 1.2 for all connections, and Amazon Bedrock AgentCore separately supports AWS PrivateLink interface VPC endpoints for Gateway, Runtime, and tool traffic, together enabling an end-to-end private-network deployment for both the graph store and the agent runtime. ([inference]; medium confidence; source: https://docs.aws.amazon.com/neptune/latest/userguide/limits.html; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/vpc.html)
Amazon Neptune's 2024 engine version 1.3.2.x delivers up to 9 times faster low-latency openCypher query performance and up to 10 times higher openCypher throughput than prior versions, a query-language-specific improvement that AWS's own blog post does not claim extends equally to Gremlin or SPARQL Protocol and RDF Query Language (SPARQL) queries. ([fact]; medium confidence; source: https://aws.amazon.com/blogs/database/new-amazon-neptune-engine-version-delivers-up-to-9-times-faster-and-10-times-higher-throughput-for-opencypher-query-performance/)
AWS Lake Formation adds fine-grained column-, row-, and cell-level access control and tag-based access control (TBAC) over data cataloged in AWS Glue, with a hybrid access mode that lets administrators onboard Lake Formation permissions incrementally alongside existing IAM permissions on the same catalog. ([fact]; medium confidence; source: https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
A prior repository evaluation of hosted ontology-first graph databases found that Stardog Cloud and Ontotext GraphDB provide stronger native ontology reasoning capability than the evidence located for Neptune in this investigation, which surfaced no equivalent native Web Ontology Language (OWL) inference engine for Neptune, making formal-ontology-reasoning requirements a genuine reason to look outside the AWS-native services examined here. ([inference]; medium confidence; source: https://davidamitchell.github.io/Research/research/2026-05-12-graph-db-saas-knowledge-ontology.html; https://docs.aws.amazon.com/neptune/latest/userguide/intro.html)

Evidence Map

Claim	Source	Confidence	Notes
Managed vs. customer-managed Knowledge Base capability split (connectors, ACL filtering, Gateway integration)	Bedrock Knowledge Bases docs	medium	consulted `[x]`
Managed GraphRAG data-source, autoscaling, config, and file-count limitations	Neptune Analytics graph KB docs	medium	consulted `[x]`
Managed GraphRAG seven-Region availability	Neptune Analytics graph KB docs	medium	consulted `[x]`
Neptune Database Region footprint (30+ Regions incl. GovCloud)	Amazon Neptune Limits	medium	consulted `[x]`
`graphrag-byokg` bring-your-own-knowledge-graph package	awslabs/graphrag-toolkit	medium	consulted `[x]`; README-level description, not a deep technical walkthrough
Gateway four-level access control and interceptor/Cedar mechanics	Gateway fine-grained access control docs	medium	consulted `[x]`
Gateway ingress/egress auth, MCP/A2A tool conversion	AgentCore Gateway docs	medium	consulted `[x]`
Memory short-term/long-term mechanics and cross-agent sharing	AgentCore Memory docs	medium	consulted `[x]`
Knowledge Base sync incrementality and metadata-only sync optimization	Sync your data docs	medium	consulted `[x]`
`StartIngestionJob` processes entire data source per call	Auto-Sync Solution README	medium	consulted `[x]`; AWS-authored sample
Event-driven curation pipeline components (EventBridge, Lambda, SQS, SNS, Step Functions)	Auto-Sync Solution README	medium	consulted `[x]`; describes one reference implementation, not the only possible pipeline
Neptune VPC-only requirement and TLS 1.2 requirement	Amazon Neptune Limits	medium	consulted `[x]`
AgentCore PrivateLink/VPC connectivity options	Protecting your data using VPC and AWS PrivateLink	medium	consulted `[x]`
Neptune 1.3.2.x openCypher throughput improvement (9x/10x)	Neptune engine version blog	medium	consulted `[x]`; single AWS blog post, openCypher-specific
Lake Formation TBAC and hybrid access mode	Lake Formation docs	medium	consulted `[x]`
Customer-managed Neptune Database + LlamaIndex GraphRAG pattern	AWS Database Blog GraphRAG post	medium	consulted `[x]`
Neptune supports Gremlin, openCypher, and SPARQL, PG-or-RDF model per cluster (dual-access on one cluster unconfirmed)	Amazon Neptune intro docs	medium	consulted `[x]`; gap noted in Risks/Gaps
Stardog Cloud / Ontotext GraphDB stronger ontology-first reasoning than Neptune	Prior item: graph-db-saas-knowledge-ontology	medium	prior repository synthesis, cross-referenced not independently re-verified in this item
TBox seed-schema hybrid outperforms pure fixed or pure schema-free extraction	Prior item: tbox-abox-graphrag	medium	prior repository synthesis, cross-referenced not independently re-verified in this item
Permission-safe RAG requires a coherent source-system permission estate regardless of vendor	Prior item: permission-safe-rag-enterprise-information-architecture	medium	prior repository synthesis, cross-referenced not independently re-verified in this item
AWS re:Invent/re:Inforce sessions on knowledge graphs and agents	AWS Region YouTube channel	n/a	identified but not consulted `[ ]`; no specific session located

Assumptions

The absence of a published numeric sync-latency Service Level Agreement (SLA) is treated as an operational-predictability gap rather than a documented guarantee of either fast or slow sync behavior; only the event-driven design intent to minimize lag is documented. [assumption; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]
A given Amazon Neptune Database cluster is assumed to be provisioned for one graph-model family (property graph or Resource Description Framework (RDF)) at a time rather than exposing both a property-graph and a SPARQL endpoint concurrently, because the consulted documentation phrases the choice as "or" without stating whether concurrent dual-model access on a single cluster is possible. [assumption; source: https://docs.aws.amazon.com/neptune/latest/userguide/intro.html]
The three-tier decision structure in Analysis (fully managed, customer-managed Neptune Database, graphrag-byokg) assumes that an enterprise's data-residency, ontology-control, and connector requirements can be evaluated independently and then combined, whereas in practice a single enterprise may need to satisfy multiple constraints simultaneously, which the located sources do not model as a joint decision. [assumption; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html]

Analysis

The evidence separates two governance surfaces that must be designed independently: agent-to-tool access, controlled by AgentCore Gateway's interceptor and Cedar-policy mechanisms, and data-layer access, controlled by Knowledge Base ACL filtering or Lake Formation depending on which acquisition path is used. [fact; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html; https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html] A design that only implements Gateway-level policy while leaving an incoherent source-system permission estate untouched inherits the weaker of the two, because Gateway can restrict which agent may call a Knowledge Base tool but cannot repair document-level permission errors coming from the source system itself. [inference; source: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html; https://davidamitchell.github.io/Research/research/2026-04-26-permission-safe-rag-enterprise-information-architecture.html]

The managed-versus-hybrid trade-off is not a single binary choice but three separable constraints that happen to point the same direction in several common enterprise scenarios. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://docs.aws.amazon.com/neptune/latest/userguide/limits.html] Ontology control, non-S3 source connectivity, and Region availability each independently rule out the fully managed GraphRAG tier for a meaningfully sized subset of enterprises: those requiring a predefined schema, those whose content lives outside S3-reachable connectors, and those operating exclusively in Regions outside the seven supported ones. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html] Where an enterprise's requirement is specifically formal ontology reasoning, for example Web Ontology Language (OWL)-based inference over a domain ontology, the rival explanation from a prior repository item, that a dedicated ontology-first hosted graph database outperforms Neptune on this specific dimension, is a stronger fit than any of the three AWS-native tiers examined here, and should be weighed against the integration cost of operating a non-AWS-native graph store behind AgentCore Gateway. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-12-graph-db-saas-knowledge-ontology.html] This item does not resolve that trade-off, because it falls outside the AWS-native scope, but the evidence gathered here establishes that Neptune's documented strengths lie in query throughput and managed operations rather than in native ontology reasoning, which is a narrower claim than "Neptune is the ontology solution for AWS." [inference; source: https://docs.aws.amazon.com/neptune/latest/userguide/intro.html; https://aws.amazon.com/blogs/database/new-amazon-neptune-engine-version-delivers-up-to-9-times-faster-and-10-times-higher-throughput-for-opencypher-query-performance/]

The sync-incrementality tension identified in §2 and §4 (document-level incrementality claimed by official docs versus whole-data-source API scope claimed by the AWS sample repository) is resolved as two facts about different layers rather than a genuine contradiction, but it has a practical consequence: an automation pipeline built only on the official incrementality claim, without reading the sample repository's operational note, could under-provision for the cost and duration of a StartIngestionJob call on a large data source, because that call re-scans the entire source even though only changed content is re-embedded. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html; https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]

This item's finding that "neither Bedrock Knowledge Bases nor AgentCore exposes a dedicated 'curation' service" (§2.1.2) is a gap when weighed against a prior repository item's regulated-enterprise governance requirement that authoritative knowledge for AI follow an intake, validation, publication, correction-to-source, and retirement-or-recertification lifecycle with logs and version metadata proving what changed and when. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-22-knowledge-curation-governance-for-regulated-ai.html; https://docs.aws.amazon.com/bedrock/latest/userguide/kb-data-source-sync-ingest.html] Amazon EventBridge-triggered re-sync, the mechanism this item identifies as AWS's substitute for a dedicated curation service, satisfies only the "publication" step of that prior lifecycle model directly; it provides no native validation gate before content becomes queryable, no correction-to-source workflow, and no explicit retirement-or-recertification state, so a regulated enterprise adopting the AWS-native pattern in this item would need to layer the prior item's governance lifecycle on top of Knowledge Base sync rather than treat sync automation as a substitute for it. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-22-knowledge-curation-governance-for-regulated-ai.html; https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]

Risks, Gaps, and Uncertainties

No consulted source states a numeric sync-latency SLA for Bedrock Knowledge Base ingestion jobs, so enterprises cannot plan freshness guarantees against a published figure and must instead measure latency empirically in their own environment. [fact; source: https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases]
Whether a single Amazon Neptune Database cluster can expose both a property-graph endpoint (Gremlin/openCypher) and a SPARQL endpoint concurrently, or whether the choice is exclusive per cluster, is not resolved by the consulted documentation and would require a direct AWS support inquiry or hands-on cluster configuration test to confirm. [fact; source: https://docs.aws.amazon.com/neptune/latest/userguide/intro.html]
The Neptune engine 1.3.2.x throughput improvement is quantified only for openCypher; no located source quantifies an equivalent improvement, or its absence, for Gremlin or SPARQL query performance on the same engine version, so applying the 9x/10x figures to non-openCypher workloads would be unsupported. [fact; source: https://aws.amazon.com/blogs/database/new-amazon-neptune-engine-version-delivers-up-to-9-times-faster-and-10-times-higher-throughput-for-opencypher-query-performance/]
No AWS re:Invent or re:Inforce 2024/2025 session recording specific to knowledge graphs and agents was located during this investigation; the seeded source pointed to a general channel search rather than a specific session Uniform Resource Locator (URL), so session-level architectural guidance beyond written documentation and blog posts is a genuine gap in this item's evidence base. [fact; source: https://www.youtube.com/user/AmazonWebServices]
The AWS Labs graphrag-byokg package was evaluated only at README depth; no consulted source documents its production maturity, adoption evidence, or a direct comparison against the customer-managed Neptune Database plus external-framework pattern, so its practical viability as an enterprise-grade tier relative to the other two tiers remains unverified. [fact; source: https://github.com/awslabs/graphrag-toolkit]
This item does not independently re-verify the three cross-referenced prior-item claims (Stardog/GraphDB ontology strength, TBox seed-schema advantage, permission-safe RAG precondition); those claims carry the confidence levels assigned in their originating items and are cited here as context rather than as newly validated findings.
No consulted AWS source describes a validation gate, correction-to-source workflow, or explicit retirement-or-recertification state for content ingested through Bedrock Knowledge Base sync, so this item's AWS-native curation pipeline covers only the "publication" step of the governance lifecycle a prior repository item establishes for regulated-enterprise knowledge, and a regulated deployment would need to build the remaining lifecycle stages outside the AWS services examined here. [inference; source: https://davidamitchell.github.io/Research/research/2026-04-22-knowledge-curation-governance-for-regulated-ai.html]

Open Questions

Can a single Amazon Neptune Database cluster expose both property-graph and RDF/SPARQL query access concurrently, and if not, what is the operational cost of running parallel clusters for enterprises needing both access patterns over the same underlying knowledge?
What quantified sync latency, in wall-clock time from source change to queryable Knowledge Base update, do enterprises observe in production for data sources of varying size, and does this vary meaningfully between the Managed and Customer-managed Knowledge Base modes?
How mature and production-adopted is AWS Labs' graphrag-byokg package relative to the customer-managed Neptune Database plus external-framework pattern, and are there documented enterprise deployments to evaluate against?
What is the actual cost differential between the three deployment tiers (fully managed GraphRAG, customer-managed Neptune Database, graphrag-byokg-based custom pipeline) at a defined enterprise scale, since this item found operational and capability differences but no side-by-side cost benchmark?
Does AWS publish or plan to publish a Neptune engine throughput benchmark for Gremlin and SPARQL comparable to the openCypher-specific 2024 figures, and if not, how should enterprises using those query languages estimate expected throughput gains from engine upgrades?

Output

(Fill in when completing: what was produced as a result of this research?)

Type: knowledge
Description: A three-tier AWS-native reference architecture and decision framework for a Knowledge Context Layer (fully managed Bedrock Knowledge Bases + Neptune Analytics GraphRAG, customer-managed Neptune Database + external retrieval framework, and AWS Labs graphrag-byokg), mapping AgentCore Gateway, Memory, and Identity governed-serving capabilities onto each tier and identifying ontology-control, connector, and Region-availability constraints that determine which tier an enterprise must use. [inference; source: https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs.html; https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-fine-grained-access-control.html]
Links: Build a knowledge base with Amazon Neptune Analytics graphs; Fine-grained access control for Amazon Bedrock AgentCore Gateway; awslabs/graphrag-toolkit