AWS でベクトルを置ける先は、2026年11月時点で少なくとも8つあります。S3 Vectors、OpenSearch Service、Aurora PostgreSQL の pgvector、DynamoDB、MemoryDB、ElastiCache for Valkey、DocumentDB、Neptune Analytics です。名前が増えたぶん、どれを選んでも動きはします。差が出るのは、Bedrock のナレッジベースに繋がるか、1回の検索で何件まで返せるか、使っていない時間にも料金が掛かるか、絞り込み条件を付けたときに件数が欠けないか、の4点です。この記事では各サービスの公式ドキュメントから上限値を拾い、選ぶ順番と見送る構成を、ナレッジベースの設定 JSON と boto3 の問い合わせ例を添えて並べます。
まとめ：AWSのベクトルデータベースは正本データの置き場とBedrock連携で決める
最初に確かめるのは、ベクトルストアを自分で持つ必要があるかどうかです。Bedrock には2026年3月から、取り込みから保管・検索までを AWS 側が持つ Managed Knowledge Base があります。社内文書の RAG で特別な要件が無ければ、ベクトルデータベースを選ばずに済みます。
自分で持つなら、新規の RAG は S3 Vectors から検討してください。常時起動のノードが無く、1インデックス20億件まで入ります。業務データが Aurora PostgreSQL にあり、行と結合して返したい場合は pgvector です。キーワード検索との組み合わせや集計まで要る検索基盤なら OpenSearch Service を選びます。
DynamoDB・DocumentDB・Neptune Analytics は、正本データがすでにそこにある場合に限って選ぶものです。MemoryDB と ElastiCache は、ミリ秒未満の応答が要件に書かれているときだけ候補に入れます。
AWSでベクトルを格納できる8サービスを専用型と拡張型と高速型に分ける
AWS の規範ガイダンス「ベクトルデータベースオプション」も複数の格納先を並べています。ここではそれに後から加わったサービスも含め、性格の違いに応じた3分類での比較です。ベクトル DB そのものの仕組みはベクトルDBの仕組みとインデックス構造の解説に譲ります。
専用型・既存DBの拡張型・インメモリの高速型という3分類の中身
専用型は、ベクトルを置くために作られたサービスです。S3 Vectors と OpenSearch Service がここに入ります。前者はストレージ、後者は検索エンジンが出自で、得意な負荷がまるで違います。
拡張型は、既存のデータベースにベクトル列やベクトルインデックスを足したものです。Aurora PostgreSQL（pgvector）、DynamoDB、DocumentDB、Neptune Analytics が該当します。正本データと同じ場所で検索できるのが利点で、別ストアへの複製パイプラインが要りません。
高速型は MemoryDB と ElastiCache for Valkey です。データをメモリに置くため応答は速く、代わりにベクトル件数がそのままノードのメモリ量になります。ElastiCache のベクトル検索は2025年10月13日に Valkey 8.2 で一般提供が始まり、追加料金は掛かりません。
公式ドキュメントで確かめた次元数・TopK・件数上限の比較表
各サービスの上限値を、2026年11月8日時点の公式ドキュメントから拾いました。次元数は埋め込みモデルの出力（Titan Text Embeddings V2 なら1,024・512・256）が収まるかの確認に使います。
| サービス | 最大次元数 | 1回の検索で返せる件数 | 規模・構成の制約 |
|---|---|---|---|
| S3 Vectors | 4,096 | TopK最大10,000（1ページ100件） | 1インデックス最大20億件 |
| OpenSearch Serverless | 16,000 | k-NNクエリのkで指定 | NextGenは書き込みから検索まで約5秒 |
| DynamoDB | 4,096 | TopK最大100 | オンデマンド容量のテーブル専用 |
| MemoryDB | 32,768 | FT.SEARCHのKNNで指定 | 単一シャードのみで水平分割不可 |
| DocumentDB | 索引付きは2,000 | 集計パイプラインのkで指定 | 5.0以降のインスタンス型クラスタ |
| Neptune Analytics | 65,535 | アルゴリズムの引数で指定 | 索引はグラフ作成時に1つだけ |
出典は S3 Vectors の制限、OpenSearch Serverless のベクトル検索コレクション、DynamoDB のクォータ、MemoryDB のベクトル検索の制限、DocumentDB のベクトル検索、Neptune Analytics のベクトル索引です。DynamoDB の TopK 100 は引き上げ不可で、リランク前に数百件を集めたい RAG では足りません。
Bedrockナレッジベースに繋ぐかどうかで候補が半分に絞れる理由
RAG を Bedrock で組むなら、ベクトルストアの選択肢はナレッジベース側の対応表で先に決まります。Bedrock 側の実装手順はAmazon BedrockでRAGを実装する手順で扱っているので、ここでは格納先の選択に関わる部分だけを見ます。
ナレッジベースが受け付けるAWSのストアは5種類という選定の前提
自前のストアを使う Customer-managed のナレッジベースについて、API リファレンスの StorageConfiguration が受け付ける type は8つです。AWS のサービスは OpenSearch Serverless、OpenSearch の管理クラスタ、Aurora（RDS）、Neptune Analytics、S3 Vectors の5つで、残りは Pinecone・Redis Enterprise Cloud・MongoDB Atlas の外部サービスです。
つまり DynamoDB、MemoryDB、ElastiCache、DocumentDB はナレッジベースのストアに指定できません。これらを選ぶと、チャンク分割・埋め込み・検索の呼び出しを自分のコードで書くことになります。取り込みも検索も AWS に任せたいなら、Managed Knowledge Base を選べばストアの選定自体が不要です。
S3 VectorsとAuroraの切り替えに使うJSON設定例
ストアの違いは、ナレッジベース作成時に渡す storageConfiguration の JSON の形に出ます。S3 Vectors はインデックスの ARN だけで済み、Aurora は表と列の対応まで書きます。ナレッジベースの前提条件のページにある項目名で書くと次のとおりです。
# S3 Vectors を使う場合（storage-s3vectors.json）
{
"type": "S3_VECTORS",
"s3VectorsConfiguration": {
"indexArn": "arn:aws:s3vectors:ap-northeast-1:123456789012:bucket/kb-vectors/index/docs-1024"
}
}
# Aurora PostgreSQL を使う場合（storage-aurora.json）
{
"type": "RDS",
"rdsConfiguration": {
"resourceArn": "arn:aws:rds:ap-northeast-1:123456789012:cluster:kb-aurora",
"credentialsSecretArn": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:kb-aurora-XXXXXX",
"databaseName": "postgres",
"tableName": "bedrock_integration.bedrock_kb",
"fieldMapping": {
"primaryKeyField": "id",
"vectorField": "embedding",
"textField": "chunks",
"metadataField": "metadata",
"customMetadataField": "custom_metadata"
}
}
}
# どちらも同じコマンドで作成できる
aws bedrock-agent create-knowledge-base \
--name docs-kb \
--role-arn arn:aws:iam::123456789012:role/BedrockKbRole \
--knowledge-base-configuration '{"type":"VECTOR","vectorKnowledgeBaseConfiguration":{"embeddingModelArn":"arn:aws:bedrock:ap-northeast-1::foundation-model/amazon.titan-embed-text-v2:0"}}' \
--storage-configuration file://storage-s3vectors.jsonAurora 側の列名は作成後に変更できません。custom_metadata 列を使うなら、GIN インデックスも先に作っておきます。表の作り方と HNSW の設定はAurora pgvectorの実装手順にまとめています。
OpenSearch管理クラスタはVPC内ドメイン不可・Auroraは同一アカウント限定
前提条件のページには、構成を縛る注記が2つあります。1つは OpenSearch の管理クラスタで、ネットワークは公開アクセスを選ぶ必要があり、VPC 内のドメインはナレッジベースに使えません。社内規程で検索基盤を VPC に閉じる決まりがあるなら、管理クラスタではなく OpenSearch Serverless の VPC エンドポイント構成を選びます。
もう1つは Aurora で、クラスタはナレッジベースと同じ AWS アカウントに置く必要があります。データ基盤を別アカウントに集約している組織では、ここで構成が崩れます。バイナリ埋め込みを使えるのは OpenSearch の2形態だけで、S3 Vectors は浮動小数点の埋め込みのみです。
料金の形で選ぶ：常時起動の固定費と使った分の従量課金の分かれ目
単価は地域と時期で動くため、ここでは課金の形だけを比べます。東京リージョンの実額は各サービスの記事に載せています。
OpenSearch Serverlessの世代別の最小OCUと固定費の違い
OpenSearch Service の料金ページによると、Serverless の Classic コレクションは最低 2 OCU の課金があり、開発・テスト用の構成でもインデックス用 0.5 OCU と検索用 0.5 OCU が残ります。新しい世代の NextGen コレクションには最小 OCU の要件が無く、10分間アクセスが無いと検索・インデックスとも 0 まで縮みます。
このため、夜間や休日に使われない社内 RAG を Classic で立てると、使っていない時間の固定費が月額の大半を占めます。新規に作るなら NextGen を選んでください。管理クラスタを含む東京の単価はOpenSearch Serviceの料金と構築手順で試算しています。
ベクトルストアの従量課金とノード時間課金で異なる件数増加時の費用
S3 Vectors は保存量・書き込み量・検索回数と処理データ量の従量です。1,024次元100万件・月30万回の検索で月4ドル台という試算をS3 Vectors APIの解説に載せています。DynamoDB のベクトル検索も書き込み・検索・保存の3軸の従量で、詳細はDynamoDBのベクトル検索の解説にあります。
MemoryDB と DocumentDB はノード（インスタンス）の時間課金です。MemoryDB の公式例では、1,536次元のベクトル1,000万件に約104.9GB のメモリが要り、db.r7g.4xlarge が推奨されます。件数が増えるほど1段大きいノードへ移る階段状の費用になる点が、従量型との違いです。
検索要件で選ぶ：絞り込み条件と全文検索の併用と応答時間の判断基準
件数と料金で候補を絞ったら、検索の中身で最終判断します。見落としやすいのは、メタデータで絞り込んだときに返る件数が TopK より減る問題です。
S3 Vectorsの事前フィルタENHANCEDで件数欠けを防ぐ問い合わせ例
S3 Vectors のインデックスには CLASSIC と ENHANCED の2つのモードがあります。インデックスモードのページによると、2026年9月30日より前に作ったベクトルバケットのインデックスは CLASSIC が既定で、絞り込みの強い条件では TopK 未満しか返らないことがあります。ENHANCED はフィルタを先に適用してから類似度を計算し、切り替えは再投入なし・追加料金なしです。
import boto3
s3v = boto3.client("s3vectors", region_name="ap-northeast-1")
# query_vec は埋め込みモデルで作った1,024次元の float のリスト
res = s3v.query_vectors(
vectorBucketName="kb-vectors",
indexName="docs-1024",
queryVector={"float32": query_vec},
topK=20,
filter={"department": {"$eq": "legal"}},
queryMode="ENHANCED", # CLASSIC のインデックスでもこの問い合わせだけ事前フィルタで動く
returnMetadata=True,
returnDistance=True,
)
for v in res["vectors"]:
print(v["key"], round(v["distance"], 4), v["metadata"].get("title"))フィルタを使う問い合わせには s3vectors:QueryVectors に加えて s3vectors:GetVectors の権限が要り、無いと 403 が返ります（QueryVectors の API リファレンス）。ENHANCED のインデックスでは、1回の問い合わせのフィルタ条件が100個までという上限も付きます。
BM25を組み合わせるハイブリッド検索はOpenSearchとAuroraに寄せる理由
型番や条文番号のように、意味の近さより文字の一致で探したい語が多い文書では、キーワード検索との併用が効きます。S3 Vectors と DynamoDB のベクトル検索にはキーワード検索の機能が無いため、併用するなら別の検索基盤を足すことになります。
OpenSearch は同じインデックスに全文検索のフィールドを持てます。Aurora も、ナレッジベース用の表で to_tsvector の GIN インデックスが必須とされており、PostgreSQL の全文検索と並べて使えます。統合の仕組みと RRF の考え方はハイブリッド検索の解説を参照してください。
ミリ秒未満を求めるならMemoryDBとElastiCache、代償はメモリ量
S3 Vectors の応答は、まれな問い合わせで1秒未満、頻繁な問い合わせで100ミリ秒程度と公式に書かれています。人が読む回答を LLM が生成する RAG なら、生成の待ち時間に比べて十分に短い値です。
レコメンドの即時表示や、同じ質問への LLM 応答を使い回すセマンティックキャッシュでは、この差が効きます。MemoryDB は検索を有効にしたクラスタを新規に作る必要があり、既存クラスタの設定変更では有効にできません。ElastiCache との違いはMemoryDBとElastiCacheの違いで整理しています。
受託開発で選ぶ順番と見送るべき構成：小規模RAGで失敗しない判断
ここまでの条件を、相談を受けたときの判断順に並べ直します。条件に当てはまらなければ次へ進む、という読み方をしてください。
新規RAGの第1候補はS3 Vectors、Aurora pgvectorに進む2条件
正本データを持たない新規の RAG で、文書数が数十万〜数百万チャンク、利用が業務時間に偏るなら、S3 Vectors を第1候補にします。固定費が無く、ナレッジベースに直接繋がり、ENHANCED で絞り込みの件数欠けも抑えられます。
Aurora pgvector に進むのは、次の2つのどちらかに当てはまるときです。1つ目の条件として、検索結果を業務テーブル（顧客・案件・権限）と SQL で結合して返したい場合が当てはまります。もう1つは、すでに Aurora PostgreSQL を本番で運用していて、エンジン版が pgvector 0.8.0 以上を入れられる場合です。版の確認方法はAurora PostgreSQLの対応バージョンの解説にあります。
既存DBの拡張型3サービスを正本データの置き場に限って選ぶ判断基準
拡張型の DynamoDB・DocumentDB・Neptune Analytics の3つは、データの複製パイプラインを無くせることが最大の利点です。裏返すと、正本が別の場所にあるならこの利点は消え、制約だけが残ります。DynamoDB は TopK 100 とオンデマンド専用、DocumentDB は索引付きで2,000次元まで、Neptune Analytics は索引が1グラフ1つで、ベクトルの更新はトランザクションの原子性の外にあります。
ナレッジベースのストアとして指定できる範囲にも、サービスごとの違いがあるため確認が必要です。DynamoDB と DocumentDB はストアに指定できず、Neptune Analytics は GraphRAG の構成としてのみ指定できます。DocumentDB の全体像はAmazon DocumentDBの解説、Neptune はAmazon Neptuneの解説で扱っています。
小規模RAGにOpenSearch Classicを置いて固定費が先に立つ失敗
見送るべき構成もはっきりさせておきます。社内向けで1日数百回程度しか検索されない RAG に、OpenSearch Serverless の Classic コレクションや常時起動の管理クラスタを置く構成は採りません。検索回数に関係なく最低 OCU やインスタンスの時間料金が積み上がり、ストア代が LLM の生成料金を上回ることがあります。
検証用に作った Classic コレクションを、そのまま本番に流用する場合も同じです。キーワード検索との併用や集計が要件に無いなら、S3 Vectors か Managed Knowledge Base へ移すと固定費が消えます。格納先の選定から RAG 全体の設計まで相談したい場合は、RAG構築支援で要件の整理からお手伝いしています。
よくある質問
AWS でベクトルデータベースを選ぶときによく受ける質問をまとめました。
AWSで一番安いベクトルデータベースはどれですか？
検索回数が少なく、使わない時間がある用途なら S3 Vectors です。常時起動のノードが無く、保存・書き込み・検索の従量だけで課金されます。1,024次元100万件・月30万回の検索で月4ドル台という試算があります。ただし1件ずつ書き込むと最低課金の単位で費用が膨らむため、まとめて書き込む設計が前提です。
S3 VectorsとOpenSearch Serviceはどう使い分けますか？
ベクトル検索だけで足りるなら S3 Vectors、キーワード検索との併用・集計・地理条件などの検索機能が要るなら OpenSearch Service です。両者は連携もでき、S3 Vectors のインデックスを OpenSearch Serverless へスナップショットとして書き出せます。ただし書き出しは開始時点の1回だけの複製で、その後の更新は同期されません。
RDS for PostgreSQLでもpgvectorは使えますか？
使えます。拡張そのものと SQL は Aurora と同じです。違いは Bedrock のナレッジベースとの関係で、前提条件のページが手順を示しているのは Aurora のクラスタです。自前のコードで検索まで書くなら RDS for PostgreSQL でも構いませんが、ナレッジベースに取り込みを任せたいなら Aurora を選びます。
DynamoDBのベクトル検索はRAGに使えますか？
使えますが、ナレッジベースのストアには指定できないため、チャンク分割から検索までを自分で実装します。1回に返せるのは最大100件で、条件の絞り込みは等号だけです。正本データが DynamoDB にあり、カテゴリやテナント単位で検索範囲を区切れる用途なら、複製が要らない利点が上回ります。
ベクトルの次元数は後から変えられますか？
多くのサービスで変えられません。S3 Vectors と DynamoDB はインデックスの作成時に次元数を決め、Neptune Analytics はグラフの作成時に固定されます。埋め込みモデルを替えて次元数が変わる場合は、新しいインデックスを作って全件を埋め込み直し、切り替える手順になります。モデルの選定はインデックスを作る前に済ませてください。
関連記事
- ベクトルデータベースの価格とおすすめ｜3タイプの料金体系比較とRAG用途の選び方【2026年版】：AWS以外の製品も含めた料金体系の比較です。
- Pineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分け【2026年版】：ナレッジベースが対応する外部ストアの代表です。
- Amazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説：Valkey 8.2のベクトル検索を使う前提のノード構成です。
- Amazon S3 Vectors APIとは？全21操作・boto3実装・東京の料金と事前フィルタを解説【2026年10月】：第1候補にしたS3 Vectorsの実装です。
- Aurora pgvectorの実装手順：対応版の確認・HNSW索引・Bedrockナレッジベース連携：Auroraを選んだ場合の表定義と索引です。
