
AgentCore Runtime VPC モードのネットワーク要件まとめ
こんにちは、コンサルティング部のシモンです。
皆さんは AgentCore Runtime を VPC の中で動かしたいと思ったことはありますか?私はあります。
社内データベースや内部 API にエージェントから直接つなぎたいという場合、AgentCore Runtime を VPC モードで実行すると実現できます。
ところが VPC モードで AgentCore Runtime を作ると、パブリックモードでは意識する必要がなかった通信経路を自分で用意することになります。
この記事では、それらの必要リソースを洗い出して整理します。
この記事のゴール
この記事では、AgentCore Runtime を VPC モードで作成する際に必要なネットワークリソースを整理します。具体的には、インターネットアクセスの経路と VPC エンドポイント群です。
エージェントのエージェントケーションコードや、Gateway・Memory・Identity の個別の使い方は扱いません。
「どの機能を使うとどのエンドポイントが要るか」という判断軸で整理しているので、自分の構成に照らし合わせて必要なリソースを選んでもらえる形にしています。
VPC モードとは
AgentCore Runtime のネットワークモードはパブリックと VPC の 2 種類です。
VPC モードを選ぶと、Runtime は指定したサブネットに ENI を作成します。Runtime はこの ENI を通じて VPC 内のリソースと通信します。ENI はプライベート IP を持ち、アタッチされたセキュリティグループで通信先を制御します。
VPC モードで Runtime を作成する主なメリットは、Runtime が VPC 内のデータベースや内部 API といったリソースへ ENI から直接到達できるようになることです。
パブリックモードの Runtime は VPC 内に ENI を持ちません。VPC 内のリソースに到達するには、AgentCore Gateway 側で VPC egress を構成し、Gateway 経由でアクセスする経路が必要です。さらに Gateway は RDS などのデータベースを直接 target にできないため、間に Lambda や ECS などの内部 API を挟む必要があります。VPC モードはこの中間層を省き、ENI から直接 RDS へ到達できます。

そのほかのメリットとして、組織のネットワーク境界の中に通信を閉じ込められること、VPC 内に置かれた他のアプリケーションから Runtime の API を PrivateLink 経由で呼べることが挙げられます。
一方、VPC モードにするとネットワーク設計・VPC エンドポイント・NAT のコストと運用が発生します。プライベート接続が不要であれば、パブリックモードで十分な場合がほとんどです。
インターネットアクセスの提供
Runtime がインターネットへ出る必要がある場合、NAT Gateway・IGW・ルートテーブルを組み合わせて用意します。VPC に接続した Runtime はデフォルトでインターネットアクセスを持たないためです。
インターネットアクセスを提供するには、次の構成をすべて揃えます。
- Runtime(ENI)を private subnet に配置する
- NAT Gateway を public subnet に配置する
- IGW を VPC にアタッチする
- ルートテーブル: private subnet の
0.0.0.0/0を NAT Gateway へ、public subnet の0.0.0.0/0を IGW へ向ける
Browser Tool を使う場合や、Code Interpreter でパブリックエンドポイントに出る場合は、この NAT 経由のインターネットアクセスが必須です。VPC エンドポイントだけで完結する設計であれば、NAT Gateway も IGW も不要です。
注意点として、Runtime を public subnet に配置してもインターネットアクセスは得られません。Runtime の ENI はプライベート IP しか持たず、IGW はパブリック IP を持つリソースにしかインターネット接続を提供しないためです。ENI からインターネットへ出るには NAT Gateway が必要です。
セキュリティグループ
VPC モードで必要なセキュリティグループは 2 つです。Runtime の NetworkConfiguration に指定するものと、Interface VPC エンドポイントにアタッチするものです(Gateway 型エンドポイントにはセキュリティグループは不要です)。
CloudFormation での実装例を示します。
# ---- エンドポイント SG: Interface VPC エンドポイント全てにアタッチ ----
VPCEndpointSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group for VPC endpoints
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: !Ref VpcCidr # VPC 内からの HTTPS を許可
# CFn はデフォルトで「全アウトバウンド許可」ルールを付与するため、
# SecurityGroupEgress を明示してデフォルトを上書きする
# Interface エンドポイントはレスポンスを返すだけで自ら outbound を起点にしないため
# ダミールールを追加して全アウトバウンドを実質ブロック
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 127.0.0.1/32
# ---- Runtime SG: Runtime の NetworkConfiguration に指定 ----
AgentRuntimeSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group for AgentCore Runtime
VpcId: !Ref VPC
SecurityGroupIngress: [] # インバウンド不要: 理由は後述
SecurityGroupEgress: [] # デフォルトの全アウトバウンド許可を削除; 下で必要なルールだけ追加
# アウトバウンドルールは循環参照を回避するため別リソースで定義
AgentRuntimeToVPCEndpointEgress:
Type: AWS::EC2::SecurityGroupEgress
Properties:
GroupId: !Ref AgentRuntimeSecurityGroup
IpProtocol: tcp
FromPort: 443
ToPort: 443
DestinationSecurityGroupId: !Ref VPCEndpointSecurityGroup
なお、Runtime SG のインバウンドは空です。VPC 内の他のアプリケーションが Runtime を呼び出す場合も、Runtime ENI へ直接接続するのではなく bedrock-agentcore エンドポイント経由で InvokeAgentRuntime を呼ぶため、Runtime SG 側にインバウンドルールは不要です。
VPC エンドポイント①: コンテナ実行基盤
Runtime はコンテナとして動作するため、イメージの取得とログ送信のために次のエンドポイントが必要です。インターネット(NAT Gateway)がない場合は必須、NAT がある場合も NAT のデータ処理料金を避けるために作成することを推奨します。
| サービス | エンドポイント | 目的 |
|---|---|---|
| ECR Docker | com.amazonaws.{region}.ecr.dkr |
コンテナイメージ本体の取得 |
| ECR API | com.amazonaws.{region}.ecr.api |
イメージの認証とメタデータ取得 |
| S3(Gateway 型・無料) | com.amazonaws.{region}.s3 |
イメージレイヤーの取得(実体は S3 に格納) |
| CloudWatch Logs | com.amazonaws.{region}.logs |
エージェントのログ送信 |
VPC エンドポイント②: AgentCore 機能
AgentCore が公開する PrivateLink エンドポイントは次の 3 つです。使う機能によって必要なものだけ足します。
| サービス | エンドポイント | 必要な条件 |
|---|---|---|
| AgentCore データプレーン | com.amazonaws.{region}.bedrock-agentcore |
Memory または Identity を使う場合や、VPC 内クライアントから InvokeAgentRuntime を private に呼ぶ場合 |
| AgentCore Gateway データプレーン | com.amazonaws.{region}.bedrock-agentcore.gateway |
Gateway を使う場合 |
| AgentCore コントロールプレーン | com.amazonaws.{region}.bedrock-agentcore-control |
インターネットのない VPC 内で Runtime の作成・更新・削除などの管理 API を実行する場合 |
VPC エンドポイント③: モデル推論とエージェント依存
その他の必要となりうるエンドポイントです。
bedrock-runtime はモデルで推論するために必要でほぼ必須、monitoring と xray は AgentCore Observability を使う場合に必要です。
それらに加えて、エージェントのコードが呼び出す AWS サービスに応じて必要な分だけ足します。
| サービス | エンドポイント | 目的 |
|---|---|---|
| Bedrock Runtime | com.amazonaws.{region}.bedrock-runtime |
モデル推論(InvokeModel / InvokeModelWithResponseStream) |
| CloudWatch | com.amazonaws.{region}.monitoring |
CloudWatch メトリクスの送信(AgentCore Observability を使う場合) |
| X-Ray | com.amazonaws.{region}.xray |
トレースの送信(AgentCore Observability を使う場合) |
| DynamoDB(Gateway 型・無料) | com.amazonaws.{region}.dynamodb |
エージェントが DynamoDB を使う場合 |
| Secrets Manager | com.amazonaws.{region}.secretsmanager |
エージェントがシークレットを取得する場合 |
| KMS | com.amazonaws.{region}.kms |
エージェントが暗号化・復号を行う場合 |
| SSM | com.amazonaws.{region}.ssm |
エージェントがパラメータストアを使う場合 |
| RDS Data | com.amazonaws.{region}.rds-data |
RDS Data API を使う場合 |
| STS | com.amazonaws.{region}.sts |
エージェントが AssumeRole を行う場合 |
まとめ
本記事では AgentCore Runtime の VPC モードについての概要やメリットと、VPC モードで通信を行うために追加で必要となるリソースについて解説しました。
AgentCore Runtime の VPC モードは、Runtime のエージェントが VPC 内のプライベートリソースへ直接接続が必要なときに使用してください。その必要がなければパブリックモードで十分です。







