AWS shows how Amazon Bedrock AgentCore Gateway connects to private APIs and services

AWS has shown how to configure Amazon Bedrock AgentCore Gateway so AI agents can securely reach private resources inside a VPC. The setup centers on a Resource Gateway, which creates Elastic Network Interfaces in subnets and provides a controlled path to closed APIs, services and internal endpoints.

How it works

The core idea is that an agent does not need to go through the public internet to call an internal service. Resource Gateway deploys one ENI in each selected Amazon VPC subnet and uses them as the entry point to private infrastructure. As a result, requests from AgentCore Gateway travel over the internal AWS network, and teams keep the controls they already know: security groups, route-table routing and subnet segmentation. For companies that do not want to expose internal APIs externally, this is the most practical option.

The approach matters most for AI agents that must work not only with public models but also with a business's closed tools. That could mean internal CRMs, document-management services, private inference endpoints or APIs reachable only from the VPC. Instead of building workarounds with proxies and public gateways, AWS offers a native access channel inside its own network. This simplifies the architecture and keeps security, audit and network-isolation requirements in one place.

Two operating modes

AWS offers two deployment options: managed and self-managed. In managed mode, the service creates and maintains most of the networking plumbing, so a team reaches a working connection faster and spends less time on routine infrastructure. Self-managed mode is for those who need full control over the deployment layout, network settings and integration with existing company rules. The choice between them depends not on what the agent does, but on how deeply the business wants to manage the network layer itself.

• Managed suits a fast start and typical scenarios.
• Self-managed gives more control over the network and the operating model.
• ENIs are created in VPC subnets, which helps keep traffic on a private route.
• Access policies can be combined with existing security groups and routes.

The practical meaning of this split is simple: Bedrock AgentCore Gateway does not force a single rigid way to connect. If pilot speed matters, a team can rely on the managed model. If the priority is a custom topology, corporate requirements or special access rules between network segments, it can build the setup itself. For enterprise teams this is an important signal: the service is built not only for demos but also for real production environments with internal constraints.

Three practical scenarios

AWS presents three scenarios that show clearly why Resource Gateway exists. The first is connecting to a private endpoint in Amazon API Gateway, where the agent must call an API that is unreachable from outside. The second is working with an MCP server in Amazon EKS, that is, a tool server deployed in a Kubernetes cluster inside the cloud network. The third is access to a private REST API, which can serve internal applications, knowledge bases or corporate logic.

• Calling a private Amazon API Gateway without publishing the endpoint externally.
• Integrating with an MCP server in Amazon EKS for agent tools.
• Connecting to an internal REST API that lives only inside the VPC.

These examples cover a fairly wide range of tasks. In one case the agent reaches existing API gateways, in another Kubernetes infrastructure with its own tools, and in the third any internal web service with a REST interface. In essence, AWS is showing a template: if you have a service inside a private network, you can carefully make it available to AgentCore Gateway without moving it onto the internet. This reduces the trade-off between security and agent usefulness.

What this means

AWS is gradually turning AgentCore Gateway into a bridge between LLM agents and closed corporate infrastructure. For companies, this removes one of the main barriers to adoption: agents can be connected to internal APIs, Kubernetes services and proprietary tools without unnecessary exposure to the outside, which means pilots can move to production faster.