官方更新 AWS ML Blog Thu, 20 Aug 2026 正文 ok 2926 words

AWS 向量解决方案:在数据所在之处构建 Agentic AI

英文标题:AWS vector solutions: Build agentic AI where your data lives

AWS 提供可直接集成到现有数据库、对象存储和搜索服务中的向量搜索能力,无需部署独立向量数据库或迁移数据。文章建议优先在数据原有位置添加向量能力;对于没有既有数据存储的新工作负载,则根据延迟、成本和访问模式选择合适引擎,并默认推荐 Amazon OpenSearch Service 以平衡搜索、扩展性和 Agentic AI 集成。文中介绍了 OpenSearch Service、Amazon S3 Vectors、Amazon DynamoDB 和 Amazon ElastiCache for Valkey 等服务的定位、性能与成本特点。对开发者而言,这意味着可以利用熟悉的 AWS API 和数据基础设施构建 RAG、语义搜索、长期记忆、推荐和多模态检索等 AI 应用。
打开原文相关 2.7 · 机会 1
media1.3 MB media101.1 KB media124.1 KB media345.0 KB media141.2 KB media346.5 KB media197.7 KB media210.0 KB media31.2 KB media10.1 KB media22.2 KB media263.6 KB

中文

Agentic AI 正在改变你的工作方式,而向量搜索为检索层提供支撑,使 Agent 能够准确、具备上下文,并基于真实数据开展工作。Agent 会在多步骤工作流中进行规划、推理和采取行动,因此,快速访问组织知识中相关信息至关重要。

这些知识已经分布在数据库、对象存储、搜索引擎,以及 PDF、录制的视频会议和团队日常使用的系统等非结构化来源中。AWS 向量解决方案可在数据原有位置为其提供智能搜索和检索能力,帮助 Agent 找到并使用恰当的上下文,无需移动或复制数据。

对于尚未适用现有数据存储的新工作负载,我们针对六项专门构建的解决方案提供了清晰的决策模型,帮助你为 Agentic AI 和分析工作负载选择合适的向量解决方案。

为什么向量很重要,以及 Agentic AI 的主要使用场景

向量是 AI 的语言。它们连接了前沿模型与组织数十年来积累、分散存放的知识。通过将数据表示为高维向量,应用程序能够理解语义含义、识别文本、图像、音频和视频之间的关系,并在会话之间维持上下文。无论处理的是产品描述、安全日志还是媒体库,向量都会将所有内容转换到共享的数学空间中,从而支持跨模态比较和搜索。

与前沿 AI 模型结合后,向量构成了智能化、上下文感知、个性化和面向特定用户体验的基础:

  • 检索增强生成(RAG)和知识库会利用运行时检索到的可信数据为前沿模型响应提供依据,从而提升准确性、减少幻觉,并生成与组织知识一致的回答。
  • 语义搜索依据含义和意图而非精确关键词匹配来检索信息,即使使用了不同术语,用户也能发现相关内容。
  • 混合搜索将词法搜索与语义搜索结合,在结构化和非结构化数据中提供全面的结果。
  • GraphRAG 将语义搜索与知识图谱相结合,为需要多步骤推理的企业场景提供准确、上下文丰富且可追溯的回答。
  • 知识图谱通过显式关系连接人员、产品、文档和概念等实体,支持更智能的搜索、发现和 AI 驱动推理。

借助上一节概述的选项,向量可支持多种使用场景,包括:

  • 实时推荐系统通过零售、媒体和娱乐领域的向量相似性,识别符合用户兴趣的产品、内容或体验,实现个性化推荐。
  • 异常和欺诈检测识别高维数据中的异常模式,有助于更早发现威胁、网络安全问题或设备故障。
  • 多模态内容发现基于语义含义而非文件类型或元数据,使用单一查询跨文本、图像、音频和视频进行搜索。

好消息是,大多数此类使用场景并不需要新数据库。借助 AWS,你可以在数据原本所在的位置获得向量能力,使用你已经熟悉和正在使用的服务及数据库,无需迁移数据。

下图展示了 AWS 向量能力的广度,以及 Agentic AI 的主要使用场景。

AWS 在六项专门构建服务中的广泛向量能力及主要 Agentic AI 使用场景

图 1:适用于 Agentic AI 使用场景的 AWS 向量能力广度

第一原则:在数据原有位置添加向量

这是指导我们整个方法的原则。如果你已经拥有 AWS 数据存储,就应向该数据存储添加向量搜索。除非存在充分理由,否则不要引入新服务。向量与源数据保存在一起,消除了跨服务跳转,并可将向量搜索与原生查询功能结合。

使用现有数据存储时,你无需学习新的编程工具、API、SDK 等。你还可以确信,现有数据存储已经满足你的要求。例如,已在生产环境中证明具备可扩展性、可用性和性能的数据库,在增加向量搜索后仍将持续提供这些能力。最后,当向量与数据存储在同一位置时,应用程序运行更快,无需担心数据同步或数据移动。基于已经完成的投入构建,也能实现成本节约。

如果你的数据已位于 Amazon OpenSearch Service、Amazon Simple Storage Service(Amazon S3)、Amazon Aurora PostgreSQL、Amazon DynamoDB、Amazon ElastiCache for Valkey 或 Amazon Neptune 中,请直接在数据所在位置添加向量。正确的向量搜索解决方案应当追随数据,而非反过来。

对于新工作负载,应确定最主要的需求:延迟、成本或访问模式,并选择针对该需求优化的引擎。许多工作负载需要在搜索能力、规模和 Agentic AI 集成之间取得平衡。对于这些工作负载,默认选择 Amazon OpenSearch Service。它在一个系统中结合了词法搜索、向量搜索、混合搜索和 Agentic 搜索,并以大规模高吞吐、低延迟提供相关结果。

以下决策模型可帮助你根据工作负载要求选择合适的向量解决方案。

根据延迟、成本和访问模式选择 AWS 向量引擎的决策模型

图 2:向量引擎决策模型

Amazon OpenSearch Service:新工作负载的默认选择

Amazon OpenSearch Service 是一款托管检索引擎,可在单一系统中结合词法搜索、向量搜索和混合搜索,以高吞吐、低延迟在大规模场景中提供相关结果。它支持多种索引策略、向量量化和元数据过滤,可从简单的 RAG 应用扩展至高级多信号检索。由机器学习(ML)驱动的自动优化能够自动选择合适配置,省去手动调优。GPU 加速可将海量数据集的索引速度提升至最高 10 倍,成本降至四分之一;UltraWarm 和 Writable Warm 层则可降低低频访问数据的存储成本。

应将 OpenSearch Service 作为新工作负载的默认选择,因为多数新工作负载并不存在单一主导需求。它们需要在搜索、规模和 Agentic AI 集成之间实现平衡。OpenSearch Service 在延迟、向量规模、每秒查询数(QPS)、成本效率、混合搜索和易用性方面提供了最强的灵活性。它覆盖最广泛的使用场景,包括 RAG、异常检测、多模态内容发现,以及任何需要混合搜索的工作负载。它支持数十亿级向量规模,可处理数千 QPS,并服务超过 10 万月活客户,每月处理超过 10 万亿次请求。

新一代 Amazon OpenSearch Serverless 面向 Agentic AI 和动态工作负载构建。其自动扩缩容速度比上一代快 20 倍,可在数秒内完成资源配置,并可从零扩展到每秒数千次请求。空闲时,它也可以缩减至零;与为峰值容量预置资源相比,最高可节省 60% 成本。你只需为已使用的容量付费;如果 Agent 没有运行,则无需付费。

Adobe 采用 OpenSearch Service 扩展其 Acrobat AI Assistant,为数亿用户提供服务。这是一款直接集成到 Adobe 文档生态系统中的对话式生成式 AI 引擎。

Amazon S3 Vectors:任意规模下成本优化的向量存储

Amazon S3 Vectors 是 Amazon S3 的一项功能,也是首个原生支持大规模存储和查询向量的云对象存储。它将 S3 的成本结构、规模和简洁性引入向量存储,相比专用向量数据库,向量上传、存储和查询成本最高可降低 90%。这使得用户能够以经济高效的方式构建和维护十亿级向量索引,增强 AI Agent 的记忆、上下文和对 Amazon S3 所存内容的语义搜索能力,同时无需管理任何基础设施。

自 S3 Vectors 正式可用以来,客户平均每天执行数千万次查询,较预览期增长超过 5 倍。两项近期增强改进了查询体验和定价。首先,S3 Vectors 现支持_每次查询最多 10,000 条搜索结果,增加了 100 倍;这对于采用重排序、聚合或去重来生成更相关结果集的多阶段检索管道尤其有价值。其次,拥有超过 1,000 万个向量的向量索引,其查询费用现已最高降低 80%_,显著降低了在大规模 AI、RAG 和语义搜索工作负载中运行相似性搜索的成本。

当你需要成本高效的向量存储、简单的向量搜索和元数据过滤,并且针对大型向量数据集进行低频查询时,应选择 Amazon S3 Vectors。它适用于可接受约 100 ms 或更高延迟的场景,或处于快速增长阶段、QPS 适中的向量数据集。每个向量索引最多支持 20 亿个向量,并采用按查询付费的定价模式:你为存储的向量付费,查询成本仅在实际搜索时产生。常见使用场景包括数据湖上的语义搜索、基于 RAG 的知识检索、大规模向量存储和批量检索。客户还可以通过 S3 API 直接操作向量和索引。

BMW Group 将 S3 Vectors 用作其混合搜索解决方案的构建模块;该方案由使用 Amazon Bedrock AgentCore 构建的智能搜索 Agent 驱动。工程师可使用自然语言查询 20 PB 数据,结合 S3 Vectors 执行语义相似性搜索,并结合 Amazon Athena 执行 SQL 查询。

Amazon DynamoDB:任意规模下的个位数毫秒向量搜索

Amazon DynamoDB 是一项无服务器、完全托管的分布式 NoSQL 数据库,可在任意规模下提供个位数毫秒性能。使用 DynamoDB 进行向量搜索可在任意规模下提供超过 99% 召回率的个位数毫秒延迟,即使面对万亿级向量也同样适用。它完全无服务器,无需预置、修补或管理服务器,也无需安装、维护或运营软件。你所熟悉的 DynamoDB 零基础设施管理体验,包括无版本、无维护窗口和无停机维护,同样适用于向量搜索。DynamoDB 中的向量搜索引入了一种新索引,可在存储向量嵌入的属性上创建。它支持最高 4,096 维、欧氏距离、余弦距离和点积距离函数,以及内联过滤。DynamoDB 向量搜索可与 DynamoDB 全局表配合使用,同时支持多区域最终一致性和强一致性。

DynamoDB 服务超过 100 万客户。客户如今已将 DynamoDB 用于 Agentic 工作负载,例如在对话中保存会话上下文,以及跟踪多步骤任务的状态。借助向量搜索,DynamoDB 可为 Agentic 应用中的长期记忆提供语义检索支持。其他使用场景包括 RAG、多模态相似性搜索和推荐引擎。所有这些功能均可在一个无服务器数据库中实现,无需维护独立向量存储或同步数据,也无需学习新的 API。

当你的运营数据已存储于 DynamoDB,或你需要在任意规模下以零基础设施管理实现个位数毫秒向量搜索时,应选择 DynamoDB 向量搜索。

Globant 是一家数字原生公司,为全球企业构建 AI 驱动产品和数字化转型解决方案。

“我们已经基于 DynamoDB 构建客户解决方案,因此能在同一个数据库中获得原生向量搜索极具价值——无需将数据复制到单独的向量存储,也无需管理第二套系统。它完全无服务器,几乎可自动扩展至任何规模,因此我们只需为每位客户实际使用的资源付费;同时,它还提供面向用户的 AI 体验所需的实时低延迟搜索。这让我们的工程师能够专注于构建 AI 应用,而不是管理基础设施。”

— Gastón Milano,Globant Enterprise AI CEO

Amazon ElastiCache for Valkey:用于语义缓存的微秒级延迟

Amazon ElastiCache 是一项无服务器、完全托管的缓存服务,可提供微秒级延迟性能,并全面兼容 Valkey、Memcached 和 Redis OSS。

借助 ElastiCache for Valkey,你可以通过实施记忆机制,为大语言模型(LLM)呈现跨会话对话历史,从而构建更具个性化和上下文感知能力的响应。正如缓存能够降低数据库成本并提升应用性能一样,语义缓存可通过为语义相似的提示词提供缓存响应,降低使用 LLM 的成本和延迟。你还可以使用向量 se

English / 原文

Agentic AI is changing how you work, and vector search powers the retrieval layer that makes agents accurate, contextual, and grounded in real data. Agents plan, reason, and take action across multi-step workflows, making fast, relevant access to your organization’s knowledge essential.

That knowledge already has a home across databases, object stores, search engines, and unstructured sources such as PDFs, recorded video calls, and the systems your teams use every day. AWS vector solutions bring intelligent search and retrieval to your data where it already lives, helping agents find and use the right context without requiring you to move or duplicate your data.

For new workloads where no existing data store applies, we offer a clear decision model across six purpose-built solutions so you can choose the right vector solution for your agentic AI and analytics workloads.

Why vectors matter and top use cases for agentic AI

Vectors are the language of AI. They bridge frontier models and the scattered organizational knowledge accumulated over decades. By representing data as high-dimensional vectors, applications can understand semantic meaning, identify relationships across text, images, audio, and video, and maintain context across sessions. Whether you’re working with product descriptions, security logs, or media libraries, vectors convert everything into a shared mathematical space so you can compare and search across modalities.

Combined with frontier AI models, vectors are the foundation for intelligent, context-aware, personalized, and user-specific experiences:

  • Retrieval Augmented Generation (RAG) and knowledge bases ground frontier model responses with trusted data retrieved at runtime, improving accuracy, reducing hallucinations, and generating responses aligned with organizational knowledge.
  • Semantic search retrieves information based on meaning and intent rather than exact keyword matches, allowing users to discover relevant content even when different terminology is used.
  • Hybrid search combines lexical search with semantic search to deliver comprehensive results across structured and unstructured data.
  • GraphRAG combines semantic search with knowledge graphs to deliver accurate, context-rich, and traceable responses for enterprise scenarios requiring multi-step reasoning.
  • Knowledge graphs connect entities, such as people, products, documents, and concepts through explicit relationships, supporting more intelligent search, discovery, and AI-powered reasoning.

With the options outlined in the previous section, vectors support several use cases, including:

  • Real-time recommendation systems identify products, content, or experiences that align with user interests for personalization through vector similarity across retail, media, and entertainment.
  • Anomaly and fraud detection identifies unusual patterns in high-dimensional data, supporting earlier detection of threats, cyber security issues, or equipment failures.
  • Multimodal content discovery searches across text, images, audio, and video using a single query based on semantic meaning rather than file type or metadata.

The good news is you don’t need a new database for most of these use cases. With AWS, you get vector capabilities where your data already lives, across the services and databases that you already know and use, with no data migration required.

The following figure shows the breadth of AWS vector capabilities and top use cases for agentic AI.

Breadth of AWS vector capabilities across six purpose-built services and top agentic AI use cases

Figure 1: Breadth of AWS vector capabilities for your agentic AI use cases

First principle: Add vectors where your data already lives

This is the principle that guides our entire approach. If you already have an AWS data store, add vector search to that data store. Don’t introduce a new service unless there’s a compelling reason to do so. Vectors stay with the source data, removing cross-service hops and combining vector search with native query capabilities.

When you use your existing data store, you remove the learning curve for new programming tools, APIs, SDKs, and more. You also can be confident that your existing data stores meet your requirements. As an example, your databases proven in production for scalability, availability, and performance will continue to deliver now with vector search. Finally, when your vectors and data are stored in the same place, your applications run faster. There’s no data sync or data movement to worry about. You also realize cost savings by building on investments that you’ve already made.

If your data is already in Amazon OpenSearch Service, Amazon Simple Storage Service (Amazon S3), Amazon Aurora PostgreSQL, Amazon DynamoDB, Amazon ElastiCache for Valkey, or Amazon Neptune, add vectors where the data already is. The right vector search solution follows the data, not the other way around.

For new workloads, identify your dominant requirement: latency, cost, or access pattern, and choose the engine optimized for it. Many workloads need a balance of search, scale, and agentic AI integration. For those, default to Amazon OpenSearch Service, which combines lexical, vector, hybrid, and agentic search in a single system with high throughput, low latency, and relevant results at scale.

The following decision model can help you select the right vector solution based on your workload requirements.

Decision model for choosing an AWS vector engine based on latency, cost, and access pattern

Figure 2: Decision model for vector engines

Amazon OpenSearch Service: The default for new workloads

Amazon OpenSearch Service is a managed retrieval engine that combines lexical, vector, and hybrid search in a single system with high throughput, low latency, and relevant results at scale. It supports multiple indexing strategies, vector quantization, and metadata filtering, scaling from simple RAG applications to advanced multi-signal retrieval. Machine learning (ML)-powered auto-optimization removes manual tuning by selecting the right configurations automatically. GPU acceleration indexes massive datasets up to 10x faster at a quarter of the cost, while UltraWarm and Writable Warm tiers reduce storage costs for less frequently accessed data.

Choose OpenSearch Service as the default for new workloads because most new workloads don’t have a single dominant requirement. They need a balance of search, scale, and agentic AI integration. OpenSearch Service provides the most flexibility across latency, vector volume, queries per second (QPS), cost efficiency, hybrid search, and ease of adoption. It covers the broadest set of use cases including RAG, anomaly detection, multimodal content discovery, and any workload requiring hybrid search. It supports multi-billion vector volumes, handles thousands of QPS, and serves more than 100,000 monthly active customers processing over 10 trillion requests per month.

The next generation of Amazon OpenSearch Serverless is built for agentic AI and dynamic workloads. It autoscales 20x faster than its previous generation, provisions in seconds, and ramps from zero to thousands of requests per second. It also scales back to zero when idle, delivering up to 60% cost savings compared to provisioning for peak capacity. You only pay for consumed capacity. If your agents aren’t running, you pay nothing.

Adobe adopted OpenSearch Service to scale its Acrobat AI Assistant to serve hundreds of millions of users. This is a conversational generative AI engine integrated directly into Adobe’s document ecosystem.

Amazon S3 Vectors: Cost-optimized vector storage at any scale

Amazon S3 Vectors, a capability of Amazon S3, is the first cloud object store with native support to store and query vectors. It brings the cost structure, scale, and simplicity of S3 to vector storage, reducing the cost of uploading, storing, and querying vectors by up to 90 percent compared to specialized vector databases. This makes it cost-effective to build and maintain billion-scale vector indexes that improve AI agent memory, context, and semantic search across content stored in Amazon S3 with zero infrastructure to manage.

Since the general availability of S3 Vectors, customers have been performing tens of millions of queries per day on average, a more than 5x increase over the preview period. Two recent enhancements improve the query experience and pricing. First, S3 Vectors now supports up to 10,000 search results per query , a 100x increase that’s especially valuable for multi-stage retrieval pipelines that apply reranking, aggregation, or deduplication to produce a more relevant result set. Second, query charges on vector indexes with over 10 million vectors are now reduced by up to 80% , significantly lowering costs for running similarity search across large-scale AI, RAG, and semantic search workloads.

Choose Amazon S3 Vectors when you need cost-effective vector storage with simple vector search and metadata filtering for infrequent queries of large vector datasets. It’s recommended when latency can be approximately 100 ms or more, or for fast-growing vector datasets at moderate QPS. It supports up to two billion vectors per vector index with pay-per-query pricing, so you pay for stored vectors while query costs accrue only when you search. Common use cases include semantic search over data lakes, RAG-based knowledge retrieval, large-scale vector storage, and batch retrieval. Customers also work directly with vectors and indexes through the S3 API.

BMW Group uses S3 Vectors as a building block for its hybrid search solution that is powered by an intelligent search agent built with Amazon Bedrock AgentCore. Engineers can query 20 petabytes of data in plain natural language, combining S3 Vectors for semantic similarity searches and Amazon Athena for SQL queries.

Amazon DynamoDB: Single-digit millisecond vector search at any scale

Amazon DynamoDB is a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale. Vector search with DynamoDB delivers single-digit millisecond latency at over 99 percent recall designed for any scale, even trillions of vectors. It’s fully serverless with no servers to provision, patch, or manage, and no software to install, maintain, or operate. The zero infrastructure management that you love with DynamoDB, including no versions, no maintenance windows, and no downtime maintenance, is also available on vector search. Vector search in DynamoDB introduces a new index you create on the attribute that stores vector embeddings. It supports up to 4,096 dimensions, Euclidean, cosine, and dot-product distance functions, and inline filtering. DynamoDB vector search works with DynamoDB global tables, both with multi-Region eventual consistency and strong consistency.

DynamoDB serves over a million customers. Customers already use DynamoDB today for agentic workloads, such as holding session context during conversations and tracking state across multi-step tasks. With vector search, DynamoDB can support semantic retrieval for long-term memory in agentic applications. Other use cases include RAG, multimodal similarity search, and recommendation engines. And you can do all of this in one serverless database, no separate vector store to maintain and synchronize data, and no new API to learn.

Choose DynamoDB vector search when your operational data already lives in DynamoDB, or you need single-digit millisecond vector search at any scale with zero infrastructure management.

Globant is a digitally native company that builds AI-powered products and digital transformation solutions for enterprises around the world.

“We already build client solutions on DynamoDB, so having native vector search in the same database is extremely valuable — no need to replicate data into a separate vector store or manage a second system. It’s fully serverless, scaling automatically across virtually any scale, so we only pay for what each client uses, and it delivers the real-time, low-latency search that user-facing AI experiences demand. It lets our engineers focus on building AI apps instead of managing infrastructure.”

— Gastón Milano, CEO Enterprise AI, Globant

Amazon ElastiCache for Valkey: Microsecond latency for semantic caching

Amazon ElastiCache is a serverless, fully managed caching service delivering microsecond latency performance with full Valkey, Memcached, and Redis OSS compatibility.

With ElastiCache for Valkey, you can build more personalized, context-aware responses by implementing memory mechanisms that surface cross-session conversation history to large language models (LLMs). Similar to how a cache reduces database costs and improves application performance, semantic caching reduces the cost and latency of using LLMs by serving cached responses for semantically similar prompts. You can also use vector search to power RAG on large datasets to improve response relevance and reduce hallucinations by grounding outputs with real-world data.

Choose ElastiCache for Valkey when the workload has a microsecond latency requirement. This includes real-time recommendation engines, session-based personalization, latency-critical RAG pipelines, and semantic caching. It supports up to one billion vectors for microsecond latency vector search.

Sanoma uses ElastiCache for Valkey to turn human moderator decisions into vectors that inform future AI moderation calls in real time, with no retraining required. Today, 30 percent of comments are matched against past decisions, and 6.5 percent receive a different, more accurate outcome as a result.

Amazon Neptune: For GraphRAG

Amazon Neptune is a serverless graph database service for connected data and improved AI accuracy.

When your workload involves highly connected data, or multi-hop reasoning, Amazon Neptune uniquely solves this by combining graph traversal with vector similarity in a single query.

Neptune delivers low-latency vector search with 2–3 billion vector capacity, and built-in multi-hop reasoning and traceability. That last point is critical. Regulated industries must show why a result was returned, not just what was returned. This transparency is what makes Neptune essential for compliance, risk, and security workloads.

Choose Neptune when the workload needs to combine graph traversal with vector similarity in a single query. With Neptune, you can traverse connections (for example, “which teams own the services affected by this alert?”) and combine that relationship context with vector similarity in a single query. Many of our customers use Neptune for workloads that need a knowledge graph, such as financial and compliance risk, pharmaceutical research, drug discovery, and security intelligence.

Deloitte uses Amazon Neptune with the AWS GraphRAG Toolkit to power a Security Intelligence Center that combines graph-based knowledge retrieval with generative AI. By connecting policy interpretation, operational enforcement, and real-time metrics through GraphRAG, Deloitte delivers predictive security guidance grounded in timely organizational context.

Amazon Aurora PostgreSQL: SQL-native vector search

Amazon Aurora delivers high performance and availability at global scale for PostgreSQL. You can turn on the pgvector extension and use optimized reads for high-performance vector search.

Amazon Aurora PostgreSQL with pgvector 0.8.0 delivers 9x faster indexing and 100x more relevant filtered results. This is a major leap. It combines vector search with the full SQL query surface: joins, aggregations, WHERE clauses, and ACID transactions in a single engine.

Choose Aurora when your source data already lives in Aurora. It’s recommended when you want to use SQL, or when you need to consolidate vector and relational workloads into a single database. It delivers low latency and supports hundreds of billions of vectors, and is ideal for multi-tenant software as a service (SaaS) applications, agentic memory stores, and RAG with structured data context.

LeadSquared, a SaaS CRM platform serving sectors such as BFSI, healthcare, and education, built their solution using Aurora PostgreSQL with pgvector and Amazon Bedrock for RAG. They accelerated chatbot deployments by using Aurora for both vector embeddings and essential operational data.

Combining solutions for complex architectures

Some use cases benefit from combining multiple vector services. You might have a workload best served by an architecture that combines Amazon ElastiCache for Valkey for semantic caching, Amazon OpenSearch Service for hybrid search, and Amazon S3 Vectors for persistent vector storage. Together, this combination allows you to scale from zero to trillions of vectors while optimizing for latency and cost across hot, warm, and cold tiers.

When evaluating complex workloads with potentially competing requirements, consider three dimensions simultaneously:

  • Performance and scale: Latency profile, vector volume, QPS requirements, and algorithm tuning for accuracy.
  • Cost and operations: Cost-latency trade-offs, tiering needs, operational model preference (serverless or provisioned), and existing team expertise.
  • Search capabilities: Hybrid search, SQL support, complex metadata filtering, full-text search, and multi-vector search.

The following table can help you select the right vector engine so you can optimize for latency, cost, or access pattern requirements.

Service Latency (P95) Vector Volume QPS Key Differentiator
Amazon OpenSearch Service 10–100 ms Hundreds of billions Thousands Lexical, semantic, hybrid, and agentic search. Broadest capability set, including serverless.
Amazon S3 Vectors > 100 ms Multi-billion Low hundreds / index Pay-per-query, lowest cost for infrequent queries
Amazon DynamoDB < 10 ms Trillions Virtually unlimited. (Thousands per vector index partition) Single-digit millisecond latency vector search at any scale
Amazon ElastiCache for Valkey < 10 ms Over 1B vectors Thousands Microsecond latency, semantic caching
Amazon Aurora PostgreSQL 10–100 ms Hundreds of billions Thousands SQL-native relational + vector
Amazon Neptune 10–100 ms 2–3B vectors Hundreds to thousands Graph traversal + vector (GraphRAG)

Table 1: AWS vector solutions

Getting started

Get started today with AWS vector solutions for semantic search and self-managed knowledge bases and RAG. Start by adding a vector solution to where your data exists today. For new workloads, use the decision model to help select a vector solution based on your latency and scale requirements, or default to Amazon OpenSearch Service if you’re not sure. If you’re interested in a fully managed knowledge base and RAG solution, read this post on Amazon Bedrock Knowledge Bases.

Join our webinar, AWS Vector Solutions Overview: Intelligence for Agentic AI Where Your Data Already Lives, for a detailed look on choosing the right vector engine and the latest updates across our portfolio. Contact your AWS account team for a hands-on workshop or proof of concept.


About the authors

Marc Trimuschat

Marc is Director, Worldwide Data and AI Go To Market at Amazon Web Services (AWS). In this role, he sits within the AWS AI Go-to-Market organization, heading up a global team focused on helping enterprise customers extract strategic value from cloud storage and data foundation services.

Erika Ehrli

Erika is Head of Product Marketing for Data for AI at Amazon Web Services, where she leads technical product marketing and go-to-market strategy across the AWS analytics, database, and storage portfolios. In this role she helps organizations build AI-ready data foundations for agentic AI and analytics workloads.

Vlad Vlasceanu

Vlad is the Worldwide Tech Leader for Databases at AWS. He focuses on accelerating customer adoption of purpose-built databases, and developing prescriptive guidance mechanisms to help customers select the right databases for their workloads. He is also the leader of the database expert community within AWS, where he helps develop Solutions Architects’ database skills and enables them to deliver the best database solutions for their customers.