Existe um custo que quase ninguém prevê no primeiro projeto de RAG. A aplicação começa pequena, com alguns milhares de documentos vetorizados em um índice do OpenSearch ou em um banco vetorial dedicado. Funciona. Aí a base cresce para milhões de embeddings, o time descobre que precisa versionar o corpus, e a fatura mensal do banco vetorial passa a competir com o custo do próprio modelo. Quando alguém finalmente calcula o custo por vetor armazenado, a resposta é sempre a mesma: caro demais para uma base que a maior parte do tempo fica parada esperando alguém perguntar alguma coisa.
O Amazon S3 Vectors é a resposta da AWS para esse problema. Anunciado em preview em julho de 2025 e disponível em GA desde novembro do mesmo ano, é o primeiro cloud object storage com suporte nativo para armazenar e consultar vetores, com a promessa de reduzir em até 90% o custo total de armazenamento e consulta em relação a bancos vetoriais especializados.
O que é o S3 Vectors
Do ponto de vista de API, o S3 Vectors introduz um novo tipo de bucket no S3, otimizado para armazenamento durável e barato de vetores, com um conjunto próprio de APIs para armazenar, acessar e consultar embeddings. Você não provisiona servidor, cluster ou nó de indexação: cria um vector bucket, dentro dele um ou mais vector indexes com uma dimensão fixa (por exemplo 1536 para embeddings do Amazon Titan V2), e passa a fazer PUT e QUERY diretamente contra a API.
O modelo mental é o mesmo do S3 tradicional: escalabilidade elástica, durabilidade de 11 noves, cobrança por uso. A diferença é que, em vez de armazenar objetos genéricos, o bucket entende que aqueles floats são vetores e sabe fazer busca por similaridade sobre eles com performance de sub-segundo.
Na versão GA, um único índice suporta até 2 bilhões de vetores e um bucket até 20 trilhões, um aumento de 40x em relação ao limite do preview. Consultas frequentes retornam em torno de 100ms e você pode recuperar até 100 resultados por query, o que é adequado para RAG e para fluxos de agentes que dependem de contexto amplo.
O modelo de custo que muda a matemática
O que faz o S3 Vectors ser interessante não é performance de ponta. Um cluster de OpenSearch bem dimensionado, ou um Pinecone dedicado, entrega latência mais baixa. O ponto é o custo por vetor armazenado quando o padrão de acesso é intermitente.
Bancos vetoriais especializados são otimizados para serem consultados o tempo todo. Isso significa manter memória quente, réplicas ativas e capacidade reservada, mesmo para vetores que quase nunca são acessados. Em cargas de RAG corporativo típicas, uma pequena fração do corpus responde pela maioria das consultas. O restante fica parado, ocupando RAM cara.
O S3 Vectors inverte essa lógica. Como está construído sobre a mesma infraestrutura elástica do S3, o preço acompanha o volume real de dados armazenados, não a capacidade provisionada para servi-los. Para bases grandes com padrão de acesso irregular, isso resulta na redução de até 90% que a AWS comunica.
Integrações que fazem o serviço fazer sentido
Duas integrações passaram para GA junto com o serviço:
Bedrock Knowledge Bases: você pode escolher S3 Vectors como storage engine para Knowledge Bases, o que permite construir aplicações de RAG em escala de produção sem gerenciar cluster nenhum. A ingestão de documentos, geração de embeddings e vetorização passam a ser um pipeline serverless de ponta a ponta.
Amazon OpenSearch Service: a integração permite usar o S3 Vectors como camada de armazenamento barata para vetores raramente consultados, mantendo o OpenSearch para os índices quentes. É uma extensão natural do padrão hot/warm/cold que já é comum em análise de logs, agora aplicada a embeddings. Vetores infrequentes ficam em S3 Vectors, e quando a demanda aumenta, você move para o OpenSearch para consultas mais rápidas e capacidades avançadas de busca híbrida.
Ambas as integrações reforçam o mesmo posicionamento: o S3 Vectors não pretende substituir bancos vetoriais especializados. Ele pretende ser a camada onde vetores vivem por padrão, e você promove seletivamente o que precisa de performance extrema.
Casos de uso principais
Três padrões concentram a maioria das adoções que apareceram em quatro meses de preview (mais de 250 mil índices criados e 40 bilhões de vetores ingeridos, segundo a AWS):
RAG corporativo em larga escala: bases de conhecimento internas com milhões de documentos onde a maior parte do corpus é raramente acessada. Encaixe natural com Bedrock Knowledge Bases.
Busca semântica sobre acervos grandes: catálogos de mídia, arquivos de vídeo em escala de petabytes, bibliotecas de imagens médicas. Casos onde você precisa achar “cenas parecidas” ou “documentos relacionados” sobre um volume que seria proibitivo manter em memória.
Memória de longo prazo para agentes: agentes de IA que precisam lembrar interações passadas geram muitos embeddings, mas raramente consultam interações antigas. É um padrão de acesso irregular clássico, exatamente onde o S3 Vectors brilha.
Limitações e trade-offs
O serviço faz escolhas conscientes que precisam ser entendidas antes de decidir:
- Latência de queries frequentes gira em torno de 100ms. Para chatbots interativos isso é suficiente, mas aplicações que precisam de sub-10ms consistentes vão precisar de um banco vetorial em memória.
- Busca híbrida avançada (combinação de similaridade vetorial com filtros lexicais complexos, boosting, rerankers integrados) é território do OpenSearch, não do S3 Vectors. Se o produto precisa disso, a arquitetura provavelmente vira S3 Vectors + OpenSearch, não S3 Vectors sozinho.
- Cada índice tem dimensão fixa. Trocar de modelo de embedding (por exemplo migrar de 768 para 1536 dimensões) implica reindexar em um novo índice.
Quando o S3 Vectors faz sentido
Faz sentido quando:
- Você já tem uma base de embeddings em produção e o custo do banco vetorial começou a incomodar mais que a latência.
- O padrão de acesso é irregular, com uma parte pequena do corpus concentrando as consultas.
- A aplicação já vive no ecossistema AWS e a integração com Bedrock Knowledge Bases elimina pipeline customizado.
- Você está construindo RAG desde o início e quer começar sem cluster para gerenciar.
Pode ser excessivo quando:
- A aplicação exige latência consistentemente abaixo de 50ms para todas as consultas.
- O caso de uso depende de recursos avançados de busca híbrida ou de plugins específicos do OpenSearch.
- O volume de vetores é pequeno e um índice em memória em uma instância modesta já resolve com custo baixo.
Conclusão
O S3 Vectors é uma dessas primitivas que só aparecem depois que o padrão de uso fica claro no mercado. Depois de dois anos observando empresas gastando com bancos vetoriais superdimensionados para bases que ficam ociosas, a AWS ofereceu a resposta óbvia: colocar os vetores no mesmo lugar onde o resto dos dados já vive, com o mesmo modelo econômico. Para arquiteturas de RAG e agentes que operam em escala corporativa, essa mudança altera a matemática do projeto na fase de planejamento, não só na hora de otimizar. Se o próximo projeto de IA generativa do time envolve mais de alguns milhões de embeddings, o S3 Vectors deveria estar na primeira página do desenho, não como otimização futura.
