S3 Vectors Pricing: Why Query Costs Track Whole Index Size

Amazon S3 Vectors arrived as a cheap way to store embeddings. A closer look at its pricing shows a more conditional bargain. The service bills each query against the size of the entire index it searches, not against the handful of results it returns. That one design choice decides whether S3 Vectors is the cheapest option in a stack or a bill that keeps climbing.

What AWS shipped

AWS made S3 Vectors generally available after a preview that began in July. The company describes it as the first cloud object store with native support for storing and querying vector data 3. The headline claim is a cost reduction of up to 90% compared with specialized vector databases 3. Adoption during the preview was substantial. AWS says customers created more than 250,000 vector indexes, ingested over 40 billion vectors and ran more than a billion queries in roughly four months 3.

The GA release also raised the scale ceiling. The per-index limit grew from 50 million vectors in preview to 2 billion, and a single vector bucket can now hold up to 20 trillion vectors 3. AWS frames this as a way to put a whole dataset in one index instead of sharding and federating queries across many smaller ones 3. Independent coverage gives the same 2 billion figure and calls it a 40x increase 2. AWS's own summary text says "up to 1 billion vectors per index," which conflicts with the 2 billion figure in the body of its announcement 3. AWS also cites query latencies around 100 milliseconds 3.

How the billing works

The main difference from conventional vector databases is how charges are structured. S3 Vectors has four meters [2]:

• storage per logical GB-month
• a per-GB charge on writes
• a per-million fee on query API calls
• a per-terabyte fee on query data processed

The last meter matters most. Pinecone's comparison describes S3 Vectors as charging per query based on the size of the index being queried 1. Each search therefore costs more as the corpus grows, whether or not more results come back.

The other half of the model is very attractive. Nothing is provisioned, storage is billed at object-storage rates, and an idle index costs nothing beyond that storage 1. Darryl Ruggles' cost analysis describes the model as charging "almost nothing when you don't query" and then rising sharply with both query count and index size 2. He calls it one of the most workload-sensitive pricing models AWS has released in years 2.

Where the sources agree, and where they don't

On the core point, the vendor-neutral analysis and the competitor's analysis agree. S3 Vectors is very cheap for large, rarely queried data and less compelling as query volume rises 12. Ruggles notes that AWS's 90% figure is not false. He argues that the actual savings depend heavily on the workload 2.

The sources disagree on what to use instead. Pinecone, which has an obvious commercial interest, argues it wins once queries are sustained 1. Its Dedicated Read Nodes convert read costs into a flat monthly rate for provisioned capacity, while S3 Vectors keeps pricing each query against the full index 1. Pinecone still concedes that S3 Vectors is the better choice for a big corpus queried infrequently, where paying nothing while idle outweighs per-query cost 1.

Ruggles' comparison is broader. It covers OpenSearch and pgvector as well as Pinecone 2. One notable detail is that the newer OpenSearch Serverless tier can also scale to zero. It bills OCU-hours only while warm and goes idle after a 10-minute timeout 2. The cost is a cold start of 10 to 30 seconds on the first query after idling, and he measured about 15 seconds at 50,000 vectors 2. So scale-to-zero is no longer unique to S3 Vectors, but the alternatives come with their own latency penalty.

The reading

S3 Vectors is best understood as a cold or warm storage tier with search built in, not as a direct replacement for a query-optimized vector database. Suitable workloads include archives, compliance data, long-tail retrieval corpora and batch jobs that search a huge index occasionally. For these, the idle-cost advantage is real and probably large.

The risk is the consolidation AWS is promoting. Putting everything into one 2-billion-vector index removes sharding complexity 3. Under a model where query cost tracks index size, it may also make every query as expensive as possible. Teams that shard by tenant, date or domain could end up paying less per search than teams that follow the single-index pitch.

The practical advice is to estimate actual query rates and index sizes before relying on the 90% figure. Below some query volume, S3 Vectors is hard to beat. Above it, flat-rate provisioned capacity or a warm database starts to win. The crossover point depends on the specific workload, and none of these analyses can calculate it for you.