AWS mostró cómo Amazon Bedrock AgentCore Gateway se conecta a APIs y servicios privados

AWS mostró cómo configurar Amazon Bedrock AgentCore Gateway para acceso seguro de agentes de IA a recursos privados dentro de una VPC. En la base de la arquitectura está el Resource Gateway, que crea Elastic Network Interfaces en subredes y proporciona una ruta controlada a APIs privadas, servicios y endpoints internos.

Cómo funciona

La idea principal es que los agentes no necesitan salir a Internet público para acceder a un servicio interno. Resource Gateway implementa una ENI en cada subred seleccionada de Amazon VPC y las utiliza como punto de entrada a la infraestructura privada. Por esto, las solicitudes de AgentCore Gateway viajan a través de la red interna de AWS, y los equipos obtienen mecanismos de control familiares: grupos de seguridad, gestión de tablas de rutas y segmentación de subredes.

Para empresas que no desean exponer APIs internas públicamente, este es el escenario más práctico. Este enfoque es especialmente importante para agentes de IA que necesitan trabajar no solo con modelos públicos, sino también con herramientas comerciales propietarias. Esto puede significar CRM internos, servicios de gestión de documentos, endpoints de inferencia privados o APIs accesibles solo desde dentro de la VPC. En lugar de construir esquemas alternativos con proxies y puertas de enlace públicas, AWS ofrece un canal de acceso nativo dentro de su propia red. Esto simplifica la arquitectura y ayuda a mantener los requisitos de seguridad, auditoría e aislamiento de red en un único lugar.

Dos modos de implementación

AWS ofrece dos opciones de implementación: gestionada y autogestionada. En modo gestionado, la mayor parte de la infraestructura de red se crea y mantiene por el servicio, por lo que los equipos alcanzan una conexión funcional más rápidamente y dedican menos tiempo a infraestructura rutinaria. El modo autogestionado es para quienes necesitan control total sobre el esquema de implementación, configuraciones de red e integración con políticas existentes de la empresa.

La elección entre ellas no depende de la funcionalidad del agente, sino de cuánto la empresa desea gestionar la capa de red de forma independiente.

• Gestionada es adecuada para inicios rápidos y escenarios típicos.
• Autogestionada proporciona más control sobre la red y el modelo operativo.
• Las ENI se crean en subredes de VPC, lo que ayuda a mantener el enrutamiento de tráfico privado.
• Las políticas de acceso se pueden combinar con grupos de seguridad y rutas existentes.

El significado práctico de esta distinción es simple: Bedrock AgentCore Gateway no impone un único método de conexión rígido. Si el equipo valora la velocidad de la prueba de concepto, puede confiar en el modelo gestionado. Si la prioridad es topología personalizada, requisitos empresariales o reglas de acceso especiales entre segmentos de red, puede construir el esquema usted mismo. Para equipos empresariales, esta es una señal importante: el servicio está diseñado no solo para demostraciones, sino para entornos de producción reales con restricciones internas.

Tres escenarios prácticos

AWS muestra tres escenarios que demuestran claramente por qué se necesita Resource Gateway.

El primero es conectarse a un endpoint privado en Amazon API Gateway, cuando un agente necesita llamar a una API que no está disponible externamente. El segundo es trabajar con un servidor MCP en Amazon EKS, es decir, con un servidor de herramientas implementado en un clúster Kubernetes dentro de la red en la nube. El tercero es el acceso a una API REST privada que puede servir a aplicaciones internas, bases de conocimiento o lógica corporativa.

• Llamar a un Amazon API Gateway privado sin publicar el endpoint públicamente.
• Integración con un servidor MCP en Amazon EKS para herramientas de agentes.
• Conectarse a una API REST interna que existe solo dentro de la VPC.

Estos ejemplos cubren un espectro bastante amplio de tareas. En un caso, el agente obtiene acceso a puertas de enlace de API ya existentes, en otro a la infraestructura de Kubernetes con sus propias herramientas, y en el tercero a cualquier servicio web interno con una interfaz REST. Esencialmente, AWS muestra un patrón: si tienes un servicio dentro de una red privada, puedes hacerlo disponible de manera limpia para AgentCore Gateway sin exponerlo a Internet. Esto reduce el compromiso entre seguridad y utilidad del agente.

Qué significa esto

AWS está transformando gradualmente AgentCore Gateway en un puente entre agentes LLM e infraestructura corporativa cerrada. Para las empresas, esto elimina una de las principales barreras para la adopción: los agentes se pueden conectar a APIs internas, servicios de Kubernetes y herramientas propietarias sin exposición externa innecesaria, lo que significa transiciones más rápidas de prueba de concepto a producción.