はじめに
こんにちは！askenでSRE/インフラエンジニアをしている小林です。
普段は「あすけん」アプリのインフラ全般の企画から運用まで一貫して対応しています。
今回は、Amazon Bedrock AgentsのAgentCore Runtimeに対して、別AWSアカウントからアクセスする方法を試してみた話をお届けします。
この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/16の記事です。
やりたかったこと
アカウントAからアカウントBにあるAgentCore Runtimeへリクエストを送りたい！
これがシンプルにやりたかったことです。
なぜこれをやろうと思ったか
いくつか理由があります。
- AgentCore Runtimeが東京リージョンにGAされた！ ので、触ってみたくなった
- 今後AIエージェント開発でよく使う可能性がありそうと感じた
また、実際に開発するときには下記の理由からAgentCore Runtimeを使うAWSアカウントを分ける可能性がありそうです。
- AI関連のコストを把握しやすくするためにアカウントを分けたい
- AWSコストを負担する部署が異なるので分離したい
- マイクロサービスごとに主管チームが異なり、AWSアカウント自体が分割されている
結論
先に結論だけ書きます。
| 方式 | 結果 |
|---|---|
| インターネット経由でのリクエスト | 実現した |
| 内部通信でのリクエスト | （たぶん）あと一歩 |
実現したい構成
実現したいことの大まかな構成は以下のような感じです。
graph LR
subgraph アカウントA
Kong[Kong Gateway]
end
subgraph アカウントB
AgentCore[AgentCore Runtime]
end
Kong --> AgentCore
アカウントA側ではKong Gatewayを使ってProxyする構成にしました。
Kong Gatewayは最近よく見かけるようになりましたが、触る機会がなかったので、ついでに試してみることに。
Kong Gatewayについて少し補足します。
オープンソースのAPIゲートウェイで、認証・認可、レート制限、ロギングなどの機能をプラグインで追加できます。
NginxベースでありながらLuaで拡張可能なため、高いパフォーマンスと柔軟性を両立しています。
選択肢の整理
各社の環境によって取れる選択肢は変わりますが、今回はお試しなので、実際に使えそうなものをリストアップして検討しました。
（★がついているものは今回試したアーキテクチャです）
| No. | 種別 | アーキテクチャ | 今回検証 |
|---|---|---|---|
| 1 | インターネット経由 | アカウントA（Kong Gateway） → API Gateway REST API + Lambda → AgentCore Runtime | ★ |
| 2 | インターネット経由 | アカウントA（Kong Gateway） → CloudFront + OAC + Lambda Function URL → AgentCore Runtime | |
| 3 | インターネット経由 | アカウントA（Kong Gateway） → API Gateway HTTP API + Lambda → AgentCore Runtime | |
| 4 | インターネット経由 | アカウントA（Kong Gateway） → CloudFront → AgentCore Runtime | |
| 5 | インターネット経由 | アカウントA（Kong Gateway） → Lambda Function URL → Lambda → AgentCore Runtime | ★ |
| 6 | インターネット経由 | アカウントA（Kong Gateway） → AgentCore Runtime（パブリックエンドポイント） | ★ |
| 7 | 内部通信 | アカウントA（Kong Gateway） → VPC Lattice → AgentCore Runtime | ★ |
| 8 | 内部通信 | アカウントA（Kong Gateway） → PrivateLink → AgentCore Runtime | ★ |
実現した方法と失敗した方法
詳細な設定方法や設定値は今回割愛します。
実現した方法
No.1: API Gateway REST API + Lambda（インターネット経由）
graph LR
subgraph アカウントA
Kong[Kong Gateway]
end
subgraph アカウントB
APIGW[API Gateway REST API]
Lambda[Lambda Proxy]
AgentCore[AgentCore Runtime]
end
Kong -->|HTTPS| APIGW
APIGW --> Lambda
Lambda --> AgentCore
外部リクエストですが、API GatewayのリソースベースポリシーでIP制限も可能なので、セキュリティ面も考慮できます。
失敗した方法
No.5: Lambda Function URL → Lambda → AgentCore Runtime（インターネット経由）
graph LR
subgraph アカウントA
Kong[Kong Gateway]
end
subgraph アカウントB
FunctionURL[Lambda Function URL]
Lambda[Lambda Proxy]
AgentCore[AgentCore Runtime]
end
Kong --> FunctionURL
FunctionURL --> Lambda
Lambda --> AgentCore
実現可能性は高そうですが、AssumeRole + SigV4署名を実現するのにKongプラグインを追加インストールが必要です。
今回は追加プラグインの検討をしている時間がなかったためパスしました。
No.6: Kong Gateway → AgentCore Runtime 直接（インターネット経由）
graph LR
subgraph アカウントA
Kong[Kong Gateway]
end
subgraph アカウントB
AgentCore[AgentCore Runtime]
end
Kong --> AgentCore
こちらも実現可能性は高そうですが、No.5と同様の理由（AssumeRole + SigV4署名のためのKongプラグインが必要）でパスしました。
No.7: VPC Lattice → AgentCore Runtime（内部通信）
graph LR
subgraph アカウントA
Kong[Kong Gateway]
end
subgraph クロスアカウント接続
Lattice[VPC Lattice]
end
subgraph アカウントB
AgentCore[AgentCore Runtime]
end
Kong --> Lattice
Lattice --> AgentCore
実現はできたのですが、VPC Latticeのアイドルタイムアウトが60秒固定で変更不可。
SSE（Server-Sent Events）でストリーミングしていると、データが流れていないタイミングでタイムアウトが発生しやすく、採用しづらいため不採用としました。
参考: AWS VPC Lattice - Services
追加検証したい方法
No.8: PrivateLink → AgentCore Runtime（内部通信）
graph LR
subgraph アカウントA
Kong[Kong Gateway]
end
subgraph クロスアカウント接続
PrivateLink[PrivateLink]
end
subgraph アカウントB
AgentCore[AgentCore Runtime]
end
Kong --> PrivateLink
PrivateLink --> AgentCore
AssumeRoleの部分で設定がうまくいっておらず、執筆までに修正する時間が取れませんでした。
ただ、できそうな感覚はあるので、引き続き検証予定です。
まとめ
- インターネット経由ではリクエスト可能
- ただし、AgentCore Runtimeの仕様により少し工夫が必要
- AgentCore Runtimeの前にLambdaを置く必要がある
- 今回はお試しでやってみたが、もっと実際の構成に近い状態でやってみたい
- 内部通信で実現できる方法を見つけたい
- プロダクトとしては、内部通信で実現したいという要望が出る可能性が高い
クロスアカウントでのAgentCore Runtime接続、皆さんはどんな構成で実現していますか？もし良い方法があれば、ぜひ教えてください！
採用について
askenではエンジニアを絶賛募集中です。
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！
https://hrmos.co/pages/asken/jobs
