AWS 三種無伺服器向量儲存服務比較與實作

Even with the massive context windows of frontier models, vector stores still have their place. I recently needed to make a relatively small collection of private documents searchable within an existing serverless application. I wanted to retain control over that data and retrieve only the relevant document sections. Perfect use case for vector.

Prior to 2026, it was still very expensive to build vector search on AWS, OpenSearch "Serverless" was not serverless at all and required a minimum spend of around $200 per month, even in their "dev-test" mode. @aws, this is not serverless!

Then, in true AWS style, we went from zero serverless vector stores to THREE in the space of a year.

1. OpenSearch Serverless NextGen can now scale to zero.
2. S3 Vectors
3. Vector indexing in DynamoDB

All now are true serverless, scale to zero services. I'm a massive DynamoDB advocate, so the last one is the option I'm most excited about. I've tried all three out, and the TLDR is that actually, it is very hard to look past OpenSearch Serverless NextGen.

This article walks through the differences, the costs, the tradeoffs, and a CDK TypeScript starter project that loads the same document chunks into all three services and tests retrieval.

The end goal:

• Three serverless vector stores, deployed from one project.
• The same embeddings and source data in each store, so we can compare retrieval sensibly.
• Answers with source references, using a small aviation knowledge base.

Introduction

The code for this article can be found here:

👉 GitHub Repository – Serverless Vector Stores

The project demonstrates how to:

• Deploy OpenSearch Serverless NextGen, S3 Vectors and a DynamoDB on-demand table with a native vector index.
• Extract and chunk a PDF, preserving references to the original pages.
• Generate embeddings with Amazon Bedrock and load them into all three stores.
• Retrieve relevant text, tables and chart descriptions.

I'm comparing the technical options here, rather than presenting a formal benchmark. The repo includes tools for measuring retrieval, but in reality, this is more about the feasibility of these vector stores.

The Use Case — An Aviation Knowledge Base

My starting point is an aviation knowledge base: being able to ask a question and find the relevant part of a document, with a reference I can follow back to the source.

For this starter, I've kept things smaller: a nine-page extract from the Public UK Aeronautical Information Publication, covering measurement conventions, altimeter procedures and Heathrow airport information.

There is a useful mix of ordinary text, runway tables and airport charts. For example:

• “Which units are used for runway lengths and altitudes?”
• “What dimensions and surface are published for Heathrow runway 09L/27R?”
• “Where is Terminal 4 relative to the southern runway on the airport chart?”

The last question is particularly useful. Extracting text from a PDF doesn't necessarily preserve the relationship between a terminal, a runway and the rest of the diagram.

I appreciate that nine pages isn't a lot. You could put the whole document into context window if you wanted. The point of this example is the retrieval pattern: finding the right evidence when your application grows to hundreds or thousands of documents, including private material the model hasn't seen.

The current repo prepares one PDF per corpus. A larger document library would need an ingestion workflow around it. The same approach applies to engineering manuals, internal policies, product documentation or customer support material.

Comparing the Three Options

My starting point would be:

• OpenSearch when the application needs a broad search engine, including keyword and hybrid search.
• S3 Vectors when storage cost matters most and queries are relatively infrequent.
• DynamoDB when I want low-latency semantic retrieval alongside application data, particularly data already stored in DynamoDB.

Here's how AWS positions the three services:

Adapted from AWS's vector solutions comparison.

OpenSearch Serverless

OpenSearch is the option I'd look at when semantic similarity is only part of the requirement.

In an aviation document, an exact reference such as EGLL AD 2.12 can matter just as much as the meaning of the surrounding text. Hybrid search lets us combine keyword matching with vector similarity.

The significant recent change is NextGen scale to zero. With both minimum capacity settings at zero, the collection group can pause after ten minutes without requests. AWS documents 10–30 seconds to cold start on first search or indexing request, so the first query after an idle period needs to be considered separately from steady-state latency. See the scale-to-zero behaviour. In my experience, even with this small example, the cold start was around 15 seconds.

For this project, I'm just using vector search with cosine similarity. It doesn't exercise hybrid search.

S3 Vectors

S3 Vectors is appealing when I have a lot of information to retain, but don't need to search every part of it continuously.

You create a vector bucket and index, write embeddings with metadata, and query for similar vectors. There is no search cluster to size. You pay for storage and the operations you perform.

For a large archive of manuals or historical documents, an extra fraction of a second in retrieval may be a perfectly reasonable trade-off. Particularly when generating the final answer takes much longer anyway.

S3 Vectors also supports metadata filtering, including numeric comparisons and logical conditions. That gives us more flexibility than the equality filters currently documented for DynamoDB vector indexes. See S3 Vectors metadata filtering.

DynamoDB Vectors

If you're already using DynamoDB, being able to keep embeddings with your application data is really quite unique. I'm really excited about this possibility, although for the purposes of this test use case, it is not actually relevant.

The project writes ordinary DynamoDB items containing the chunk text, its source information and an embedding. A native vector index handles similarity search through SearchVectors.

The index uses the corpus identifier as its HASH scope, with page and content type declared as inline filters. For a SaaS application, a tenant identifier could serve a similar search-scoping role.

This makes DynamoDB an interesting fit for:

• RAG over existing DynamoDB data.
• Per-tenant semantic search in a SaaS application.
• Agent memory and context retrieval.

How the Example Works

The retrieval pipeline is the same for all three stores:

1. Extract the PDF text, retaining the physical page number.
2. Split it into chunks, using roughly 1,800 characters with a 200-character overlap.
3. Generate embeddings using Titan Text Embeddings V2 through Bedrock.
4. Cache and load the same 1,024-dimensional vectors into each backend.
5. Embed the question and retrieve similar chunks using cosine similarity.

Handling Charts and Tables

For the visual examples, the project renders PDF pages as images and asks Amazon Nova Lite to describe them. Those descriptions are embedded using the same text embedding model.

This is retrieval using image descriptions. The vector stores aren't interpreting the chart themselves.

When generating an answer, the application can also send the original retrieved page images to the model. That lets it inspect the table or diagram directly, although a poor description can still cause the retrieval stage to miss the right page.

Architecture

The project consists of a CDK stack and a local TypeScript CLI. Bedrock provides embeddings. The user interface is through a CLI that interacts directly to each vector store. There is no Bedrock Knowledge Base or frontend in this example.

CDK provisions the OpenSearch collection, the DynamoDB table and its native vector index, the S3 Vectors bucket and index, and an ordinary S3 bucket for page images.

After deployment, init creates or validates the OpenSearch index mapping and validates the existing DynamoDB and S3 vector indexes. For DynamoDB, it also waits for ACTIVE status with backfill complete and confirms that vector search succeeds.

Cost Comparison

The first improvement is that all three options can avoid an idle compute floor in the configurations used here. Storage remains billable. With OpenSearch NextGen, we also need to allow for the ten-minute idle window before compute stops.

The figures below use us-east-1, in USD.

The query charges need a little care. S3's processing calculation uses the logical index size and pricing tiers; non-filterable metadata is excluded. DynamoDB charges for the data its search processes and returns. Those are different calculations, so comparing a headline “price per GB processed” doesn't tell us which query will cost less.

A Simple Storage Example

Assume 10 GB of billable storage in each relevant layer, retained for a full month:

• S3 Vectors: 10 × $0.06 = $0.60 per month.
• DynamoDB Standard: 10 GB in the vector index costs $2.50. If the base table also bills 10 GB at $0.25 per GB-month, that adds $2.50, giving $5.00 per month before requests.
• OpenSearch NextGen: price the stored index, then add the indexing and search capacity consumed while active. A corpus size alone doesn't determine that total.

This illustrates storage rates, not the billed size of identical embeddings in each service. Text, metadata and index representation change the amount stored. If the data already lives in DynamoDB, some base-table cost may already exist; adding embeddings and an index still adds usage.

For a complete monthly example, AWS's S3 pricing page models 10 million vectors split across 40 indexes, one million monthly queries and replacement of one-sixth of the corpus each month. Its estimate is $11.38 for vector storage, PUTs and queries. That is AWS's example, not the bill for this project, and changing how those vectors are split across indexes changes the query calculation.

Overall, the idle storage costs are low, unless your corpus is particularly huge, so it doesn't feel like cost should be the driving factor when selecting the vector store for a use case like this one. Worth noting that the vector store is only part of the cost. This example also uses Bedrock for embeddings and image descriptions. Model charges depend on the model and tokens used; see Bedrock pricing.

Getting Started

Get started by cloning the repo and following the README covering permissions, Bedrock model access and CDK bootstrapping.

Once deployed, use the CLI to interact wih the vector stores.

npm run lab

E.g. embed the content and load all three backends:

npm run lab -- embed --vision
npm run lab -- ingest
npm run lab -- verify

Example Queries

Retrieve the same question from all three stores:

npm run lab -- query \
  --question 'What dimensions and surface are published for Heathrow runway 09L/27R?' \
  --modality text

Or select one backend and generate an answer using a chart:

npm run lab -- query --stores dynamodb \
  --question 'Where is Terminal 4 relative to the southern runway on the Heathrow aerodrome chart?' \
  --modality image --answer --images

Results include the retrieved content and physical page references within the nine-page demo PDF.

Comparing Retrieval

The repo includes a benchmark command if you want to take the comparison further:

npm run lab -- benchmark --rounds 10

It records retrieval latency, errors, recall against an exact local vector search, and whether the expected source pages were found. Query embedding and answer generation sit outside the retrieval timing.

There are two useful questions here: did the store return the nearest vectors, and did those vectors lead us to the right evidence? A good score on the first doesn't automatically answer the second.

A small PDF also won't establish production throughput, so don't read too much into the benchmarks in this example repo.

Which Would I Choose?

Although I started this exercise with a bias towards DynamoDB Vector Indexes, I wouldn’t automatically choose them for every vector workload. My main hesitation is the additional design work. Designing access patterns for DynamoDB can already take some thought, particularly with single-table design, and vector search adds decisions around partitioning, filtering and which data to index. I’d want to be confident those requirements fit comfortably alongside the existing application. The lack of native full-text search also makes DynamoDB less attractive when I need hybrid search combining keyword and semantic results. For me, the strongest appeal is adding semantic retrieval to an existing DynamoDB application where the data is already well structured and managed. Keeping the content and its vectors together is a useful simplification.

For a large document archive with occasional queries, I’d start by looking at S3 Vectors, particularly if storage cost is a priority. The trade-off is retrieval latency, so I’d want to be comfortable that the response times suit the application.

For a new application with broader search requirements, though, OpenSearch Serverless NextGen is difficult to overlook. Its support for keyword, vector and hybrid search makes it a flexible starting point. Provided the cold starts are acceptable, it would probably be my default unless storage economics or data already held elsewhere gave me a reason to choose differently.

Next Steps

This starter provides a foundation for experimenting with serverless retrieval. The next things I'd explore are:

• A larger document library, with versioning and ingestion across multiple PDFs.
• Hybrid retrieval, particularly for exact document references. Natively supported for OpenSearch, but also investigating some form of non-native hybrid retrieval options in the other vector store options.
• Richer relevance tests, including questions the documents cannot answer.
• Tenant authorisation, applied before any retrieval request.

About Me

I'm Ian, an AWS Serverless Specialist, AWS Community Builder and AWS Certified Cloud Architect based in the UK. I work as an independent consultant, having worked across multiple sectors, with a passion for Aviation.

Let's connect on LinkedIn, or find out more about my work at Crockwell Solutions.