AgentCore RuntimeをVPC内から実行する際に必要なVPCエンドポイントたち

皆さんAgentCore触ってますか？わたしは触ってません（白目）
フロントエンド分からないインフラ民、AgentCoreのテンプレート作りやらアプリデプロイ周りのハードルに負けています。ｾﾂﾅｲﾈ。

さてさて、本日はフロントエンドを作ってくれた方から「VPC内にAgentCoreデプロイしたけど、アプリ実行時にタイムアウトになってそうなんだよね」というお話を頂き、ネットワーク関連どこか詰まってるんだろうなとインフラレイヤーのわたしが調査をさせてもらいました。

まずは結論

• VPCエンドポイントに不足が無いか確認する
• VPCエンドポイントのセキュリティグループが疎通可能な設定となっているか確認する
• アプリケーションによって必要なVPCエンドポイントは変わるので注意

ちなみに、今回のわたしが見た内容では「X-Ray」のVPCエンドポイントが不足していました。予想外のエンドポイントが出てきて、結構ややこしい通信をしてそうだなと少し踏み込んで確認していきます。

AgentCoreプライベート通信に必須なサービス

基本的には以下の443通信の疎通が必要になります。

接続先	サービス名	概要
bedrock-runtime	com.amazonaws.[region].bedrock-runtime	AIモデルへの推論リクエスト
bedrock-agentcore	com.amazonaws.[region].bedrock-agentcore	エージェント実行/Identity機能の利用

その他必要に応じて必要なサービス

各アプリケーションの設定によっても変わりますが、AgentCoreが関わってきそうな箇所として以下が思い当たります。

接続先	サービス名	概要
bedrock-agentcore.gateway	com.amazonaws.[region].bedrock-agentcore.gateway	ツール呼び出しに利用
ecr.dkr	com.amazonaws.[region].ecr.dkr	Code Interpreter 等のツール環境の起動
ecr.api	com.amazonaws.[region].ecr.api	Code Interpreter 等のツール環境の起動
s3	com.amazonaws.[region].s3	リポジトリデータ取得に利用
logs	com.amazonaws.[region].logs	CloudWatchへログ出力
xray	com.amazonaws.[region].xray	Observabilityに利用

以上で本記事の内容は全てになります。
以下からはサンプルアプリケーションから実際に通信設定を深堀りしてみようの内容となります。

興味がある方はどうぞご参照ください。

デモアプリ（AgentCoreプライベートVPC）

実際に見てみないと分からない箇所もあるので、awslabsに公開されているAgentCoreのサンプルアプリケーションから確認してみましょう。

customer-support-assistant-vpc

色々漁ってみたところ、AgentCoreのVPC運用に関するサンプルがawslabsの「amazon-bedrock-agentcore-samples」に公開されていました。

This is a customer support agent implementation using Amazon Bedrock AgentCore deployed in a fully private VPC environment.

2025/8月の情報になりますが、構成図も揃ってる優れモノ。もはやこれを生成AIに食わせれば答えが概ね出てくると言っても過言では無いです。

構成図

画像をGithub上から拝借します。

自己理解のためにメモ

「AgentCore の Agent Runtime が、Gateway と MCP Runtime を MCP で呼び出して使っている」 アプリです。

データの流れ（誰が何を呼ぶか）

ユーザー（フロント or テストスクリプト）
    │
    ▼ HTTP（JWT 認証）
┌─────────────────────────────────────────────────────────┐
│  Agent Runtime（AgentCore・VPC 内）                      │
│  Strands Agent + Bedrock LLM                            │
│  ・プロンプトに応じて「どのツールを呼ぶか」を判断               │
└─────────────────────────────────────────────────────────┘
    │
    ├── MCP クライアント → AgentCore Gateway（MCP）
    │       └── Lambda → DynamoDB
    │           ・get_customer_profile（顧客プロフィール）
    │           ・check_warranty_status（保証状況）
    │
    ├── MCP クライアント → AgentCore MCP Runtime（DynamoDB MCP）
    │       └── ツール: レビュー・製品の取得など
    │
    └── MCP クライアント（stdio）→ Aurora 用 postgres-mcp-server
            └── ツール: Users / Products / Orders（Aurora PostgreSQL）

実際に作成されるリソース内容を確認する

一部コード修正が必要だったので注意が必要です。

コード修正：aurora-postgres-stack.yaml

デフォルトのコードではFailedになりました。AuroraStackでコケてそうです。

02-use-cases/customer-support-assistant-vpc/cloudformation/aurora-postgres-stack.yamlを参照してみます。

PostgreSQLなのに、なぜMySQLのポート3306が変ですね。
3306の部分をpostgresqlの5432書き換えておきましょう。

      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 5432
          ToPort: 5432
          SourceSecurityGroupId: !Ref LambdaSecurityGroup
          Description: 'PostgreSQL access from Lambda functions'
        - IpProtocol: tcp
          FromPort: 5432
          ToPort: 5432

上記設定変更したところデプロイに成功しました

0. 事前準備

README.mdを参考に。
https://github.com/awslabs/amazon-bedrock-agentcore-samples/blob/main/02-use-cases/customer-support-assistant-vpc/README.md

• AWSアカウントの準備
• AWS CLIのインストールと設定
• uvのインストール（手順）
• Anthoropicのモデルが利用出来るように申請を出す
  • みのるんさん記事を参考に
    • Bedrockのモデルアクセス有効化が不要に！ でもClaudeは初回のみ別操作が必要😣）

構築する

• リポジトリをコピーした後に下記ディレクトリへ移動します

git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/02-use-cases/customer-support-assistant-vpc

• デプロイスクリプトを実行可能にして実行します

chmod +x deploy.sh
./deploy.sh --help

※オプションが色々出てくれば実行出来ているので次に行きます。

• オプションを指定して環境を構築

./deploy.sh --model global.anthropic.claude-haiku-4-5-20251001-v1:0 --region us-west-2 --env dev --email <EmailAddress> --password <Password>

※emailとpasswordはCognitoへ登録されるファーストユーザです。デモアプリのフロントエンドへサインインする際に必要となります。

deploy.sh実行後に下記が表示されたら[y]を押して実行します。

========================================
Customer Support VPC Stack Deployment
========================================

Stack Name:   customer-support-vpc-dev
S3 Bucket:    customersupportvpc-vdve21m18bzn
Region:       us-west-2
Environment:  dev
DB Username:  postgres
Model ID:     global.anthropic.claude-haiku-4-5-20251001-v1:0
Admin Email:  [e-mail]
Password:     ******** (hidden)
Continue with deployment? (y/n): 

30-40分くらい構築に時間がかかりそうです。

作成される14個のVPCエンドポイント

オレゴンリージョン（us-west-2）に出来上がる14個のVPCエンドポイント。

（削除し忘れたら破産しそうですね）

AgentCore関連：3つ作成

• Runtime

  • csvpcAgentRuntime：親エージェント
  • csvpcMCPDynamoDBRuntime：MCPツール（子エージェント）
    

• Gateway

  • test-customer-support-vpc：Lambda実行
    

• Identity

  • アウトバウンド認証
    • GatewayOAuth2Provider-csvpc-test
    • MCPOAuth2Provider-csvpc-test

メモリには作成されたものは無し。

VPC内にフロントエンド作成必要？

とりあえずREADME.mdを信じてローカル端末上にフロントエンドを構築しました。

cd frontend
npm install

chmod +x ./setup-env.sh
./setup-env.sh

npm run dev

• Identityへの接続は可能っぽい（Cognito画面表示→認証はOK）
• localhost→AgentCoreへの接続で会話が表示されない

一旦検証としては不完全燃焼ですが以上になります。
本当はプライベート接続であればつながるよね？など行いたかったのですが、構成変更や追加がしんどそうなのでひとまずは必要なプライベート通信が何か？の参考までに確認でした。

後片付け

• 構築後に手動で構成変更するとshによる削除に影響が出ます
• AgentCore Runtime はVPC 内にENI を作成します
  • これらの ENI はサービスによって自動的に削除されるまでに約 8 時間かかります。
  • ENI が削除された後、VPC スタックを手動で削除してください

REAMDE.mdのコマンドではスタック名がcustomer-support-vpcになってしまいます。
スタック名に環境名を付与していた際はオプションでスタック名を設定して削除しましょう。

# Make it executable
chmod +x cleanup.sh

./cleanup.sh --help

# Delete all stacks except VPC
./cleanup.sh --delete-s3 --region us-west-2 -s customer-support-vpc-dev

構築時と同じく30分ほど経過して削除が完了します。

最後に

プライベート通信を行おうとすると考慮事項が増えます。

・AgentCoreのどの機能にどの通信が必要か？
・構築するアプリケーションにどのプライベート通信が必要か？

など、詰まった際の参考になれば幸いです。

サンプルアプリケーションも、構築まで行おうとすると詰まる箇所が多いため構成の参考にする程度で留めるのが良いなと試して実感した次第です。（力尽きました）

参考