Throttling, caching og brugsplaner

Uden begrænsning af kald kunne en enkelt fejlbehæftet klient eller en trafikstigning overbelaste dine backend-tjenester – Lambda-samtidighed, RDS-forbindelser eller downstream-API'er. Begrænsning af kald i API Gateway begrænser antallet af anmodninger pr. sekund og tillader korte bursts over den stabile hastighed. Begrænsede anmodninger modtager straks et 429 Too Many Requests-svar, uden at anmodningen når din backend, så downstream-ressourcer beskyttes mod overbelastning.

Begrænsning af kald fungerer på flere niveauer. Grænsen på kontoniveau er 10.000 anmodninger pr. sekund (RPS) med et burst på 5.000 anmodninger (en blød grænse, der kan forhøjes). På stage-niveau kan du angive en standardhastighed for begrænsning af kald (RPS) og en burst-grænse, der gælder for alle metoder i staget. På metodeniveau kan du tilsidesætte stage-standarderne for bestemte endpoints – du kan f.eks. give et læsetungt GET-endpoint en højere hastighedsgrænse end et skrivetungt POST-endpoint.

API Gateway bruger en token bucket-algoritme til at begrænse kald. Tokens samles i en bucket op til burst-grænsen (den maksimale kapacitet her og nu). Hver anmodning bruger ét token. Tokens fyldes op med hastighedsgrænsen (den stabile RPS). Hvis bucket'en er tom, begrænses anmodningerne. Eksempel: burst=5000, rate=1000 RPS. I starten kan du håndtere 5000 samtidige anmodninger; bucket'en fyldes op med 1000 tokens pr. sekund. Det gør det muligt at absorbere korte trafikstigninger, samtidig med at de langsigtede hastighedsgrænser overholdes.

Caching af svar (tilgængelig for REST API-stages) gemmer backend-svar i en cache, der administreres af API Gateway, så identiske anmodninger besvares fra cachen uden at ramme backenden. Det reducerer belastningen på backenden, sænker latenstiden og kan reducere omkostningerne til Lambda-kald betydeligt for læsetunge API'er. Cachen indekseres efter anmodningen (metode, sti, querystringer og headere afhængigt af konfigurationen). Cache-TTL'en kan konfigureres fra 0 til 3600 sekunder (standard: 300 sekunder).

Som standard er cache-nøglen hele URL'en til anmodningen. Du kan tilpasse, hvilke elementer der bidrager til cache-nøglen: medtag bestemte parametre i forespørgselsstrengen (f.eks. pageSize, filter), men udelad irrelevante parametre (f.eks. tidsstempel). Du kan også medtage bestemte headere i cache-nøglen. Udelad følsomme headere fra cache-nøglen for at forhindre, at private data forurener delte cacheposter. Brug justering af cache-nøglen til at maksimere cache-træffere, samtidig med at forskellige logiske anmodninger får forskellige cachelagrede svar.

Klienter kan ugyldiggøre cachen for en bestemt anmodning ved at medtage headeren Cache-Control: max-age=0. Du kan også rydde hele stage-cachen fra konsollen eller API'et. Konfigurer, om klienter må ugyldiggøre cachen – begræns dette i produktion for at forhindre, at klienter med vilje omgår caching. Hvis du vil give udvalgte klienter tilladelse til at rydde cachen, skal du tilknytte en ressourcepolitik eller bruge en Lambda-authorizer, der kontrollerer, om den kaldende har tilladelse til at rydde cachen.

En brugsplan definerer begrænsninger for hastighed og kvoter for en gruppe API-klienter. Knyt en API-stage til en brugsplan, og knyt derefter API-nøgler til planen. Hver API-nøgle håndhæver planens begrænsninger uafhængigt. Med brugsplaner kan du tilbyde adgang i niveauer: en Gratis-plan med 100 RPM/10.000 anmodninger pr. dag og en Pro-plan med 1.000 RPM/100.000 anmodninger pr. dag. Dette er modellen for API'er, der tjener penge, og partnerintegrationer, hvor forskellige klienter har brug for forskellige hastighedsgrænser.

API-nøgler er uigennemsigtige teksttokens, som klienter medtager i anmodningsheaderen x-api-key. API Gateway validerer nøglen og knytter anmodningen til den tilsvarende brugsplan. API-nøgler er IKKE en sikkerhedsmekanisme – de identificerer kun klienter med henblik på hastighedsbegrænsning og kvoter. Af sikkerhedshensyn skal du altid kombinere API-nøgler med korrekt godkendelse (IAM, Lambda-authorizer eller Cognito). API-nøgler, der ikke er knyttet til en brugsplan, får ikke anvendt hastighedsbegrænsninger.

Ud over hastighedsbegrænsninger pr. sekund understøtter brugsplaner kvotegrænser: et maksimalt antal anmodninger over en tidsperiode (DAY, WEEK eller MONTH). Når en klient har opbrugt sin kvote, returnerer efterfølgende anmodninger 429, indtil kvoten nulstilles. Kvotegrænser er nyttige til håndhævelse af gratisniveauer, forebyggelse af misbrug af API'er og tilpasning af API-forbrug til fakturering. Kvtotællere er eventual consistent, så en klient kan overskride sin kvote en smule, før den bliver blokeret.

Overvåg API Gateway's tilstand med disse CloudWatch-målinger:

• Count: samlet antal API-kald
• 4XXError: klientfejl, herunder 429-fejl på grund af hastighedsbegrænsning
• 5XXError: backend-fejl
• Latency: samlet tid for anmodningen
• IntegrationLatency: ventetid på backend
• CacheHitCount / CacheMissCount: cacheeffektivitet

Indstil alarmer på stigninger i 4XXError for at registrere problemer med hastighedsbegrænsning, før de påvirker brugerne, og på CacheMissCount for at identificere problemer med cachekonfigurationen.

Brug caching til API'er med mange læseoperationer, hvor svarene sjældent ændres – opslag i produktkataloger, referencedata og statiske konfigurationer. Caching er uhensigtsmæssigt for brugerspecifikke eller meget dynamiske data. Brug altid hastighedsbegrænsning – også for interne API'er – for at beskytte backend-tjenester mod overbelastning. Kombiner begge dele: cachelagr almindelige data for at reducere belastningen på backend, og brug stramme hastighedsbegrænsninger for at forhindre, at en enkelt klient dominerer API'et. Til SAA-C03-eksamen reducerer caching omkostninger og svartid, mens hastighedsbegrænsning sikrer tilgængelighed.

I denne lektion har du lært, at hastighedsbegrænsning på konto-, stage- og metodeniveau beskytter backends ved hjælp af en token bucket-algoritme med konfigurerbare hastigheder og burst-grænser, at svarcaching gemmer backend-svar i konfigurerbare TTL-perioder for at reducere backend-belastning og svartid for endpoints med mange læseoperationer, og at brugsplaner med API-nøgler håndhæver hastigheder og kvoter pr. klient, så der kan tilbydes adgang i niveauer til partner- og offentlige API'er. Næste emne er ECS-klynger, opgavedefinitioner og tjenester til containeriserede arbejdsbelastninger.