

# VPC Lattice を使用して VPC 内のプライベートリソースに接続する
<a name="vpc-egress-private-endpoints"></a>

Amazon Bedrock AgentCore は、プライベート MCP サーバー、内部 REST APIs、データベースなど、 AWS VPC または VPC に接続されたオンプレミス環境内でホストされているリソースへのプライベート接続をサポートします。これらのサービスはパブリックインターネットに公開されません。

プライベート接続は、[Amazon VPC Lattice ](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html)リソースゲートウェイとリソース設定を使用して確立されます。サポートされている 2 つのモード (マネージドおよびセルフマネージド Lattice) の詳細については、[「サポートされている VPC 出力モード](#lattice-vpc-egress-compare-modes)」を参照してください。

**Topics**
+ [主要なコンセプト](#lattice-vpc-egress-concepts)
+ [サポートされている Amazon Bedrock AgentCore サービス](#lattice-vpc-egress-supported-services)
+ [サポートされている VPC 出力モード](#lattice-vpc-egress-compare-modes)
+ [オプション 1: マネージド VPC リソース](#lattice-vpc-egress-managed-lattice)
+ [オプション 2: セルフマネージド Lattice リソース](#lattice-vpc-egress-self-managed-lattice)
+ [中間ドメイン経由でトラフィックをルーティングする](#lattice-vpc-egress-routing-domain)
+ [プライベート証明書の回避策: ALB](#lattice-vpc-egress-private-certs)
+ [VPC 出力のサービスにリンクされたロール](#lattice-vpc-egress-slr)
+ [ターゲットのステータスとトラブルシューティング](#lattice-vpc-egress-target-status)
+ [制約事項と考慮事項](#lattice-vpc-egress-limitations)

## 主要なコンセプト
<a name="lattice-vpc-egress-concepts"></a>

 **リソースゲートウェイ**   
Amazon VPC Lattice リソースゲートウェイは、VPC への進入ポイントです。VPC 内の 1 つ以上のサブネットとセキュリティグループに関連付けられ、AgentCore からのトラフィックのネットワークエントリポイントとして機能します。マネージド Lattice を使用する場合、AgentCore はユーザーに代わってこのリソースを作成および管理します。

 **リソース設定**   
リソース設定は、VPC 内の特定のプライベートエンドポイント - IP アドレスまたは DNS 名 - を表します。これはリソースゲートウェイにアタッチされ、AgentCore が到達できるリソースを定義します。マネージド Lattice を使用すると、AgentCore はユーザーに代わって AgentCore サービスアカウントにこのリソースを作成します。

 **サービスネットワークリソースの関連付け**   
サービスネットワークリソースの関連付けは、リソース設定を AgentCore サービスネットワークに接続し、AgentCore サービスがプライベートエンドポイントを呼び出すことを可能にします。AgentCore は、マネージド Lattice を使用するかセルフマネージド Lattice を使用するかにかかわらず、常にユーザーに代わってこの関連付けを作成および管理します。

 **ルーティングドメイン**   
AgentCore が実際のターゲットドメインではなくリソース設定ドメインとして使用する中間ドメインを指定するオプションのフィールド。これは、VPC エンドポイントや内部ロードバランサーなどの中間コンポーネントを介してトラフィックをルーティングする場合に便利です。例えば、単一の VPC エンドポイントの背後に複数のプライベート API Gateway を統合し、リソース設定の数と関連コストを削減する場合などに便利です。AgentCore サービスは、SNI オーバーライドを使用して実際のターゲットドメインを呼び出し続けます。詳細については、[「中間ドメインを介してトラフィックをルーティング](#lattice-vpc-egress-routing-domain)する」を参照してください。

## サポートされている Amazon Bedrock AgentCore サービス
<a name="lattice-vpc-egress-supported-services"></a>

次の Amazon Bedrock AgentCore サービスは、VPC Lattice を使用した VPC 出力をサポートしています。

 **AgentCore ゲートウェイ**   
AgentCore Gateway は、MCP サーバーと OpenAPI ターゲットタイプのプライベートエンドポイントをサポートしています。各ターゲットタイプの VPC 出力の設定の詳細については、[「Amazon Bedrock AgentCore Gateway VPC Egress for Gateway Targets の設定](gateway-vpc-egress.md)」を参照してください。

 **AgentCore ID**   
AgentCore Identity は、インバウンド JWT 認可プロバイダーとアウトバウンド OAuth 認証情報プロバイダーの両方について、VPC がホストする OAuth 2.0 ID プロバイダーに接続するためのプライベートエンドポイントをサポートします。詳細については、[「プライベート ID プロバイダーに接続する](identity-private-idp.md)」を参照してください。

## サポートされている VPC 出力モード
<a name="lattice-vpc-egress-compare-modes"></a>

Amazon Bedrock AgentCore は、VPC Lattice 接続を設定するための 2 つのモードをサポートしています。
+  **マネージド VPC リソース** — Amazon Bedrock AgentCore は、ユーザーに代わって VPC Lattice リソースゲートウェイとリソース設定を作成および管理します。VPC、サブネット、およびオプションのセキュリティグループを指定します。これは、hub-and-spokeなどの既存のネットワークアーキテクチャに接続するアカウント内 VPC 接続のよりシンプルなアプローチです。
**注記**  
このオプションを使用するには、VPC Lattice IAM アクセス許可、SCP の変更、または追加の承認プロセスは必要ありません。Amazon Bedrock AgentCore は、ユーザーに代わってすべての VPC Lattice リソースを管理します。
+  **セルフマネージド Lattice リソース** — VPC Lattice リソースゲートウェイとリソース設定は自分で作成および管理します。このアプローチにより、ガバナンスと可視性が強化されます。どのサービスがどのドメインに接続されているか、誰がアクセスできるかを正確に確認し、接続をきめ細かく取り消すことができます。また、VPC ピアリングや Transit Gateway を必要とせずに AWS 、RAM 経由で直接クロスアカウント接続が可能になります。

次の表は、主な違いをまとめたものです。


| ディメンション | マネージド VPC リソース | セルフマネージド Lattice リソース | 
| --- | --- | --- | 
| 追加のサービスの依存関係 | VPC Lattice のオンボーディングや許可リストは必要ありません。VPC Lattice は、実装の詳細として Amazon Bedrock AgentCore によって内部的に使用されます。VPC Lattice IAM ポリシー、SCP の変更、または追加の承認プロセスは必要ありません。必要なのは、標準の Amazon EC2 アクセス許可と、サービスにリンクされたロールを作成する機能のみです。 | はい。VPC Lattice リソースを直接作成および管理します。これには VPC Lattice IAM アクセス許可 (、`vpc-lattice:CreateResourceGateway``vpc-lattice:CreateResourceConfiguration`、 など) が必要です`vpc-lattice:CreateServiceNetworkResourceAssociation`。組織が VPC Lattice アクセスを制限している場合は、SCPs の更新または承認のリクエストが必要になる場合があります。 | 
| ガバナンスと可視性 | アカウント内の唯一のリソースはリソースゲートウェイです。これは実質的に VPC 内のネットワークインターフェイス (ENI) です。これは Amazon Bedrock AgentCore によって完全に管理される読み取り専用リソースです。変更、設定、操作はできません。 | リソースゲートウェイ、リソース設定、サービスネットワークの関連付け、接続されたドメインを完全に可視化します。すべてのリソースを所有および管理し、接続を監査してアクセスをきめ細かく取り消すことができます。 | 
| 複雑さ | シンプル — VPC、サブネット、セキュリティグループを提供します。Amazon Bedrock AgentCore が残りを管理します。 | アドバンスト — VPC Lattice リソースゲートウェイとリソース設定を自分で作成および管理します。 | 
| クロスアカウント接続 | サポート外。クロスアカウントまたはクロス VPC シナリオでは、hub-and-spoke (VPC ピアリングまたは AWS Transit Gateway) などの既存のネットワークアーキテクチャで を使用します。 | RAM AWS でサポートされています。VPC ピアリングや Transit Gateway を必要とせずに、直接クロスアカウント接続を有効にします。 | 
| VPC Lattice の料金 | データ処理料金のみ (リソースゲートウェイを介して処理された GB あたり）。 | サービスネットワークに追加された VPC リソースあたりの時間料金とデータ処理料金 (GB あたり）。 | 
| リソースライフサイクル | Amazon Bedrock AgentCore は、ユーザーに代わってリソースゲートウェイを作成、再利用、削除します。 | リソースゲートウェイとリソース設定のライフサイクル全体を所有している。 | 
| IP の消費量とスループット | 各マネージドリソースゲートウェイは、サブネットごとに 1 つの IP アドレスを消費します。これは設定できません。 | Amazon Bedrock AgentCore で使用すると、 はサブネットごとに 1 つの IP アドレスを消費します。他の VPC Lattice サービスネットワークにもアタッチされている場合、 はリソースゲートウェイ`ipv4AddressesPerEni`の値に基づいて追加の IPs を消費します。ポート範囲と IP アドレスの組み合わせによって、そのサービスネットワークリソースの関連付けの同時接続の最大数が決まります。ポートを再利用する前に、接続が終了してから 350 秒のポートクールダウン期間があることに注意してください。 | 

VPC Lattice の料金の詳細については、[「Amazon VPC Lattice の料金](https://aws.amazon.com/vpc/lattice/pricing/)」を参照してください。

## オプション 1: マネージド VPC リソース
<a name="lattice-vpc-egress-managed-lattice"></a>

マネージド VPC リソースでは、VPC、サブネット、およびオプションのセキュリティグループ情報を提供します。AgentCore は、ユーザーに代わって VPC Lattice リソースゲートウェイとリソース設定の作成とライフサイクル管理を処理します。マネージドリソースゲートウェイは、VPC 内の ENIs を囲むラッパーです。変更、設定、操作はできません。AgentCore は、作成、再利用、削除を含むライフサイクル全体を所有します。

**注記**  
Amazon Bedrock AgentCore は内部依存関係として Lattice を使用し、Lattice リソースゲートウェイは顧客に読み取り専用であるため、マネージド VPC リソースを使用するには VPC Lattice IAM アクセス許可、SCP の変更、または追加の承認プロセスは必要ありません。

AgentCore は、`AWSServiceRoleForBedrockAgentCoreGatewayNetwork`サービスにリンクされたロールを使用して、アカウントで VPC Lattice リソースゲートウェイを作成および管理します。このロールは、マネージドプライベートエンドポイントを使用してゲートウェイターゲットを初めて作成するときに自動的に作成されます。このロールの詳細については、[「ゲートウェイサービスにリンクされたロール](service-linked-roles.md#gateway-service-linked-role)」を参照してください。

### 前提条件
<a name="lattice-vpc-egress-managed-lattice-prereqs"></a>

マネージドプライベートエンドポイントを使用してゲートウェイターゲットを作成する前に、以下を確認してください。
+ プライベートリソース (MCP サーバーまたは REST API) が実行されており、VPC 内でアクセスできます。
+ VPC 内に、プライベートリソースへのネットワークアクセスを持つサブネットが少なくとも 1 つあります。
+ セキュリティグループは、プライベートリソース (通常は HTTPS 用のポート 443) で使用されるポートでインバウンドトラフィックを許可します。
+ IAM プリンシパルには `bedrock-agentcore.amazonaws.com` の`iam:CreateServiceLinkedRole`アクセス許可があり、サービスにリンクされたロールがまだ存在しない場合、AgentCore がユーザーに代わって作成できるようにします。必要な IAM ポリシーについては、[「ゲートウェイサービスにリンクされたロール](service-linked-roles.md#gateway-service-linked-role)」を参照してください。
+ IAM プリンシパルには次の Amazon EC2 アクセス許可があります。これは、AgentCore が VPC 内の VPC Lattice リソースゲートウェイをセットアップするために必要です。
  +  `ec2:CreateNetworkInterface` 
  +  `ec2:DescribeVpcs` 
  +  `ec2:DescribeSecurityGroups` 
  +  `ec2:DescribeSubnets` 
+ プライベートリソースがプライベート認証機関によって発行された TLS 証明書を使用している場合は、内部 Application Load Balancer の前にパブリック ACM 証明書を配置できます。詳細については、[「プライベート証明書の回避策: ALB](#lattice-vpc-egress-private-certs)」を参照してください。

### マネージドプライベートエンドポイントを使用してターゲットを作成する
<a name="lattice-vpc-egress-managed-lattice-create"></a>

マネージドプライベートエンドポイントを使用してリソースを作成するには、作成リクエストに `privateEndpoint.managedVpcResource`ブロックを含めます。

```
{
  ...
  "privateEndpoint": {
    "managedVpcResource": {
      "vpcIdentifier": "vpc-0abc123def456",
      "subnetIds": ["subnet-0abc123", "subnet-0def456"],
      "endpointIpAddressType": "IPV4",
      "securityGroupIds": ["sg-0abc123def"]
    }
  },
  ...
}
```

`managedVpcResource` ブロックは、次のフィールドを受け入れます。

 `vpcIdentifier` (必須)  
プライベートリソースを含む VPC の ID。

 `subnetIds` (必須)  
リソースゲートウェイが配置される VPC 内のサブネット IDs のリスト。

 `endpointIpAddressType` (必須)  
リソース設定の IP アドレスタイプ。有効な値は、`IPV4` および `IPV6` です。

 `securityGroupIds` (オプション)  
リソースゲートウェイに関連付けるセキュリティグループ IDs のリスト。指定しない場合、VPC のデフォルトのセキュリティグループが使用されます。

 `routingDomain` (オプション)  
実際のターゲットドメインではなく、リソース設定エンドポイントとして使用する中間ドメイン。これは、VPC エンドポイントや内部ロードバランサーなどの中間コンポーネントを介してトラフィックをルーティングする場合に使用します。詳細については、[「中間ドメインを介してトラフィックをルーティング](#lattice-vpc-egress-routing-domain)する」を参照してください。

 `tags` (オプション)  
マネージド VPC Lattice リソースゲートウェイに適用するタグ。タグキー`BedrockAgentCoreGatewayManaged`は予約されており、指定できません。

### マネージドリソースを表示する
<a name="lattice-vpc-egress-managed-lattice-response"></a>

リソースを作成したら、関連する Get API ( など) `GetGatewayTarget` を呼び出して、AgentCore がユーザーに代わって作成したマネージド VPC Lattice リソースを表示します。これらはレスポンスの `privateEndpointManagedResources`フィールドで返されます。

```
{
  ...
  "status": "READY",
  "privateEndpoint": {
    "managedVpcResource": {
      "vpcIdentifier": "vpc-0abc123def456",
      "subnetIds": ["subnet-0abc123", "subnet-0def456"],
      "endpointIpAddressType": "IPV4",
      "securityGroupIds": ["sg-0abc123def"]
    }
  },
  "privateEndpointManagedResources": [
    {
      "domain": "my-server.internal.example.com",
      "resourceGatewayArn": "arn:aws:vpc-lattice:us-east-1:123456789012:resourcegateway/rgw-abc123"
    }
  ]
}
```

`resourceGatewayArn` は、AgentCore がアカウントで作成した VPC Lattice リソースゲートウェイの ARN です。AgentCore は、このリソースのライフサイクル全体を管理します。VPC とサブネットの設定が一致するターゲットに対して同じリソースゲートウェイを再利用し、ターゲットで使用されなくなったときに削除します。

## オプション 2: セルフマネージド Lattice リソース
<a name="lattice-vpc-egress-self-managed-lattice"></a>

セルフマネージド Lattice では、VPC Lattice リソースゲートウェイとリソース設定を自分で作成および管理し、リソース設定識別子を AgentCore に提供します。このオプションは、VPC Lattice リソースが既に設定されている場合、複数のサービス間でリソース設定を共有する必要がある場合、または Lattice リソースのライフサイクルを制御する必要がある場合に使用します。

### 前提条件
<a name="lattice-vpc-egress-self-managed-lattice-prereqs"></a>

セルフマネージドプライベートエンドポイントを使用してゲートウェイターゲットを作成する前に、次の手順を実行します。
+ プライベートリソース (MCP サーバーまたは REST API) が実行されており、VPC 内でアクセスできます。
+ VPC 内に、プライベートリソースへのネットワークアクセスを持つサブネットが少なくとも 1 つあります。
+ セキュリティグループは、プライベートリソース (通常は HTTPS 用のポート 443) で使用されるポートでインバウンドトラフィックを許可します。
+ プライベートリソースがプライベート認証機関によって発行された TLS 証明書を使用している場合は、内部 Application Load Balancer の前にパブリック ACM 証明書を配置できます。詳細については、[「プライベート証明書の回避策: ALB](#lattice-vpc-egress-private-certs)」を参照してください。

 **セルフマネージド接続用の VPC Lattice リソースを設定する** 

1.  VPC **Lattice コンソールまたは API を使用して、VPC に Resource Gateway を作成します**。 `CreateResourceGateway`プライベートリソースにアクセスできるサブネットとセキュリティグループに関連付けます。

   ```
   aws vpc-lattice create-resource-gateway \
     --name my-resource-gateway \
     --vpc-identifier vpc-0abc123def456 \
     --subnet-ids subnet-0abc123 subnet-0def456 \
     --security-group-ids sg-0abc123def \
     --ip-address-type IPV4
   ```

1.  プライベートエンドポイントを指す**リソース設定を作成します**。前のステップで作成したリソースゲートウェイの ARN を使用します。

   ```
   aws vpc-lattice create-resource-configuration \
     --name my-resource-config \
     --type SINGLE \
     --resource-gateway-identifier <resource-gateway-arn> \
     --resource-configuration-definition '{"dnsResource": {"domain": "my-service.internal.example.com", "ipAddressType": "IPV4"}}' \
     --port-ranges 443
   ```

1.  **リソースが AgentCore 所有者アカウントとは異なるアカウントにある**場合は、RAM を使用してリソース設定を AgentCore AWS 所有者アカウントと共有します。 AgentCore 

   ```
   aws ram create-resource-share \
     --name my-resource-config-share \
     --resource-arns <resource-configuration-arn> \
     --principals <gateway-owner-account-id>
   ```

   AgentCore 所有者アカウントは、ターゲットを作成する前にリソース共有を受け入れる必要があります。

1. リソース設定の ARN または ID を書き留めます。ゲートウェイターゲットを作成する`resourceConfigurationIdentifier`ときに、これを として指定します。

AgentCore がユーザーに代わってリソース設定を AgentCore サービスネットワークに関連付けるには、IAM プリンシパルに次のアクセス許可も必要です。

```
{
"Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "vpc-lattice:GetResourceConfiguration",
        "vpc-lattice:CreateServiceNetworkResourceAssociation",
        "vpc-lattice:GetServiceNetworkResourceAssociation",
        "vpc-lattice:ListServiceNetworkResourceAssociations",
        "vpc-lattice:AssociateViaAWSService"
      ],
      "Resource": "*"
    }
  ]
}
```

### セルフマネージドプライベートエンドポイントを使用してターゲットを作成する
<a name="lattice-vpc-egress-self-managed-lattice-create"></a>

セルフマネージドプライベートエンドポイントを使用してリソースを作成するには、作成リクエストに `privateEndpoint.selfManagedLatticeResource`ブロックを含めます。

```
{
  ...
  "privateEndpoint": {
    "selfManagedLatticeResource": {
      "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123"
    }
  },
  ...
}
```

は、VPC Lattice リソース設定の ARN または ID のいずれか`resourceConfigurationIdentifier`です。AgentCore は (フォ[ワードアクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)を介して) 認証情報を使用して、リソース設定を AgentCore サービスネットワークに関連付けます。

リソースが作成されると、Get API レスポンスには `privateEndpointManagedResources`フィールド`resourceAssociationArn`の が含まれます。同じリソース設定を指す複数のリソースを作成すると、AgentCore は既存のサービスネットワークリソースの関連付けを自動的に再利用します。

### クロスアカウントプライベートリソース
<a name="lattice-vpc-egress-cross-account"></a>

AgentCore は、ゲートウェイを所有する AWS アカウントとは異なるアカウントのプライベートリソースに接続できます。これは、一元化されたゲートウェイを管理するプラットフォームチームにとって一般的なパターンであり、個々のサービスチームがプライベートリソースを所有しています。

リソース所有者アカウントは、RAM を使用して VPC Lattice AWS リソース設定をゲートウェイ所有者アカウントと共有する必要があります。次に、ゲートウェイ所有者アカウントは、ゲートウェイターゲットの作成時に共有リソース設定識別子を提供します。

次のステップは、クロスアカウント設定をまとめたものです。

 **クロスアカウントプライベート接続を設定する** 

1.  **リソース所有者アカウント** : [「前提条件](#lattice-vpc-egress-self-managed-lattice-prereqs)」の説明に従って、VPC Lattice リソースゲートウェイとリソース設定を作成します。

1.  **リソース所有者アカウント** : RAM AWS を使用して、リソース設定をゲートウェイ所有者アカウントと共有します。

   ```
   aws ram create-resource-share \
     --name my-resource-config-share \
     --resource-arns <resource-configuration-arn> \
     --principals <gateway-owner-account-id>
   ```

1.  **ゲートウェイ所有者アカウント** : リソース共有を受け入れます。

   ```
   aws ram accept-resource-share-invitation \
     --resource-share-invitation-arn <invitation-arn>
   ```

1.  **ゲートウェイ所有者アカウント **で: [「セルフマネージドプライベートエンドポイントを使用してターゲットを作成する」で説明されているように、共有リソース設定識別子を使用してゲートウェイターゲットを作成します](#lattice-vpc-egress-self-managed-lattice-create)。

## 中間ドメイン経由でトラフィックをルーティングする
<a name="lattice-vpc-egress-routing-domain"></a>

`routingDomain` フィールドを使用して、VPC エンドポイント、内部 Application Load Balancer、Network Load Balancer などの中間コンポーネントを介してトラフィックをターゲットドメインに直接ルーティングできます。これは、1 つのエントリポイントの背後で複数のプライベートリソースを統合する場合に役立ちます (たとえば、1 つの VPC エンドポイントを介して複数のプライベート API Gateway をルーティングして、リソース設定の数と関連コストを削減するなど）。

ルーティングドメインを使用する場合、ターゲットに指定するドメイン (MCP エンドポイント URL または OpenAPI サーバー URL 内) は、リソースの実際の DNS 名である必要があります。`routingDomain` は、AgentCore が VPC Lattice リソース設定をセットアップするために使用する別のドメインです。呼び出し時に、AgentCore はルーティングドメインを介してトラフィックをルーティングしますが、実際のターゲットドメインを TLS SNI ホスト名としてリクエストを送信するため、リソースは実際のドメイン宛てのリクエストを受け取ります。

ルーティングドメインは、VPC 内のプライベートリソースにルーティングする任意のドメインにすることができます。一般的なオプションは次のとおりです。
+  **プライベート API Gateway の VPC エンドポイント (VPCE) ドメイン** - VPCE DNS 名を `routingDomain` として使用します。例: `<vpce-id>.execute-api.us-east-1.vpce.amazonaws.com` 。OpenAPI 仕様のターゲット URL を、 などのプライベート API Gateway `https://<api-id>.execute-api.us-east-1.amazonaws.com` ホスト名に設定します。AgentCore は VPCE ドメインを介してトラフィックをルーティングしますが、プライベート API ホスト名を TLS SNI としてリクエストを送信し、VPC 内で正しいルーティングを確保します。
+  **Internal Application Load Balancer (ALB)** - 内部 ALB DNS 名を `routingDomain` として使用します。たとえば、 `internal-<alb-name>-<id>.us-west-2.elb.amazonaws.com` です。ターゲット URL を ALB の背後にあるリソースの DNS 名に設定します。
+  **Internal Network Load Balancer (NLB)** - 内部 NLB DNS 名を `routingDomain` として使用します。例: `internal-<nlb-name>-<id>.elb.us-west-2.amazonaws.com` 。ターゲット URL を NLB の背後にあるリソースの DNS 名に設定します。

次の手順では、ルーティングドメインを使用する場合のトラフィックフローについて説明します。

1. AgentCore は、VPC Lattice で生成された DNS 名を解決してリソースゲートウェイに到達します。

1. トラフィックは、ルーティングドメイン宛てのリソースゲートウェイを介して VPC に入ります。

1. ルーティングドメイン (VPCE または ALB) は、リクエストをプライベートリソースに転送します。TLS SNI ヘッダーには実際のターゲットドメインが含まれているため、リソースは正しいホスト名でリクエストを受け取ります。

### 例: VPCE ルーティングドメインを持つプライベート API Gateway
<a name="lattice-vpc-egress-routing-domain-setup"></a>

次の例は、VPCE ドメインをルーティングドメインとして使用してプライベート API Gateway のゲートウェイターゲットを作成する方法を示しています。ターゲット URL はプライベート API Gateway ホスト名で、 `routingDomain`は VPCE DNS 名です。

```
{
  "name": "my-private-apigw-target",
  "privateEndpoint": {
    "managedVpcResource": {
      "vpcIdentifier": "vpc-0123456789abcdef0",
      "subnetIds": ["subnet-0123456789abcdef0", "subnet-0abcdef1234567890"],
      "endpointIpAddressType": "IPV4",
      "routingDomain": "<vpce-id>.execute-api.us-east-1.vpce.amazonaws.com"
    }
  },
  "targetConfiguration": {
    "mcp": {
      "openApiSchema": {
        "inlinePayload": "<OpenAPI spec JSON with server URL matching the public certificate domain, for example https://<api-id>.execute-api.<region>.amazonaws.com>"
      }
    }
  }
}
```

**注記**  
`routingDomain` フィールドは `managedVpcResource`オプションでのみ使用できます。セルフマネージド Lattice の場合は、作成時にリソース設定でルーティングドメインを直接設定します。

## プライベート証明書の回避策: ALB
<a name="lattice-vpc-egress-private-certs"></a>

VPC 出力では、ターゲットエンドポイントにパブリックに信頼された TLS 証明書が必要です。プライベートリソースがプライベート認証機関 (CA) によって発行された証明書を使用する場合、推奨される回避策は、リソースの前に内部 Application Load Balancer (ALB) を配置することです。

次の手順では、トラフィックフローについて説明します。

1. ターゲット URL を、パブリック ACM 証明書 ( など) `https://my-server.my-company.com` に一致するドメインに設定します。

1. `routingDomain` を内部 ALB DNS 名 (例: ) `internal-my-alb-1234567890.us-west-2.elb.amazonaws.com` に設定します。

1. VPC Lattice は、ルーティングドメインを介してトラフィックを ALB にルーティングします。TLS SNI は `my-server.my-company.com` に設定され、ALB のパブリック ACM 証明書と一致するため、TLS ハンドシェイクは成功します。

1. ALB は TLS を終了し、ホストヘッダー変換を適用して、ホストヘッダーを からプライベートリソースのドメイン ( など) `my-server.my-company.internal` `my-server.my-company.com`に書き換えます。

1. ALB は、プライベート証明書を使用してリクエストを HTTPS 経由でバックエンドリソースに転送します。すべてのトラフィックは VPC 内に残ります。

 **ステップ 1: パブリック ACM 証明書をリクエストする** 

所有するドメインのパブリック証明書を ACM にリクエストします。このドメインはターゲット URL として使用されます。手順については、 AWS 「 Certificate Manager ユーザーガイド[」の「パブリック証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)」を参照してください。

 **ステップ 2: 内部 ALB を作成する** 

プライベートリソースと同じ VPC に内部 Application Load Balancer を作成します。手順については、Elastic [ Application Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)」を参照してください。 Elastic Load Balancing スキームを に設定してください`internal`。

 **ステップ 3: IP ベースのターゲットグループを作成する** 

ポート 443 (HTTPS) でプライベートリソースの IP アドレス`ip`を指すターゲットタイプを使用してターゲットグループを作成し、プライベートリソースをターゲットとして登録します。手順については、Elastic Load Balancing [ユーザーガイド」の「ターゲットグループの作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」を参照してください。

 **ステップ 4: ホストヘッダー変換を使用して HTTPS リスナーを作成する** 

パブリック ACM 証明書を使用して、ポート 443 に HTTPS リスナーを作成します。転送前にホストヘッダーをパブリックドメインからプライベートリソースのドメインに変換するリスナールールを追加します。

```
aws elbv2 create-listener \
  --load-balancer-arn <alb-arn> \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=<acm-certificate-arn> \
  --default-actions '[{
    "Type": "forward",
    "TargetGroupArn": "<target-group-arn>",
    "ForwardConfig": {
      "TargetGroups": [{"TargetGroupArn": "<target-group-arn>", "Weight": 1}]
    }
  }]'
```

次に、リスナールールを変更してホストヘッダー変換を追加します。

```
aws elbv2 modify-rule \
  --rule-arn <default-rule-arn> \
  --actions '[{
    "Type": "forward",
    "TargetGroupArn": "<target-group-arn>",
    "ForwardConfig": {
      "TargetGroups": [{"TargetGroupArn": "<target-group-arn>", "Weight": 1}]
    }
  }]' \
  --transforms '[{
    "Type": "host-header",
    "HostHeaderConfig": {
      "Values": ["my-server.my-company.internal"]
    }
  }]'
```

 **ステップ 5: プライベートエンドポイントを設定する** 

ALB DNS 名を として使用`routingDomain`し、パブリック証明書ドメインをターゲット URL として使用します。

```
{
  ...
  "privateEndpoint": {
    "managedVpcResource": {
      "vpcIdentifier": "<vpc-id>",
      "subnetIds": ["<subnet-id-1>", "<subnet-id-2>"],
      "endpointIpAddressType": "IPV4",
      "routingDomain": "internal-my-alb-1234567890.us-west-2.elb.amazonaws.com"
    }
  },
  ...
}
```

ターゲット設定のターゲット URL は、プライベートドメインではなく `https://my-server.my-company.com` (パブリック証明書ドメイン) を使用する必要があります。

## VPC 出力のサービスにリンクされたロール
<a name="lattice-vpc-egress-slr"></a>

マネージドプライベートエンドポイント ( `managedVpcResource` ) を使用してゲートウェイターゲットを作成すると、AgentCore は`AWSServiceRoleForBedrockAgentCoreGatewayNetwork`サービスにリンクされたロールを使用して、アカウントで VPC Lattice リソースゲートウェイを作成および管理します。このロールは、IAM プリンシパルが必要な`iam:CreateServiceLinkedRole`アクセス許可を持っている場合、マネージドプライベートエンドポイントターゲットを初めて作成するときに自動的に作成されます。

サービスにリンクされたロールには、次の主要な特性があります。
+ でタグ付けされた VPC Lattice `BedrockAgentCoreGatewayManaged: true` リソースゲートウェイのみを作成および削除できます。自分で作成および管理しているリソースゲートウェイを変更することはできません。
+ AgentCore は、同じ VPC、サブネット、セキュリティグループ、および IP アドレスタイプの設定を共有するターゲットに対して、同じマネージドリソースゲートウェイを再利用します。リソースゲートウェイは、ゲートウェイターゲットが使用していない場合にのみ削除されます。
+ マネージド Lattice のリソース設定は、 アカウントではなく AgentCore サービスアカウントに作成されます。VPC Lattice コンソールには表示されません。

完全なポリシードキュメントと、このロールを作成、編集、削除する手順については、[「ゲートウェイサービスにリンクされたロール](service-linked-roles.md#gateway-service-linked-role)」を参照してください。

## ターゲットのステータスとトラブルシューティング
<a name="lattice-vpc-egress-target-status"></a>

プライベートエンドポイントを使用してリソースを作成すると、AgentCore が VPC Lattice リソースをセットアップしてサービスネットワークの関連付けを確立している間、リソースは `CREATING`状態になります。関連する Get API ( など) を呼び出し、 `status`および `GetGatewayTarget` `statusReasons`フィールドを確認することで、ステータスをモニタリングできます。

次の表に、一般的なステータス値とその意味を示します。


| ステータス | 説明 | 
| --- | --- | 
|  `CREATING`  | AgentCore は VPC Lattice リソースをセットアップし、サービスネットワークの関連付けを確立しています。これには数分かかる場合があります。 | 
|  `READY`  | プライベートエンドポイントが設定され、ターゲットはリクエストを受信する準備ができています。 | 
|  `FAILED`  | ターゲットの作成に失敗しました。詳細については、 `statusReasons`フィールドを確認してください。一般的な原因には、IAM アクセス許可の欠落や無効なリソース設定識別子などがあります。 | 

次の表に、一般的な問題とその解決策を示します。


| 問題 | ソリューション | 
| --- | --- | 
| ターゲットの作成が IAM アクセス許可エラーで失敗する | IAM プリンシパルに `bedrock-agentcore.amazonaws.com` の`iam:CreateServiceLinkedRole`アクセス許可があることを確認します。セルフマネージド Lattice の場合は、前提条件に記載されている[必要な VPC ](#lattice-vpc-egress-self-managed-lattice-prereqs)Lattice アクセス許可があることを確認してください。 | 
| ツール呼び出しが失敗し、ターゲットの作成後に接続エラーが発生する | リソースゲートウェイに関連付けられたセキュリティグループが、プライベートリソースが使用するポートでインバウンドトラフィックを許可していることを確認します。また、プライベートリソースが実行されており、指定されたサブネットからアクセス可能であることを確認します。 | 
| ツール呼び出しが TLS エラーで失敗する | プライベートリソースがプライベート CA によって発行された証明書を使用している場合は、証明書のサブジェクト代替名 (SAN) が MCP エンドポイントまたは OpenAPI サーバー URL のドメインと一致していることを確認してください。ルーティングドメインを使用している場合は、ルーティングドメインが TLS をプライベートリソースに正しく転送していることを確認します。 | 
| リソース設定が見つかりません (セルフマネージド) | クロスアカウントシナリオでは、ターゲットを作成する前に、ゲートウェイ所有者アカウントで RAM AWS リソース共有が受け入れられていることを確認します。 | 

## 制約事項と考慮事項
<a name="lattice-vpc-egress-limitations"></a>

AgentCore に VPC 出力を使用する場合は、次の制限に注意してください。
+  **クロスアカウント** : クロスアカウントプライベート接続には、セルフマネージド Lattice リソースオプションが必要です。マネージド VPC リソースは、クロスアカウントシナリオをサポートしていません。
+  **DNS TTL 設定**: VPC Lattice は IP ベースのルーティングを使用します。ローリングデプロイ中の IP アドレスの変更によって接続が中断されないように、リソース設定ドメインの DNS TTLs が適切に設定されていることを確認します。