AgentCore RuntimeからS3 Filesをマウントしてみる¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Amazon Bedrock AgentCore Runtime上のエージェントから、S3 Filesをファイルシステムとして扱う検証スライド。 AgentCore Runtimeはセッションごとに実行環境が消えるため、生成ファイルや履歴を外部ストレージに逃がす必要がある。 S3 Filesを組み合わせることで、クラウド上のエージェントがS3上のデータをファイル操作に近い形で扱える可能性を示している。
本文¶
この資料は、AgentCore RuntimeとS3 Filesを組み合わせ、AIエージェントの実行環境からS3上のデータをファイルシステムとして扱う検証。
S3 Filesは、S3バケットのデータをファイルやディレクトリ操作に近い形で扱えるようにする仕組み。裏側ではEFSに近い基盤が使われ、S3 Files側の変更は一定の遅延を伴ってS3バケットへ反映される。
AgentCore Runtimeは、AIエージェントやツールのコードをホストするためのサーバーレスなコンテナ実行基盤として説明されている。セッションごとに隔離された実行環境を立ち上げられ、好きなフレームワークやモデルを使える。一方で、セッション終了後に環境が消えるため、生成ファイルや会話履歴を継続的に扱いたい場合は外部ストレージが必要になる。
AgentCoreにはSession Storageもあるが、資料では同一セッション内の半永続ストレージとして位置づけられている。別エージェントや別セッションから同じデータを参照する用途には向かないため、S3 Filesを使う意味が出てくる。
完成アーキテクチャの考え方は、通常のComputeリソースをAgentCore Runtimeに置き換えること。S3 Filesの制約によりRuntimeをVPC内に配置し、マネージドな接続だけでは完結しないため、独自にマウントできるようにする。
構築手順は、EC2からS3 Filesをマウントする流れをAgentCore Runtime向けに読み替える形。S3バケット作成とバージョニング有効化、S3 Filesサービスロール、AgentCore実行ロール、S3 Files作成、セキュリティグループ、マウントターゲット作成などはEC2の場合と近い。
差分として重要なのは、amazon-efs-utils の導入とマウント処理。EC2ならOS上でパッケージを入れてコマンドを実行すればよいが、AgentCore Runtimeではコンテナイメージ内で必要なものを用意する必要がある。資料ではAmazon Linux 2023から必要なユーティリティを持ち込み、DockerのマルチステージビルドでRuntimeコンテナへ渡す方針が示されている。
マウント時もEC2とは違い、ルート権限でマウントしたあと、非rootユーザーに切り替えてアプリを起動する形にする。非rootユーザーにはワークスペース配下の読み書き権限を与え、それ以外は読み取り中心にする設計。
この検証の価値は、クラウド上のAIエージェントが一般的なコーディングエージェントのようにファイル操作できる状態へ近づける点にある。RAGや生成物の保存、複数エージェント間のファイル共有を考えると、外部ストレージをファイルシステムとして見せられることは実装の見通しを良くする。
要点¶
- AgentCore Runtimeはエージェント実行基盤だが、セッション後の永続化には外部ストレージが必要。
- S3 Filesにより、S3のオブジェクトをファイルシステム的に読み書きできる。
- RuntimeをVPC内に置き、S3 Files側とNFS相当の通信を許可する必要がある。
- EC2手順を流用できる部分は多いが、AgentCoreではDockerイメージと起動手順に工夫が必要。
- マウントはルート権限で行い、アプリ実行は非rootユーザーへ切り替える設計が扱いやすい。
- AIエージェントの生成ファイル、履歴、作業ディレクトリをクラウド側で扱う設計材料になる。