Limitación, almacenamiento en caché y planes de uso

Sin limitación de solicitudes, un solo cliente con un comportamiento incorrecto o un pico de tráfico podría saturar sus servicios de backend, como la concurrencia de Lambda, las conexiones de RDS o las API posteriores. La limitación de solicitudes en API Gateway limita el número de solicitudes por segundo y permite ráfagas breves por encima de la tasa estable. Las solicitudes limitadas reciben inmediatamente una respuesta 429 Too Many Requests, sin llegar al backend, lo que protege los recursos posteriores frente a la sobrecarga.

La limitación de solicitudes funciona en varios niveles. El límite a nivel de cuenta es de 10 000 solicitudes por segundo (RPS), con una ráfaga de 5000 solicitudes (límite flexible que se puede aumentar). En el nivel de etapa, puede establecer una tasa de limitación predeterminada (RPS) y un límite de ráfaga que se apliquen a todos los métodos de la etapa. En el nivel de método, puede reemplazar los valores predeterminados de la etapa para endpoints específicos; por ejemplo, puede asignar un límite de tasa mayor a un endpoint GET con muchas lecturas que a un endpoint POST con muchas escrituras.

La limitación de solicitudes de API Gateway utiliza un algoritmo de depósito de tokens. Los tokens se acumulan en un depósito hasta alcanzar el límite de ráfaga (capacidad instantánea máxima). Cada solicitud consume un token. Los tokens se reponen a la tasa límite (RPS estable). Si el depósito está vacío, las solicitudes se limitan. Ejemplo: ráfaga=5000, tasa=1000 RPS. Al principio puede gestionar 5000 solicitudes simultáneas; el depósito se repone a razón de 1000 tokens por segundo. Esto permite absorber picos breves de tráfico y aplicar al mismo tiempo límites de tasa a largo plazo.

El almacenamiento en caché de respuestas (disponible en las etapas de REST API) guarda las respuestas del backend en una caché gestionada por API Gateway, de modo que las solicitudes idénticas se sirven desde la caché sin acceder al backend. Esto reduce la carga del backend, disminuye la latencia y puede reducir considerablemente los costes de invocación de Lambda en API con muchas lecturas. La caché utiliza como clave la solicitud (método, ruta, cadenas de consulta y encabezados, según la configuración). El TTL de la caché se puede configurar entre 0 y 3600 segundos (300 segundos de forma predeterminada).

De forma predeterminada, la clave de caché es la URL completa de la solicitud. Puede personalizar qué elementos contribuyen a la clave de caché: incluir parámetros de cadena de consulta específicos (por ejemplo, pageSize, filter) y excluir los irrelevantes (por ejemplo, la marca de tiempo). También puede incluir encabezados específicos en la clave de caché. Excluya los encabezados confidenciales de la clave de caché para evitar que los datos privados contaminen las entradas de caché compartida. Ajuste la clave de caché para maximizar la tasa de aciertos y garantizar que las solicitudes lógicamente distintas reciban respuestas almacenadas en caché diferentes.

Los clientes pueden invalidar la caché de una solicitud específica incluyendo el encabezado Cache-Control: max-age=0. También puede vaciar toda la caché de la etapa desde la consola o la API. Configure si los clientes pueden invalidar la caché; restrinja esta capacidad en producción para evitar que los clientes omitan intencionadamente el almacenamiento en caché. Para conceder permisos de vaciado de forma selectiva, asocie una política de recursos o use un autorizador de Lambda que compruebe si el llamador tiene permiso para vaciar la caché.

Un Usage Plan define límites de control de solicitudes y límites de cuota para un grupo de clientes de API. Asocie una etapa de API a un plan de uso y, después, asocie API keys al plan. Cada clave de API aplica los límites del plan de forma independiente. Los planes de uso permiten ofrecer acceso por niveles: un plan Free con 100 RPM/10.000 solicitudes al día y un plan Pro con 1.000 RPM/100.000 solicitudes al día. Este es el modelo para las API monetizadas y las integraciones con socios en las que distintos clientes necesitan diferentes límites de tasa.

Las API keys son tokens de cadena opacos que los clientes incluyen en el encabezado de solicitud x-api-key. API Gateway valida la clave y asocia la solicitud con el plan de uso correspondiente. Las claves de API NO son un mecanismo de seguridad: solo identifican a los clientes con fines de control de solicitudes y cuotas. Para garantizar la seguridad, combínelas siempre con una autorización adecuada (IAM, un autorizador de Lambda o Cognito). Las claves de API que no están asociadas a un plan de uso simplemente no tienen límites de control de solicitudes aplicados.

Además de las tasas de control de solicitudes por segundo, los planes de uso admiten límites de cuota: un número máximo de solicitudes durante un periodo (DAY, WEEK o MONTH). Cuando un cliente agota su cuota, las solicitudes posteriores devuelven 429 hasta que la cuota se restablece. Los límites de cuota son útiles para aplicar niveles gratuitos, evitar el uso abusivo de la API y alinear el consumo de la API con la facturación. Los contadores de cuota son eventualmente coherentes, por lo que un cliente puede superar ligeramente su cuota antes de que se bloquee.

Supervise el estado de API Gateway con estas métricas de CloudWatch:

• Count: total de llamadas a la API
• 4XXError: errores del cliente, incluidos los controles de solicitudes 429
• 5XXError: errores del backend
• Latency: tiempo de la solicitud de extremo a extremo
• IntegrationLatency: tiempo de espera del backend
• CacheHitCount / CacheMissCount: eficacia de la caché

Configure alarmas para los picos de 4XXError a fin de detectar problemas de control de solicitudes antes de que afecten a los usuarios, y para CacheMissCount a fin de identificar problemas de configuración de la caché.

Use el almacenamiento en caché para las API con predominio de lecturas cuyas respuestas cambian con poca frecuencia: consultas de catálogos de productos, datos de referencia y configuraciones estáticas. El almacenamiento en caché resulta contraproducente para datos específicos de usuarios o muy dinámicos. Use el control de solicitudes siempre, incluso para las API internas, para proteger los servicios de backend frente a la sobrecarga. Combine ambos mecanismos: almacene en caché los datos habituales para reducir la carga del backend y aplique límites estrictos para evitar que un solo cliente monopolice la API. Para el examen SAA-C03, el almacenamiento en caché reduce los costes y la latencia; el control de solicitudes garantiza la disponibilidad.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que el control de solicitudes en los niveles de cuenta, etapa y método protege los backends mediante un algoritmo de cubeta de tokens con límites configurables de tasa y ráfaga; la caché de respuestas almacena las respuestas del backend durante TTL configurables para reducir la carga del backend y la latencia en los puntos de conexión con predominio de lecturas; y los planes de uso con claves de API aplican tasas de control de solicitudes y cuotas por cliente, lo que permite un control de acceso por niveles para las API públicas y de socios. A continuación exploraremos los clústeres de ECS, las definiciones de tareas y los servicios para cargas de trabajo en contenedores.