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 muestra cómo Amazon Bedrock AgentCore Gateway se conecta a APIs y servicios privados
Fuente: AWS Machine Learning Blog. Collage: Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Fuente originalAWS Machine Learning Blog ↗
Editor jefe
Dato clave #1Managed sirve para empezar rápido y para escenarios típicos.
Dato clave #2Self-managed ofrece más control sobre la red y el modelo operativo.
Dato clave #3Las ENI se crean en subredes de la VPC, lo que ayuda a mantener una ruta privada del tráfico.

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.

Historia

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

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Hands-On AI Engineering · Hamidun Academy

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.

Start 72h Free Trial →Vibe-Coding Intensive
¿Qué te parece?
Cargando comentarios…