AWS muestra cómo Amazon Bedrock AgentCore Gateway se conecta a APIs y servicios privados
AWS ha mostrado cómo conectar Amazon Bedrock AgentCore Gateway con recursos privados dentro de una VPC mediante un Resource Gateway. El esquema crea ENI en las subredes y da a los agentes acceso seguro a APIs cerradas, entre ellas un Amazon API Gateway privado, un servidor MCP en EKS y servicios REST internos, sin exponerlos a internet. Se admiten escenarios managed y self-managed.
Procesado por IA desde AWS Machine Learning Blog; editado por Hamidun News
AWS ha mostrado cómo configurar Amazon Bedrock AgentCore Gateway para que los agentes de IA accedan de forma segura a recursos privados dentro de una VPC. La base del esquema es Resource Gateway, que crea Elastic Network Interfaces en las subredes y ofrece una ruta controlada hacia APIs cerradas, servicios y endpoints internos.
Cómo funciona
La idea central es que el agente no necesita salir a internet para llamar a un servicio interno. Resource Gateway despliega una ENI en cada subred de Amazon VPC seleccionada y las usa como punto de entrada a la infraestructura privada. Así, las solicitudes de AgentCore Gateway circulan por la red interna de AWS, y el equipo conserva los mecanismos de control habituales: security groups, enrutamiento mediante tablas de rutas y segmentación por subredes. Para las empresas que no quieren exponer sus APIs internas, es el escenario más práctico.
Este enfoque importa sobre todo para los agentes de IA que deben trabajar no solo con modelos públicos, sino también con herramientas cerradas de la empresa. Pueden ser CRM internos, servicios de gestión documental, endpoints privados de inferencia o APIs accesibles solo desde la VPC. En lugar de montar rodeos con proxies y gateways públicos, AWS propone un canal de acceso nativo dentro de su red. Esto simplifica la arquitectura y concentra en un solo lugar los requisitos de seguridad, auditoría y aislamiento de red.
Dos modos de funcionamiento
AWS ofrece dos variantes de implantación: managed y self-managed. En el modo managed, el servicio crea y mantiene la mayor parte de la infraestructura de red, de modo que el equipo llega antes a una conexión operativa y dedica menos tiempo a infraestructura rutinaria. El modo self-managed es para quienes necesitan control total sobre el esquema de despliegue, la configuración de red y la integración con las reglas ya existentes de la empresa. La elección no depende de la funcionalidad del agente, sino de cuánto quiere el negocio gestionar por su cuenta la capa de red.
- Managed sirve para empezar rápido y para escenarios típicos.
- Self-managed ofrece más control sobre la red y el modelo operativo.
- Las ENI se crean en subredes de la VPC, lo que ayuda a mantener una ruta privada del tráfico.
- Las políticas de acceso pueden combinarse con los security groups y rutas existentes.
El sentido práctico de esta división es sencillo: Bedrock AgentCore Gateway no impone una única forma rígida de conexión. Si al equipo le importa la velocidad del piloto, puede apoyarse en el modelo gestionado. Si la prioridad es una topología personalizada, requisitos corporativos o reglas de acceso especiales entre segmentos de red, puede montar el esquema por su cuenta. Para los equipos enterprise es una señal importante: el servicio no está pensado solo para demos, sino para entornos de producción reales con restricciones internas.
Tres escenarios prácticos
AWS presenta tres escenarios que dejan claro para qué sirve Resource Gateway. El primero es la conexión a un endpoint privado de Amazon API Gateway, cuando el agente debe llamar a una API inaccesible desde fuera. El segundo es el trabajo con un servidor MCP en Amazon EKS, es decir, un servidor de herramientas desplegado en un clúster de Kubernetes dentro de la red de la nube. El tercero es el acceso a una API REST privada, que puede dar servicio a aplicaciones internas, bases de conocimiento o lógica corporativa.
- Llamada a un Amazon API Gateway privado sin publicar el endpoint al exterior.
- Integración con un servidor MCP en Amazon EKS para herramientas de agentes.
- Conexión a una API REST interna que existe solo dentro de la VPC.
Estos ejemplos cubren un abanico bastante amplio de tareas. En un caso el agente accede a gateways de API ya existentes; en otro, a una infraestructura de Kubernetes con herramientas propias; y en el tercero, a cualquier servicio web interno con interfaz REST. En el fondo, AWS muestra una plantilla: si tienes un servicio dentro de una red privada, puedes hacerlo accesible con cuidado para AgentCore Gateway sin sacarlo a internet. Eso reduce el compromiso entre seguridad y utilidad de los agentes.
Qué significa
AWS convierte poco a poco AgentCore Gateway en un puente entre los agentes LLM y la infraestructura corporativa cerrada. Para las empresas, esto elimina una de las principales barreras de adopción: los agentes pueden conectarse a APIs internas, servicios de Kubernetes y herramientas propias sin exposición innecesaria al exterior, lo que permite llevar los pilotos a producción más rápido.
- 31 oct 2026Worldwide Express encargó las facturas en disputa a agentes de IA y redujo su deuda un 75%
- 30 oct 2026AWS ofrece a los agentes de código una vista previa en vivo del sitio desde la sesión aislada
- 30 oct 2026MoEngage abre 400 API cerradas a agentes de IA con AgentCore Gateway, sin servidores MCP propios
- 29 oct 2026NVIDIA Nemotron 3.5 Super VL: 120 mil millones de parámetros, 12 mil millones activos, despliegue en AWS
Preguntas frecuentes sobre la noticia
Cómo funciona?
La idea central es que el agente no necesita salir a internet para llamar a un servicio interno. Resource Gateway despliega una ENI en cada subred de Amazon VPC seleccionada y las usa como punto de entrada a la infraestructura privada. Así, las solicitudes de AgentCore Gateway circulan por la red interna de AWS, y el equipo conserva los mecanismos de control habituales: security groups, enrutamiento mediante tablas de rutas y segmentación por subredes. Para las empresas que no quieren exponer sus APIs internas, es el escenario más práctico. Este enfoque importa sobre todo p
¿Qué se sabe sobre Dos modos de funcionamiento?
AWS ofrece dos variantes de implantación: managed y self-managed. En el modo managed, el servicio crea y mantiene la mayor parte de la infraestructura de red, de modo que el equipo llega antes a una conexión operativa y dedica menos tiempo a infraestructura rutinaria. El modo self-managed es para quienes necesitan control total sobre el esquema de despliegue, la configuración de red y la integración con las reglas ya existentes de la empresa. La elección no depende de la funcionalidad del agente, sino de cuánto quiere el negocio gestionar por su cuenta la capa de red. Manag
¿Qué se sabe sobre Tres escenarios prácticos?
AWS presenta tres escenarios que dejan claro para qué sirve Resource Gateway. El primero es la conexión a un endpoint privado de Amazon API Gateway, cuando el agente debe llamar a una API inaccesible desde fuera. El segundo es el trabajo con un servidor MCP en Amazon EKS, es decir, un servidor de herramientas desplegado en un clúster de Kubernetes dentro de la red de la nube. El tercero es el acceso a una API REST privada, que puede dar servicio a aplicaciones internas, bases de conocimiento o lógica corporativa. Llamada a un Amazon API Gateway privado sin publicar el endpo
Build & Ship Production AI Agents Without Boilerplate Code
Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.
Lo esencial de la IA — una vez por semana
Siete historias que de verdad importaron, elegidas a mano. Sin ruido ni notas de prensa.
¡Listo! Revisa tu correo para la confirmación.