【AWS】RAGのベクトルストア、S3 VectorsとOpenSearchどっちを選ぶ?

はじめに

おいおい、何番煎じのネタだよ..と思ったかもしれませんが、このS3 VectorsとOpenSearchって意外と比較検証の記事があまりなくて、S3 Vectorsを試してみたの記事が多かったので書いてみました。

本記事では、AWS上でRAGを構築する際の代表的な2つのベクトルストア
Amazon S3 Vectors
Amazon OpenSearch Service
について、それぞれの特徴を整理したうえで比較し、ユースケース別の使い分けを考えてみます。
RAGの導入やOpenSearchからS3 Vectorsへの移行を検討している方の参考になれば幸いです。

そもそもRAGとは

そもそもRAGってなんだっけ?というところから軽くおさらいしておきます。

RAG (Retrieval-Augmented Generation、検索拡張生成) は、LLMに外部の知識を参照させながら回答を生成させる手法です。

LLM単体だと、

• 学習時点までの知識しか持っていない
• 社内情報みたいな固有のデータは知らない
• ハルシネーション (それっぽい嘘) を平気で言ってくる

といった困りごとがあります。
これを解決するために、関連する情報をどこかから検索してきて、プロンプトに含めて渡してあげよう!というのがRAGの基本的な考え方になります。

ざっくりとした処理の流れは以下のような感じです。

1. ドキュメントをチャンク (小さい単位) に分割する
2. 埋め込みモデルでチャンクをベクトル (数値の配列) に変換する
3. ベクトルをベクトルストアに保存しておく
4. ユーザーのクエリも同じようにベクトル化する
5. クエリベクトルと意味的に近いチャンクをベクトルストアから探してくる
6. 検索結果をコンテキストとしてLLMに渡し、回答を生成してもらう

このうち、3と5を担当するのがベクトルストアですね。
「クエリと意味が近いベクトルを高速に探してきてくれる人」と思っておけば大丈夫です。

RAGについては今回は軽く触れる程度にしようと思います。
RAGの詳細な解説については、以下の記事でしてますので、よければ読んでみてください。

また、以下のAWSさんのブラックベルトオンラインセミナーの資料や動画でも分かりやすく解説されていますので、参考にしてみてください。

ベクトルストアに求められる要件は色々ありますが、ざっくり言うと、

• 大量のベクトルを保存できるか
• ちゃんと精度よく検索できるか
• 応答速度はどうか
• 同時にどれくらいクエリを捌けるか
• メタデータでフィルタできるか
• お財布に優しいか
  このあたりがポイントになります。
  このうちどれを優先するかで、選ぶべきベクトルストアが変わってくるんですね〜

Amazon S3 Vectorsについて

概要

Amazon S3 Vectors は、ベクトルの保存とクエリをネイティブにサポートする、初のクラウドオブジェクトストレージサービスです
2025年7月にプレビュー公開され、re:Invent 2025のタイミングで一般提供 (GA) が発表されました。

ざっくり言ってしまうと、「S3バケットそのものをベクトルDBとして使えるようにしたサービス」 という感じですね。

従来、AWSでベクトル検索を行うにはOpenSearchやAuroraなど別のサービスが必要で、コンピュートリソースが常時稼働するためそれなりのコストが発生していました。S3 Vectorsはこの構造を根本から変え、ストレージ主体のアーキテクチャでベクトル検索を実現していました。

スペック

GAされたS3 Vectosのスペックは以下のとおりです。

項目	値
1インデックスあたりのベクトル数	最大20億
1バケットあたりのインデックス数	最大10,000
1アカウントあたりのバケット数	最大10,000
次元数	1〜4,096 (Titan、OpenAI、Cohereなど主要モデル対応)
距離メトリクス	コサイン類似度、ユークリッド距離
クエリレイテンシ	頻度の高いクエリで約100ms以下、低頻度でも1秒未満
書き込みスループット	単一ベクトルストリーミングで最大1,000ベクトル/秒
1クエリあたりの取得件数	最大100件
メタデータ	1ベクトルあたり最大50キー(フィルタリング可能/不可)
暗号化	SSE-S3 (デフォルト)、SSE-KMS

プレビュー時点では1インデックスあたり5,000万ベクトルが上限でしたが、GAで20億ベクトルまで拡張され、ほとんどのエンタープライズユースケースに対応できる規模になりました。また、他の項目でも改善されています。

料金体系

料金は以下の3要素で構成されます。

• ストレージ料金: 保存している論理ベクトルデータ量(GB単位)
• PUT料金: アップロードするベクトルの論理GB
• クエリ料金: APIコール料金 + 処理データ量(TB単位)

公式によると、専用のベクトルDBと比較して最大90%のコストダウンが可能とのこと。
アイドル時のコンピュートコストがそもそも発生しないというのが、コスト面で効いてくるポイントです。

Amazon OpenSearch Serviceについて

概要

Amazon OpenSearch Service は、Elasticsearchから派生したオープンソースの検索エンジンOpenSearchをマネージドで提供するサービスです。

OpenSearch Serviceには大きく2つのデプロイモデルがあります。

• Amazon OpenSearch Service (プロビジョンド): インスタンスベース。クラスタを自分で構成・運用する
• Amazon OpenSearch Serverless: サーバーレス。コレクションタイプとして「ベクトル検索」を選べる
  RAG用途であれば、Bedrock Knowledge Basesのデフォルト選択肢にもなっている OpenSearch Serverless のベクトル検索コレクション が一般的です。

料金体系 (OpenSearch Serverless)

OpenSearch Serverlessのベクトル検索コレクションは、OpenSearch Compute Unit (OCU) という単位で課金されます。

• 1 OCU = 6GB RAM + vCPU + GP3ストレージ + S3データ転送
• OCU時間あたり約 0.24 USD
  冗長化なし (開発用途) の場合は最小1 OCU、本番環境 (冗長化あり) では最小2 OCU (インデックス用1 + 検索用1) が必要になります。

非冗長構成での最小ランニングコストはざっくりこんな感じ。

0.24 USD/OCU時間 × 24時間 × 30日 × 1 OCU ≈ 172.8 USD/月

つまり、データ量がどうあれ月額170 USD程度の固定費が発生するというのがコスト面で大きな特徴です。
データ量が増えればOCUもさらに増えていくので、より料金は上がっていきます。
ちょっとお試しで始めたい...というときには、ここがネックになりがちですね。

強み

OpenSearchの最大の強みは、もともと検索エンジンであるという点に由来します。

ハイブリッド検索

ベクトル検索と全文検索 (BM25など) を組み合わせるハイブリッド検索がネイティブで実現できる、というのは純粋なベクトルストアにはない大きな差別化ポイントです。
RAGの精度向上の手段としてハイブリッド検索はもうほぼ必須に近い存在になっていて、これをマネージドで扱える意味はかなり大きいです。

検索精度

メタデータフィルタリングがめちゃくちゃ高機能で、数値・ブール値・日付・地理情報など多様な型に対応しています。
範囲検索や複合条件、ジオ距離検索なども標準で扱えるため、ECサイトの商品検索や不動産検索のような複雑な要件にも対応できちゃいます。

加えて、日本語ユーザーにとって嬉しいのが形態素解析との親和性。
kuromojiなどのアナライザを組み合わせることで、日本語特有のトークナイズ問題を解消できて、検索精度を高めることができます。
これはS3 Vectors単体ではちょっと難しい領域ですね。

レイテンシ・スループット

ミリ秒単位の低レイテンシと高QPSを両立できる点も際立ちます。
リアルタイム性が求められる対話型アプリや、多数のユーザーが同時にクエリを投げる本番ワークロードでも、安定してさばけます。
S3 Vectorsが100ms前後のレイテンシなのに対して、OpenSearchは数ms〜数十msオーダーで応答できるので、ユーザー体験にシビアな要件があるシステムにはピッタリです。

比較してみる

ここまでの内容を踏まえて、両者を観点別に整理してみます。

機能・性能比較

観点	Amazon S3 Vectors	Amazon OpenSearch Service
アーキテクチャ	ストレージ主体	コンピュート主体
プロビジョニング	不要	OCU管理 (Serverless)、インスタンス管理 (プロビジョンド)
クエリレイテンシ	約100ms〜1秒未満	ミリ秒〜数十ms
スループット	中程度 (1,000 vec/秒の書き込み)	高い (リアルタイム向け)
最大ベクトル数	20億/インデックス	数十億/コレクション
次元数	1〜4,096	〜16,000
距離メトリクス	コサイン、ユークリッド	コサイン、ユークリッド、ドット積など
ハイブリッド検索	単体では非対応 (OpenSearch統合で可能)	ネイティブ対応
メタデータフィルタ	対応 (最大50キー)	高機能 (型・範囲・地理情報など)
Bedrock Knowledge Bases連携	対応	対応
運用負荷	低 (フルマネージド)	中 (OCUのモニタリング等が必要)

コスト比較

コスト構造は両者で根本的に異なります。

観点	S3 Vectors	OpenSearch Serverless
課金モデル	従量課金 (使った分だけ)	OCU時間 + ストレージ
最低固定費	なし	約172 USD/月〜 (1 OCU、非冗長)
アイドル時のコスト	発生しない (ストレージのみ)	OCU料金が継続発生
大規模データ時のコスト	スケールしても比較的低コスト	データ量に応じてOCUが増加

ざっくり言うと、

• S3 Vectors: データ量とクエリ回数に応じて課金。使わなければほぼゼロ
• OpenSearch Serverless: 使っていなくても最低OCU分の固定費が発生

という違いです。AWSは公式に「S3 Vectorsで最大90%のコスト削減が可能」とアピールしています。

S3 Vectorsのコスト計算例

「最大90%のコストダウン」と言われても、実際のところどれくらいかかるのか?が気になるところですよね。
ここでは、公式ドキュメントを参考にシナリオを用意して計算してみたいと思います。

単価のおさらい

項目	単価
ストレージ料金	0.06 USD/GB/月
PUT料金	0.20 USD/GB
クエリAPI料金	2.5 USD / 100万リクエスト
クエリ処理データ料金 (Tier 1: 〜10万ベクトル)	0.004 USD/TB
クエリ処理データ料金 (Tier 2: 10万ベクトル超)	0.002 USD/TB

実際のリージョン別料金は以下の公式ページを確認してください。

1ベクトルあたりの論理サイズ

公式の計算式によると、1ベクトルの論理ストレージサイズは以下のように計算されます (1024次元の場合)。

ベクトルデータ:               4 bytes × 1024次元 = 4,096 bytes (約4 KB)
フィルタリング可能メタデータ:  1 KB
フィルタリング不可メタデータ:  1 KB
キー:                         0.17 KB
─────────────────────────────────────────
合計:                          約 6.17 KB / ベクトル

クエリ処理時のサイズは、フィルタリング不可メタデータが含まれないため 約5.17 KB/ベクトル になります。

シナリオ: 社内ナレッジRAG

公式ドキュメントの数値を参考に、社内RAGを運用した時のコストを試算してみます。

前提:
- ドキュメント数: 10万ドキュメント
- 1ドキュメントを10チャンクに分割 → 100万ベクトル
- 埋め込み次元: 1024
- インデックス数: 1
- 月間クエリ数: 50,000回 (社員200人 × 1日1回弱)
- データ更新: 月1回フルアップロード

ストレージ料金:

6.17 KB × 1,000,000ベクトル = 6,170 MB ≈ 6.03 GB
6.03 GB × 0.06 USD = 0.36 USD/月

PUT料金:

6.03 GB × 0.20 USD = 1.21 USD/月

クエリ料金:

APIコール料金: 50,000回 × (2.5 / 1,000,000) = 0.125 USD
 
処理データ料金:
  Tier 1 (10万ベクトル分): 100,000 × 5.17 KB × 50,000 = 約 0.0258 TB
                         → 0.0258 TB × 0.004 USD/TB = 0.000103 USD
  Tier 2 (90万ベクトル分): 900,000 × 5.17 KB × 50,000 = 約 0.232 TB
                         → 0.232 TB × 0.002 USD/TB = 0.000464 USD
  処理データ料金合計: 約 0.0006 USD (誤差レベル)
 
クエリ合計: 約 0.13 USD/月

月額合計: 約 1.7 USD (≒ 約260円)

100万ベクトルあっても月額数百円で収まっちゃうんですね...!
社内ナレッジ検索みたいな用途には、めちゃくちゃ向いてそうです。

OpenSearch Serverlessの場合

同じ条件で、OpenSearch Serverlessだとどうなるかも計算してみます。

OpenSearch Serverlessは、OCU (OpenSearch Compute Unit) という単位で課金されるんでしたね。
非冗長構成 (開発用途) でも最小1 OCUは必要で、本番環境だとインデックス用と検索用で最小2 OCUからになります。

項目	単価
OCU料金	0.24 USD/OCU時間
ストレージ料金 (S3)	0.024 USD/GB/月
最小OCU数 (非冗長)	1 OCU
最小OCU数 (本番・冗長あり)	2 OCU

100万ベクトル × 1024次元のデータサイズはざっくり以下の通り。

4 bytes × 1024次元 × 1,000,000ベクトル = 4,096 MB ≈ 4 GB
※ HNSWインデックスのオーバーヘッドが乗るので実際はもう少し増えます

この程度のデータ量なら、最小OCU構成 (非冗長で1 OCU、本番で2 OCU) で十分カバーできるサイズ感です。

非冗長構成 (開発用途) の場合

OCU料金: 0.24 USD × 24時間 × 30日 × 1 OCU = 172.8 USD/月
ストレージ料金: 4 GB × 0.024 USD ≈ 0.10 USD/月
合計: 約 172.9 USD/月

本番構成 (冗長化あり) の場合

OCU料金: 0.24 USD × 24時間 × 30日 × 2 OCU = 345.6 USD/月
ストレージ料金: 4 GB × 0.024 USD ≈ 0.10 USD/月
合計: 約 345.7 USD/月

OpenSearch Serverless 月額合計: 約 173〜346 USD (≒ 約26,000〜52,000円)

比較してみると...

両者の結果を並べてみます。

構成	月額
S3 Vectors	約 1.7 USD (≒ 約260円)
OpenSearch Serverless (非冗長)	約 172.9 USD (≒ 約26,000円)
OpenSearch Serverless (本番・冗長あり)	約 345.7 USD (≒ 約52,000円)

なんと100倍以上の差が出てしまいました...!
公式が「最大90%のコストダウン」と言っているのも納得の数字感ですね。

ただ、これはあくまでこのシナリオでの話で、

• クエリ数がもっと多い (高QPSが必要) ならS3 Vectorsのクエリ料金が増える
• 逆にOpenSearchは、ある程度のデータ量・クエリ数までなら同じOCUで賄える
  というように、規模が変わると話が変わってきます。
  特にOpenSearchは「使っていなくても固定費がかかる」のがネックですが、「使い込めば使い込むほど割安になる」という性質もあります。

なので、コストだけで決めるのではなく、後ほど触れるユースケースごとの向き不向きと合わせて判断するのが良さそうです!

レイテンシのトレードオフ

S3 Vectorsはストレージ主体のアーキテクチャなので、OpenSearchと比べるとどうしてもレイテンシは劣ります。

• OpenSearch: ミリ秒〜数十ms (リアルタイム対話向け)
• S3 Vectors: 約100ms以下〜1秒未満 (チャットボットなら全然許容範囲)

ただ、GA版で「頻繁にクエリされるインデックスは100ms以下」までレイテンシが改善されたので、対話型AIでも全然実用に耐えるレベルになっています。
このあたりはGAで一気に強くなったポイントですね!

ユースケース別で想定される使い分け

ここまで色々比較してきましたが、結局「どっちを使えばいいの?」が一番気になるところかなと思います。
私なりに、ユースケース別にまとめてみました。

S3 Vectorsが向くケース

• コスト重視のRAG: 個人プロジェクト、PoC、社内ナレッジ検索など、とにかくコストを抑えたい場面
• アクセス頻度が低い大量ベクトル: ログ分析エージェント、過去ドキュメント検索、エージェントの長期記憶など
• マルチテナント構成: 顧客ごとにインデックスを分けたい場面 (1バケット10,000インデックスをフル活用!)
• 間欠的に使うシステム: アイドル時間が長くて、固定費を払いたくないシステム
• 大規模だけどコスト優先: 数億〜数十億ベクトルを保存するけど、レイテンシ要件は緩い場面

OpenSearchが向くケース

• 低レイテンシ要件: ミリ秒単位の応答が必要な対話型アプリ、リアルタイム検索
• ハイブリッド検索が必要: ベクトル検索だけじゃなくキーワード検索も組み合わせたい場面
• 高QPS: たくさんのユーザーが同時にクエリを投げる本番アプリ
• 複雑なフィルタリング: 地理情報、範囲検索、複合条件など、高度なフィルタが必要な場面
• 既にOpenSearchを使っている: 全文検索やログ分析でOpenSearchを運用していて、ベクトル検索もまとめて統合したい場面
• 日本語の高精度検索: 形態素解析と組み合わせた高い検索精度が求められる場面

両者を組み合わせる選択肢

実は、GAに伴ってS3 VectorsとOpenSearchの統合も一般提供されています。

これは、大量のベクトルをS3 Vectorsに保存しつつ、OpenSearchで検索・分析機能を活用するという、いわゆる階層化戦略です。
これについては過去記事で検証していました。

さいごに

いかがでしたか?
今回は、Amazon S3 VectorsとAmazon OpenSearch Serviceを比較してみました。

ざっくりまとめると、

• S3 Vectors: コスト最適化されたストレージ主体のベクトルストア。アイドル時のコストがほぼゼロで、大量ベクトルを安価に保存できる。レイテンシはミリ秒オーダーには及ばないけど、100ms以下まで改善されている
• OpenSearch: コンピュート主体のフルマネージド検索エンジン。低レイテンシ・高QPS・ハイブリッド検索など高度な検索要件に対応できるけど、最低固定費が発生する
  という感じでしょうか。

S3 VectorsがGAして、東京リージョンでも使えるようになったことで、「とりあえずS3 Vectorsから始めてみて、レイテンシやスループットの要件が厳しくなったらOpenSearchに移行 (or併用)」という戦略がだいぶ現実的になったかなと思います。
特にPoCや個人開発、社内RAGのような場面では、固定費がかからないS3 Vectorsの恩恵が非常に大きいです。

この記事がRAGの導入やベクトルストアの選定で悩んでいる方の参考になれば幸いです。
最後まで読んでいただきありがとうございました。

参考