AWS bedrock-agentcore documentation change
Summary
Updated documentation for VPC egress private endpoints, including renaming options from 'Managed Lattice' to 'Managed VPC resources' and 'Self-managed Lattice' to 'Self-managed Lattice resources', adding a new section for AgentCore Identity private endpoints for OAuth 2.0 identity providers, updating the 'routingDomain' field description from a workaround for private DNS to a feature for routing through intermediate components, removing the beta service disclaimer, and updating limitations.
Security assessment
The changes primarily involve feature renaming, clarification of functionality, and the addition of a new feature (AgentCore Identity private endpoints for OAuth 2.0 identity providers). There is no concrete evidence of addressing a specific security vulnerability, weakness, or incident. However, the addition of documentation for private endpoints for OAuth 2.0 identity providers (inbound JWT authorization and outbound OAuth credential providers) adds security documentation by describing how to securely connect to VPC-hosted identity providers, which can enhance security by keeping authentication traffic within the VPC and reducing exposure to the public internet.
Diff
diff --git a/bedrock-agentcore/latest/devguide/vpc-egress-private-endpoints.md b/bedrock-agentcore/latest/devguide/vpc-egress-private-endpoints.md index cb46cf02e..26bde390c 100644 --- a//bedrock-agentcore/latest/devguide/vpc-egress-private-endpoints.md +++ b//bedrock-agentcore/latest/devguide/vpc-egress-private-endpoints.md @@ -7 +7 @@ -Key conceptsSupported Amazon Bedrock AgentCore servicesSupported VPC egress modesOption 1: Managed LatticeOption 2: Self-managed LatticeWorkaround for private DNS support: routing domainWorkaround for private certificates: ALBService-linked role for VPC egressTarget status and troubleshootingLimitations and considerations +Key conceptsSupported Amazon Bedrock AgentCore servicesSupported VPC egress modesOption 1: Managed VPC resourcesOption 2: Self-managed Lattice resourcesRoute traffic through an intermediate domainWorkaround for private certificates: ALBService-linked role for VPC egressTarget status and troubleshootingLimitations and considerations @@ -11,4 +10,0 @@ Key conceptsSupported Amazon Bedrock AgentCore servicesSupported VPC egress mode -###### Important - -This feature is made available to you as a "Beta Service" as defined in the AWS Service Terms. It is subject to your Agreement with AWS and the AWS Service Terms. - @@ -27 +23 @@ Private connectivity is established using [Amazon VPC Lattice](https://docs.aws. - * Option 1: Managed Lattice + * Option 1: Managed VPC resources @@ -29 +25 @@ Private connectivity is established using [Amazon VPC Lattice](https://docs.aws. - * Option 2: Self-managed Lattice + * Option 2: Self-managed Lattice resources @@ -31 +27 @@ Private connectivity is established using [Amazon VPC Lattice](https://docs.aws. - * Workaround for private DNS support: routing domain + * Route traffic through an intermediate domain @@ -64 +60 @@ A service network resource association connects a resource configuration to the -An optional field that specifies an intermediate publicly resolvable domain that AgentCore uses as the resource configuration domain instead of the actual target domain. This is required when your private endpoint uses a domain that is not publicly resolvable, because Amazon VPC Lattice requires publicly resolvable DNS for resource configurations. The AgentCore service continues to invoke the actual target domain using SNI override. For more information, see Workaround for private DNS support: routing domain. +An optional field that specifies an intermediate domain that AgentCore uses as the resource configuration domain instead of the actual target domain. This is useful when you want to route traffic through an intermediate component such as a VPC endpoint or an internal load balancer — for example, to consolidate multiple private API Gateways behind a single VPC endpoint, reducing the number of resource configurations and associated costs. The AgentCore service continues to invoke the actual target domain using SNI override. For more information, see Route traffic through an intermediate domain. @@ -74,0 +71,5 @@ AgentCore Gateway supports private endpoints for MCP server and OpenAPI target t +**AgentCore Identity** + + +AgentCore Identity supports private endpoints for connecting to VPC hosted OAuth 2.0 identity providers for both inbound JWT authorization and outbound OAuth credential providers. For details, see [Connect to private identity providers](./identity-private-idp.html). + @@ -79 +80,5 @@ Amazon Bedrock AgentCore supports two modes for configuring VPC Lattice connecti - * **Managed Lattice** — Amazon Bedrock AgentCore creates and manages the VPC Lattice resource gateway and resource configuration on your behalf. You provide your VPC, subnets, and optional security groups. This is the simpler approach for in-account VPC connectivity that plugs into existing network architectures such as hub-and-spoke. + * **Managed VPC resources** — Amazon Bedrock AgentCore creates and manages the VPC Lattice resource gateway and resource configuration on your behalf. You provide your VPC, subnets, and optional security groups. This is the simpler approach for in-account VPC connectivity that plugs into existing network architectures such as hub-and-spoke. + +###### Note + +You do not need VPC Lattice IAM permissions, SCP changes, or additional approval processes to use this option. Amazon Bedrock AgentCore manages all VPC Lattice resources on your behalf. @@ -81 +86 @@ Amazon Bedrock AgentCore supports two modes for configuring VPC Lattice connecti - * **Self-managed Lattice** — You create and manage the VPC Lattice resource gateway and resource configuration yourself. This approach provides enhanced governance and visibility: you can see exactly which services are connected to which domains, who has access, and revoke connections at a granular level. It also enables direct cross-account connectivity via AWS RAM without requiring VPC peering or Transit Gateways. + * **Self-managed Lattice resources** — You create and manage the VPC Lattice resource gateway and resource configuration yourself. This approach provides enhanced governance and visibility: you can see exactly which services are connected to which domains, who has access, and revoke connections at a granular level. It also enables direct cross-account connectivity via AWS RAM without requiring VPC peering or Transit Gateways. @@ -88 +93 @@ The following table summarizes the key differences: -Dimension | Managed Lattice | Self-managed Lattice +Dimension | Managed VPC resources | Self-managed Lattice resources @@ -89,0 +95,2 @@ Dimension | Managed Lattice | Self-managed Lattice +Additional service dependency | No VPC Lattice onboarding or allowlisting required. VPC Lattice is used internally by Amazon Bedrock AgentCore as an implementation detail. You do not need VPC Lattice IAM policies, SCP changes, or additional approval processes. You only need standard Amazon EC2 permissions and the ability to create a service-linked role. | Yes. You create and manage VPC Lattice resources directly, which requires VPC Lattice IAM permissions (for example, `vpc-lattice:CreateResourceGateway`, `vpc-lattice:CreateResourceConfiguration`, and `vpc-lattice:CreateServiceNetworkResourceAssociation`). You may need to update SCPs or request approval if your organization restricts VPC Lattice access. +Governance and visibility | The only resource in your account is a resource gateway, which is effectively a network interface (ENI) in your VPC. This is a read-only resource fully managed by Amazon Bedrock AgentCore — you cannot modify, configure, or interact with it. | Full visibility into resource gateways, resource configurations, service network associations, and connected domains. You own and manage all resources, and can audit connections and revoke access at a granular level. @@ -94,2 +101 @@ Resource lifecycle | Amazon Bedrock AgentCore creates, reuses, and deletes reso -Governance and visibility | Resource configurations are managed in the Amazon Bedrock AgentCore service account. You do not see them in your VPC Lattice console. | Full visibility into resource configurations, service network associations, and connected domains. You can audit connections and revoke access at a granular level. -IP consumption and throughput | Each managed resource gateway consumes 1 IP address per subnet. This is not configurable. | You can configure the number of IP addresses per ENI (up to the VPC Lattice maximum) when creating the resource gateway. More IPs allow higher throughput — the combination of port range and IP addresses determines the maximum number of concurrent connections for that service network resource association. Note that there is a 350-second port cooldown period after a connection ends before that port can be reused. +IP consumption and throughput | Each managed resource gateway consumes 1 IP address per subnet. This is not configurable. | When used with Amazon Bedrock AgentCore, consumes 1 IP address per subnet. If also attached to other VPC Lattice service networks, consumes additional IPs based on the `ipv4AddressesPerEni` value on the resource gateway. The combination of port range and IP addresses determines the maximum number of concurrent connections for that service network resource association. Note that there is a 350-second port cooldown period after a connection ends before that port can be reused. @@ -99 +105,5 @@ For VPC Lattice pricing details, see [Amazon VPC Lattice pricing](https://aws.am -## Option 1: Managed Lattice +## Option 1: Managed VPC resources + +With managed VPC resources, you provide your VPC, subnet, and optional security group information. AgentCore handles the creation and lifecycle management of the VPC Lattice resource gateway and resource configuration on your behalf. The managed resource gateway is a wrapper around ENIs in your VPC. You cannot modify, configure, or interact with it. AgentCore owns its full lifecycle, including creation, reuse, and deletion. + +###### Note @@ -101 +111 @@ For VPC Lattice pricing details, see [Amazon VPC Lattice pricing](https://aws.am -With managed Lattice, you provide your VPC, subnet, and optional security group information. AgentCore handles the creation and lifecycle management of the VPC Lattice resource gateway and resource configuration on your behalf, and does not require you to have VPC Lattice permissions in your own IAM policies. +You do not need VPC Lattice IAM permissions, SCP changes, or additional approval processes to use managed VPC resources, because Amazon Bedrock AgentCore uses Lattice as an internal dependency and any Lattice resource gateways are read-only to the customer. @@ -127,2 +136,0 @@ Before creating a gateway target with a managed private endpoint, ensure the fol - * If your private endpoint uses a domain that is not publicly resolvable, you must use the `routingDomain` field. For more information, see Workaround for private DNS support: routing domain. - @@ -136 +144 @@ Before creating a gateway target with a managed private endpoint, ensure the fol -To create a resource with a managed private endpoint, include the `privateEndpoint.managedLatticeResource` block in your create request. +To create a resource with a managed private endpoint, include the `privateEndpoint.managedVpcResource` block in your create request. @@ -142 +150 @@ To create a resource with a managed private endpoint, include the `privateEndpoi - "managedLatticeResource": { + "managedVpcResource": { @@ -152 +160 @@ To create a resource with a managed private endpoint, include the `privateEndpoi -The `managedLatticeResource` block accepts the following fields: +The `managedVpcResource` block accepts the following fields: @@ -177 +185 @@ A list of security group IDs to associate with the resource gateway. If not prov -An intermediate publicly resolvable domain to use as the resource configuration endpoint. Required when your private endpoint domain is not publicly resolvable. For more information, see Workaround for private DNS support: routing domain. +An intermediate domain to use as the resource configuration endpoint instead of the actual target domain. Use this when you want to route traffic through an intermediate component such as a VPC endpoint or internal load balancer. For more information, see Route traffic through an intermediate domain. @@ -193 +201 @@ After the resource is created, call the relevant Get API (for example, `GetGatew - "managedLatticeResource": { + "managedVpcResource": { @@ -210 +218 @@ The `resourceGatewayArn` is the ARN of the VPC Lattice resource gateway that Age -## Option 2: Self-managed Lattice +## Option 2: Self-managed Lattice resources @@ -224,2 +231,0 @@ Before creating a gateway target with a self-managed private endpoint, complete - * If your private endpoint uses a domain that is not publicly resolvable, you must use the `routingDomain` field. For more information, see Workaround for private DNS support: routing domain. - @@ -333 +339 @@ The following steps summarize the cross-account setup: -## Workaround for private DNS support: routing domain +## Route traffic through an intermediate domain @@ -335 +341 @@ The following steps summarize the cross-account setup: -Amazon VPC Lattice requires that the domain used in a resource configuration be publicly resolvable. If your private endpoint uses a domain that is only resolvable within your VPC (for example, a private hosted zone in Route 53), you must use the `routingDomain` field. +You can use the `routingDomain` field to route traffic through an intermediate component — such as a VPC endpoint, internal Application Load Balancer, or Network Load Balancer — instead of directly to your target domain. This is useful when you want to consolidate multiple private resources behind a single entry point (for example, routing multiple private API Gateways through a single VPC endpoint to reduce the number of resource configurations and associated costs). @@ -337 +343 @@ Amazon VPC Lattice requires that the domain used in a resource configuration be -When using a routing domain, the domain you specify for your target (in the MCP endpoint URL or OpenAPI server URL) should be the actual private DNS name of your resource - i.e. the name that is resolvable within your VPC. The `routingDomain` is a separate, publicly resolvable domain that AgentCore uses only to set up the VPC Lattice resource configuration. At invocation time, AgentCore routes traffic through the routing domain but sends requests with the private DNS name as the TLS SNI hostname, so your resource receives requests addressed to its actual private domain. +When using a routing domain, the domain you specify for your target (in the MCP endpoint URL or OpenAPI server URL) should be the actual DNS name of your resource. The `routingDomain` is a separate domain that AgentCore uses to set up the VPC Lattice resource configuration. At invocation time, AgentCore routes traffic through the routing domain but sends requests with the actual target domain as the TLS SNI hostname, so your resource receives requests addressed to its actual domain. @@ -339 +345 @@ When using a routing domain, the domain you specify for your target (in the MCP -The routing domain can be any publicly resolvable domain that routes to your private resource within the VPC — including any existing component in your architecture that already has a publicly resolvable DNS name. Common options include: +The routing domain can be any domain that routes to your private resource within the VPC. Common options include: @@ -343 +349 @@ The routing domain can be any publicly resolvable domain that routes to your pri - * **Internal Application Load Balancer (ALB)** \- Use the internal ALB DNS name as the `routingDomain` , for example `internal-<alb-name>-<id>.us-west-2.elb.amazonaws.com` . Set the target URL to the private DNS name of the resource behind the ALB. + * **Internal Application Load Balancer (ALB)** \- Use the internal ALB DNS name as the `routingDomain` , for example `internal-<alb-name>-<id>.us-west-2.elb.amazonaws.com` . Set the target URL to the DNS name of the resource behind the ALB. @@ -345 +351 @@ The routing domain can be any publicly resolvable domain that routes to your pri - * **Internal Network Load Balancer (NLB)** \- Use the internal NLB DNS name as the `routingDomain` , for example `internal-<nlb-name>-<id>.elb.us-west-2.amazonaws.com` . Set the target URL to the private DNS name of the resource behind the NLB. + * **Internal Network Load Balancer (NLB)** \- Use the internal NLB DNS name as the `routingDomain` , for example `internal-<nlb-name>-<id>.elb.us-west-2.amazonaws.com` . Set the target URL to the DNS name of the resource behind the NLB. @@ -369 +375 @@ The following example shows how to create a gateway target for a private API Gat - "managedLatticeResource": { + "managedVpcResource": { @@ -387 +393 @@ The following example shows how to create a gateway target for a private API Gat -The `routingDomain` field is only available for the `managedLatticeResource` option. For self-managed Lattice, configure the routing domain directly in your resource configuration when you create it. +The `routingDomain` field is only available for the `managedVpcResource` option. For self-managed Lattice, configure the routing domain directly in your resource configuration when you create it. @@ -465 +471 @@ Use the ALB DNS name as the `routingDomain` and the public cert domain as the ta - "managedLatticeResource": { + "managedVpcResource": { @@ -479 +485 @@ The target URL in your target configuration should use `https://my-server.my-com -When you create a gateway target with a managed private endpoint ( `managedLatticeResource` ), AgentCore uses the `AWSServiceRoleForBedrockAgentCoreGatewayNetwork` service-linked role to create and manage VPC Lattice resource gateways in your account. This role is created automatically the first time you create a managed private endpoint target, provided your IAM principal has the required `iam:CreateServiceLinkedRole` permission. +When you create a gateway target with a managed private endpoint ( `managedVpcResource` ), AgentCore uses the `AWSServiceRoleForBedrockAgentCoreGatewayNetwork` service-linked role to create and manage VPC Lattice resource gateways in your account. This role is created automatically the first time you create a managed private endpoint target, provided your IAM principal has the required `iam:CreateServiceLinkedRole` permission. @@ -517,3 +523 @@ Resource configuration not found (self-managed) | For cross-account scenarios, -Be aware of the following limitations during the public preview of VPC egress for AgentCore: - - * **Private DNS** : Amazon VPC Lattice requires publicly resolvable DNS for resource configurations. If your private endpoint uses a domain that is only resolvable within your VPC, you must use the `routingDomain` field with a publicly resolvable intermediate domain such as a VPCE domain or internal ALB DNS name. +Be aware of the following limitations when using VPC egress for AgentCore: @@ -521 +525 @@ Be aware of the following limitations during the public preview of VPC egress fo - * **Cross-account** : Cross-account private connectivity requires the self-managed Lattice option. Managed Lattice does not support cross-account scenarios. + * **Cross-account** : Cross-account private connectivity requires the self-managed Lattice resources option. Managed VPC resources does not support cross-account scenarios.