Networking & Content Delivery

Private connectivity patterns for Amazon Bedrock AgentCore Gateway Targets

Introduction

Private connectivity from AgentCore Gateway to your targets reduces compliance scope and simplifies auditing making it a common requirement in regulated environments. Whether your targets run inside an Amazon Virtual Private Cloud (Amazon VPC), across AWS accounts, in other AWS Regions, on-premises, or in multicloud environments, you need connectivity patterns that keep traffic off the public internet while remaining simple to configure. 

In this post, we walk through four private connectivity patterns for AgentCore Gateway:

1) Model Context Protocol (MCP) server Targets connectivity using private endpoint
2) REST API Targets connectivity using private endpoint 
3) Amazon Regional REST API Gateway Targets connectivity using VPC Link  
4) AWS Lambda targets connectivity using Hyperplane Elastic Network Interface (ENI)

By the end of this post, you can identify which pattern fits your architecture and configure private connectivity from AgentCore Gateway to each target type. The blog will assist platform engineers and cloud architects designing private connectivity for agentic AI workloads. The following figure illustrates Targets supported by Amazon Bedrock AgentCore Gateway.

Figure 1: AgentCore Gateway Targets with Internet and VPC integration

Figure 1: AgentCore Gateway Targets with Internet and VPC integration

Private MCP servers

Amazon Bedrock AgentCore Gateway natively connects to MCP servers with no protocol translation needed. When you add an MCP server as a target, AgentCore Gateway automatically discovers available tools by fetching the latest tool definitions from your target endpoints. 

Connect MCP server using private endpoint

For MCP servers running inside your VPC, you can configure a private endpoint powered by Amazon VPC Lattice. The Amazon VPC Lattice resource gateway in your subnet routes traffic privately to your MCP server. The private endpoint resides in the same account as AgentCore Gateway. Figure 2 shows this architecture. 

You can choose from two Amazon VPC Lattice options that determine how the resource gateway connects to your private MCP server 

Figure 2: MCP server Target integration via privateEndpoint (Lattice)

Figure 2: MCP server Target integration via privateEndpoint (Lattice)

a. Managed Amazon VPC Lattice

With the managed option, VPC Lattice resource gateways and resource configurations are provisioned and managed by AgentCore Gateway on your behalf. You provide your VPC, subnets, and security groups. This mode works well if you want simplicity with existing centralized routing topologies. Cross-account connectivity requires VPC peeringAWS Transit Gateway, or AWS Cloud WAN. Figure 3 shows the managed configuration. 

Figure 3: Managed Lattice

Figure 3: Managed Lattice

b. Self-Managed Amazon VPC Lattice

You provision and manage the Amazon VPC Lattice resource configuration, giving you full visibility and control over connected services, domains, and access policies. Use this mode if you need granular control or direct cross-account connectivity. You can connect through AWS Resource Access Manager (AWS RAM) without requiring VPC peering, AWS Transit Gateway or AWS Cloud WAN .

Figure 4: Self-Managed Lattice

Figure 4: Self-Managed Lattice

REST API

Many customers already have internal REST APIs powering their business: order management systems, inventory
services, CRM integrations and want to expose these to agentic AI use cases. You don’t need to rebuild these as MCP servers. AgentCore Gateway handles the protocol translation for you. You provide an OpenAPI 3.0 or 3.1 specification, and AgentCore Gateway converts MCP tool calls from your agents into standard HTTP requests, with your API responses wrapped back into MCP format. Each operationId in your OpenAPI spec automatically becomes a tool that agents can discover and call, so your existing APIs work with AI agents without additional configuration.

Connect REST APIs using private endpoint

a. OpenAPI Target with Private Endpoint

For REST APIs running as Private Compute in your VPC, you can configure an OpenAPI target with a private endpoint. This uses the same private endpoint configuration as MCP server targets. 

b. Private REST API Gateway with privateEndpoint

Private REST API Gateway endpoints are not natively supported as direct Gateway targets. To connect a Private REST API Gateway endpoint, export it as an OpenAPI specification, create an OpenAPI target with a private endpoint, and set the routingDomain to your Amazon API Gateway VPC endpoint (VPCE) DNS name. The routingDomain tells AgentCore Gateway where to send traffic for this target

You use the same private endpoint configuration to reach your private REST API VPC endpoint. For both patterns, if your endpoint uses a domain that isn’t resolvable from the public internet. For example, a private Amazon Route 53 hosted zoneyou must specify a routingDomain to tell Amazon VPC Lattice where to route traffic. Figure 5 shows the connectivity architecture.

Figure 5: REST API Target Integration via privateEndpoint (Lattice)

Figure 5: REST API Target Integration via privateEndpoint (Lattice)

Regional REST API Gateway

AgentCore Gateway integrates directly with your Amazon API Gateway REST API stages. Point it to a stage, and it automatically handles the translation between MCP and REST formats at runtime.

Regional REST API Gateway targets connectivity using VPC Link 

The Amazon API Gateway target must be a Regional REST API in the same account and Region as AgentCore Gateway. To reach private VPC resources, configure a VPC Link private integration on your Amazon API Gateway. AgentCore Gateway calls the public endpoint, and Amazon API Gateway routes traffic to your VPC through the VPC Link, establishing private connectivity to resources. 

VPC Link V1 supports Network Load Balancer only. VPC Link V2 supports both Network Load Balancer and Application Load Balancer. Figure 6 shows this architecture.

Figure 6: REST API Gateway Target Integration via VPC Link V2

Figure 6: REST API Gateway Target Integration via VPC Link V2

AWS Lambda functions

Amazon Bedrock AgentCore Gateway supports Lambda functions as targets, invoking them directly when an MCP tool call is received. The AgentCore Gateway passes tool arguments as the event object and provides metadata including gateway ID, target ID, and tool name via the context object. Your Lambda function simply processes the input and returns JSON, making it straightforward to implement custom tool logic without managing protocol translation. 

Lambda targets connectivity using Hyperplane ENI

Configure your Lambda function with VPC-enabled ENI to reach private resources within your VPC. AgentCore Gateway invokes Lambda, and the Lambda ENIs handle connectivity to VPC resources. When you configure a Lambda function with VPC access, AWS creates ENIs in the specified subnets. These ENIs provide the Lambda function with a private IP address from the VPC CIDR range, so it can communicate with other resources in the VPC. Figure 7 shows this architecture.

Figure 7: Lambda Target Integration via VPC enabled ENIs

Figure 7: Lambda Target Integration via VPC enabled ENIs

Advanced Connectivity Patterns

a. On-Premises Connectivity

To reach MCP servers or OpenAPI servers running in on-premises data centers, you can connect through AWS Direct Connect or AWS Site-to-Site VPN. 

b. Multi-Cloud Connectivity

To reach MCP servers or OpenAPI servers running in other cloud environments, you can connect through AWS Site-to-Site VPN or AWS Interconnect. 

You can establish VPN tunnels to other cloud providers (Google CloudOracle Cloud, or Microsoft Azure) using AWS Site-to-Site VPN without deploying or managing VPN appliances. You can create high-speed private connections (1 Gbps to 100 Gbps) to supported cloud providers using AWS Interconnect without configuring physical connections. 

In both cases, verify that the subnets associated with your Amazon VPC Lattice resource gateway, VPC Link, or VPC-enabled Lambda have routes to the other cloud environment through Virtual private gateways, AWS Transit Gateway, or AWS Cloud WAN. Figure 8 shows both on-premises and multicloud connectivity. 

Figure 8: Hybrid And Multi Cloud Connectivity Patterns

Figure 8: Hybrid And Multi Cloud Connectivity Patterns

c. Multi-VPC Connectivity

For targets distributed across multiple VPCs, accounts, or Regions, verify that the subnets associated with your Managed Amazon VPC Lattice resource gateway, VPC Link, or VPC-enabled Lambda have routes to the target VPCs through VPC peering, AWS Transit Gateway, or AWS Cloud WAN. Alternatively, with Self-Managed Amazon VPC Lattice, you can establish direct cross-account connectivity through AWS RAM without requiring VPC peering, AWS Transit Gateway, or AWS Cloud WAN. Figure 9 shows this architecture.

Figure 9: Multi-VPC Connectivity Pattern

Figure 9: Multi-VPC Connectivity Pattern

Conclusion 

In this post, we showed you four private connectivity patterns for routing AgentCore Gateway traffic to your targets without traversing the public internet. Each target has its own connectivity path: MCP targets connect through Amazon VPC Lattice, OpenAPI targets bridge REST endpoints including private Amazon API Gateways, AWS Lambda targets use built-in VPC ENIs, and Amazon API Gateway targets route through VPC Link. 

Start with the pattern that aligns with your existing infrastructure. The Advanced Connectivity Patterns section covers hybrid, multi-cloud, and multi-account configurations. 

About the authors

Rahi Patel

Rahi Patel

Rahi is a Startups Technical Account Manager at AWS specializing in Networking. He architects cloud networking solutions optimizing performance across global AWS deployments. Previously a network engineer with Cisco Meraki, he holds an MS in Engineering from San Jose State University. Outside work, he enjoys tennis and pickleball.

Vishal Bhagchandani

Vishal Bhagchandani

Vishal is a Cloud Engineer at AWS. He works actively with customers on Amazon SageMaker, Amazon Bedrock, and Amazon CloudFront, helping them build, deploy, and optimize their AI/ML workloads and content delivery solutions on the cloud. He authors technical documentation and produces video content for the AWS YouTube channel that directly helps customers optimize their cloud workloads, improving their overall AWS experience.