Begrensning, caching og bruksplaner

API Gateway bruker en token bucket-algoritme for å begrense forespørselsfrekvensen. Token samles opp i en bøtte, opptil toppgrensen (maksimal kapasitet for samtidige topper). Hver forespørsel bruker ett token. Token fylles på med frekvensgrensen (stabil RPS). Hvis bøtten er tom, begrenses forespørslene. Eksempel: burst=5000, rate=1000 RPS. I starten kan De håndtere 5000 samtidige forespørsler, og bøtten fylles på med 1000 token per sekund. Dette gjør det mulig å absorbere korte trafikktopper samtidig som langsiktige frekvensgrenser håndheves.

Svarbufring (tilgjengelig for REST API-stager) lagrer backend-svar i en hurtigbuffer som administreres av API Gateway, slik at identiske forespørsler kan besvares fra hurtigbufferen uten å kontakte backend. Dette reduserer belastningen på backend, senker ventetiden og kan redusere kostnadene for Lambda-kall betydelig for lesetunge API-er. Hurtigbufferen bruker forespørselen som nøkkel (metode, bane, spørringsstrenger og headere, avhengig av konfigurasjonen). TTL-en for hurtigbufferen kan konfigureres fra 0 til 3600 sekunder (standard er 300 sekunder).

Som standard er cache-nøkkelen hele URL-en for forespørselen. De kan tilpasse hvilke elementer som inngår i cache-nøkkelen: inkluder bestemte parametere i query-strengen (for eksempel pageSize og filter), men utelat irrelevante parametere (for eksempel tidsstempel). De kan også inkludere bestemte headere i cache-nøkkelen. Utelat sensitive headere fra cache-nøkkelen for å hindre at private data påvirker delte cache-oppføringer. Bruk justering av cache-nøkkelen for å maksimere treffraten i cachen, samtidig som ulike logiske forespørsler får ulike bufrede svar.

Klienter kan ugyldiggjøre cachen for en bestemt forespørsel ved å inkludere headeren Cache-Control: max-age=0. De kan også tømme hele stage-cachen fra konsollen eller API-et. Konfigurer om klienter skal ha lov til å ugyldiggjøre cachen – begrens dette i produksjon for å hindre at klienter bevisst omgår caching. For å gi utvalgte klienter tillatelse til å tømme cachen kan De knytte til en ressurspolicy eller bruke en Lambda-authorizer som kontrollerer om den som foretar kallet, har tillatelse til å tømme cachen.

En Usage Plan definerer begrensninger for throttling og kvoter for en gruppe API-klienter. Knytt en API-stage til en bruksplan, og knytt deretter API keys til planen. Hver API-nøkkel håndhever planens begrensninger uavhengig av de andre. Med bruksplaner kan De tilby tilgang på ulike nivåer: en Free-plan med 100 RPM/10 000 forespørsler per dag og en Pro-plan med 1 000 RPM/100 000 forespørsler per dag. Dette er modellen for API-er som skal tjene penger, og for partnerintegrasjoner der ulike klienter trenger ulike hastighetsgrenser.

API keys er ugjennomsiktige tekstbaserte tokens som klienter inkluderer i forespørselsheaderen x-api-key. API Gateway validerer nøkkelen og knytter forespørselen til den tilsvarende bruksplanen. API-nøkler er IKKE en sikkerhetsmekanisme – de identifiserer bare klienter for throttling og kvoteberegning. Av sikkerhetshensyn må De alltid kombinere API-nøkler med riktig autorisasjon (IAM, Lambda-authorizer eller Cognito). API-nøkler som ikke er knyttet til en bruksplan, får ganske enkelt ikke anvendt throttle-begrensninger.

I tillegg til throttle-rater per sekund støtter bruksplaner kvotebegrensninger: et maksimalt antall forespørsler i løpet av en tidsperiode (DAY, WEEK eller MONTH). Når en klient har brukt opp kvoten sin, returnerer påfølgende forespørsler 429 frem til kvoten tilbakestilles. Kvotebegrensninger er nyttige for håndheving av gratisnivåer, forebygging av misbruk av API-et og tilpasning av API-forbruket til faktureringen. Kv多tellerne er eventual consistent, så en klient kan overskride kvoten litt før den blir blokkert.

Overvåk helsen til API Gateway med disse CloudWatch-målingene:

• Count: totalt antall API-kall
• 4XXError: klientfeil, inkludert 429-throttling
• 5XXError: backend-feil
• Latency: forespørselstid fra ende til ende
• IntegrationLatency: tid brukt på å vente på backend
• CacheHitCount / CacheMissCount: hvor effektiv cachen er

Sett opp alarmer for topper i 4XXError for å oppdage throttle-problemer før de påvirker brukerne, og for CacheMissCount for å identifisere problemer med cache-konfigurasjonen.

Bruk caching for API-er med mange leseoperasjoner, der svarene endres sjelden – for eksempel oppslag i produktkataloger, referansedata og statiske konfigurasjoner. Caching er uheldig for brukerspesifikke eller svært dynamiske data. Bruk throttling alltid – også for interne API-er – for å beskytte backend-tjenester mot overbelastning. Kombiner begge deler: bufre vanlige data for å redusere belastningen på backend, og bruk stram throttling for å hindre at én enkelt klient dominerer API-et. Til SAA-C03-eksamenen bør De huske at caching reduserer kostnader og ventetid, mens throttling sikrer tilgjengelighet.

I denne leksjonen har De lært at Throttling på konto-, stage- og metodenivå beskytter backend-systemer ved hjelp av en token bucket-algoritme med konfigurerbare rate- og burst-grenser, at Response Caching lagrer backend-svar i konfigurerbare TTL-perioder for å redusere backend-belastning og ventetid for endepunkter med mange leseoperasjoner, og at Usage Plans with API Keys håndhever throttle-rater og kvoter per klient, slik at De kan tilby tilgang på ulike nivåer for partner- og offentlige API-er. Neste tema er ECS-klynger, oppgavedefinisjoner og tjenester for containeriserte arbeidsbelastninger.