How to add AI search to your app on AWS (2026).

IWhat "AI search" means — and the problem it actually solves

AI search is search that understands meaning. Instead of matching the literal words in a query against the literal words in your documents, it compares the <em>semantics</em> of the query to the semantics of each item — so "laptop won't charge" surfaces the "battery and power adapter troubleshooting" page even though they share almost no words.

Traditional search is lexical: it scores documents by how often the query's terms appear (TF-IDF / BM25), optionally with stemming and synonym lists you maintain by hand. It is fast, exact, and explainable — and it fails the moment a user phrases something differently from your content. Search for "remote work policy" when the document says "telecommuting guidelines" and lexical search returns nothing. Semantic search fixes this by comparing meaning instead of words.

The mechanics: offline, you run each document (or product, ticket, FAQ, listing) through an embedding model that converts text into a vector — a list of numbers that encodes meaning, where semantically similar text lands near each other in vector space. You store those vectors in a vector index. At query time, you embed the user's query with the same model and ask the index for the nearest vectors (approximate nearest-neighbour search). The results are ranked by semantic closeness, so synonyms, paraphrases, and intent all match without anyone maintaining a synonym list.

Where this shows up in a product: the search box in a SaaS app, help centre, or docs site; product / catalogue search in e-commerce (find by description, not just title); internal knowledge search across wikis and tickets; recommendations and "more like this"; and as the retrieval layer underneath a chat assistant. The last one is RAG — retrieval-augmented generation — and AI search is the retrieval half of it. This page is about making search itself better; if your goal is specifically a grounded chatbot over your docs, see the dedicated RAG-on-AWS guide.

On AWS, every stage of this maps to a managed service, and there is also a fully-managed end-to-end option (Amazon Kendra) if you would rather buy than build. The next section sets up the decision that determines everything else: keyword vs semantic vs hybrid.

IIKeyword vs semantic vs hybrid search — and why hybrid usually wins

The single most important thing to understand before building is that semantic search is not strictly better than keyword search — it is better at different things. The production answer on almost every real corpus is to run both and fuse the results.

Each mode has a failure shape. Keyword (lexical / BM25) search is exact and unbeatable for precise terms — a part number, a SKU, an error code, a person's name, an acronym — but it returns nothing when the user's words differ from your content's words. Semantic (vector) search is the opposite: it shines on intent, synonyms, and natural-language questions, but it can miss or blur an exact token (it might rank a conceptually-similar product above the exact SKU someone typed) and it can return plausible-but-wrong neighbours. Hybrid search runs both and combines the scores, so exact matches and semantic matches both surface.

The standard way to combine them is Reciprocal Rank Fusion (RRF) — score each result by its rank position in each list and sum, which needs no score-normalisation and is robust across very different scoring scales. The typical pattern: run a BM25 query and a vector query in parallel, fuse with RRF, then (often) re-rank the fused top-N with a cross-encoder for final precision. Amazon OpenSearch supports this hybrid flow natively because it is both a keyword engine and a vector engine in one system.

The practical guidance: start hybrid, do not start pure-vector. Teams that ship pure semantic search are frequently surprised when it cannot find an exact product code that lexical search would have nailed instantly. Hybrid is a small amount of extra wiring for a large, reliable quality gain — and it is the configuration that most often clears a relevance bar that pure-vector alone misses.

IIIThe AI-search reference architecture on AWS, stage by stage

A semantic / hybrid search system runs five logical stages. Two are offline (indexing), three are at query time. Almost every relevance problem traces back to a specific stage, so it pays to know each one before you build.

It helps to split the stages into an indexing phase (embed → index) that runs whenever your content changes, and a query phase (query → re-rank → optionally generate) that runs on every search. The table below maps each stage to the AWS service that typically implements it. Note that if you choose Amazon Kendra, it collapses all five stages behind a single managed API — that build-vs-buy choice is section VII.

IVStep-by-step: adding semantic + hybrid search to your app

Here is the fastest credible path from a keyword-only search box to AI-powered hybrid search on AWS, using Bedrock embeddings and OpenSearch Serverless. Each step maps to a stage above; the order matters because every step depends on the one before it being clean.

• Step 1 — Get clean, searchable records — Pull the items you want searchable (rows from a database, articles from a CMS, products from a catalogue) into a normalised form: an id, the text to embed (title + body, or title + description), and the metadata to filter/return (category, price, tags, tenant, ACL, updated-at). For long documents, chunk them (300–800 tokens, ~10–20% overlap) so each vector is one coherent passage.
• Step 2 — Enable Bedrock model access — In the Bedrock console, request access in your Region to an embedding model (Titan Text Embeddings v2 or Cohere Embed) and — only if you plan an answer box — a generation model (Claude, Nova, Llama, or Mistral). Pick your Region for data-residency and latency reasons up front.
• Step 3 — Embed and index — Call the Bedrock embeddings API for each record and write the vector + text + metadata into an OpenSearch Serverless collection configured for vector (k-NN) search with an HNSW index. Backfill the whole corpus once, then index new/changed records going forward. Store the embedding model + dimension in your index config so future-you knows what produced these vectors.
• Step 4 — Wire the query path (start hybrid) — On each search: embed the query, run a k-NN vector query and a BM25 keyword query against OpenSearch, and fuse them with Reciprocal Rank Fusion. Apply metadata filters in the query (in-stock, tenant, category) so filtering happens before ranking, not after. Return a candidate top-K of 20–100.
• Step 5 — Add re-ranking for precision — Pass the fused top-K to Amazon Rerank or Cohere Rerank on Bedrock, keep the best 5–10, and return those to the UI. This is the single biggest quality jump for the top results users actually click. Skip re-ranking on trivial exact-match queries to save cost and latency.
• Step 6 — (Optional) add a generated answer box — If you want an answer above the list, send the re-ranked results to a Bedrock generation model with a strict "answer only from these results and cite them" prompt, attach a Bedrock Guardrail, and render the answer with citations. This turns search into search-plus-RAG.
• Step 7 — Measure relevance and tune — Build a labelled query set (real queries + which results should rank highly) and track relevance metrics (nDCG, recall@K, MRR) on every change so you can tell whether a new chunk size, embedding model, or fusion weight actually helped. Tuning blind is the most common reason AI-search projects stall. Section VI covers the metrics and the knobs.

VVector index options on AWS — OpenSearch, Aurora pgvector, Kendra

The vector index holds your embeddings and answers nearest-neighbour queries. For an in-app search feature the three relevant AWS options are OpenSearch Serverless, Aurora PostgreSQL with pgvector, and — at the fully-managed end — Amazon Kendra, which is an index and a search engine in one.

Amazon OpenSearch Serverless is the default for building search on AWS, and the natural choice for AI search specifically because it is both a vector engine (k-NN) and a mature keyword engine (BM25) in one system — so native hybrid search and Reciprocal Rank Fusion work out of the box, plus faceting, filtering, and aggregations you already expect from a search backend. It is fully managed and auto-scales; the trade is that it bills by OpenSearch Compute Units (OCUs) with a baseline minimum, so it can feel expensive for a very small index even when idle.

Aurora PostgreSQL with the pgvector extension is the pragmatic choice when your app already runs on Postgres. Your vectors live next to your relational data, so you can combine a vector search with SQL WHERE filters and joins to business tables in a single query — ideal for product search where you must filter by price, stock, and category. With HNSW indexing it scales comfortably into the millions of vectors. Native keyword search is weaker than OpenSearch's (Postgres full-text plus pgvector is workable hybrid, but not as turnkey), and at very high query concurrency a purpose-built engine pulls ahead.

Amazon Kendra is a different animal: a fully-managed intelligent-search service, not just an index. It ingests from 40+ connectors (S3, SharePoint, Confluence, Salesforce, databases, web crawl), builds and tunes its own semantic ranking, supports natural-language queries and FAQ matching, and enforces document-level access control by reading source-system ACLs — all without you running an embedding pipeline or a vector store. You trade per-engine control and granular cost tuning for speed-to-launch and far less to operate. The full build-vs-buy comparison is in section VII.

Two more AWS-native vector options exist and are worth knowing for adjacent needs: Amazon MemoryDB / Redis (in-memory, single-digit-millisecond vector queries) when latency is the hard constraint, and the newer S3 Vectors capability for very large, cost-optimised vector sets with infrequent queries. For an in-product search feature, though, the decision is almost always among the three in the table below.

VIEmbeddings, re-ranking, and relevance tuning — where search quality is won

Whether AI search feels magic or mediocre comes down to retrieval quality, not the fanciness of any single component. Four knobs dominate: the embedding model, chunking, hybrid fusion, and re-ranking — and you tune all four against a labelled query set, not by feel.

VIIBuild it yourself vs Amazon Kendra — the central decision

Before choosing an embedding model or a vector store, decide whether to build the pipeline at all. Amazon Kendra is AWS's fully-managed intelligent-search service; building on Bedrock + OpenSearch is the DIY path. This one choice sets how much you build, how much you control, and how fast you ship.

The honest framing: Kendra if you want managed search with connectors and access control fast; build if you need control, custom ranking, or the lowest per-query cost at scale. Kendra is a search service — it crawls 40+ data sources, builds and tunes its own semantic ranking, answers natural-language queries, matches FAQs, and (critically for enterprise) reads source-system ACLs so each user only sees what they are permitted to, with no embedding pipeline or vector store to run. The trade is less granular control over ranking and embeddings, and a pricing model that is a fixed index baseline plus queries rather than something you tune stage by stage.

Building on Bedrock + OpenSearch Serverless gives you the opposite: full control of the embedding model, chunking, hybrid fusion weights, re-ranking, and exactly what you index — and typically a lower marginal cost per query at high volume because you are paying for tokens and OCUs rather than a managed-search premium. You own the connectors (you write the ingestion), the access-control logic (metadata filters you design), and the maintenance. For a custom in-product search box with bespoke relevance rules, or a very high-QPS workload where per-query cost dominates, building usually wins. For "make our internal wiki and Confluence and SharePoint searchable, with permissions, by next month," Kendra usually wins.

A common pattern is to prototype on Kendra to prove the use case and get a strong baseline in days, then migrate to a built pipeline only if a concrete requirement — custom ranking, a vector store you already run, or cost at scale — forces it. Many teams never need to: Kendra is enough. Others start built because search relevance is their product and they want every knob. The comparison table makes the trade explicit.

VIIIProduction concerns and the AI-search cost stack

A search demo and a production search feature differ on freshness, access control, latency, and a bill that scales with usage. Each has a concrete AWS answer, and the cost stack has predictable line items that surprise teams who budgeted only for embeddings.

On freshness, your index is only as current as your last sync: trigger re-embedding on a data-change event (an S3 event or DB CDC stream via Lambda, or a scheduled job) and store an updated-at in each record so stale items can be filtered or down-weighted. On access control, enforce it in the query — tag each record with ACL / tenant metadata at index time and apply a filter on every search so a user only ever retrieves what they are entitled to; for multi-tenant SaaS, filter by tenant at minimum, or use separate indexes for hard isolation. (Kendra does this for you by reading source ACLs.) On latency, end-to-end time is query + re-rank + optional generation; cache query embeddings for repeated searches, keep re-ranking to a sensible top-N, and stream any generated answer so perceived latency stays low.

The cost figures below are representative as of 2026 to show the shape of the bill — always check the AWS pricing page (and the third-party vendor for any non-AWS component) for current rates. For pure semantic/hybrid search the dominant cost is the always-on index baseline (OpenSearch OCUs or the Kendra index edition); embeddings are a one-time-per-corpus cost plus updates; per-query embedding and re-ranking are small; and generation only appears if you added an answer box — at which point generation tokens usually become the largest line.