AgentCore Runtime VPC モードのネットワーク要件まとめ

AgentCore Runtime VPC モードのネットワーク要件まとめ

AgentCore Runtime を VPC モードで動かすには、インターネットアクセス経路や VPC エンドポイントなど、パブリックモードでは不要なネットワークリソースの設定が必要です。この記事では、VPC モード構築に必要なリソースを機能別に整理して紹介します。
2026.06.30

こんにちは、コンサルティング部のシモンです。

皆さんは 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 へ到達できます。

AgentCore Runtime Public vs VPC

そのほかのメリットとして、組織のネットワーク境界の中に通信を閉じ込められること、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 はモデルで推論するために必要でほぼ必須、monitoringxray は 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 内のプライベートリソースへ直接接続が必要なときに使用してください。その必要がなければパブリックモードで十分です。

この記事をシェアする

関連記事