La puerta de enlace AgentCore de Amazon Bedrock es una puerta de enlace de IA sin servidor y totalmente administrada que proporciona un punto de entrada único y seguro para el tráfico de IA. La puerta de enlace AgentCore enruta el tráfico a herramientas como búsqueda web administrada, bases de conocimiento administradas, servidores MCP, modelos de inferencia (LLM), agentes (A2A, agentes como herramientas, etc.) o puntos finales HTTP. Hoy anunciamos compatibilidad con la limitación de velocidad en la puerta de enlace AgentCore, lo que le brinda un control detallado sobre la cantidad de tráfico que los usuarios individuales pueden consumir a través de su puerta de enlace.
La limitación de velocidad en la puerta de enlace AgentCore le brinda control por usuario sobre cómo los usuarios consumen sus herramientas, modelos de inferencia y agentes. Defina reglas basadas en OAuth o IAM para solicitudes por minuto, conexiones simultáneas y rendimiento de tokens, asegurándose de que los servicios descendentes permanezcan disponibles ante picos de tráfico intensos.
Limitación de velocidad centralizada para el tráfico de IA con la puerta de enlace AgentCore
La puerta de enlace AgentCore proporciona tres tipos de objetivos: objetivos MCP, objetivos de inferencia y objetivos de paso HTTP. Los objetivos admiten las siguientes métricas de limitación de velocidad.
Los límites de tasa de solicitudes, medidos en solicitudes por segundo (RPS) y solicitudes por minuto (RPM), se aplican a todos los tipos de objetivos. Cada límite define un recuento máximo de solicitudes permitidas dentro de un período de tiempo determinado, y la puerta de enlace mide cada solicitud entrante en función de él. Una solicitud cuenta exactamente como una unidad para el límite configurado, independientemente de cuánto tiempo demore en completarse, una solicitud que finaliza en 50 milisegundos y una que se transmite durante 90 segundos consumen exactamente una unidad del límite por segundo o por minuto. Los límites de la tasa de tokens, medidos en tokens por minuto (TPM), se aplican únicamente a los objetivos de inferencia. Cuentas que limitan la tasa de tokens tanto para tokens de entrada como para tokens de salida. El costo total del token de ida y vuelta de una solicitud cuenta para el límite. La puerta de enlace AgentCore utiliza un tokenizador de propósito general para estimar los tokens entrantes para una solicitud y los deduce del depósito de límite de velocidad por adelantado antes de que la puerta de enlace envíe la llamada de inferencia. Una vez que la llamada de inferencia devuelve una respuesta, que incluye el uso real de tokens de entrada y salida informado por el proveedor del modelo, la puerta de enlace concilia el límite teniendo en cuenta el consumo real de tokens. Los límites de velocidad de conexión, medidos en conexiones por segundo (CPS), se aplican a todos los tipos de destino. A diferencia de los límites de la tasa de solicitudes, la limitación de la tasa de conexión rastrea cuánto tiempo cada solicitud mantiene una conexión abierta. Por ejemplo, si una llamada de inferencia de transmisión tarda 100 segundos en completarse, esa solicitud consume un espacio de conexión durante toda la duración. CPS proporciona un mecanismo adicional para proteger objetivos contra sesiones simultáneas de larga duración, particularmente útil cuando se necesita limitar el número de conexiones simultáneas que sostiene un objetivo, en lugar de cuántas solicitudes llegan a cada ventana.
Para este caso de uso, suponga tres grupos de usuarios: Básico, Avanzado y Beta. AgentCore Identity maneja la autenticación entrante utilizando JSON Web Tokens (JWT) con Microsoft Entra ID como proveedor de identidad y también sirve como servicio de venta de tokens para objetivos salientes. La política de Amazon Bedrock AgentCore aplica el control de acceso basado en roles (RBAC), limitando el acceso de cada grupo a objetivos y modelos específicos. El siguiente diagrama ilustra esta configuración.
Figura 1: Arquitectura de limitación de velocidad de puerta de enlace de AgentCore con grupos de usuarios, identidad y aplicación de políticas
Los usuarios básicos operan bajo límites de tarifas más restrictivos que los usuarios avanzados, mientras que los usuarios Beta reciben límites elevados en los modelos restringidos, lo que permite a la organización comparar el rendimiento y la idoneidad antes de implementar estos modelos en la organización en general. Antes de configurar límites de tarifas para cada grupo de usuarios, revise la estructura de límites de tarifas.
Estructura de límite de tarifas
Una configuración de límite de velocidad consta de dos partes: claves de dimensión y entradas. Las claves de dimensión definen cómo la puerta de enlace agrupa el tráfico entrante en grupos de tarifas. Las entradas definen el rendimiento permitido para cada depósito.
En esta publicación, utilizamos la interfaz de línea de comandos de AWS (AWS CLI) para crear la configuración del límite de velocidad. El siguiente ejemplo demuestra la relación entre claves de dimensión y entradas. Este límite de velocidad utiliza targetName como clave de dimensión y define dos entradas: una entrada específica para el objetivo de Booking (servidor MCP), un objetivo de alto tráfico, a 100 solicitudes por segundo, y una entrada comodín que aplica 10 solicitudes por segundo individualmente a cada objetivo restante, lo que significa que cada otro objetivo recibe su propio depósito de 10 RPS.
Figura 2: Estructura de límite de tarifas con claves de dimensión y entradas
Las claves de dimensión definen cómo la puerta de enlace agrupa el tráfico en grupos de tarifas. Cuando llega una solicitud, la puerta de enlace resuelve cada clave de dimensión en su valor del contexto de la solicitud y utiliza la combinación resultante para asignar la solicitud al grupo de tarifas correcto. La puerta de enlace AgentCore admite las siguientes claves de dimensión: targetName, toolName, QualifiedModelId, $.context.jwt., $.context.iam.principal y $.context.iam.sourceIdentity. Exploraremos cada uno de estos a través de ejemplos en las secciones siguientes.
Las entradas son las reglas dentro de un límite de tarifa. Cada entrada especifica un conjunto de claves de dimensión que deben coincidir y el rendimiento permitido para esa coincidencia. Las entradas admiten el valor predeterminado general especial * que le da a cada valor distinto su propio depósito independiente a la velocidad configurada. Cuando la puerta de enlace evalúa una solicitud, comprueba si una entrada coincide por nombre antes de recurrir al comodín. Una entrada con nombre tiene prioridad porque hace referencia explícita al valor en lugar de depender del comodín.
Tomando el límite de tarifa anterior como ejemplo, cuando llega una solicitud para el destino de la reserva (servidor MCP), la puerta de enlace coincide con la primera entrada y permite hasta 100 RPS. Esta entrada tiene prioridad porque el valor más específico coincide con el valor predeterminado *, ya que se refiere al destino de reserva por nombre. Para cualquier otro objetivo, no existe ninguna entrada con nombre, por lo que la puerta de enlace recurre a la entrada comodín y permite hasta 10 solicitudes por segundo. Cada destino que coincide con el comodín (Docs, BedrockMantle, CustomPlatform y awsdocsagent) obtiene su propio depósito independiente.
Puede combinar varias claves de dimensión para obtener un control más granular. Por ejemplo, dimensionKeys: [“targetName”, “$.context.jwt.role”] agrupa el tráfico según el objetivo y el rol de identidad de la persona que llama, dando a cada grupo de usuarios (Básico, Avanzado o Beta en el ejemplo anterior) su propio grupo de tarifas independiente por objetivo.
Tipos de límites de velocidad y configuraciones de ejemplo
La puerta de enlace AgentCore aplica dos capas de limitación de tarifas: límites de tarifas definidos por el cliente y cuotas de servicio. Los límites de tarifas definidos por el cliente se evalúan primero. Si se aprueba la solicitud, se evalúan las cuotas de servicio. Las siguientes secciones explican las cuotas de servicio y los diferentes tipos de límites de tarifas definidos por el cliente.
Servicio de cuotas gestionadas.
Estos son los límites que el servicio aplica en la puerta de enlace de AgentCore por cuenta de AWS. Las cuotas administradas por el servicio definen el límite que los límites de tarifas definidos por el cliente no pueden exceder. La tarifa efectiva para solicitudes es el mínimo del límite definido por el cliente y el límite administrado por el servicio. Puede solicitar aumentos para algunas cuotas utilizando la consola de Cuotas de Servicio.
Límites de usuarios definidos por el cliente.
Los límites a nivel de usuario utilizan $.context.jwt., $.context.iam.principal y $.context.iam.sourceIdentity como claves de dimensión para controlar cuánto tráfico pueden consumir los usuarios individuales o el grupo de usuarios completo. Estos límites imponen un uso justo en toda su base de llamadas y evitan que una sola persona monopolice la capacidad de la puerta de enlace. El siguiente ejemplo asigna diferentes tasas de solicitud por grupo de usuarios. El reclamo de rol de JWT es una matriz, por lo que cada combinación única requiere su propia entrada.
En esta configuración, los usuarios Básicos reciben dos depósitos, 100 RPM y 50 CPS, lo que significa que cada solicitud de cualquier usuario Básico cuenta para el mismo total de 100 RPM, y cada conexión cuenta para el mismo total de 50 CPS. Si un usuario Básico envía 80 solicitudes en un minuto, solo quedan 20 para todos los demás usuarios Básicos en esa ventana. Los usuarios avanzados reciben sus propios dos cubos a 300 RPM y 150 CPS, regidos por el mismo comportamiento colectivo. Los usuarios con membresía en el grupo [“Avanzado”, “Beta”] reciben dos depósitos a 300 RPM y 200 CPS. La mayor asignación de conexión se adapta a sus cargas de trabajo de evaluación comparativa con gran cantidad de transmisión.
Sin embargo, dentro de un grupo, un solo usuario aún puede consumir todo el grupo de tarifas del grupo, lo que limita a todos los demás en ese grupo. Por ejemplo, un usuario Básico que envía 100 solicitudes en un minuto dejaría cero capacidad para todos los demás usuarios Básicos. Para evitar esto, también creamos la siguiente configuración de límite de velocidad.
Con esta configuración, cada usuario individual tiene su propio límite, independientemente de cuántos usuarios existan en su grupo. El reclamo $.context.jwt.sub del JWT identifica de forma única a cada usuario, lo que permite a la puerta de enlace rastrear y hacer cumplir los límites a nivel individual. Incluso si el límite a nivel de grupo permite un total de 100 RPM para Básico, ningún usuario puede consumir más de 20 RPM y 10 CPS de ese grupo compartido. La misma lógica se aplica a los usuarios avanzados y beta con sus respectivos límites individuales. Juntos, el límite por grupo y el límite por usuario crean un modelo de cumplimiento de dos niveles: el límite máximo de grupo ayuda a evitar que un grupo mate de hambre a otro, y el límite por usuario ayuda a evitar que un individuo mate de hambre a sus pares dentro del mismo grupo.
Ambos límites de velocidad se evalúan de forma independiente mediante la semántica AND. Una solicitud debe superar tanto el límite a nivel de grupo como el límite por usuario para continuar. Si cualquiera de las comprobaciones rechaza la solicitud, la puerta de enlace devuelve una respuesta de limitación. Por ejemplo, si Arnav (Básico) ha consumido 20 RPM individualmente, el límite por usuario deniega su siguiente solicitud, aunque al grupo Básico todavía le quedan 80 RPM de capacidad restante. Por el contrario, si el grupo Básico ha consumido colectivamente 100 RPM, todos los usuarios Básicos están limitados independientemente de su consumo individual.
Límites de nivel objetivo definidos por el cliente.
Los límites a nivel de destino utilizan targetName, QualifiedModelId o toolName como clave de dimensión para controlar el rendimiento de objetivos, modelos o herramientas posteriores específicos. Estos límites protegen la capacidad de backend y distribuyen la carga entre los recursos de destino. El siguiente ejemplo limita el tráfico por objetivo.
También puede utilizar QualifiedModelId para establecer límites de velocidad de conexión (CPS) por modelo, o toolName para establecer límites de velocidad de solicitud (RPS) por herramienta individual, como Booking___bookTool o Docs___searchDocsTool.
Nota: Excluimos los límites de tarifas a nivel objetivo definidos por el cliente de nuestra configuración de casos de uso. Los usuarios beta ejecutan pesadas cargas de trabajo de evaluación comparativa con modelos restringidos, consumiendo una parte desproporcionada de un límite de nivel objetivo compartido. Debido a que este límite limita las dimensiones solo en targetName, todos los usuarios comparten un límite único, lo que significa que el alto tráfico de un grupo o individuo puede matar de hambre a todos los demás en ese objetivo. Cuando se espera que un subconjunto de usuarios domine el consumo de tokens o conexiones en un objetivo específico, limite el límite por identidad (por ejemplo, [“targetName”, “$.context.jwt.role”]). Vea el siguiente ejemplo.
Límites de nivel de usuario objetivo definidos por el cliente.
Los límites híbridos combinan dimensiones de destino y usuario en una configuración de límite de tasa única, lo que le brinda el control más granular. Al utilizar claves multidimensionales, puede limitar los límites de velocidad a un usuario o grupo de usuarios específico en un objetivo, modelo o herramienta específicos.
El siguiente ejemplo aplica límites de tokens a nivel de modelo, con alcance para cada usuario dentro de su grupo. La dimensión QualifiedModelId es el identificador de modelo completo para los objetivos de inferencia. Identifica de forma única el modelo que se invoca (consulte la documentación).
En esta configuración, anthropic.claude-fable-5 es un modelo restringido. Solo los usuarios con el rol [“Avanzado”, “Beta”] pueden invocarlo, recibiendo 80 000 TPM por usuario para cargas de trabajo de evaluación y evaluación comparativa. Tanto los usuarios [“Básicos”] como los [“Avanzados”] tienen bloqueado* la posibilidad de invocar este modelo con una tasa de cero. El mismo patrón se aplica a otros modelos restringidos (openai.gpt-5.6-luna y openai.gpt-5.6-terra), asegúrese de agregar entradas siguiendo la misma estructura para cada uno. Para los modelos disponibles de forma general, los usuarios básicos reciben 20 000 TPM por usuario, mientras que los usuarios avanzados reciben 40 000 TPM por usuario a través de entradas comodín.
Las entradas específicas tienen prioridad sobre los comodines siguiendo la regla de victorias del partido más específico. Cuando María (sub: “María”, rol: [“Avanzado”, “Beta”]) invoca anthropic.claude-fable-5, la puerta de enlace coincide con la entrada explícita y aplica 80,000 TPM con alcance a María individualmente. Si María agota el límite de 80.000 TPM, otros usuarios Beta no se verán afectados porque * en $.context.jwt.sub le da a cada usuario su propio depósito aislado. Cuando John (sub: “John”, rol: [“Avanzado”]) intenta anthropic.claude-fable-5, la puerta de enlace coincide con la entrada explícita [“Avanzado”] para ese modelo, que establece las solicitudes en cero bloqueando la llamada. Cuando John invoca un modelo disponible de forma general como anthropic.claude-sonnet-5, no existe una entrada explícita para esa combinación de modelo y rol, por lo que la puerta de enlace pasa a la entrada comodín para [“Avanzado”] y aplica 40 000 TPM. Cuando Arnav (sub: “Arnav”, rol: [“Básico”]) invoca el mismo modelo disponible de forma general, recibe 40 000 TPM a través de la entrada comodín Básico.
También puede combinar dimensiones como [“$.context.jwt.role”, “targetName”] para límites de solicitudes por función y por objetivo, [“$.context.jwt.sub”, “targetName”] para solicitudes combinadas por usuario y por objetivo y límites de token, o [“$.context.jwt.role”, “toolName”] para límites de solicitudes por función y por herramienta. Para obtener más configuraciones de limitación de velocidad, consulte Ejemplos de API de límite de velocidad.
Límites de tarifas para cargas de trabajo agentes
Considere la siguiente configuración de puerta de enlace de AgentCore donde un usuario invoca el Agente de documentación de AWS. El agente utiliza dos recursos posteriores a través de la puerta de enlace: el objetivo Docs MCP para la búsqueda y recuperación de documentos, y el objetivo de inferencia BedrockMantle para razonar a través del modelo anthropic.claude-sonnet-5. La siguiente arquitectura muestra esto:
Figura 3: Limitación de la tasa de carga de trabajo de Agentic con el consumo de recursos posteriores
Hay dos tipos de límites de velocidad a considerar para cargas de trabajo agentes:
Límites de velocidad en la invocación de agentes.
El primer tipo protege la frecuencia con la que los usuarios u otros servicios pueden invocar al agente. Estos son límites de solicitud (RPM) y conexión (CPS) cuyo ámbito es el propio objetivo del agente. En el nivel más simple, puede dimensionar solo en targetName, por ejemplo, {“targetName”: “awsdocsagent”}, de modo que todos los usuarios compartan un único límite de invocación. Para obtener un control más granular, empareje targetName con dimensiones de usuario como [“targetName”, “$.context.jwt.role”] o [“targetName”, “$.context.jwt.role”, “$.context.jwt.sub”] para limitar la frecuencia con la que cada grupo de usuarios o usuario individual puede invocar al agente.
Límites de tarifas de los recursos consumidos por el agente.
El segundo tipo protege los recursos posteriores que consume el agente en cada invocación. El agente de documentación de AWS desencadena varias solicitudes posteriores. El agente llama al destino Docs MCP para recuperar documentos y al destino BedrockMantle para realizar inferencias. La forma de calificar el límite de estas llamadas descendentes depende de cómo el agente se autentica con la puerta de enlace al invocar esos recursos.
Si el agente realiza un intercambio de tokens en nombre de (OBO) basado en el token JWT entrante del usuario, las solicitudes posteriores llevan la identidad del usuario original. Se aplican todos los límites de tarifas existentes basados en el usuario. Los límites por rol y por usuario que configuró anteriormente se aplicarán a las llamadas posteriores del agente como si el usuario las realizara directamente.
Sin embargo, si el agente realiza una concesión de máquina a máquina para obtener un nuevo token (por ejemplo, un flujo de credenciales de cliente), las solicitudes posteriores llevan la propia identidad del agente en lugar de la de la persona que llama. En este caso, los límites de tarifas basados en el usuario no coincidirán con las reclamaciones del usuario. Debe agregar límites de tarifas que identifiquen al agente en sí, según su proveedor de identidad, utilizar un reclamo que identifique de forma única al agente, como $.context.jwt.azp (parte autorizada), y limitar en consecuencia para evitar que un solo agente agote los recursos compartidos.
Mejores prácticas de limitación de velocidad
Siga estas mejores prácticas al crear límites de tarifas con la puerta de enlace AgentCore:
Si está utilizando la Política en AgentCore para hacer cumplir la autorización RBAC, es importante comprender el orden de evaluación. Los límites de tarifas se aplican primero; La política AgentCore se evalúa después. Esto significa que incluso si la política AgentCore finalmente le niega el acceso a un usuario o rol, su solicitud aún consume el depósito de límite de velocidad antes de que ocurra esa denegación. Para evitar este consumo, cree una entrada de límite de tasa que asigne explícitamente una tasa de cero a los usuarios o grupos que la política AgentCore bloquearía; esto garantiza que la solicitud se rechace en la capa de límite de tasa sin agotar el presupuesto disponible para las personas que llaman autorizadas. La puerta de enlace evalúa primero los límites de velocidad con más claves de dimensión (los límites más específicos tienen prioridad). Dentro del mismo número de dimensiones, la puerta de enlace evalúa primero los límites de tarifas con tarifas más estrictas (más bajas). La evaluación sufre un cortocircuito en la primera denegación, lo que significa que la puerta de enlace no evalúa los límites de velocidad restantes una vez que se rechaza una solicitud. Diseñe su configuración de límite de tasa para que sus límites más estrictos se encuentren en el nivel de dimensión más alto (por ejemplo, el límite de tres claves [“$.context.jwt.role”,“qualifiedModelId”,“$.context.jwt.sub”]). No se pueden crear dos límites de tarifas con la misma clave de dimensión pero con diferentes pedidos. Por ejemplo, no puede crear un límite de velocidad con [“$.context.jwt.role”, “qualifiedModelId”, “$.context.jwt.sub”] y [“qualifiedModelId”, “$.context.jwt.role”, “$.context.jwt.sub”] clave de dimensión en la misma puerta de enlace. Sin embargo, el orden de la clave de dimensión es importante. Cuando un límite de tasa tiene varias claves de dimensión, el orden en que las declara determina cómo se pueden utilizar los comodines. El valor predeterminado catch all * solo puede aparecer en posiciones finales. Si utiliza * en la posición N, todas las posiciones posteriores también deben ser *. Esta restricción de seguimiento facilita un comportamiento de coincidencia predecible. Para comprender este comportamiento, consulte los ejemplos. Evite el uso de notificaciones JWT ilimitadas o de alta cardinalidad como claves de dimensión (por ejemplo, $.context.jwt.jti, $.context.jwt.nonce o ID de solicitud). Estos crean un número ilimitado de categorías de tarifas y pueden reducir la efectividad de la limitación de tarifas. Utilice identificadores estables y acotados, como sub, rol, equipo o nivel. La puerta de enlace utiliza semántica de apertura fallida para la evaluación del límite de velocidad. Debido al comportamiento de apertura fallida, no confíe únicamente en los límites de velocidad como límite de seguridad. Utilice límites de velocidad para la gestión del tráfico y la calidad del servicio, y utilice autenticación, autorización y reglas de AWS WAF para aplicar la seguridad. Habilite los registros de aplicaciones en su puerta de enlace AgentCore. Esto le brinda acceso a registros de limitación de velocidad. La puerta de enlace emite atributos de intervalo de OpenTelemetry (OTEL) en el intervalo del servidor para cada solicitud en la que se evalúan los límites de tarifas del cliente. Utilice estos atributos para depurar y monitorear. Asegúrese de incluir una entrada general; considere una puerta de enlace con un límite de velocidad único para simplificar:
En esta configuración, sólo Arnav tiene una entrada explícita. Si John ($.context.jwt.sub: “John”) invoca la puerta de enlace, la solicitud no coincide con ninguna entrada, el límite de velocidad se omite efectivamente y John no alcanza las cuotas administradas por el servicio sin aplicación definida por el cliente. Agregar una entrada general comodín garantiza que todas las personas que llaman sin una entrada explícita reciban su propio límite de tarifa por usuario:
Ahora John, María y cualquier otra persona que llame recibe cada uno su propio depósito aislado de 50 RPM a través del comodín, mientras que Arnav conserva su asignación explícita de 100 RPM. Sin la entrada general, las personas que llaman sin correspondencia pasan por alto el límite de tarifa por completo.
Para conocer más prácticas recomendadas, consulte la documentación de la puerta de enlace de AgentCore.
Conclusión
En esta publicación, explicamos cómo configurar límites de velocidad en la puerta de enlace de Amazon Bedrock AgentCore para controlar el tráfico de IA, imponiendo un uso justo entre roles y usuarios y, al mismo tiempo, ayudando a evitar que cualquier persona que llama o carga de trabajo agote la capacidad compartida. Demostramos cómo superponer límites de velocidad: límites a nivel de usuario para lograr equidad por función y por usuario, límites a nivel de objetivo para proteger la capacidad del servicio descendente y límites multidimensionales que combinan usuario y objetivo para imponer límites de velocidad específicos. También cubrimos consideraciones de limitación de velocidad para cargas de trabajo de agente, donde el consumo de recursos posteriores varía dependiendo de cómo el agente se autentica con la puerta de enlace.
Los límites de tarifas son una capa de una estrategia integral de gestión del tráfico. Combinados con AgentCore Identity para autenticación, Policy en AgentCore para control de acceso basado en roles y registro de aplicaciones para observabilidad, le brindan las herramientas para operar una puerta de enlace de IA de nivel de producción con confianza, facilitando el uso justo, protegiendo los servicios backend y manteniendo la disponibilidad a medida que aumentan sus cargas de trabajo.
¿Qué sigue?
Para comenzar con los límites de velocidad en la puerta de enlace AgentCore, explore los siguientes recursos:
Agregue límites de velocidad a la puerta de enlace AgentCore, referencia API completa para crear, actualizar y eliminar límites de velocidad con claves de dimensión, entradas y métricas admitidas. Ejemplos de API de límite de velocidad, ejemplos de CLI adicionales que cubren operaciones por lotes, listado, filtrado y eliminación de flujos de trabajo. Cuotas y límites de la puerta de enlace de AgentCore, cuotas administradas por el servicio, límites predeterminados y cómo solicitar aumentos. AgentCore Identity, configure la autenticación JWT entrante y la venta de tokens salientes para los destinos de puerta de enlace de AgentCore. Política en AgentCore, configura un control de acceso basado en roles para complementar los límites de velocidad con la aplicación de autorizaciones. El registro de aplicaciones para la puerta de enlace AgentCore habilita el registro basado en OpenTelemetry para monitorear las evaluaciones de límites de velocidad, las denegaciones y el consumo por depósito en tiempo real.
Seguimos invirtiendo en la puerta de enlace AgentCore según los comentarios de los clientes. Esperamos saber cómo utiliza la puerta de enlace AgentCore como sistema central de control para su tráfico de IA.
Sobre los autores
Anagh Agrawal
Anagh es ingeniero de software en Amazon Bedrock AgentCore, donde crea una infraestructura de puerta de enlace central que impulsa experiencias de IA agente. Anteriormente trabajó en Amazon Bedrock Agents y aporta la experiencia en sistemas distribuidos y servicios criptográficos de su tiempo en AWS Key Management Service. Tiene una maestría en Ciencias de la Computación de la Universidad Stony Brook. Fuera del trabajo, Anagh es un músico que toca el piano y el ukelele, y un ávido excursionista al que le encanta todo lo que esté al aire libre.
Eashan Kaushik
Eashan es arquitecto de soluciones especializado en IA/ML en Amazon Web Services. Su motivación es la creación de soluciones de inteligencia artificial generativa de vanguardia y, al mismo tiempo, prioriza un enfoque de su trabajo centrado en el cliente. Antes de ocupar este cargo, obtuvo una maestría en Ciencias de la Computación de la Escuela de Ingeniería Tandon de la Universidad de Nueva York. Fuera del trabajo, le gustan los deportes, levantar pesas y correr maratones.
Tanuja Joshi
Tanuja es ingeniera de software en Amazon Web Services y forma parte del equipo de AgentCore Gateway. Desde el comienzo de su mandato, ha estado trabajando en el espacio de IA agente, contribuyendo a servicios como Bedrock Agents. Cuando no está en el trabajo, le gusta leer y escalar rocas.
Sean Eichenberger
Sean es director principal de productos en AWS Agentic AI. Lidera iniciativas de gobernanza, seguridad y conectividad de agentes para Amazon Bedrock AgentCore.
Yuan Tian
Yuan es ingeniero de desarrollo de software en el equipo de Agentcore Gateway. Yuan, que anteriormente fue pasante en el equipo de AutoGluon, regresó a AWS Agentic AI como nuevo graduado y ahora trabaja para ayudar a los clientes a crear e implementar aplicaciones de Agentic AI. Cuando no codifica, a Yuan le gusta jugar videojuegos y leer novelas.
Banda Shravani
Shravani es ingeniera de frontend en Amazon Web Services en el equipo de AgentCore Gateway, donde crea experiencias de consola para infraestructura de IA agente. Comenzó su trayectoria en AWS en el equipo de Bedrock Agents y ha sido parte del equipo de Agentic AI Gateway desde sus inicios. Tiene una maestría en Sistemas de Información de la Universidad Estatal de Dakota. Fuera del trabajo, a Shravani le gusta hacer senderismo y acampar.