AWS følger op med del 2 i en serie om multi‑tenant agentiske løsninger på Amazon Bedrock AgentCore. Blogposten viser mønstre til at opnå fuld isolation mellem kunder oven på en delt infrastruktur og ledsages af et GitHub‑eksempel med en sundhedsagent. Fokus er skarpt: isolation, service‑tiering, granulær omkostningsmåling og per‑tenant observability. README i repoet siger det tydeligt: demo til læring, ikke produktion.
Hvorfor det er vigtigt nu
Agentiske applikationer er ikke bare en ny UI. De binder samtaler, værktøjer, dokumenter og nøgler sammen. I en delt infrastruktur kan et fejlmærket dokument eller en for bred søgning bryde isolation. Bloggen advarer eksplicit om risiko for kontekstlæk, skæv kvalitet og skjulte omkostninger uden klare skotter mellem kunder og funktioner.
Mange platformteams samler agent‑funktioner i ét miljø for at undgå model‑sprawl. Pool‑modellen lokker, men uden dokumenterede mekanismer for isolation, måling og styring bliver shared nothing hurtigt til shared everything i praksis. Det er her hierarkiet og de konkrete isolationspunkter hjælper.
Arkitekturen i grove træk
Løsningen organiseres i tre lag: Tier → Tenant → User. Politik og konfiguration strammes for hvert hop ned. Tiers grupperer kunder efter produktpakke og QoS, tenants er den enkelte kundeorganisation, og users er brugerne dér. Opdelingen gør det muligt at variere modelvalg og værktøjer pr. tier uden at svække isolation pr. tenant.
Isolation håndhæves fire steder, ifølge bloggen: i knowledge base‑dokumenter (metadata‑filtrering), i memory (samtalehistorik i eget namespace), i model‑adgang (tier‑ og tenant‑bundne policies) og i cost tracking (labels for måling og fordeling). Det er også dér, brister typisk opstår, hvis kæden ikke er konsistent hele vejen.
Tekniske greb under motorhjelmen
Metadata‑tagging på dokumenter er første forsvarslinje. Repoet viser tagging med en clinic_id og filtrering ved retrieval, så søgning kun rammer egne data. Enkelt og effektivt, hvis hele tool‑kæden respekterer filtrene. Memory isoleres via navngivne namespaces pr. tenant og bruger, så historik ikke flyder på tværs. Begge dele er konfigurationsmønstre, man kan starte med i en POC, før man bygger resten ud.
Modeladgang og tiering
Model‑adgang styres per tier. I healthcare‑eksemplet demonstreres et mønster, hvor en Basic‑tier benytter en mindre model til simple forespørgsler, mens Premium anvender en større model, får mere avanceret reasoning og adgang til et web‑search‑værktøj. Pointen er styringen: små opgaver på mindre modeller, komplekse opgaver på dyrere modeller, bundet til produktpakke. Demoen illustrerer mønstret, ikke en endelig modelliste til produktion.
Pool‑modellen betyder, at kunder deler compute og værktøjer med logisk isolation. Fordelen er høj udnyttelse og enklere drift. Ulempen er behov for strammere kontrol: fejl og spikes kan brede sig uden fair‑use‑mekanismer. Bloggen lægger vægt på cost tracking og isolationsmekanismer; kvoter og throttling må implementeres særskilt som en driftsbeslutning.
Praktiske konsekvenser for implementatører
Drift og opsyn: Planlæg belastningstests per tenant og per tier, inklusiv syntetiske spikes, for at se om latency påvirker naboer. Etabler SLO’er pr. tier og overhold dem i alarmering. Mål end‑to‑end, ikke kun modelkald.
Omkostningsstyring: Indfør målepunkter ned til tenant og værktøj med meter‑events for hvert modelkald og retrieval‑hop. Konsistente labels på tværs af hele flowet er nøglen, ellers kan man ikke skelne dyr adfærd fra fejladfærd.
Observability og cost‑attribution i praksis
Oversæt bloggens krav om granular måling til konkret instrumentering. Minimums‑telemetri, per request og per tenant:
- request_rate og succesrate pr. endpoint
- tokens_in og tokens_out pr. modelkald
- tool_calls med værktøjstype og udfald
- retrieval_hits og filtrerings‑labels
- error_rate med fejlkode og oprindelse
- p95_latency for end‑to‑end og for modelkald
Labels: brug ens konventioner, fx tier_id, tenant_id, user_id, session_id. Byg dashboards for cost per tenant per feature og alarmer for cost‑skred og latency‑afvigelser. Tradeoff i kort form: en fælles model‑pool sænker faste omkostninger, men kræver fairness‑kontrol; dedikerede modeller øger isolation og forudsigelighed til en højere pris. En mellemvej er at lade Premium køre i en snævrere pool med skarpere SLO’er.
Kvoter, fairness og belastning
For at beskytte poolen mod spikes er det praktisk at indføre simple kvotemekanismer per tenant og per tier. Eksempler, der ofte bruges i AWS‑miljøer: token‑bucket‑grænser for anmodninger pr. minut og per‑tenant concurrency‑lofter. Det kan håndhæves ved indgangslag med fx API‑nøgler knyttet til brug/plan, opslag af kvotedata i en lav‑latens storage og afvisning eller nedprioritering over grænsen. Pointen er ikke værktøjet, men at grænserne findes, måles og kommunikeres.
Hold det synligt: udsend kvotastatus til klienten, så produktet kan vise fair besked i UI og undgå uforståelige fejl. Log alle afvisninger med de samme labels som øvrig telemetri, så I kan justere politikker med fakta i hånden.
Sikkerhed, dataprivatliv og compliance
Access control skal håndhæves i både applikations‑ og datalag. RBAC eller ABAC på endpoints og funktionskald suppleret af politikker på knowledge base og memory, der forhindrer krydssøgning. Audit‑spor bør være tamper‑evident og koblet til tenant og bruger. Bloggens pointer om streng isolation og sporbarhed er på sin plads — uden det er ansvarlig drift ikke realistisk.
For regulerede domæner: dokumentér kryptering i hvile og transit, nøglestyring og rotation, data‑retention per tenant og ret‑til‑slet for både dokumenter og memory. Planlæg tidligt, hvem der bærer driftsansvaret for disse kontroller, og hvordan de testes løbende.
Healthcare‑eksemplet kortlagt
I eksemplet tilbydes Basic og Premium. Basic begrænses til dokument‑søgning og patientkontekst på en mindre model. Premium åbner for dybere reasoning og web‑search‑værktøjet. Tier‑routing styres via konfiguration, så én agentklasse kan servicere begge med forskellige kapabiliteter og prisprofiler. Mønstret kan løftes over i andre domæner, hvilket bloggen også angiver.
Backup, restore og recovery‑skitse
Memory og vektorstores kræver en plan for per‑tenant recovery. Tænk i:
- Eksportformat for dokumenter og embeddings, så per‑tenant eksport og import kan ske uden at røre andre kunder
- Navngivnings‑ eller namespace‑konventioner, der gør selective restore muligt
- Mål for RPO og RTO pr. tier, så Premium kan gendannes hurtigere end Basic, hvis det er en del af aftalen
- Rutiner for sletning og genopbygning af et enkelt tenants indeks ved datakorruption
Test det. Kør jævnlige øvelser med genskabelse af én tenant, ikke hele klyngen. Notér hullerne, før de bliver hændelser.
Driftsopsætning og test‑roadmap
Start pragmatisk: en POC med tenant‑tagging på dokumenter, navngivne memory‑namespaces og tier‑baseret modelpolitik. Indfør metrikker for tokens, latency og tool‑kald mærket per tenant. Tilføj alarmer for daglige cost‑afvigelser og outlier‑latency pr. tier. Hold det simpelt, men mål alt.
Test for blast radius: fremprovoker fejlmærkede dokumenter, simulér overskridelse af kvoter hos en test‑tenant og observer effekten på naboer. Kør failover‑scenarier for vektorstore og memory, inklusiv selective restore. Hvis selective restore ikke findes endnu, registrér det som et risiko‑punkt i backloggen.
Hvad kan man copy‑paste til en POC
- Sikkert at løfte: dokument‑metadata med tenant‑tags, retrieval‑filtre, navngivne memory‑namespaces, og konfig‑drevet tier‑routing i en enkelt agentklasse
- Kræver produktionsarbejde: secrets management, adskilte nøgler per tenant, kvotestyring og fairness, per‑tenant backup og selective restore, formelle RBAC‑integrationer og CI\/CD‑checks
Åbne spørgsmål og svage punkter
Skalering og livscyklus for memory er ikke detaljeret i kilderne. Hvordan håndteres backup, restore og sletning pr. tenant, når samtaler vokser? Ligeledes er model‑kvoter, throttling og fairness i en delt pool uafklaret i materialet. Bloggen beskriver cost tracking, men ikke konkrete SLA‑mekanismer. Platformteams må træffe valg her og dokumentere dem.
Antagelser og relevans
Artiklens anbefalinger antager uforudsigelige workloads på tværs af kunder, krav om skarp dataadskillelse og behov for gennemsigtighed i omkostninger. Hvis jeres miljø har meget stabile mønstre eller ikke‑følsomme data, kan mindre hårde isolationstiltag være tilstrækkelige i første iteration. Omvendt, med følsomme data eller stramme SLO’er, bør man planlægge snævrere pools eller dedikerede ressourcer tidligt.
Konklusion og næste skridt
Blogposten demonstrerer, at en pool‑model kan kombineres med stærk isolation, når arkitektur bindes til klare labels og politikker. Tre‑lags‑hierarkiet og de fire isolationspunkter er brugbare mønstre, mens repoet er et læringsværktøj, ikke en launch‑knap. Der er huller om memory‑skalerbarhed, fairness og recovery, som implementatører selv må lukke.
Tre skridt er oplagte: byg en minimal POC med stringent tenant‑tagging og per‑tenant måling, valider isolation med skarp‑til‑borde tests under last, og design observability fra dag ét. Man opdager først forskellen, når man sidder med det i hænderne.
