Rate limits Amazon Bedrock AgentCore Gateway

Det nye lag arbejder på identitetsniveau, ikke kun på applikationsniveau. Det betyder, at gatewayen kan skelne mellem forskellige brugere, klienter eller agenter, der alle sender kald gennem samme opsætning, og sætte individuelle grænser for hver af dem. En agent, der betjener 500 medarbejdere i en organisation, kan dermed få en samlet grænse for hele trafikken, samtidig med at hver enkelt bruger har sit eget loft. Det forhindrer, at én overivrig bruger eller ét fejlbehæftet script kan spise hele kapaciteten og efterlade de øvrige uden adgang.

Det er ikke kun antallet af requests, der kan begrænses. Vi ser tre konkrete dimensioner, som virksomheder kan skrue på: antal requests pr. tidsenhed, antal tokens der forbruges, og antal samtidige forbindelser. Det giver en mere præcis kontrol, end hvis man kun kunne stille på ét reguleringsspejl.

Token-baserede grænser er særligt vigtige for agentiske systemer, fordi et enkelt kald til en stor sprogmodel kan variere enormt i pris og belastning, alt efter hvor lang konteksten er, og hvor meget modellen genererer. En grænse på antal requests fanger ikke nødvendigvis, at én bruger sender korte kald, mens en anden sender kald med enorme kontekstvinduer. Ved at begrænse på tokens rammer man den faktiske belastning af modellen, ikke bare antallet af opkald.

Forbindelsesgrænser løser et andet problem: langvarige, streamende svar eller agent-loops, der holder en forbindelse åben i lang tid. Uden et loft på samtidige forbindelser kan et fåtal af tunge, langsomme processer optage ressourcer, der ellers skulle bruges til kortere, hurtigere kald fra andre brugere.

AgentCore gateway sidder typisk som mellemled mellem agenter og de modeller og tools, de kalder. Uden trafikstyring på det lag risikerer man, at en spids belastning fra agentsiden vælter videre til modellerne og de eksterne tjenester, agenten er afhængig af. Det kan give forsinkelser for alle brugere, overskredne kvoter hos tredjepartsleverandører eller i værste fald nedbrud af hele kæden.

Vi ser det samme mønster igen og igen i produktionssystemer med agenter: problemet opstår sjældent ved normal drift, men ved de øjeblikke hvor mange brugere rammer systemet samtidig, eller hvor en fejl i en agent skaber en løkke af gentagne kald. Rate limits på gateway-niveau fungerer som en sikkerhedsventil, der stopper den slags belastning, før den når frem til de dyre og sårbare dele af arkitekturen.

Det handler ikke kun om at undgå nedbrud. Det handler også om at kunne styre omkostninger. Modelkald koster penge pr. token, og uden grænser kan en enkelt bruger eller en fejlkonfigureret integration generere en regning, ingen havde budgetteret med.

Det, der adskiller den nye funktion fra en simpel, global rate limit, er muligheden for at differentiere. En organisation kan sætte en høj grænse for interne, betroede systemer og en lavere grænse for eksterne integrationer eller nye, endnu ikke fuldt validerede agenter. Man kan også opdele grænserne efter formål, sådan at en agent, der udfører kritiske, tidsfølsomme opgaver, får mere båndbredde end en agent, der kører baggrundsjobs.

Denne finkornede tilgang gør det muligt at rulle nye agenter ud gradvist. I stedet for at give en ny integration fuld adgang fra dag ét, kan man starte med stramme grænser og løsne dem, efterhånden som man ser, hvordan trafikken faktisk opfører sig. Det er en langt mere ansvarlig måde at introducere agentisk trafik på end at åbne helt op og håbe, at systemet kan bære det.

Vi har set flere danske virksomheder gå fra proof-of-concept til produktion med AI-agenter i det seneste år, og et af de mest oversete punkter i den overgang er trafikstyring. Et pilotprojekt med ti brugere afslører sjældent de problemer, der opstår, når 200 medarbejdere begynder at bruge den samme agent samtidig.

Som principal konsulent hos Agent Enterprise er jeg sammen med mit team med til at drive netop den slags overgange, fra problemafklaring og planlægning til implementering og drift. Det er typisk her, i overgangen fra pilot til fuld drift, at rate limits, kvoter og downstream-beskyttelse bliver afgørende for, om et agentisk system holder, eller om det vælter under sin egen succes.

For virksomheder, der allerede kører agenter på AgentCore, er den nye funktion en direkte mulighed for at lægge et beskyttende lag ind uden at bygge det selv. For virksomheder, der stadig planlægger deres første agentiske løsning, er det et signal om, hvad der bør indgå i arkitekturen fra starten: ikke kun hvordan agenten løser opgaven, men hvordan trafikken til og fra den styres, når mange brugere rammer den på én gang.