Amazon Kendra can connect to enterprise repositories, synchronize added, changed, and deleted documents, enrich content and metadata, ingest access controls, rank search results, and retrieve passages for RAG applications. Those controls do not decide who owns an incomplete sync, a failed deletion that leaves obsolete content searchable, a connector whose ACL mapping exposes the wrong evidence, a relevance change that hides an authoritative document, a throttled Retrieve API, or a GenAI index migration that changes identity behavior.
Datrick provides an ongoing operating layer for an agreed Kendra estate. Named engineers correlate authoritative repositories, connector schedules and runs, document-level reports, index fields, custom document enrichment, ACL and user-context behavior, index edition, Query and Retrieve APIs, confidence and relevance, capacity units, CloudWatch, IAM, consuming applications, AWS cost, and business outcomes. AWS Support remains the escalation path for platform defects. Datrick owns the client-specific diagnosis, containment, validation, communication, change, and prevention accepted in the service boundary.
Do you have Kendra in production but no team accountable for turning incomplete syncs, failed deletions, ACL drift, weak retrieval, throttling, or downstream grounded-answer defects into a verified outcome? Start with one representative index, connector, identity path, and consuming application.
Define ownership from repository and ACL to indexed document, retrieved passage, and grounded answer
A production plan can include SharePoint, S3, Salesforce, Confluence, Google Drive, databases, web crawlers, or custom sources; connector roles and network access; schedules and incremental sync; additions, updates, and deletions; document formats and metadata; custom enrichment; index type and Region; fields, facets, boosts, and filters; ACLs and user context; Query and Retrieve APIs; application integration; monitoring; capacity; backup or rebuild evidence; releases; changes; and AWS escalation.
Document source and index ownership separately. A connector can reach a repository while one path, object type, permission, metadata file, enrichment Lambda, or deletion operation fails. Search can return a relevant passage to an unauthorized user if the consuming route omits user context or if identity mapping differs from the source. A GenAI Enterprise index supports different access-control mechanisms and Regions than other index types. Product success requires explicit contracts for all of them.
Operate the complete Amazon Kendra production surface
| Service area | Managed responsibility | Boundary to define |
|---|---|---|
| Sources, connectors, sync, and deletion | Repository inventory, connector configuration, schedule, sync status, crawled and indexed counts, skipped and failed documents, deletion outcomes, retries, and freshness reporting. | Source owner, authoritative path, supported connectors and formats, expected population, freshness SLO, deletion SLA, maintenance, exceptions, and replay authority. |
| Metadata and document enrichment | Field mappings, required metadata, facets, custom document enrichment rules and Lambda hooks, transformed content, validation, versioning, and rollback. | Schema owner, PII handling, enrichment contract, Lambda and S3 ownership, timeout and failure behavior, backfill, release gate, and acceptance set. |
| Index type, retrieval, and relevance | Enterprise or GenAI Enterprise decision, Query and Retrieve behavior, filters, boosts, confidence, search result types, passages, query cohorts, evaluations, and application route. | Search versus RAG use, Region and language constraints, expected result or passage, quality threshold, low-confidence handling, grounded-answer policy, latency, and fallback. |
| ACL, identity, and security | Source ACL ingestion, user attributes or context, group and data-source filters, public-document behavior, IAM roles, KMS, VPC path where used, audit evidence, and denied-path tests. | Identity authority, index-type limitations, public-content rule, application obligation to send context, least privilege, cross-account access, incident authority, and compliance evidence. |
| Capacity, incidents, releases, and cost | Document and query capacity, throttling, peak tests, CloudWatch, alarms, incident triage, change control, canary, rollback, usage attribution, forecast, and reporting. | Peak QPS and corpus growth, capacity approval, severity, SLO, support escalation, release window, budget owner, cost allocation, exclusions, and service acceptance. |
Treat source coverage, deletion, ACLs, retrieval relevance, grounded answers, latency, and cost as one design
Start with an expected-document ledger, not a green sync badge. Reconcile repository inventory, connector filters and schedules, sync status, CloudWatch metrics, document-level reports, indexed and deleted counts, failed metadata and enrichment, and sampled searches. AWS exposes metrics including documents crawled, submitted for indexing, failed indexing, submitted for deletion, failed deletion, and indexed totals. Alert on expected counts and ratios, not only job failure.
Evaluate search and RAG separately. Query API results, answer excerpts, FAQs, Retrieve API passages, confidence buckets, filters, boosts, and the final generated answer are different surfaces. Use labelled production-like queries with expected documents or passages, access outcomes, recency, confidence rules, answer claims, and business acceptance. Compare relevance changes in small increments and prove that a boost improves the intended cohort without suppressing another.
Capacity is a correctness and continuity control. Kendra uses provisioned document and query capacity, can throttle requests beyond the accepted envelope, and changes take time to apply. Model corpus growth, sync concurrency, query peaks, Retrieve and Query traffic, application retry, adaptive bursting where available, downstream generation latency, and budget. Load-test the complete authenticated route rather than the index alone.
Distinguish connector, document, deletion, enrichment, ACL, relevance, capacity, application, and cost failures
| Symptom | Evidence to reconcile | Safe containment | Permanent control |
|---|---|---|---|
| Expected content is missing or obsolete content remains searchable | Source object and version, connector scope, sync status, crawled and submitted counts, invalid metadata, failed indexing or deletion, document report, index count, query sample, and retry history. | Pause consequential answers, preserve sync evidence, isolate affected sources, remove unsafe content through an accepted path, reprocess changed documents, and disclose freshness risk. | Expected-document ledger, freshness and deletion SLOs, count reconciliation, per-document reports, exception queue, idempotent replay, stale-content test, and source-owner signoff. |
| Users see restricted content or cannot find allowed content | Source ACL, connector mapping, index type, user ID, groups or attributes, data-source groups, public flag, application request, filters, original repository access, and recent identity change. | Disable the unsafe route, default deny high-risk cohorts, preserve request evidence, restore accepted context mapping, verify source access, and retest allowed and denied cases. | Identity contract, index-type decision record, ACL reconciliation, public-content rule, user-context middleware, negative tests, group-change canary, and periodic access review. |
| Search or RAG answers are irrelevant, incomplete, or unsupported | Labelled query, expected document and passage, index fields, enrichment output, filters, boosts, confidence bucket, Query or Retrieve response, generation context, answer claims, latency, and release. | Restore accepted relevance configuration, filter low-confidence results, show sources, require review, route to fallback, and block high-consequence automation. | Query cohort evaluation, expected-passage threshold, relevance canary, claim-support checks, enrichment regression tests, feedback review, attribution, and rollback. |
| Queries throttle, latency spikes, release fails, or cost escapes | Index edition, document and query capacity, corpus size, QPS, burst history, ThrottlingException, application retries, CloudWatch, sync load, downstream generation, change, usage, and spend. | Protect critical traffic, stop retry amplification, restore accepted capacity or release, defer noncritical sync, use validated fallback, cap spend, and communicate impact. | Capacity model, peak load test, quota and cost alarms, retry budget, release matrix, canary, autoscaling decision where applicable, usage attribution, and rollback. |
A retry is not automatically safe. Before rerunning a sync, changing filters, reprocessing documents, deleting index content, updating enrichment, changing ACL behavior, raising capacity, or reopening traffic, determine which documents succeeded, what failed deletion, which source is authoritative, whether the index already exposed an answer, whether consuming caches retain it, and whether the operation is idempotent.
Release connectors, schemas, enrichment, ACLs, relevance, capacity, and applications together
A production release includes source and deletion contracts, connector version and schedule, IAM and network path, field schema, custom enrichment, index edition, ACL and user-context model, Query or Retrieve API configuration, filters and relevance, monitoring, capacity, application route, generation model where used, budgets, rollout, and rollback. Before release, reconcile document coverage, run access negatives, evaluate expected results and grounded claims, load-test peak traffic, exercise connector and deletion faults, and canary the complete path.
Onboard through inventory, baselines, controlled failures, and shadow operations
- Inventory: accounts, Regions, indexes, editions, sources, connectors, schedules, schemas, enrichment, ACLs, APIs, applications, capacity, monitoring, cost, and outcomes.
- Responsibility: define supported layers, freshness, deletion, access, relevance, latency and availability SLOs, severity, authority, budget, fallback, AWS escalation, and exclusions.
- Baseline: measure expected and indexed documents, sync and deletion failures, access outcomes, relevance, grounded claims, capacity, latency, usage, cost, and incidents.
- Controls: validate connectors, metadata, enrichment, ACLs, public content, expected results, low-confidence handling, capacity, releases, retries, cost, and rollback.
- Exercise: rehearse incomplete sync, failed deletion, enrichment failure, ACL leak, missing allowed result, relevance regression, throttling, connector outage, unsafe replay, and bad release.
- Transition: operate in shadow, close or accept material gaps, publish runbooks and escalation routes, and accept the steady-state scope.
Start with the Kendra index that already influences employee, customer, financial, support, compliance, or operational decisions. Datrick can define the operating boundary, close material gaps, and transition one representative search or RAG workflow into managed support.
Request a Kendra operations reviewOfficial references and adjacent operating guides
- Amazon Kendra index types and GenAI Enterprise limitations
- Troubleshooting data-source synchronization
- CloudWatch metrics for synchronization and indexed documents
- User-context filtering and access control
- Retrieve API for RAG passages
- Document and query capacity planning
- Amazon Bedrock Knowledge Bases production support
- Amazon OpenSearch Service vector search production support
- Production AI workflow automation and operations
- White-label AI agent managed support for MSPs
Frequently asked questions
What is included in Amazon Kendra production support?
A defined service can include connectors, synchronization and deletion coverage, metadata, custom document enrichment, index type, ACL and user-context filtering, Query and Retrieve API relevance, capacity, CloudWatch, IAM, incidents, releases, cost, runbooks, and reporting.
Can an Amazon Kendra sync succeed while documents are missing?
Yes. AWS documents separate data-source and document-level processing, and a run can be incomplete or appear successful while expected documents are skipped or fail indexing. Reconcile source inventory, sync history, CloudWatch metrics, document reports, indexed counts, deletion outcomes, and sampled queries.
How should Amazon Kendra document access be tested?
Test public, allowed, denied, removed-user, changed-group, missing-ACL, and cross-source cases using the exact index type, connector, identity attributes, user context, filters, and consuming application route used in production. GenAI Enterprise index limitations must be included in the design.
How should Amazon Kendra relevance and capacity be validated?
Use labelled production-like queries with expected passages, confidence and access outcomes. Test Query and Retrieve behavior, filters, boosts, custom enrichment, source freshness, peak concurrency, throttling, adaptive bursting where applicable, latency, downstream grounded answers, and cost together.
How long does Amazon Kendra managed support onboarding take?
A focused onboarding commonly takes two to four weeks for a representative index, connector set, identity path, and consuming search or RAG application. It covers inventory, freshness and deletion baselines, access and relevance tests, capacity, monitoring, incident and release controls, failure exercises, runbooks, and steady-state acceptance.
Operating enterprise knowledge discovery inside Microsoft 365?
Review the Microsoft 365 Copilot connector production support boundary