Limitação, armazenamento em cache e planos de uso

Sem limitação de taxa, um único cliente com comportamento inadequado ou um pico de tráfego poderia sobrecarregar seus serviços de back-end — a simultaneidade do Lambda, as conexões do RDS ou as APIs posteriores. A limitação de taxa no API Gateway restringe o número de solicitações por segundo e permite pequenos picos acima da taxa estável. As solicitações limitadas recebem imediatamente uma resposta 429 Too Many Requests, sem chegar ao back-end, protegendo os recursos posteriores contra sobrecarga.

A limitação de taxa opera em vários níveis. O limite no nível da conta é de 10.000 solicitações por segundo (RPS), com um pico de 5.000 solicitações (limite flexível, que pode ser aumentado). No nível do estágio, você pode definir uma taxa de limitação padrão (RPS) e um limite de pico aplicáveis a todos os métodos do estágio. No nível do método, você pode substituir os padrões do estágio para endpoints específicos — por exemplo, atribuindo a um endpoint GET com muitas leituras uma taxa maior do que a de um endpoint POST com muitas gravações.

A limitação de taxa do API Gateway usa um algoritmo de balde de tokens. Os tokens se acumulam em um balde até o limite de pico (capacidade instantânea máxima). Cada solicitação consome um token. Os tokens são repostos na taxa limite (RPS em estado estável). Se o balde estiver vazio, as solicitações sofrerão limitação. Exemplo: pico=5000, taxa=1000 RPS. No início, você pode processar 5000 solicitações simultâneas; o balde é reabastecido com 1000 tokens por segundo. Isso permite absorver breves picos de tráfego e, ao mesmo tempo, aplicar limites de taxa de longo prazo.

O armazenamento em cache de respostas (disponível nos estágios da API REST) armazena as respostas do back-end em um cache gerenciado pelo API Gateway, para que solicitações idênticas sejam atendidas a partir do cache sem acessar o back-end. Isso reduz a carga do back-end, diminui a latência e pode reduzir significativamente os custos de invocação do Lambda em APIs com muitas leituras. O cache usa a solicitação como chave (método, caminho, strings de consulta e cabeçalhos, conforme a configuração). O TTL do cache pode ser configurado de 0 a 3600 segundos (o padrão é 300 segundos).

Por padrão, a chave de cache é o URL completo da solicitação. Pode personalizar quais elementos contribuem para a chave de cache: incluir parâmetros de cadeia de consulta específicos (por exemplo, pageSize, filter), mas excluir os irrelevantes (por exemplo, o carimbo de data e hora). Também pode incluir cabeçalhos específicos na chave de cache. Exclua cabeçalhos confidenciais da chave de cache para evitar que dados privados contaminem entradas de cache compartilhadas. Ajuste a chave de cache para maximizar as taxas de acerto do cache, garantindo que solicitações lógicas diferentes recebam respostas armazenadas em cache diferentes.

Os clientes podem invalidar o cache de uma solicitação específica incluindo o cabeçalho Cache-Control: max-age=0. Também pode limpar todo o cache do estágio pelo console ou pela API. Configure se os clientes podem invalidar o cache — restrinja essa possibilidade em produção para evitar que os clientes ignorem o armazenamento em cache intencionalmente. Para conceder permissões de limpeza seletivamente, associe uma política de recursos ou use um autorizador do Lambda que verifique se o chamador tem permissão para limpar o cache.

Um plano de uso define limites de controle de taxa e limites de cota para um grupo de clientes da API. Associe um estágio da API a um plano de uso e, em seguida, associe chaves de API ao plano. Cada chave de API aplica os limites do plano de forma independente. Os planos de uso permitem oferecer acesso em níveis: um plano Gratuito com 100 RPM/10.000 solicitações por dia e um plano Pro com 1.000 RPM/100.000 solicitações por dia. Esse é o modelo usado para APIs monetizadas e integrações com parceiros nas quais clientes diferentes precisam de limites de taxa diferentes.

As chaves de API são tokens de cadeia de caracteres opacos que os clientes incluem no cabeçalho de solicitação x-api-key. O API Gateway valida a chave e associa a solicitação ao plano de uso correspondente. As chaves de API NOT são um mecanismo de segurança — elas servem apenas para identificar clientes para fins de controle de taxa e cota. Para garantir a segurança, combine sempre as chaves de API com uma autorização adequada (IAM, autorizador do Lambda ou Cognito). As chaves de API que não estão associadas a um plano de uso simplesmente não têm limites de controle de taxa aplicados.

Além das taxas de controle por segundo, os planos de uso aceitam limites de cota: um número máximo de solicitações durante um período (DAY, WEEK ou MONTH). Quando um cliente esgota a cota, as solicitações subsequentes retornam 429 até que a cota seja redefinida. Os limites de cota são úteis para aplicar níveis gratuitos, evitar abusos da API e alinhar o consumo da API ao faturamento. Os contadores de cota acabam sendo consistentes, portanto, um cliente pode exceder ligeiramente a cota antes de ser bloqueado.

Monitore a integridade do API Gateway com estas métricas do CloudWatch:

• Count: total de chamadas à API
• 4XXError: erros do cliente, incluindo controles de taxa 429
• 5XXError: erros do back-end
• Latency: tempo total da solicitação, do início ao fim
• IntegrationLatency: tempo de espera pelo back-end
• CacheHitCount / CacheMissCount: eficácia do cache

Configure alarmes para picos de 4XXError a fim de detectar problemas de controle de taxa antes que afetem os usuários, e para CacheMissCount a fim de identificar problemas na configuração do cache.

Use o armazenamento em cache para APIs com muitas operações de leitura, nas quais as respostas mudam com pouca frequência — consultas de catálogo de produtos, dados de referência e configurações estáticas. O armazenamento em cache é contraproducente para dados específicos do usuário ou altamente dinâmicos. Use o controle de taxa sempre — mesmo para APIs internas — para proteger os serviços de back-end contra sobrecarga. Combine os dois: armazene dados comuns em cache para reduzir a carga do back-end e aplique um controle de taxa rigoroso para evitar que um único cliente domine a API. Para a prova SAA-C03, o armazenamento em cache reduz custos e latência; o controle de taxa garante a disponibilidade.

Nesta lição, você aprendeu que o controle de taxa nos níveis de conta, estágio e método protege os back-ends usando um algoritmo de intervalo de tokens com limites configuráveis de taxa e rajada; o armazenamento de respostas em cache armazena respostas do back-end por TTLs configuráveis para reduzir a carga e a latência do back-end em endpoints com muitas leituras; e os planos de uso com chaves de API aplicam taxas de controle e cotas por cliente, permitindo um controle de acesso em níveis para APIs de parceiros e públicas. A seguir, vamos explorar clusters do ECS, definições de tarefas e serviços para cargas de trabalho conteinerizadas.