本番RAGのアーキを選ぶ — Bedrock Managed KB / S3 Vectors / 自前の損得をTCOで比較する
本番RAGの構成は『全部任せる(Bedrock Managed KB)／自分で選ぶ(S3 Vectors)／自前で持つ(OpenSearch・pgvector)』の3択です。違いの本質は機能ではなく課金モデル＝固定費か変動費か。東京リージョンの単価でTCOの損益分岐を机上計算し、規模別にどれを選ぶかを整理します。単価は2026年6月18日時点・東京・参考値で、公式pricingとPricing Calculatorでご確認ください。
- #RAG
- #AWS
- #Bedrock Knowledge Bases
- #S3 Vectors
- #OpenSearch
- #pgvector
- #TCO
- #コスト最適化
PoCのRAG（検索した文書を生成AIに渡して回答させる仕組み）は動いた。しかし本番に移すと、毎月いくらかかるのかが急に読めなくなります。本記事は、RAGの本番構成を「全部任せる／自分で選ぶ／自前で持つ」の3択に整理し、TCO（総保有コスト）の観点でどれを選ぶかを決められるようにします。鍵は、RAGのコストが固定費か変動費かで本質的に分かれるという点です。対象はRAGを本番化する設計担当の上級エンジニアで、RAGの基礎説明は省きます。
本番で読めなくなる3つのコスト
本番RAGで効いてくるコストは、おおまかにストレージ、retrieval（検索）、埋め込み・再ランクの3つです。ストレージはベクトルとメタデータを保持するコストで、文書量に比例します。retrievalは1クエリごとにベクトルストアへ問い合わせるコストで、トラフィックに比例します。埋め込み・再ランクは、文書やクエリをベクトル化し、検索結果を並べ替えるモデル呼び出しのコストです。
重要なのは金額そのものより、それが変動費（使った分だけ）か固定費（常時発生）かという課金モデルの違いです。ここが3構成を分ける軸になります。なお、埋め込みや基盤モデルのトークン課金は3構成に共通する外部要素のため、本記事の比較からは分離して扱います（混ぜると損益分岐が歪むためです）。以下の単価はすべて東京リージョン・2026年6月18日時点の参考値で、公式pricingとPricing Calculatorでの確認を前提とします。
構成A 全部任せる（Bedrock Managed KB）
取り込みから検索、ベクトルストア、埋め込み・再ランクまでを自動で受け持つフルマネージド構成です。インフラとモデル選定を自動管理するため、構築は不要です。課金は変動費で、トラフィックがゼロに近ければ安く済みます。
| 課金要素 | 単価（東京・2026-06-18時点・参考値） |
|---|---|
| インデックスストレージ | $5.00 / GB（raw）/ 月 |
| 標準 Retrieval | $1.00 / 1,000 calls |
| Agentic Retrieval | $4.00 / 1,000 ＋ underlying $1.00 / 1,000 |
注意点が2つあります。1つはagentic retrievalで、1回が内部で複数ホップ（underlying Retrieve）を呼ぶため、固定倍率ではなくクエリの複雑さ次第で割高になります。もう1つはクォータ（KB100・データソース5・Retrieve 20 rpsなど）が調整不可である点です。機能の詳細はBedrockマネージドナレッジベースの解説を参照してください。向くのは小〜中規模・短納期・運用人員が薄いケースです。
構成B 自分で選ぶ（S3 Vectors 直接）
ベクトルストアにS3 Vectorsを直接使い、チャンク戦略やモデルを自分で選ぶ構成です。ストレージとクエリは非常に安い一方、埋め込み・チャンク・再ランク・オーケストレーションは自前になります。
| 課金要素 | 単価（東京・2026-06-18時点・参考値） |
|---|---|
| ベクトルストレージ | $0.06 / GB・月（論理量） |
| PUT（アップロード） | $0.20 / GB |
| クエリ（リクエスト） | $2.5 / 100万クエリ |
| クエリ（データ処理） | 最初の10万ベクトル $0.004/TB、超過 $0.002/TB |
大規模（1,000万ベクトル超）ではクエリ料金が自動で最大80%削減されます。Aの手軽さを手放す代わりに、コストと精度を握れるのが利点です。機能の詳細はS3 Vectors GAの解説を参照してください。向くのは中〜大規模で、コストや精度を自分で制御したいケースです。
構成C 自前で持つ（OpenSearch / pgvector）
OpenSearchやpgvectorを自前で運用する構成です。最大の制御と引き換えに運用負荷を負い、課金はインスタンス時間に対する固定費（常時起動）になります。
| 項目 | レート（東京・on-demand list・2026-06-18時点） |
|---|---|
OpenSearch r6g.large.search | $0.202 / instance-hour |
| EBS gp3 ストレージ | $0.096 / GB・月 |
Aurora db.r6g.large（Standard） | $0.313 / hour |
| Aurora Standard ストレージ / I/O | $0.12 / GB・月 ／ $0.24 / 100万 I/O |
| pgvector | $0（OSS拡張・追加課金なし） |
I/Oの多いRAGではAurora I/O-Optimized（インスタンス$0.407/h・ストレージ$0.27/GB・月・I/O課金なし）が有利な場合があり、TCOでどちらの構成かを明示します。これらの値は鮮度が重要なため、本番試算ではAWS Pricing Calculatorで東京リージョンの実値を確認してください。向くのは大規模・特殊要件・既存資産があるケースです。
規模別TCO：固定費と変動費の損益分岐
ここが本記事の核です。次の前提で机上計算します。東京・on-demand list・2026年6月18日時点、インデックスはraw 10GB、月間の標準retrievalは10万回、ベクトル規模は約100万、構成Cは常時起動（730時間/月）。埋め込み・基盤モデルのトークン課金は別建てです。
| 構成 | 概算月額（前提下） | 費用の型 |
|---|---|---|
| A Managed KB | ストレージ$50 ＋ retrieval$100 ≒ $150/月 | 変動費（retrievalゼロなら$50） |
| B S3 Vectors直接 | ストレージ主体で数〜十数$/月（＋自前運用） | 変動費（最安）／運用工数は別 |
| C OpenSearch | $0.202×2×730 ＋ EBS ≒ $304/月 | 固定費（トラフィックゼロでも発生） |
| C pgvector(Aurora) | $0.313×730 ＋ ストレージ ≒ $240+/月 | 固定費 |
変動費のAと固定費のC（OpenSearch）が交わる点が損益分岐です。
50 + 0.001 × N = 304.9 → N ≒ 255,000 retrieval/月
つまり月25万retrievalあたりを境に、それ未満なら変動費のAが安く、超過すると固定費のCが逆転して安くなります（純インフラ比較）。BはこのグラフでA・Cより低い水準を横ばいで進みますが、その分の埋め込みやオーケストレーションを自前で組む工数が別途かかる点を忘れてはいけません。
単価は時点や前提で変わりますが、変動費の線が右肩上がり、固定費の線が水平、その交点が分岐という構造自体は変わりません。だからこそ、特定の金額を覚えるより、自分の案件のretrieval数がこの交点の左右どちらにあるかを掴むことが判断材料になります。
選定フローと本番の落とし穴
机上の損益分岐は出発点に過ぎません。本番では次の補正が効きます。まずロックインで、AはAPI互換のため移行が容易（新KB IDへの差し替え）、Cは資産化する反面、移行コストを抱えます。次にagentic retrievalの課金増で、複数ホップを前提にするとAの変動費が膨らみ、分岐点はC有利の方向へ動きます（採用時は前提ホップ数を明記します）。さらにAのクォータ調整不可、低トラフィック時にCの固定費が遊ぶ問題があります。
構成Cの中でも課金構造の選択が残ります。AuroraはStandardとI/O-Optimizedで料金体系が異なり、I/Oが多いRAGワークロードではI/O課金のないI/O-Optimizedが結果的に安くなる場合があります。どちらを前提にTCOを出すかで分岐点が動くため、試算時にどちらの構成かを明示します。
そして見落とされがちなのが、Cに乗る運用労務という「見えない固定費」です。SRE工数・パッチ適用・スケール・冗長化は月額に現れませんが確実にコストです。これを織り込むと、損益分岐は実際にはCに不利な方向へ動きます。本番設計では、検索層をどう監視・運用するかも含めて判断する必要があります（検索層を含むエージェントの本番運用の設計では可観測性やコスト上限の観点を扱っています）。
まとめ：選定チェックリスト
最後に、4つの軸で3構成を選ぶ視点を整理します。
| 軸 | A Managed KB | B S3 Vectors | C 自前 |
|---|---|---|---|
| トラフィック量 | 低〜中 | 中〜大 | 高・常時 |
| 運用体制 | 薄くてよい | 中（自前パイプライン） | 厚い（SRE前提） |
| 制御・精度要件 | 自動管理で十分 | 握りたい | 最大限握る |
| ロックイン許容 | 移行容易 | 中 | 資産化 |
RAGの構成選びは、機能の優劣ではなく課金モデルと運用体制の選択です。損益分岐の構造を押さえ、自分の案件のトラフィックと運用体制に当てはめれば、3択は判断できます。単価は改定されうるため、本番試算の前に公式pricingとPricing Calculatorで東京リージョンの最新値をご確認ください。
出典
単価は東京リージョン・2026年6月18日時点の参考値です。改定されうるため、本番試算の前に各公式pricingとAWS Pricing Calculatorで最新値をご確認ください。
- 構成A Bedrock Managed KB（ストレージ/Retrieval/Agentic Retrieval・クォータ）: Amazon Bedrock 料金 ／ Amazon Bedrock のクォータ
- 構成B S3 Vectors（ストレージ/PUT/クエリ・大規模割引）: Amazon S3 料金
- 構成C OpenSearch（インスタンス時間）: Amazon OpenSearch Service 料金
- 構成C EBS gp3（ストレージ）: Amazon EBS 料金
- 構成C Aurora（Standard / I/O-Optimized・ストレージ・I/O）: Amazon Aurora 料金
- pgvector（PostgreSQL拡張・OSS）: pgvector ／ Aurora PostgreSQL でのベクトル検索
規模別TCOの概算月額・損益分岐（約25万retrieval/月）は、上記公式料金の単価と本文に明記した前提から算出した机上計算値です。