View a markdown version of this page

Cumplimiento del límite de tarifas - Base amazónica AgentCore

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cumplimiento del límite de tarifas

En este tema se describe cómo la puerta de enlace evalúa y aplica los límites de velocidad en tiempo de ejecución, incluida la interacción con otras funciones de la puerta de enlace, los formatos de respuesta limitados y la capacidad de observación.

Interacción con las reglas de la pasarela

La puerta de enlace evalúa los límites de velocidad antes de establecer las reglas de la puerta de enlace. Si un límite de velocidad limita una solicitud, la solicitud nunca llega a la fase de evaluación de la regla.

Semántica de apilamiento

Cuando se aplican varios límites de velocidad a una solicitud, la puerta de enlace utiliza la lógica AND: deben superarse todos los límites de velocidad para que la solicitud continúe. Si un único límite de velocidad rechaza la solicitud, la pasarela la limita.

Coincidencia y especificidad de las entradas

Cuando un límite de velocidad tiene varias entradas, la pasarela selecciona la entrada coincidente más específica para los valores de dimensión resueltos:

  • La coincidencia de valores exactos tiene prioridad sobre una * entrada.

  • El * valor significa «aplicar esta tasa a todos los valores de esta dimensión»; actúa como entrada predeterminada.

  • Para los límites de velocidad multidimensionales, la pasarela utiliza una alternativa progresiva: primero intenta conseguir una coincidencia exacta completa y, a continuación, sustituye las dimensiones finales por * una cada vez hasta encontrar una coincidencia.

En el siguiente ejemplo, se muestra cómo se comparan las entradas para determinar un límite de velocidad con el dimensionKeys: ["targetName", "toolName"] momento en que los valores resueltos son: ["my-target", "readData"]

Dimensiones de entrada ¿Partidos? ¿Por qué

{"targetName": "my-target", "toolName": "readData"}

Sí (se comprobó primero)

Coincidencia exacta en ambas dimensiones. La más específica.

{"targetName": "my-target", "toolName": "*"}

Sí (marcada en segundo lugar)

Coincidencia exacta en la primera dimensión, * en la segunda.

{"targetName": "", "toolName": ""}

Sí (se comprobó por última vez)

Entrada predeterminada. La menos específica.

La primera entrada coincidente gana. Si ninguna entrada coincide (y no existe ningún * valor predeterminado), se omite el límite de velocidad para esa solicitud.

Orden de evaluación

La pasarela evalúa los límites de tarifas en el siguiente orden:

  1. La pasarela evalúa primero los límites de velocidad con más claves de dimensión (los límites más específicos tienen prioridad).

  2. Dentro del mismo número de dimensiones, la puerta de enlace evalúa primero los límites de velocidad y, en primer lugar, las tasas más estrictas (más bajas).

  3. La evaluación produce un cortocircuito en la primera denegación: la pasarela no evalúa los límites de velocidad restantes.

Interacción con los límites administrados por el servicio

La pasarela impone tanto los límites de tarifas definidos por el cliente como los límites administrados por el servicio. La tasa efectiva para cualquier solicitud es la mínima de las dos siguientes:

  • La pasarela evalúa primero los límites de tarifas definidos por el cliente.

  • Si la solicitud supera los límites de clientes, se evalúan los límites administrados por el servicio.

  • Una denegación por parte de cualquiera de las fuentes provoca una limitación.

Respuestas limitadas

Cuando se limita una solicitud, la puerta de enlace devuelve una respuesta de error específica del protocolo que contiene el valor en el cuerpo de la respuesta. retryAfter

Protocolo HTTP:

{ "error": "Rate limit exceeded", "success": false, "limitKey": "rl-abc123/targetName=my-target", "metric": "requests", "retryAfter": 1 }

Protocolo MCP (JSON-RPC):

{ "jsonrpc": "2.0", "id": "request-1", "error": { "code": -32003, "message": "Rate limit exceeded", "data": { "limitKey": "rl-abc123/targetName=my-target", "metric": "requests", "retryAfter": 1 } } }

OpenAI-compatible protocolo:

{ "error": { "message": "Rate limit exceeded", "type": "rate_limit_error", "code": "429", "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet", "metric": "tokens", "retryAfter": 60 } }

Anthropic-compatible protocolo:

{ "type": "error", "error": { "type": "rate_limit_error", "message": "Rate limit exceeded", "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet", "metric": "tokens", "retryAfter": 60 } }

El retryAfter campo indica cuántos segundos debe esperar la persona que llama antes de volver a intentarlo. Usa este valor directamente en la lógica de reintentos del lado del cliente.

Tiempo de propagación

Los cambios en el límite de velocidad (crear, actualizar, eliminar) se propagan al plano de datos en 30 segundos. Durante la propagación:

  • Los nuevos límites de velocidad no se aplican hasta que se complete la propagación.

  • Los límites de velocidad actualizados siguen aplicando la configuración anterior hasta que se propague la actualización.

  • Los límites de velocidad eliminados se siguen aplicando hasta que se propague la eliminación.

Precisión de la aplicación y, finalmente, coherencia

La aplicación de los límites de velocidad es, en última instancia, coherente en lugar de exacta. La precisión de la aplicación es aproximada en los momentos posteriores a que un límite comience a recibir tráfico, y mejora a medida que el tráfico continúa. Por lo tanto, la precisión que observe depende de su patrón de tráfico.

Se esperan los siguientes comportamientos:

  • Los límites fríos admiten en exceso al principio. Un límite en frío es aquel que se ha creado recientemente o que no ha tenido tráfico reciente. Durante un período inicial breve, es posible que la puerta de enlace admita en exceso (permita más solicitudes que la velocidad configurada) antes de que la aplicación converja. Una vez que se alcanza un límite de tráfico continuo, la precisión mejora y la velocidad de aceleración observada se sitúa cerca de la velocidad configurada.

  • El tráfico sostenido se aplica con precisión, pero es posible que las ráfagas cortas no. Una breve ráfaga contra un límite de frío puede pasar sin que se estrangule. Se aplica la misma velocidad de envío que el tráfico continuo, ya que la precisión mejora a medida que se aumenta el límite. Para cumplir o demostrar el cumplimiento, envía el tráfico sostenido al límite durante varios minutos en lugar de una sola ráfaga breve. Por ejemplo, para un límite de 4 solicitudes por segundo, es posible que la puerta de enlace no limite la quinta solicitud en el primer segundo. Si envías 5 solicitudes por segundo de forma continua, verás que la solicitud adicional se limita de forma constante una vez que se aumente el límite.

  • Las tasas muy bajas son menos precisas. Las tasas por debajo de aproximadamente 1 solicitud por segundo (por ejemplo, un límite pequeño de solicitudes por minuto) son más difíciles de aplicar con precisión y mostrarán una mayor variabilidad. Prefiera tasas más altas cuando la aplicación de la ley sea precisa, y trate los límites muy bajos como aproximados.

  • Los límites de los tokens convergen más lentamente. Token-per-minute los límites actualizan (concilian) el uso total registrado solo después de que el modelo responda. Una solicitud que esté en trámite durante varios segundos o minutos retiene únicamente su coste estimado en relación con el presupuesto hasta que se complete. Esto amplía el período durante el cual la pasarela puede admitir solicitudes en exceso, en relación con los límites de solicitudes. Consulta las preguntas frecuentes sobre el límite de velocidad de los tokens para obtener más información.

Diseña tus límites en función del uso justo y la protección del backend. Esto significa suavizar las ráfagas y proteger a los objetivos de los vecinos ruidosos durante un período prolongado, en lugar de bloquear un número de solicitud exacto en el instante en que se cruza un umbral. Los límites de velocidad no son una forma precisa y exacta de procesar las solicitudes. Los límites de velocidad tampoco son un límite de seguridad, como se explica en la siguiente sección.

Fail-open comportamiento

La pasarela utiliza una semántica de apertura por error para la evaluación del límite de velocidad. La siguiente tabla describe el comportamiento cuando el sistema de límite de velocidad detecta errores:

Escenario Decisión Justificación

Se agotó el tiempo de espera del servicio con límite

Permitir

La disponibilidad tiene prioridad sobre la aplicación.

La clave de dimensión no se puede resolver a partir de la solicitud

Omitir (permitir)

El límite de velocidad no se aplica a este tipo de solicitud.

Error de actualización de la caché con límite de velocidad

Vuelva a intentarlo con datos obsoletos

La última configuración conocida se utiliza hasta que se recupere la memoria caché.

importante

Debido al comportamiento de apertura por error, no se base únicamente en los límites de velocidad como límite de seguridad. Utilice los límites de velocidad para la gestión del tráfico y la calidad del servicio, y utilice las reglas de autenticación, autorización y WAF para hacer cumplir la seguridad.

Rastreo con intervalos OpenTelemetry

La pasarela emite atributos de intervalo OpenTelemetry (OTEL) en el intervalo del servidor para cada solicitud en la que se evalúan los límites de tarifa de los clientes. Utilice estos atributos para depurar y supervisar.

Atributo Description (Descripción) Ejemplo

aws.agentcore.gateway.throttle.customer.decision

La decisión de ejecución de esta solicitud.

allowed o throttled

aws.agentcore.gateway.throttle.customer.limit_key

La rateLimitId del límite tarifario que rechazó la solicitud. Solo está presente cuando hay una decisiónthrottled.

per-target-rps

aws.agentcore.gateway.throttle.customer.metric

El tipo de métrica que se agotó. Solo está presente cuando hay una decisiónthrottled.

requests

aws.agentcore.gateway.throttle.customer.matched_entry

Comma-separated valores de dimensión resueltos de la entrada que activó el acelerador. Solo está presente cuando hay throttled una decisión.

my-target,alice

aws.agentcore.gateway.throttle.customer.evaluated

Lista ordenada de todos los grupos con límite de velocidad comprobados para esta solicitud. Cada entrada muestra el identificador del límite de velocidad, la métrica y los valores de dimensión resueltos. Presente tanto para tomar decisiones allowed como para throttled tomar decisiones.

["per-target-rps:requests:my-target", "per-caller-rpm:requests:alice"]

El evaluated atributo es útil para comprender qué límites de frecuencia se aplican a una solicitud, incluso cuando estaba permitida. Cada entrada de la lista sigue el formato{rateLimitId}:{metric}:{resolvedDimVal1,dimVal2,…​}.