Amazon Kendra vs Azure AI Search vs Google Enterprise Search

Introduction

The average enterprise employee spends 3.6 hours a day searching for information, according to McKinsey research, often typing “what is our vacation policy” into a system that only understands “paid time off” because that’s the exact phrase in the source document. That’s the problem Amazon Kendra, Azure AI Search, and Google’s enterprise search tools all try to solve, and it’s the latest entry in our Cloud AI Comparison series, there’s a critical fact that changes this comparison entirely: Amazon Kendra closed to new customers on July 30, 2026. It’s not gone, existing deployments keep running with full support, but nobody evaluating enterprise search today can actually start a new Kendra deployment. AWS is directing new projects toward Amazon Bedrock Managed Knowledge Base instead, and the swap isn’t equivalent: Kendra’s 32+ native connectors versus BMKB’s 7 is a real gap, not a rounding error. Layer on top of that the same naming complexity we’ve covered elsewhere in this series, there is no single “Google enterprise search” product anymore, either, and this comparison needs updating from how it would have read even two months ago. This piece covers what’s actually available to evaluate right now, not what used to be.

Quick Comparison Table

What Is Amazon Kendra?

Amazon Kendra was AWS’s managed enterprise search service, using machine learning to enable natural-language search across an organization’s internal content. Rather than matching exact keywords, Kendra returned precise answers with confidence scores and source citations, adapting over time as it learned which results users actually found useful. It connected natively to over 32 data source types, Amazon S3, SharePoint, Salesforce, ServiceNow, MongoDB Atlas, and more, automatically syncing content and access control lists so search results respected existing document permissions.

Here’s the part that matters most for anyone evaluating it today: AWS put Kendra into Maintenance Mode on June 30, 2026, and closed it to new customers on July 30, 2026. Existing deployments keep running with full support, bug fixes, and security updates, but no new features are being built, and no new organization can start a Kendra deployment at all. AWS’s recommended path for new enterprise search and RAG projects is Amazon Bedrock Managed Knowledge Base (BMKB), which reached general availability June 17, 2026. The migration isn’t a like-for-like swap: BMKB currently supports 7 native connectors against Kendra’s 32+, and six Kendra capabilities have no direct BMKB equivalent yet, query suggestions, faceted search, custom synonyms, spell checking, incremental learning, and custom document enrichment. This was part of a larger AWS consolidation announced the same day, which also moved Bedrock Agents to “Agents Classic” (also closed to new customers) and closed Amazon Q Business to new signups.

Best for: Organizations that are already existing Kendra customers, who can continue operating with full support. For anyone evaluating enterprise search fresh today, Kendra isn’t actually an option, the practical AWS-native choice now is Bedrock Managed Knowledge Base, with the connector and feature gaps above factored into that decision.

What Is Azure AI Search?

Azure AI Search, formerly Azure Cognitive Search, is Microsoft’s search-as-a-service offering, built for teams wanting fine-grained control over retrieval behavior. It supports full-text search, boolean queries, fuzzy matching, wildcard queries, autocomplete, geospatial search, and first-class vector search, with hybrid retrieval combining vector similarity, keyword relevance, and semantic ranking in a single query.

Data ultimately needs to reach the index as JSON, and while native Azure sources ingest fairly directly, non-Azure systems typically require Logic Apps or custom ingestion pipelines to get there, more integration work than Kendra’s native connector model, but with a corresponding gain in retrieval flexibility once the data is in. Azure AI Search is commonly paired with Azure OpenAI for RAG applications, and its semantic ranking layer specifically helps surface conceptually relevant results even when the exact query terms don’t appear in the source document.

Best for: Azure-centric organizations that need granular control over hybrid retrieval, combining vector, keyword, and semantic signals, and are willing to invest more integration effort for that flexibility.

What Is Google Enterprise Search?

This is the section where precision matters most, because the honest answer is that “Google enterprise search” isn’t a single product anymore. What used to be called Vertex AI Search was folded into the Gemini Enterprise Agent Platform at Google Cloud Next 2026, the same rebrand covered in more depth in our SageMaker vs Azure Machine Learning vs Vertex AI comparison, and within the platform’s console, it’s now simply labeled “Search,” one tool among several under the “Agents > Build” menu, sitting alongside a separate RAG Engine and a separate Vector Search tool.

That distinction is architecturally real, not cosmetic. Search handles the retrieval layer directly comparable to Kendra or Azure AI Search. RAG Engine is a dedicated tool specifically for building retrieval-augmented generation pipelines, rather than search being retrofitted into that role. Vector Search is available as its own standalone component if you need embedding-based similarity search without the rest of the Search product’s overhead. In practice, this means Google’s approach is more composable than either competitor, you can use Search alone, combine it with RAG Engine for a generative pipeline, or use Vector Search independently, but it also means there’s more architectural decision-making required upfront than picking one managed product off a shelf.

Best for: GCP-native teams building agent-first architectures who want to compose search, RAG, and vector retrieval as separate, purpose-built components rather than one bundled product.

Feature-by-Feature Comparison

Keyword Search

All three handle traditional keyword and full-text search competently. This isn’t the differentiator it once was, every platform here has moved well past simple term matching.

Semantic Search

All three understand query intent beyond exact phrasing. Azure AI Search’s semantic ranking layer is particularly explicit about this as a distinct, configurable stage; Kendra and Google’s Search component both handle it more as an integrated part of the core retrieval model.

Vector Search

Kendra’s GenAI Index, Azure AI Search’s native vector support, and Google’s dedicated Vector Search tool all provide embedding-based similarity search. Google is notable for being available as a fully separate component, useful if vector search is all you actually need, without the broader search product’s overhead.

Hybrid Search

Combining keyword, semantic, and vector signals in one query is where Azure AI Search’s architecture is most explicit and configurable. Kendra and Google’s tools both support hybrid retrieval too, generally with less manual tuning exposed to the developer.

Relevance and Ranking

All three apply machine learning to rank results by actual usefulness, not just term frequency, and all three improve over time based on user interaction signals. None publishes a specific, verifiable accuracy percentage worth repeating as fact.

Data Connectors and Indexing

Kendra’s 14+ native connectors with automatic ACL sync is the most turnkey option for AWS-native data. Azure AI Search requires more manual pipeline work for non-Azure sources. Google’s connector depth is strongest for GCP-native data, particularly BigQuery.

Enterprise Search and RAG Architecture

A production RAG pipeline generally follows: Enterprise Data → Ingestion → Indexing → Embeddings → Retrieval → Context → LLM → Grounded Response. Data gets pulled from source systems, indexed (both for traditional and vector search), converted into embeddings for similarity matching, retrieved based on a user’s query, assembled into context, and passed to an LLM to generate a response grounded in that retrieved material.

Kendra’s legacy GenAI Index and Retriever API were built specifically for the retrieval and context-assembly stages feeding into Bedrock, and that pattern now carries over to Bedrock Managed Knowledge Base for new deployments. Azure AI Search plugs into that same pipeline typically paired with Azure OpenAI. Google’s RAG Engine is a dedicated tool for this exact workflow, separate from its general Search component. Building and maintaining this pipeline reliably is real data engineering work, not just API configuration. Worth stating plainly: none of these eliminates hallucination risk entirely, grounding retrieved context reduces it meaningfully, but a RAG pipeline is only as reliable as the retrieval quality feeding it, and monitoring for cases where the model ignores or misreads retrieved context remains necessary regardless of platform.

Security and Access Control

Enterprise search has to respect existing document permissions, not just find content. Kendra’s automatic ACL sync pulled access controls directly from source systems, so a user searching Kendra never saw results they couldn’t already access in the original repository; the same principle carries over to Bedrock Managed Knowledge Base. Azure AI Search supports access control but requires more explicit per-index configuration. Google’s approach integrates with Gemini Enterprise’s broader governance model. This connects directly to your broader security and compliance posture, not just the search layer in isolation, and if your indexed content includes protected health information specifically, that’s a HIPAA compliant infrastructure question underneath the search product, not something the search layer alone resolves. None of the three should be treated as a substitute for reviewing your actual document permission architecture before deployment, search-layer access control is a real safeguard, not a guarantee against misconfiguration further upstream.

Scalability and Performance

All three are built for enterprise-scale document volumes and query loads. Actual latency and throughput depend heavily on index size, query complexity, and how much of the workload is vector versus keyword retrieval, none of the three publish benchmark numbers specific enough to responsibly repeat as a general claim. Data freshness (how quickly new or updated documents become searchable) also varies by ingestion method, real-time connectors sync faster than scheduled batch jobs, a design choice you make per data source, not a fixed platform limitation. Watching for degradation here over time is the same continuous monitoring discipline that matters for any production system, not a one-time performance check at launch.

Integration and APIs

The general pattern across all three: Application → API → Search Service → Retrieved Context → AI/LLM → Response. All three expose REST APIs and SDKs suitable for web, mobile, and internal application integration. Kendra’s legacy integration pattern with Bedrock now carries over to Bedrock Managed Knowledge Base; Azure AI Search most commonly pairs with Azure OpenAI; Google’s Search, RAG Engine, and Vector Search all connect natively within the Gemini Enterprise Agent Platform’s broader agent-building tools. Wiring this correctly into a real application is AI software development work in its own right, not just a search-service configuration step.

Managed Search vs. Custom Search Architecture

Google’s composable approach (Search + RAG Engine + Vector Search as separate tools) sits architecturally between these two, more assembly required than a single managed product, but each component still handles its own infrastructure, so it’s not a fully custom build either.

Which Platform Is Best for Different Use Cases?

Enterprise knowledge bases: All three fit well; Kendra’s fast deployment and Azure AI Search’s granular relevance tuning are both strong specifically here.

E-commerce and product search: Azure AI Search’s faceted filtering and hybrid ranking are particularly well-suited to product discovery use cases.

Internal employee search: Kendra’s automatic ACL sync and natural-language Q&A are purpose-built for exactly this, finding the right internal document without knowing its exact filename or terminology.

RAG and generative AI: Depends on your model provider, Kendra for Bedrock-based RAG, Azure AI Search for Azure OpenAI-based RAG, Google’s RAG Engine for Gemini-based agent workflows.

AWS-centric organizations: Amazon Bedrock Managed Knowledge Base is the current path, Kendra is no longer available to new customers, though existing Kendra deployments remain fully supported.

Microsoft-centric organizations: Azure AI Search, particularly if already running Azure OpenAI.

Google Cloud organizations: The Search, RAG Engine, and Vector Search components within the Gemini Enterprise Agent Platform.

Cost and Operational Considerations

All three price around usage, documents indexed, query volume, and for RAG-specific features, embedding and retrieval operations. For AWS specifically, the relevant pricing to model now is Bedrock Managed Knowledge Base’s, not Kendra’s, Kendra’s historical pricing is no longer the number a new evaluation should be built around, since new deployments aren’t possible. Azure AI Search and Google’s components both use tiered, consumption-based pricing that requires careful modeling against your actual document and query volume, the same cost forecasting discipline that applies to any consumption-based cloud service, not something search pricing is exempt from. The operational cost most teams underestimate is relevance tuning, none of these platforms delivers perfect results out of the box, and ongoing tuning against real user queries is ongoing engineering work regardless of platform. Verify current pricing directly against each provider’s official pages before budgeting, since rates shift periodically across all three, and in AWS’s case, the entire product you’d be pricing has changed within the last two months.

Pros and Cons

Amazon Kendra

Status: Closed to new customers as of July 30, 2026. The points below apply to existing deployments; anyone evaluating fresh should look at Bedrock Managed Knowledge Base instead. 

Pros (for existing customers): Automatic ACL sync; broad native connector library (32+); mature, well-documented product with years of production use. 

Considerations: No new deployments possible; no further feature development; AWS’s own migration guidance flags a real capability gap versus its recommended replacement.

Azure AI Search

Pros: Most configurable hybrid search architecture of the three; strong semantic ranking layer; mature product with extensive documentation. 

Considerations: Non-Azure data sources require more integration work; more configuration required to get optimal relevance.

Google Enterprise Search (Gemini Enterprise Agent Platform components)

Pros: Genuinely composable, use Search, RAG Engine, or Vector Search independently or together; RAG Engine is purpose-built rather than retrofitted; strong BigQuery integration. 

Considerations: No single bundled product means more upfront architectural decisions; naming and structure changed significantly in 2026, so documentation and third-party comparisons are inconsistent right now.

How to Choose the Right Enterprise Search Platform

1. Which cloud does your primary data and infrastructure already live on?
2. Is fast deployment or fine-grained retrieval control the higher priority?
3. Do you need RAG specifically, or general enterprise search, or both?
4. How complex are your access control requirements?
5. What’s your document volume and expected query volume?
6. Do you need vector search as a standalone capability, or bundled with broader search?
7. How much engineering capacity do you have for ongoing relevance tuning?
8. What’s your realistic budget, modeled against actual usage, not list pricing?

Conclusion

Amazon Kendra closed to new customers on July 30, 2026, which makes this a different comparison than it would have been two months ago, existing Kendra deployments remain fully supported, but any new AWS-native enterprise search evaluation should be built around Bedrock Managed Knowledge Base instead, with its real connector and feature gaps factored in. Azure AI Search remains a directly comparable, actively developed managed product, well-suited to teams needing granular hybrid-retrieval control. And there’s still no single “Google enterprise search” to compare either of them against, Search, RAG Engine, and Vector Search are separate, composable tools within the Gemini Enterprise Agent Platform. Whichever direction fits your infrastructure, model your actual document volume and query patterns against current pricing and current product availability before committing, both changed meaningfully in the last two months, and neither is likely finished changing.

If you’re architecting a RAG or enterprise search system and want a second opinion grounded in real implementation experience, including what the AWS transition actually means for your specific setup, Triotech Systems works across all three clouds. Reach us through our contact page.

Frequently Asked Questions

Is Amazon Kendra still available? 

Not for new customers. AWS put Kendra into Maintenance Mode on June 30, 2026 and closed it to new signups on July 30, 2026. Existing deployments keep full support, bug fixes, and security updates, but no new features are being built. AWS’s recommended path for new projects is Amazon Bedrock Managed Knowledge Base.

What is the difference between Amazon Kendra and Azure AI Search? 

Kendra is a fully managed service optimized for fast deployment and natural-language Q&A with automatic access control. Azure AI Search offers more granular control over hybrid retrieval (keyword, semantic, vector) at the cost of more integration effort, especially for non-Azure data sources.

How does Google enterprise search compare with Amazon Kendra? 

Google doesn’t have a single equivalent product, what was Vertex AI Search is now called “Search” within the Gemini Enterprise Agent Platform, alongside separate RAG Engine and Vector Search tools. This makes Google’s approach more composable but less of a direct one-to-one comparison with Kendra’s single bundled service.

Which enterprise search platform is best for AI applications? 

All three support RAG well, but the natural fit follows your model provider: Kendra for Bedrock, Azure AI Search for Azure OpenAI, and Google’s RAG Engine for Gemini-based agents.

What is the difference between semantic search and vector search? 

Semantic search understands query intent and meaning beyond exact keyword matching. Vector search specifically uses numerical embeddings to find conceptually similar content through mathematical similarity. Hybrid search combines both with traditional keyword matching in one query.

Which enterprise search platform is best for RAG? 

Depends on your LLM provider. Kendra’s GenAI Index and Retriever API integrate directly with Bedrock; Azure AI Search commonly pairs with Azure OpenAI; Google’s RAG Engine is purpose-built for Gemini-based agent workflows specifically.

Can enterprise search work with large language models? 

Yes, that’s the core use case behind RAG architecture, enterprise search retrieves relevant, permission-aware context, which gets passed to an LLM to generate a grounded response rather than relying on the model’s training data alone.

How does enterprise search protect sensitive documents? 

Kendra automatically syncs access control lists from source systems. Azure AI Search and Google’s tools both support access control but require more explicit configuration. None substitutes for reviewing your actual document permission architecture independently.

What is hybrid search? 

Combining keyword matching, semantic understanding, and vector similarity in a single query, so results account for exact terms, conceptual meaning, and mathematical similarity simultaneously rather than relying on just one retrieval method.