TL;DR

OpenSearch Serverless（AOSS）をバックエンドにしたAmazon Bedrock Knowledge Baseを運用している場合、ドキュメントを1件も取り込む前から月額約700ドルの最低料金が発生している。ほとんどの小中規模RAGワークロードでは、AOSSをAurora PostgreSQL Serverless v2 + pgvector拡張に置き換えることで、その最低料金が月額50ドル未満、つまり約90%のコスト削減になる。しかもBedrock Knowledge Baseの第一級ベクトルストアとして完全にサポートされた状態のままだ。

この記事では、実運用インフラをリファレンス実装として、理由、計算、トレードオフ、移行パスを解説する。

問題: AOSSには最低課金額が存在する

コンソールまたはTerraformでBedrock Knowledge Baseを作成すると、AWSはデフォルトのベクトルストアとしてOpenSearch Serverlessを推奨する。このデフォルトは便利だが、PoCでは見逃しやすく、本番では痛い価格設定の現実を隠している。

OpenSearch ServerlessはOpenSearch Compute Units（OCU）で課金される。

• インデックス作成に最低2 OCU
• 検索に最低2 OCU
• 本番モードでは冗長性の乗数が加算

つまり、非開発用コレクションでは最低4 OCUが必要になる。eu-west-1のオンデマンド料金は約1 OCU時間あたり0.24ドルなので: 4 OCU × $0.24/OCU時 × 730時間/月 ≈ $700/月

これが最低ラインだ。インデックスは空。トラフィックなし。クエリなし。コレクションが存在するだけでこれがかかる。

リーンなRAGユースケース（ドキュメントチャットボット、社内Q&Aアシスタント、サポート自動応答ボット）では、これがスタックの他のすべてを圧倒する。Bedrockモデル呼び出し、Lambda、API Gateway、S3を合わせても月額100ドル未満に収まることが多い。OpenSearchはほとんど仕事をしていないのに請求額の80〜90%を占めるのだ。

リファレンスワークロード

以下の数字は、本番AIインフラ（Terraform、eu-west-1）から取得したものだ。

つまり、完全に普通のSMBスケールのRAGワークロードだ。OpenSearch Serverlessが過剰にプロビジョニングされている種類のものだ。

なぜAurora Serverless v2 + pgvectorが適切な選択なのか

Amazon Bedrock Knowledge Baseは、OpenSearch Serverless、Pinecone、MongoDB Atlas、Redis Enterpriseと並んで、Amazon Aurora PostgreSQL互換をベクトルストアとして公式にサポートしている。これはハックやワークアラウンドではなく、AWSがドキュメント化した第一級の統合だ。

構成要素:

• Aurora Serverless v2はAurora Capacity Units（ACU）でコンピュートをスケールし、2024年後半からアイドル時の0 ACUへのスケーリングをサポートしている。
• pgvectorはベクトル類似度検索用の標準的なPostgreSQL拡張で、ivfflatおよびhnswインデックスタイプを備える。
• Bedrock Knowledge Baseは、テーブル、ベクトルカラム、HNSWインデックスがAWSの仕様に従って事前作成されていれば、Auroraクラスタを直接使用できる。

Titan v2 / 1024次元 / 数千チャンクというプロファイルでは、min_capacity = 0 / max_capacity = 2のAurora Serverless v2クラスタで取り込みも検索も十分に処理できる。

コスト比較

eu-west-1の現在のオンデマンド料金を代表的なベースラインとして使用する（必ず自分のリージョンで再計算すること）。

ざっくり言えば、ベクトルストアの行で10〜15倍のコスト削減、つまり環境あたり月額600ドル以上の節約になる。開発/ステージング/本番で掛け合わせると、年間の節約額は急速に大きくなる。

AOSSが依然として勝るケース

これは「pgvectorがOpenSearchに勝つ」という記事ではない。AOSSが依然として正しい選択であるケースは:

• 大規模インデックスで非常に高いQPSにおいてp99 100ms未満が必要な場合。
• コーパスが数千万ベクトル規模で増加中の場合。
• OpenSearchの全文検索機能を使ったハイブリッドキーワード+ベクトル検索が必要な場合。
• OpenSearchに付属するニューラルプラグイン、リランカー、セマンティックパイプラインが必要な場合。

その上限を下回るすべてのケース、つまり実世界のほとんどのRAGワークロードでは、Aurora + pgvectorは十分に高速で、劇的に安価だ。

移行手順

移行は簡単だが、事前に知っておくべきいくつかの注意点がある。

1. pgvector付きAurora Serverless v2をプロビジョニング

resource "aws_rds_cluster" "kb" {
  engine                      = "aurora-postgresql"
  engine_mode                 = "provisioned"
  engine_version              = "15.5"
  database_name               = "kb"
  master_username             = "kb_admin"
  manage_master_user_password = true
  storage_encrypted           = true
serverlessv2_scaling_configuration {
min_capacity = 0      # アイドル時にゼロスケール
max_capacity = 2
}
}
resource “aws_rds_cluster_instance” “kb” {
cluster_identifier = aws_rds_cluster.kb.id
instance_class     = “db.serverless”
engine             = aws_rds_cluster.kb.engine
engine_version     = aws_rds_cluster.kb.engine_version
}

初回接続時に以下を実行:

CREATE EXTENSION IF NOT EXISTS vector;
CREATE SCHEMA bedrock_integration;
CREATE TABLE bedrock_integration.bedrock_kb (
id        uuid PRIMARY KEY,
embedding vector(1024),
chunks    text,
metadata  json
);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING gin (to_tsvector(‘simple’, chunks));

カラム名と型（id、embedding、chunks、metadata）はBedrock Knowledge Baseが必須とするものだ。AWSの仕様に正確に従うこと。

2. DB認証情報をSecrets Managerに保存

Bedrock KBはSecrets Managerのシークレットからデータベース認証情報を読み取る。クラスタでmanage_master_user_password = trueを使用すれば、Auroraがそのシークレットを管理してくれるので、そのARNをKnowledge Baseの設定に渡すだけだ。

3. Knowledge Baseの指す先をOpenSearchからAuroraに変更

Terraformの場合、storage_configurationブロックを差し替える:

storage_configuration {
  type = "RDS"
  rds_configuration {
    resource_arn           = aws_rds_cluster.kb.arn
    credentials_secret_arn = aws_rds_cluster.kb.master_user_secret[0].secret_arn
    database_name          = aws_rds_cluster.kb.database_name
    table_name             = "bedrock_integration.bedrock_kb"
    field_mapping {
      primary_key_field = "id"
      vector_field      = "embedding"
      text_field        = "chunks"
      metadata_field    = "metadata"
    }
  }
}

S3データソース、チャンク戦略、埋め込みモデル、取り込みLambdaなど、上流のすべては同一のままだ。

4. 再取り込み

新しいKnowledge Baseに対して完全取り込みジョブをトリガーする。埋め込みはS3から再計算されるため、AOSSからAuroraへのデータ移行ステップは不要で、信頼できるソースからインデックスを再構築するだけだ。

5. OpenSearchコレクションを廃止

新しいKBで回答を検証した後にのみ行う。古いコレクションは1〜2週間保持しておくこと。重複期間のコストは、失敗したロールバック1回に比べれば取るに足らない。

本番運用の注意点

本番投入前に知っておくべきいくつかの点:

• コールドスタート。Aurora Serverless v2のゼロスケールからの復帰には約10〜15秒かかる。チャットボットに厳しいp99 SLAがある場合は、min_capacity = 0.5に設定すること。それでもAOSS比で約85%の節約になる。
• HNSWチューニング。デフォルトで始めて問題ない。大規模で再現率が低下した場合は、インデックスのmとef_construction、およびクエリ時のhnsw.ef_searchを調整する。
• バックアップ。Auroraのバックアップとスナップショットは自分の責任になる。OpenSearch Serverlessのスナップショットは自動だった。
• VPC。Bedrock KBからAuroraへの通信はVPC経由で行われる。サブネット、セキュリティグループ、Bedrockサービスロールが正しく配線されていることを確認すること。これは「コンソールでは動くが取り込みで失敗する」バグの最大の原因だ。
• スケーリングの上限。100万ベクトル以上で高QPSが持続する場合は再評価すること。pgvector + HNSWは優れているが、その領域ではAOSSや専用ベクトルDBが優位に立つ。

結論

Bedrockを使ったRAGアプリケーションの大多数（ドキュメントボット、ナレッジアシスタント、サポート自動化、社内Q&A）にとって、OpenSearch Serverlessは過剰設計で過剰価格だ。pgvectorを使ったAurora Serverless v2は、サポートされた本番グレードの代替手段であり、小中規模では桁違いに安く、移行も数週間ではなく数時間で完了する。

FinOpsチームが「軽量チャットボット」になぜ月額800ドル以上かかるのかと疑問を呈しているなら、その答えはほぼ確実にOpenSearchの請求明細にある。ベクトルストアを交換し、他のすべてをそのままにして、予算を取り戻そう。

eu-west-1でBedrock Knowledge Baseを運用した実経験に基づく。価格と設定は2026年4月時点のAWSを反映している。移行を決定する前に、必ず自分のリージョンの最新の価格とサービスクォータを確認すること。