「社内のドキュメントをAIに読ませてQ&A検索システムを作りたいが、BedrockとOpenSearch Serverlessをどう組み合わせればいいのか、VPCの閉域設計はどこから手を付ければいいのかわからない。」
AWS上でRAG(Retrieval-Augmented Generation)システムを構築しようとすると、LLMのAPI呼び出しだけでなく、ベクターDBの選定、プライベートネットワーク経由でのサービス間通信、セキュリティグループとIAMロールの権限設計が同時に絡み合います。
この記事では、Amazon BedrockとAmazon OpenSearch Serverlessを組み合わせたRAGアーキテクチャの設計方針と、VPC内閉域構成の具体的な設計パターンを解説します。想定環境はAWS ap-northeast-1(東京)リージョンを対象とし、インターネットゲートウェイを経由しないプライベート通信設計を前提としています。
この記事のポイント
・AWS RAGはBedrock(LLM・Embedding)+OpenSearch Serverless(ベクターDB)+Lambdaの3層構成
・LambdaからBedrockとOpenSearchへはVPC Interface Endpointで閉域通信を実現する
・セキュリティグループはSG ID参照でLambda->VPCエンドポイント間のHTTPS 443のみ許可する
・OpenSearch ServerlessはネットワークポリシーでVPC限定アクセスに設定する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
RAGアーキテクチャとAWSサービスの役割分担
RAG(Retrieval-Augmented Generation)は、ユーザーの質問に対してベクターデータベースから関連ドキュメントを検索(Retrieval)し、その内容をコンテキストとしてLLMに渡して回答を生成(Generation)するアーキテクチャです。
「検索して答える」という仕組みにより、モデルが学習していない社内情報や最新情報を回答に反映できるのが最大の特徴です。AWS上でRAGを構築する際の主要コンポーネントは以下のとおりです。
・Amazon Bedrock:Claude 3やAmazon Titan等のLLM呼び出し(InvokeModel)と、ドキュメントのEmbedding(ベクター変換)を担当します。
・Amazon OpenSearch Serverless:k-NNインデックスによるベクター類似度検索が可能なマネージド型のベクターDBです。クラスター管理が不要なサーバーレス形式で動作します。
・AWS Lambda:ドキュメント投入パイプラインとクエリ処理パイプラインを担うオーケストレーション層です。
・VPC Interface Endpoint:LambdaからBedrockおよびOpenSearch ServerlessへのAPI通信をVPC内に閉じ込めるプライベートルーティングです。
この4層の連携が設計の核心であり、中でもVPC通信経路の設計がシステムのセキュリティ要件を左右します。
VPCアーキテクチャの設計方針
1. サブネット設計
RAGシステムのコンポーネントはすべてプライベートサブネットに配置します。LambdaもOpenSearch Serverlessも外部からの直接アクセスを必要としないため、インターネットゲートウェイを経由しない閉域構成が実現できます。NATゲートウェイも不要です(VPCエンドポイント経由でBedrockとOpenSearchに到達するため)。
可用性確保のため、マルチAZ(ap-northeast-1aとap-northeast-1c)に2つのプライベートサブネットを作成します。
# VPCとサブネットの設計例(CIDRは環境に合わせて変更) VPC CIDR: 10.0.0.0/16 # Lambdaおよびエンドポイント配置用プライベートサブネット Private Subnet A (ap-northeast-1a): 10.0.1.0/24 Private Subnet C (ap-northeast-1c): 10.0.2.0/24 # インターネットゲートウェイ: 不要(BedrockとOpenSearchへはVPCエンドポイント経由) # NATゲートウェイ: 不要(外部へのHTTP通信なし)
2. セキュリティグループ設計
Lambda用セキュリティグループとVPC Endpoint用セキュリティグループを分けて定義し、最小権限の原則を徹底します。
# sg-lambda(Lambda関数に適用) インバウンド : なし アウトバウンド: HTTPS(443) -> sg-vpce-bedrock (Bedrock Runtime VPCエンドポイントSGを指定) HTTPS(443) -> sg-vpce-aoss (OpenSearch Serverless VPCエンドポイントSGを指定) # sg-vpce-bedrock(Bedrock RuntimeエンドポイントENIに適用) インバウンド: HTTPS(443) <- sg-lambda からの通信を許可 アウトバウンド: なし # sg-vpce-aoss(OpenSearch ServerlessエンドポイントENIに適用) インバウンド: HTTPS(443) <- sg-lambda からの通信を許可 アウトバウンド: なし
セキュリティグループのルールはCIDRではなくSG IDの参照形式で記述します。LambdaのENI IPが変わってもルール修正が不要となり、意図しないIPからのアクセスを防ぎます。
3. VPC Interface Endpointの設定
BedrockとOpenSearch Serverlessへのプライベートアクセスには、それぞれInterfaceタイプのVPCエンドポイントが必要です。
・com.amazonaws.ap-northeast-1.bedrock-runtime:LLM推論(InvokeModel)とEmbedding生成に使います。
・com.amazonaws.ap-northeast-1.aoss:OpenSearch Serverlessへの検索・インデックス操作に使います。
エンドポイントは「プライベートDNS有効」で設定します。これによりLambda内のコードは通常のBedrockサービスエンドポイント(bedrock-runtime.ap-northeast-1.amazonaws.com)をそのまま使え、エンドポイント固有のURLを意識する必要がありません。
# Bedrock Runtime VPCエンドポイント作成例(AWS CLI) aws ec2 create-vpc-endpoint --vpc-id vpc-XXXXXXXXX --vpc-endpoint-type Interface --service-name com.amazonaws.ap-northeast-1.bedrock-runtime --subnet-ids subnet-AAAAAAA subnet-BBBBBBB --security-group-ids sg-vpce-bedrock-id --private-dns-enabled # OpenSearch Serverless VPCエンドポイント作成例 aws ec2 create-vpc-endpoint --vpc-id vpc-XXXXXXXXX --vpc-endpoint-type Interface --service-name com.amazonaws.ap-northeast-1.aoss --subnet-ids subnet-AAAAAAA subnet-BBBBBBB --security-group-ids sg-vpce-aoss-id --private-dns-enabled
出力例(環境により異なります):
{ "VpcEndpoint": { "VpcEndpointId": "vpce-0123456789abcdef0", "VpcEndpointType": "Interface", "State": "pending", "ServiceName": "com.amazonaws.ap-northeast-1.bedrock-runtime", "PrivateDnsEnabled": true } }
OpenSearch Serverlessのアクセスポリシー設計
OpenSearch Serverlessへのアクセスには3種類のポリシーをそれぞれ設定します。この3層構造はOpenSearch Serverless固有の仕様であり、通常のOpenSearch Serviceとは異なります。
・ネットワークポリシー:VPCエンドポイント経由のみアクセスを許可し、パブリックアクセスを無効にします。コレクション(インデックス操作用)とダッシュボード(管理UI用)それぞれに設定が必要です。
・暗号化ポリシー:コレクションデータをAWS管理キーまたはカスタマー管理KMSキーで暗号化します。
・データアクセスポリシー:Lambda実行ロールのARNに対して、インデックスの読み書き権限(aoss:ReadDocument・aoss:WriteDocuments・aoss:CreateIndex・aoss:DescribeIndex)を付与します。
AWSのクラウドサービスをLinux環境から操作する基礎を固めておくと、設計作業が格段にスムーズになります。AWS Amazon Linux環境の基本設定と操作方法の入門ガイドも参考にしてみてください。
LambdaでRAGパイプラインを実装する手順
4. IAMロールの設計
Lambda実行ロールには最小権限の原則に基づき以下のポリシーを付与します。
・bedrock:InvokeModel(Bedrock呼び出し権限):使用するモデルARNをResourceで限定することで、予期しないモデルへのアクセスを防ぎます。
・aoss:APIAccessAll(OpenSearch Serverless権限):コレクションへのアクセスに必要です。コレクションARNをResourceで限定します。
・VPC接続基本権限:ec2:CreateNetworkInterface / ec2:DescribeNetworkInterfaces / ec2:DeleteNetworkInterfaceはLambdaをVPC内で実行するために必須です。AWSマネージドポリシー「AWSLambdaVPCAccessExecutionRole」に含まれています。
5. PythonでのRAGクエリ実装パターン
LambdaからBedrockのEmbeddingとOpenSearch Serverlessのk-NN検索を呼び出す基本パターンを示します。
import boto3, json from opensearchpy import OpenSearch, RequestsHttpConnection from requests_aws4auth import AWS4Auth REGION = "ap-northeast-1" # Bedrock clientの初期化(VPCエンドポイント経由で自動ルーティング) bedrock = boto3.client("bedrock-runtime", region_name=REGION) # OpenSearch Serverlessの認証設定(SigV4認証) credentials = boto3.Session().get_credentials() awsauth = AWS4Auth( credentials.access_key, credentials.secret_key, REGION, "aoss", session_token=credentials.token ) aoss_client = OpenSearch( hosts=[{"host": "コレクションID.ap-northeast-1.aoss.amazonaws.com", "port": 443}], http_auth=awsauth, use_ssl=True, connection_class=RequestsHttpConnection ) def get_embedding(text: str) -> list: # Amazon Titan Embeddings V2でEmbeddingを生成(1024次元) response = bedrock.invoke_model( modelId="amazon.titan-embed-text-v2:0", body=json.dumps({"inputText": text}) ) return json.loads(response["body"].read())["embedding"] def search_documents(query: str, k: int = 3) -> list: query_embedding = get_embedding(query) body = { "size": k, "query": { "knn": { "embedding": {"vector": query_embedding, "k": k} } } } response = aoss_client.search(index="documents", body=body) return [hit["_source"]["content"] for hit in response["hits"]["hits"]]
RAGパイプラインのトラブルシュート
「EndpointConnectionError」が出る場合
LambdaからBedrockやOpenSearch ServerlessへのHTTPS通信が届かない場合、以下の順序で確認します。
・LambdaのVPC設定でプライベートサブネットとセキュリティグループが正しく設定されているか確認します。
・VPCエンドポイントのENIがLambdaのサブネットと同一AZに配置されているか確認します(AZ不一致は通信不能になります)。
・LambdaのセキュリティグループのアウトバウンドルールがVPCエンドポイントSGに対してTCP 443を許可しているか確認します。
「AccessDeniedException」が出る場合
IAMとOpenSearchポリシーの両方を確認します。
・Lambda実行ロールにbedrock:InvokeModelとaoss:APIAccessAllが付与されているか確認します。
・OpenSearch ServerlessのデータアクセスポリシーにLambda実行ロールのARNが含まれているか確認します。
・BedrockコンソールのModel accessページで対象モデルのアクセスが有効化されているか確認します(デフォルトは無効です)。
ベクター検索の精度が低い場合
・ドキュメントのチャンキングサイズを調整します。一般的には500~1000トークン程度が目安です。
・EmbeddingモデルとOpenSearchインデックスのベクター次元数が一致しているか確認します(Titan Embeddings V2は1024次元)。
・OpenSearchのk-NNインデックスエンジンをfaissに変更すると大規模コレクションでの精度と速度が改善するケースがあります。
本記事のまとめ
BedrockとOpenSearch Serverlessを使ったAWS RAGアーキテクチャのVPC設計をまとめます。
| 設計要素 | 設定内容 |
|---|---|
| サブネット | マルチAZのプライベートサブネット(NATゲートウェイ不要の閉域構成) |
| Bedrock VPCエンドポイント | com.amazonaws.ap-northeast-1.bedrock-runtime(プライベートDNS有効) |
| OpenSearch Serverless VPCエンドポイント | com.amazonaws.ap-northeast-1.aoss(プライベートDNS有効) |
| セキュリティグループ | Lambda SG→VPCエンドポイントSG(HTTPS 443・SG ID参照) |
| IAMロール | bedrock:InvokeModel(モデルARN限定)+aoss:APIAccessAll+EC2ネットワーク権限 |
| OpenSearchポリシー | ネットワーク(VPC限定)・暗号化・データアクセス(Lambda ARN)の3層設定 |
| Embedding次元数 | Titan Embeddings V2 = 1024次元(インデックスと必ず一致させる) |
AWS上でRAGシステムを設計する際は、VPCエンドポイントによる閉域化とIAM・OpenSearchの3層ポリシー設計が、セキュリティと可用性の核心となります。BedrockとOpenSearch Serverlessを組み合わせることで、インフラ管理の負荷を最小化しながら本番品質のRAGアーキテクチャを構築できます。
AWS Amazon Linux環境の構築・設定を基礎から体系的に学べる無料入門ガイドです。BedrockやOpenSearch Serverlessを動かすLinux基盤の扱いをしっかり押さえておきましょう。
>> AWS Amazon Linux 無料入門ガイドを確認する
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWSアーキテクチャパターン入門|3層Web・サーバーレス・イベント駆動の構成設計と選定基準
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます