Amazon S3 Vectors の構造と OpenSearch・Bedrock KB との使い分け

本記事では、2025 年 12 月に GA となった Amazon S3 Vectors の仕組みと、既存のベクトルストア選択肢との使い分け判断を整理します。 S3 ネイティブのアーキテクチャが生む制約と上限値、料金モデルの構造を順に整理します。続いて Bedrock Knowledge Bases や OpenSearch Serverless との統合パターンと、ユースケース別の選択フローを取り上げます。 これらの判断材料を踏まえ、手元の RAG・セマンティック検索の要件に合うベクトルストアの選択を確定させましょう。

S3 Vectors の位置付け ── 「S3 と同じ耐久性・従量課金・ゼロプロビジョニング」のベクトルストア

Amazon S3 Vectors は 2025 年 7 月にプレビュー、同年 12 月 2 日に GA となったサービスです。クラウドオブジェクトストアとしては初めてベクトルの保存とクエリをネイティブにサポートしています。東京リージョン (ap-northeast-1) でも利用可能で、VPC エンドポイント (PrivateLink) にも対応しています。

AWS は S3 Vectors を「AI エージェント・推論・RAG・セマンティック検索のための目的特化型ベクトルストレージ」と位置付けています。

Amazon S3 Vectors delivers purpose-built, cost-optimized vector storage for AI agents, inference, RAG, and semantic search.

出典: Amazon S3 Vectors features (AWS)

S3 Vectors が他のベクトルストアと根本的に異なる点は、専用の Compute ノードをプロビジョニングしない設計にあります。OpenSearch Serverless や専用ベクトル DB のように常時起動のインフラを持たず、ストレージとクエリ処理をオンデマンドで分離しています。この設計は S3 が長年採ってきた「耐久性・従量課金・ゼロプロビジョニング」という設計思想をベクトルストアに持ち込んだものです。

プレビュー期間中のデータとして、AWS は 25 万以上のインデックス、400 億以上のベクトル、10 億回以上のクエリが実行されたと GA ブログで公表しています。また、AWS は専用ベクトル DB と比較して TCO を最大 90% 削減できると主張していますが、比較対象のサービス名は非公開です。参考値として把握しておくにとどめてください。

アクセス制御は s3vectors: という専用の IAM 名前空間を使います。通常の s3: 権限とは別に設定が必要な点は、既存の S3 ポリシーを流用しようとするとつまずきやすい点です。

インデックスの構造と上限値 ── 設計前に確認すべき不変制約

S3 Vectors では「ベクトルバケット」という新しい種別のバケットを作成し、その中に複数のベクトルインデックスを作成します。汎用バケットとは別物で、Block Public Access が常時有効になっており、無効化できません。暗号化はデフォルトで SSE-S3 が適用され、AWS KMS (CMK) もオプションで利用できます。

ベクトルインデックスの主な制約

出典: S3 Vectors regions and quotas (AWS)

インデックス作成時に設定する距離関数 (Cosine / Euclidean) と次元数は、作成後に変更できません。変更が必要になった場合は、インデックスを再作成してベクトルを再投入する必要があります。埋め込みモデルの乗り換えを想定している場合は、この制約を設計段階から考慮してください。

ベクトルキーは UTF-8 で最大 1,024 文字、インデックス内でユニーク、大文字小文字を区別します。メタデータの型は string / number / boolean / list の 4 種類です。

書き込みは Strong Consistent (即時一貫性) であるため、書き込み直後のクエリで最新ベクトルが反映されます。

公式の Recall は平均 90% 以上とされています。レイテンシについては、低頻度のコールド状態でサブ秒 (数百 ms 台に伸びる可能性)、高頻度のウォーム状態で 100ms 以下と公式に記載がありますが、「低頻度」「高頻度」の閾値 QPS は公式ドキュメントに明記されていません。

Bedrock KB と OpenSearch への接続 ── 2 つの統合パターン

S3 Vectors は単体でも使えますが、Bedrock Knowledge Bases および OpenSearch との統合が GA の段階で公式にサポートされています。統合パターンは用途によって大きく 2 方向に分かれます。

パターン 1: Bedrock Knowledge Bases のバックエンドとして使う

Bedrock Knowledge Bases の作成画面で、ベクトルストアとして S3 Vectors を選択できます。Quick Create (自動作成) と既存バケット選択の両方に対応しています。SageMaker Unified Studio 経由でも利用可能です。

この統合でサポートされるのはセマンティック検索のみです。ハイブリッド検索 (セマンティック + キーワードの組み合わせ) は Bedrock KB + S3 Vectors の構成では利用できません。

また、Bedrock Knowledge Bases 側の仕様として、S3 Vectors をバックエンドに選んだ場合のメタデータ上限が標準より厳しく設定されています。S3 Vectors 単体では 2 KB / 50 keys ですが、Bedrock KB 経由では 1 KB / 35 keys に制限されます。既存の Bedrock KB を他のベクトルストアから S3 Vectors へ移行する場合は、この上限差を事前に確認してください。

AWS の公式は S3 Vectors + Bedrock KB の用途を「ストレージコスト最適化を優先するが、超低レイテンシは求めない RAG アプリケーション」と明記しています。

パターン 2: OpenSearch との統合 (2 方向)

OpenSearch との統合には、目的の異なる 2 つの経路があります。一方は段階的な移行のための一方向エクスポート、もう一方は OpenSearch のストレージ層を S3 Vectors に差し替える恒久的な構成変更です。

エクスポート統合 (S3 Vectors → OpenSearch Serverless) は、S3 Vectors のインデックスを OpenSearch Serverless へ一方向・非同期でエクスポートするパターンです。当初は S3 Vectors でコスト優先の構成を運用し、クエリ頻度やレイテンシ要件が上がってきたタイミングで OpenSearch Serverless に段階移行する「Tier-up」の用途に向いています。エクスポート中は両サービスの費用が発生する点に注意が必要です。

OpenSearch Managed Cluster の S3 Vectors エンジン は、インデックス設定で engine: s3vector を指定することで、OpenSearch のストレージ層を S3 Vectors に差し替える恒久的な構成変更です。OpenSearch 2.19 以降が必要です。この構成ではハイブリッド検索が利用でき、OpenSearch のフルテキスト検索機能と組み合わせられます。

ただしこのエンジン利用時にはいくつかの機能制限があります。Snapshot、UltraWarm、Cross-cluster replication、Split/Shrink/Clone、Radial search は利用できません。top-K の上限は 100 で、通常の OpenSearch インデックスと同じです。

出典: OpenSearch + S3 Vectors engine (AWS)

請求書の構造を読む ── ストレージ・PUT・クエリの 3 層課金

S3 Vectors の課金は「ストレージ・PUT・クエリ」の 3 層で構成されています。以下は東京リージョン (ap-northeast-1) の単価です。1 USD = 155 円換算・確認日 2026-05-06。

出典: Amazon S3 料金 (AWS)

S3 Vectors に明示的な無料枠はありません。

PUT 料金の構造で特に注意が必要なのが最小課金単位です。1 回の PutVectors リクエストは最小 128 KB として課金されます。1 ベクトルずつ個別に書き込む構成では、実際のデータ量よりも PUT 料金が大きく膨らみます。バッチでまとめて書き込む実装が前提です。1 リクエストに最大 500 ベクトルを含めることができます。

クエリデータ処理料金の Tier はインデックスあたりのベクトル数で決まります。10 万ベクトル以下なら Tier 1 (USD 0.004278 / TB)、10 万を超えると Tier 2 (USD 0.002139 / TB) と半額になります。単価自体が TB あたり 0.66 円以下と極小であるため、クエリデータ処理はコスト全体に占める割合が小さく、PUT 料金・QueryVectors API 料金・ストレージ料金が主要なコストドライバとなります。大規模インデックスの方がクエリのデータ処理コストは低くなる設計です。

OpenSearch Serverless と比較したコスト感を把握するために、常時課金の有無が最大の違いになります。OpenSearch Serverless はインデックスユニットを最低 2 OCU (約 USD 0.24 / 時 × 2 = USD 0.48 / 時) 常時確保する構成です。クエリ頻度が低い場合、S3 Vectors の従量課金の方が総コストが抑えられます。逆に 1 日中クエリが発生するプロダクション構成では、OpenSearch Serverless の固定コストが相対的に有利になる場面もあります。

ストレージ単価は us-east-1 (USD 0.06 / GB-月) と比較して東京は約 10% 割高です。

参考として、Google Cloud の Vertex AI Vector Search と課金モデルを比較します。Vector Search は 2026 年 3 月に 2.0 が GA (Vector Search 2.0 の解説) となり、課金軸が 2 系統に分かれました。ANN インデックスをサービングする場合は Capacity Unit (CU) を時間課金で確保する設計 (パフォーマンス最適化 CU で $0.065 / 時間)、ANN を持たずに直接 KNN 検索を実行する場合は操作単位の従量課金 ($0.06 / 10 万読み取り、$0.18 / 10 万書き込み、ストレージ $0.000410959 / GiB / 時間) という構造です。

後者の KNN モードは S3 Vectors と同じく常時起動の Compute を持たない設計で、低 QPS の従量ワークロードでは課金モデルが S3 Vectors と近い性質を持ちます。継続稼働の大規模インデックスには CU 課金の ANN モードが向き、S3 Vectors の Storage-first モデルとはまた別の選択肢です。なお Vector Search 1.0 (per-VM-node-hour) も継続提供されており、既存運用は移行期間中も維持できます。

どのベクトルストアを選ぶか ── クエリ頻度・レイテンシ・ハイブリッド検索の 3 軸判断

S3 Vectors と他のベクトルストア選択肢を比較するとき、クエリ頻度・レイテンシ・ハイブリッド検索の必要性の 3 軸で論理的に切ることができます。なお、Aurora pgvector のようなリレーショナル DB ベースのベクトル機能は、既存 RDS 基盤との統合を前提とするため本フローでは対象外としています。

主要選択肢の比較

3 軸による選択フロー

① ハイブリッド検索の要否 キーワード検索とセマンティック検索を組み合わせた検索が必要な場合、S3 Vectors は選択肢から外れます。この要件がある場合は OpenSearch Serverless または OpenSearch Managed Cluster (S3 Vectors エンジン) を検討してください。

② レイテンシ要件 エンドユーザーが操作するリアルタイム検索で 100ms を超えるレイテンシが許容できない場合、S3 Vectors よりも OpenSearch Serverless や専用ベクトル DB の方が適しています。S3 Vectors が公式に示すレイテンシはウォーム状態で 100ms 以下ですが、コールド状態ではサブ秒 (数百 ms 台) まで伸びる可能性があります。バッチ処理・夜間の定期更新・開発環境での評価など、人が待たないユースケースであれば実用的な範囲です。

③ クエリ頻度 クエリ頻度が低い (1 日数十〜数百回程度) か、夜間バッチなど断続的な使い方であれば、S3 Vectors の完全従量課金が OpenSearch Serverless の常時 OCU 課金より合理的です。逆に 1 日を通じてクエリが発生し、OCU の常時課金分を使い切る量のリクエストがある場合は、OpenSearch Serverless の単価が相対的に有利になります。

Bedrock Knowledge Bases を使う場合、バックエンドとして S3 Vectors を選ぶのは次の 3 条件が重なる場面です。

• Bedrock エコシステムで完結させたい
• ハイブリッド検索は不要
• ストレージコスト最適化を優先したい

このいずれかが外れる場合は、Bedrock KB のバックエンドを OpenSearch Serverless に切り替えるか、S3 Vectors を直接利用する構成に戻って検討してください。

まとめ ── S3 設計思想がベクトルストアの使い分けを変える理由

S3 Vectors の本質は、「S3 と同じ耐久性・従量課金・ゼロプロビジョニング」という設計思想をベクトルストアに持ち込んだという選択です。Compute ノードのプロビジョニングが不要で、クエリしない間は課金が発生しない点が、従来のベクトル DB や OpenSearch Serverless との根本的な差です。

この設計が最もフィットするのは、バッチ型 RAG・オフライン埋め込み更新・開発環境での評価のように、クエリ頻度が低く、レイテンシに余裕があり、ハイブリッド検索が不要なユースケースです。

逆に、エンドユーザーが操作するリアルタイム検索でサブ秒以下の応答が必要な場合、またはキーワードとセマンティックを組み合わせたハイブリッド検索が必要な場合は、OpenSearch Serverless や専用ベクトル DB の方が設計上の整合性が高いと判断できます。

3 軸 (クエリ頻度・レイテンシ・ハイブリッド検索) を順に確認することで、S3 Vectors を採用すべき状況か、OpenSearch Serverless・Bedrock KB・専用ベクトル DB に切り替えるべき状況かを論理的に切り分けられます。

なお、S3 Vectors の SLA については、AWS の FAQ に可用性 99.99% / SLA 99.9% の記載があります。ただし、公式 S3 SLA ページに “vector buckets” の明示的な記載は 2026-05-06 時点で確認できていません。SLA を根拠に設計の前提を置く場合は、AWS サポートへの確認を推奨します。

参考文献

• Amazon S3 Vectors ユーザーガイド
• Amazon S3 Vectors features
• S3 Vectors と Bedrock Knowledge Bases の統合
• S3 Vectors と OpenSearch の統合
• S3 Vectors のリージョンとクォータ
• S3 Vectors の制限事項
• S3 Vectors インデックス
• S3 Vectors クエリ
• OpenSearch + S3 Vectors エンジン
• Amazon S3 料金ページ
• Amazon S3 Vectors GA 発表 (AWS What’s New, 2025-12-02)
• Amazon S3 Vectors GA ブログ (AWS Blog, 2025-12-02)
• Vertex AI core release notes (March 05, 2026 — Vector Search 2.0 GA)
• Vertex AI Vector Search 2.0 overview

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile