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

AWS showed how to configure Amazon Bedrock AgentCore Gateway for secure access of AI agents to private resources within a VPC. At the core of the architecture is Resource Gateway, which creates Elastic Network Interfaces in subnets and provides a controlled path to private APIs, services, and internal endpoints.

How it works

The main idea is that agents don't need to go out to the public internet to access an internal service. Resource Gateway deploys one ENI in each selected Amazon VPC subnet and uses them as an entry point to private infrastructure. Because of this, requests from AgentCore Gateway travel through AWS's internal network, and teams get familiar control mechanisms: security groups, routing table management, and subnet segmentation.

For companies that don't want to expose internal APIs publicly, this is the most practical scenario. This approach is especially important for AI agents that need to work not only with public models, but also with proprietary business tools. This could mean internal CRMs, document management services, private inference endpoints, or APIs accessible only from within the VPC. Instead of building workaround schemes with proxies and public gateways, AWS offers a native access channel within its own network. This simplifies architecture and helps keep security, audit, and network isolation requirements in one place.

Two deployment modes

AWS offers two implementation options: managed and self-managed. In managed mode, most of the network infrastructure is created and maintained by the service, so teams reach a working connection faster and spend less time on routine infrastructure. Self-managed mode is for those who need full control over the deployment scheme, network settings, and integration with existing company policies.

The choice between them depends not on agent functionality, but on how much the business wants to manage the network layer independently.

• Managed is suitable for quick starts and typical scenarios.
• Self-managed provides more control over the network and operational model.
• ENIs are created in VPC subnets, which helps maintain private traffic routing.
• Access policies can be combined with existing security groups and routes.

The practical meaning of this distinction is simple: Bedrock AgentCore Gateway doesn't impose one rigid connection method. If the team values speed of proof-of-concept, they can rely on the managed model. If the priority is custom topology, enterprise requirements, or special access rules between network segments, you can build the scheme yourself. For enterprise teams, this is an important signal: the service is designed not just for demos, but for real production environments with internal constraints.

Three practical scenarios

AWS shows three scenarios that clearly demonstrate why Resource Gateway is needed.

The first is connecting to a private endpoint in Amazon API Gateway, when an agent needs to call an API that's unavailable externally. The second is working with an MCP server in Amazon EKS—that is, with a tools server deployed in a Kubernetes cluster within the cloud network. The third is access to a private REST API that might serve internal applications, knowledge bases, or corporate logic.

• Calling a private Amazon API Gateway without publishing the endpoint publicly.
• Integration with an MCP server in Amazon EKS for agent tools.
• Connecting to an internal REST API that exists only within the VPC.

These examples cover a fairly wide range of tasks. In one case, the agent gets access to already-existing API gateways, in another—to Kubernetes infrastructure with its own tools, and in the third—to any internal web service with a REST interface. Essentially, AWS shows a pattern: if you have a service inside a private network, you can cleanly make it available to AgentCore Gateway without exposing it to 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 external exposure, which means faster transitions from proof-of-concept to production.