AWS har lagt en konkret opskrift frem: en serverless A2A-gateway, der samler agent-discovery, routing og adgangskontrol bag ét domæne. Ét endpoint, sti-baseret routing og centraliserede rettigheder. Med en Terraform-vej gennem udrulningen. Timingen giver mening. Mange virksomheder rammes af agent-integrationer, der vokser fra små koblinger til et operativt spaghettilandskab på få måneder.
Kort nyhedspeg: Guiden viser, hvordan man bygger gatewayen omkring Amazon API Gateway (REST), Lambda, DynamoDB, Cognito og Bedrock-komponenter. Målet er at bryde punkt-til-punkt-eksplosionen, når agenter skal tale sammen på kryds og tværs. Kilderne er AWS’ tekniske blog og AgentCore-dokumentationen. Der er ingen offentlige kundecases eller benchmarks i materialet.
Punkt-til-punkt-eksplosionen
Uden en central gateway ender hvert nyt agent-par i sin egen specialkonstruktion: særskilt routing, egne credentials, undtagelser hist og her. AWS peger selv på regnestykket: 20 agenter kan give op til 190 forbindelser, hvis der ikke er en central gateway eller orkestrator. Det er O(n^2) i praksis – dyrt for drift, sikkerhed og compliance.
Det mærkes især i governance: spredte adgange, mangelfuld audit-trail og svært ved at lukke en enkelt aktør uden følgefejl. Ved 8–10 agenter begynder det at knage i kanterne, både teknisk og organisatorisk.
Hvad gatewayen konkret gør
Gatewaymønstret stiller et single-entry REST-endpoint foran alle agenter og ruter på stier, typisk som \/agents\/{agentId}. Det afkobler klienter fra specifikke runtimes og frameworks og centraliserer autorisation. Ikke kun “én dør ind” – også “én kilde til policyer”.
Ansvarsfordelingen bliver renere: agenter udvikles og vedligeholdes separat, mens gatewayen håndterer discovery, adgangskontrol og transport. Den afkobling gør det muligt at skifte model eller framework bag kulissen uden at bryde klienter.
Tre lag der spiller sammen
AWS deler løsningen i tre lag – og her er det ikke kun pædagogik, men konkrete komponenter.
- Management-lag: Et Agent Registry, semantisk søgning via Amazon Titan Text Embeddings i Bedrock og livscyklus for registrering og opdatering. Data ligger i DynamoDB og S3-baserede vektorstrukturer.
- Control-lag: Adgang styres med JWT-scopes, valideret af en Lambda-authorizer, der mapper scopes til IAM-policyer. Dermed en deterministisk gate før hvert kald.
- Execution-lag: Routing med Amazon API Gateway (REST) som indgang, en proxy-Lambda, backend-OAuth og Server-Sent Events (SSE) til streaming-svar.
Arkitekturen er tydeligt vist i AWS’ materiale og taler åbne protokoller. Der er stadig AWS-specifik sammenføjning i kanterne.
Hvorfor REST og hvorfor SSE
API Gateway i REST-mode vælges, fordi varianten understøtter response streaming, som er nødvendig for SSE. SSE er enkel for klienter sammenlignet med WebSockets. Til gengæld giver streaming længerevarende forbindelser, som har konsekvenser for pris og skalering. Man undgår polling, men betaler i connection-lifetime.
Tradeoffs skal måles, ikke gættes: throughput, connection-lifetime og proxy-latens. Guiden leverer ingen hårde tal, så performance- og prisestimater kræver egne tests med realistisk last. Latens under streaming og timeouts i Lambda Web Adapter hører til de første testcases.
Identitet, scopes og governance
Adgang kører på OAuth 2.0 med Cognito (client credentials), der udsteder en JWT med scopes. En Lambda-authorizer læser scopes og mapper dem til IAM-policyer med stiadgang – fx \/agents\/agent-a\/* ja, \/agents\/agent-b\/* nej. Permissions slås op i DynamoDB. Mekanikken er ligetil.
Det kræver til gengæld disciplin: scope-taxonomi skal designes omhyggeligt. For brede scopes giver politiske undtagelser; for smalle eksploderer antallet. Token-rotation, nøgleskift, revisorsikre logs og faste adgangsreviews er basispakken, ikke tilvalg.
Discovery og semantik
Agentbeskrivelser forældes hurtigt, i takt med at evner ændrer sig. Uden faste opdateringer ender man med tvivlsomme hits. Log søgninger og planlæg regelmæssige evaluation-jobs fra start, ellers bliver registry’et støjende.
Hosting og runtime
Bedrock AgentCore Runtime fungerer som serverless værtsmiljø til agenter og understøtter kommunikation via MCP og A2A. Dokumentationen angiver kompatibilitet med LangGraph, Strands og CrewAI samt brede modelvalg, inkl. Bedrock-modeller, Anthropic Claude, Google Gemini og OpenAI.
Isolation er en væsentlig detalje: hver session kører i en microVM med isolerede ressourcer og saniteres ved afslutning. Det reducerer risiko for læk mellem samtidige forløb – relevant for følsomme data og længere reasoning-kæder.
Terraform og drift
Tutorialen lander infrastrukturen med Terraform, hvilket hjælper på reproducerbarhed og miljøparitet. Men det rækker ikke med en “terraform apply”. CI\/CD-pipelines, godkendelser, miljøsegregering og sikre rollbacks skal på plads. Observability er obligatorisk.
Mål i minimum: SSE-connection-lifetime og fejlrate, end-to-end proxy-latens, auth-fejl per scope, rate-limiting-tællere i DynamoDB, throttling-events i Lambda og standardiseret oversættelse af backend-fejl. Distribueret tracing på tværs af agenter bliver hurtigt et krav.
Praktiske implikationer for teams
Roller flytter sig. Sikkerhed kommer tættere på udvikling, fordi scopes og policies nu er en del af API-designet. Platform\/SRE får ansvar for gatewayens SLO’er, kapacitetsplan og incident-håndtering. Udviklere undgår nøgleudveksling på kryds og tværs, men skal levere solide agentbeskrivelser og holde kontrakterne skarpe.
Processer følger med: faste token-rotationer, kvartalsvise adgangsreviews, playbooks for kompromitterede credentials og aftaler for fallback, når et backend-agentmiljø er nede. Og ja – der skal være en procedure, når semantisk søgning peger forkert. Det sker indimellem.
Begrænsninger og modargumenter
En central gateway er også et centraliseret risikopunkt. Uden redundans er det et single point of failure. Vendor lock-in er reelt: API Gateway + Lambda + Cognito + DynamoDB binder til AWS’ drifts- og prismodeller. Man kan standardisere meget, men porteringsomkostninger forsvinder ikke.
Performance og pris ved mange samtidige SSE-forbindelser kræver særlig opmærksomhed. Tutorialen indeholder ingen tal for store mængder streams, og API Gateways connection-limits og pris kan bide uden throttling og batching. For latency-følsomme kæder kan en internt hostet proxy eller en specialiseret streaming-løsning være mere passende.
Alternativer og hybridvalg
Alternativet er ofte mesh eller federerede designs, hvor lokale gateways eller sidecars håndhæver politik tættere på workloads. Det aflaster den centrale flaskehals, men øger governance-arbejdet. Et pub\/sub-lag afkobler pænt, men hjælper mindre på finmasket autorisation pr. endpoint. Hybridmønstre er realistiske: central discovery og kontrol, med lokal eksekvering eller regional routing for at reducere latens.
Der er ingen universalløsning. Få, tæt koblede agenter i samme miljø kan stadig køre via en simpel reverse proxy og delte secrets. Planlægger man et bredere økosystem af leverandør-agenter og interne bots, er en central gateway tæt på en forudsætning for overblik og styring.
En stram køreplan til PoC
En tretrins PoC holder fokus uden at trække i langdrag.
- Discovery: Etabler Agent Registry, registrér 3–5 agenter og aktivér semantisk søgning. Mål præcision og indfør en simpel review-proces for beskrivelser.
- Control: Implementér JWT-scopes med Lambda-authorizer, definér 6–10 scopes og kør adgangsreviews. Log alle denials og brug dem til at justere taxonomien.
- Execution: Sæt API Gateway op med path-routing og proxy-Lambda. Test SSE med realistiske sessioner. Indfør basis-rate limiting og observability-metrics.
Checkpoint ved hvert trin: test af tokensikkerhed, belastningstest af streaming og en runbook for fejlscenarier. Der er ingen offentlige caser eller feltdata i kilderne, så lokale målinger er nødvendige før produktion.
Hvad gevinsten i realiteten er
Den konkrete gevinst er mindre integrationsarbejde og en central kontrolflade for sikkerhed. Nye agenter kræver ikke længere fem nye særintegrationer, men én registrering og måske et ekstra scope. Onboarding og offboarding bliver kontrollerede ændringer med auditspor i stedet for koordinerede ad hoc-tråde.
Organisatorisk forsvinder arbejdet ikke. Governance bliver mere formelt, og ansvaret for en god scope-model og opdaterede beskrivelser flytter fra enkeltpersoner til faste processer. Teknologien er til at implementere; forskellen mærkes i driften og i samarbejdet omkring den.
Kilder og videre læsning
- AWS Machine Learning Blog: Building a serverless A2A gateway for agent discovery, routing, and access control — arkitektur, tre lag, path-baseret routing, JWT + Lambda-authorizer, SSE, Terraform (kilde 2183)
- Amazon Bedrock AgentCore Runtime docs — kompatibilitet, microVM-isolation, MCP og A2A-understøttelse (kilde 2186)
- Manual brief — pragmatiske drifts- og governance-overvejelser fra et neutralt perspektiv (kilde 2184)
Bemærk usikkerheder i AWS-guiden: manglende performance- og prisestimater, ingen detaljer om multi-region failover, begrænset skaleringsdiskussion for mange samtidige SSE-streams og ingen runbooks for incidents. De punkter skal afklares i egne tests før produktion.
