# Amazon S3 Vectors: similarity search without a dedicated database
Table of Contents
When you search an archive, you usually search for exact words: type “invoice” and you get the documents that contain the word “invoice”, not the ones that talk about a “receipt” or a “payment note”. Applications built on artificial intelligence need a different kind of search: finding content that is similar in meaning, even when the words differ. Doing that requires a way of storing and comparing data called a vector database. On 2 December 2025, at the re:Invent conference, AWS made Amazon S3 Vectors generally available - meaning it left the restricted preview and opened to everyone - bringing this capability into S3, its most widely used storage service.
What vectors are and why they matter
To make sense of the announcement, start with vectors, or embeddings. An embedding is a list of numbers that represents the meaning of a piece of content: a sentence, a document, an image. It’s produced by an AI model that turns text or an image into a long sequence of figures. The core idea is simple: two pieces of content that are similar in meaning produce “nearby” vectors, while two pieces about different things produce “distant” ones. Nearness is measured with a geometric calculation, like the distance between two points.
With this trick, searching becomes a different operation. Instead of comparing words, you compare numbers: you take the user’s question, turn it into its vector, and look for the closest vectors in the archive. The result is semantic search, that is, search by meaning. Someone asking “how do I protect the server from unauthorised access” can get a document titled “SSH hardening”, even though it contains none of the words they typed.
The link to AI: RAG
This mechanism is at the heart of a technique widely used with language models, RAG (Retrieval Augmented Generation). A model like the ones behind conversational assistants knows a lot in general, but it doesn’t know a company’s internal documents or information that’s current as of yesterday. RAG fills that gap: before answering, the system searches its own archives for the passages most relevant to the question - using exactly this similarity search over vectors - and passes them to the model as context. That way the answer rests on real, checkable documents, not only on what the model learned during training.
To do all this you need two things: somewhere to store the vectors, and a fast way to find the ones closest to a reference vector. That’s the job of a vector database. Until recently it meant adopting specialised software to install and maintain, or a separate dedicated service, with a cost that grows along with the number of vectors.
What changes by putting vectors inside S3
Amazon S3 is AWS’s object storage: a place to drop files of every kind - images, backups, logs, documents - paying little for large amounts of space. It’s one of the most common building blocks of cloud infrastructure, the same service that also manages server-side encryption settings. The idea behind S3 Vectors is to add to that storage the ability to hold vectors and search them by similarity, without a separate database alongside it.
In practice you create a vector bucket, a container similar to an ordinary S3 bucket but designed for vectors, and inside it one or more vector indexes. When you create an index you declare a few things: the dimension of the vectors, that is, how many numbers each one contains, and the distance metric used to measure nearness, which can be cosine or euclidean. Each vector can carry metadata - extra information such as the date or the source of the document, handy for filtering results: up to 50 metadata keys per vector.
The service is serverless, much like other AWS serverless databases. “Serverless” doesn’t mean there are no servers; it means the people using the service don’t have to choose, size or update them: AWS handles that. There’s no cluster to keep running and pay for by the hour: you pay for the space the vectors take up and for the write and query operations actually performed.
The benefit AWS puts front and centre is cost. The official estimate is a reduction of up to 90% in the total cost to upload, store and query vectors compared with dedicated vector database solutions. That’s a figure stated by the provider, and, as always, the real saving depends on how the service is used; but it signals the direction: making similarity search an affordable option even for very large archives.
How far it scales, and its limits
General availability arrives with higher numbers than the preview. Each index can hold up to 2 billion vectors, forty times the preview limit of 50 million, and each vector bucket can host up to 10,000 indexes. These figures move the service from demo territory to production use over large document collections.
On response times, AWS states that infrequent queries return a result in under a second, while frequent ones drop to around 100 milliseconds or less. Each query can return up to 100 results (it was 30 in preview), and writes reach up to 1,000 vectors per second when updating indexes one vector at a time.
It’s worth being honest about the trade-off. S3 Vectors is built to be cheap and to hold enormous volumes, not to be the fastest option outright: a hundred milliseconds is fine for a document archive, less so for scenarios that need answers in a few milliseconds under heavy traffic. Tellingly, AWS also presents it paired with OpenSearch, its search engine: you can keep the rarely used, cheaper vectors in S3 Vectors and move only the ones that need top performance over to OpenSearch.
The integrations
General availability also stabilises some useful integrations. S3 Vectors connects to Amazon Bedrock Knowledge Bases, the service AWS uses to build RAG applications: you can use S3 Vectors as the vector store to lower the cost of an assistant that answers by drawing on a document base. The integration with Amazon OpenSearch is available too, for the two-tier architecture described above. There’s also support for CloudFormation, to create resources automatically and repeatably, PrivateLink for private-network connectivity, a dedicated encryption key per individual index, and tags for access control and cost allocation.
As of the announcement the service is live in 14 AWS Regions, up from 5 in preview, including Ireland, London, Paris, Frankfurt and Stockholm in Europe.
Where it fits
S3 Vectors is a good option when there are many vectors, queries aren’t constant, and cost matters more than minimal latency: documentation archives, knowledge bases for internal assistants, semantic search over catalogues. In these cases it avoids installing, updating and paying for a separate vector database, and keeps the vectors close to data that is often already on S3.
The opposite reasoning holds just as well. If an application needs answers in the order of a few milliseconds over a steady stream of requests, or advanced features offered by a specialised engine, a dedicated vector database - or the pairing with OpenSearch - remains the better fit. As always, the choice depends on concrete requirements of volume, frequency and speed, not on the novelty itself.
