Anthropic og AWS har offentliggjort en referencearkitektur for en Claude apps gateway, der kan køre i virksomhedens egen AWS-konto. Kernen er governance: central kontrol over login, modeladgang, cost attribution og håndhævelse af spend. Praktisk betyder det bl.a., at nøgler ikke længere skal ud på udviklermaskiner, og at forbrug kan styres i stedet for at overraske sidst på måneden [kilde: AWS blogposten].
Set fra maskinrummet handler nyheden om at placere en driftbar, stateless gateway mellem Claude Code eller Claude Desktop på klientsiden og Amazon Bedrock eller Claude Platform på AWS som upstream. Referencearkitekturen lægger sig på Fargate – med mulighed for EKS eller EC2 – og lægger sessions samt eventuelle spend-counters i RDS for PostgreSQL. Klassiske AWS-byggesten, men med valg, der påvirker både netværksdesignet og de daglige processer.
Gatewayen følger med i den samme Claude Code CLI-binary. Den startes i server-mode med kommandoen “claude gateway –config gateway.yaml”, som læser en YAML-konfiguration ved opstart [kilde: AWS blogposten]. Det gør test let. Produktion kræver til gengæld stramme beslutninger om autentificering, DNS og egress.
Hvad gatewayen er — kort og konkret
Claude apps gateway er et selv-hostet styringslag. Den modtager kald fra Claude Code og Claude Desktop, validerer tokens, anvender politikker, evaluerer forbrugsloft og ruter til enten Amazon Bedrock eller Claude Platform på AWS [kilde: AWS blogposten]. Compute-laget er stateless, så alle instanser kan håndtere alle kald. Til gengæld lander kortlivet login-state og – hvis aktiveret – per-bruger forbrugsoptællinger i en database.
Referencearkitekturen komponent for komponent
Compute: Ét Fargate task pr. stateless gateway-container. Ingen sticky sessions, fordi al sessionsstate ligger i databasen [kilde: AWS blogposten]. Det gør skalering enkel, men øger presset på databasen, hvis connection pooling ikke er sat rigtigt. EKS eller EC2 kan anvendes i stedet, hvis man vil tættere på underlaget eller genbruge eksisterende node pools.
State: Amazon RDS for PostgreSQL rummer kortlivede sign-in-artefakter som device codes og sessions. Slås spend-limits til, lander per-bruger counters og auditoptegnelser samme sted [kilde: AWS blogposten]. Kryptering i hvile og i transit håndteres af RDS, og backup/point-in-time recovery er understøttet i AWS’ dokumentation. Schema og indeksvalg er ikke beskrevet i blogindlægget og kræver egen vurdering [kilde: AWS docs generelt].
Ingress og DNS: En intern Application Load Balancer terminerer TLS med ACM-certifikat, og en privat Route 53 hosted zone peger klienterne mod gatewayens private IP’er [kilde: AWS blogposten]. Forbindelsen fra udviklermaskiner til VPC’en sker typisk via VPN eller Direct Connect. Vær opmærksom på idle timeout i ALB. Standard er 60 sekunder, hvilket kan lukke en streaming-session med længere pauser mellem chunks. Sæt den over længste forventede pause [kilde: AWS blogposten og ALB best practices].
Hvorfor disse valg betyder noget for drift og sikkerhed
Stateless tasks gør autoskalering ligetil. Ingen in-memory sessionbind og ingen sticky cookies. Til gengæld bliver RDS samlingspunktet for sessions og spend. En fornuftig connection pool, meningsfulde TTLs og backoff ved fejl er nødvendigt for at undgå flaskehalse, når mange brugere logger ind samtidigt.
Fargate er bekvemt for teams uden tung Kubernetes-opsætning. Omvendt kan EKS eller EC2 give mere kontrol, dybere observability og lettere integration, hvis man allerede arbejder med sidecars, DaemonSets eller specifikke CNI-politikker. Valget er mellem enkelhed nu og platformfleksibilitet senere.
Privat DNS via Route 53 betyder, at klienter kun resolver til interne IP’er og rammer en intern ALB. Kombinér det med VPC endpoints til S3, Secrets Manager og – hvor understøttet – Bedrock, så service-trafik bliver på private net [kilde: AWS docs]. En NAT gateway er dog stadig nødvendig til nødvendig egress. Log den trafik og følg omkostningerne.
Operationelle krav til auth, attribution og håndhævelse af spend
Loginflowet kører som et OAuth 2.0 device authorization grant (OIDC i ryggen) [kilde: AWS blogposten og IETF RFC 8628]. Udvikleren kører /login, browseren åbner en verifikationsside, og gatewayen udsteder et kortlivet bearer token – typisk gyldigt i en time – som fornyes løbende. Det forudsætter stabil adgang til det private endpoint.
Cost attribution og spend-enforcement sker ved, at gatewayen kobler autentificeret identitet, grupper og politik, før der routes til upstream. Når spend-limits er slået til, registreres forbrug i RDS per bruger [kilde: AWS blogposten]. Samtidighed er et kendt problem: to samtidige anmodninger kan ramme samme grænse. Her kræves transaktioner og atomare opdateringer i databasen – evt. advisory locks. Blogindlægget beskriver ikke detaljerne.
Audit logging er central for afstemning og misbrugsdetektion. En minimumsfeltliste er praktisk: requester, model-id, cost-center, antal tokens/bytes, tidsstempel og policy-version. AWS indlægget nævner, at klienten udsender brugsmålinger, som gatewayen kan videresende via OpenTelemetry Protocol (OTLP) til en collector, I konfigurerer [kilde: AWS blogposten]. Sørg for at den identitet, der evalueres til policy, også bruges i metrics-attribuering.
Netværk og drift der rammer netværksarkitekten direkte
En privat Route 53 hosted zone er nødvendig, hvis klienterne skal resolve gatewayens hostname til interne IP’er. Zonen skal associeres med relevante VPC’er; i hybrid set-ups skal on-prem DNS-forwarders pege korrekt, så opløsning sker via VPN eller Direct Connect [kilde: AWS Route 53 docs]. Uden korrekt forwarding kan verifikationssiden til tider virke, mens CLI-token-refresh fejler senere.
Multi-region øger kompleksiteten. Private hosted zones er bundet til VPC-associationer per region. Man ender ofte med separat association per region og skal vælge routing og failover-strategi. VPC peering eller Transit Gateway på tværs af regioner kan hjælpe, men latency og politik skal tænkes ind. Blogindlægget dækker ikke dette, så der kræves arkitekturarbejde.
ALB idle timeout fylder lidt i dokumentationen, men meget i drift. Streaming-svar pauser naturligt mellem chunks. Overskrides ALB’s idle timeout, lukkes forbindelsen uden tydelig logstøj. Symptomet ligner en netværksfejl, men årsagen er for lav timeout. Sæt timeouts i ALB og klienter, test med lange pauser, og mål end-to-end.
Sikkerhed, compliance og audit
Sessions og device codes ligger i RDS og bør krypteres i hvile med KMS-nøgle, mens forbindelser fra gateway-containere anvender TLS med server-side certifikatvalidering [kilde: AWS RDS docs]. Secrets Manager bør indeholde statiske nøgler – fx Claude Platform API-nøgler – som gatewayen henter ved opstart. Planlæg løbende rotation og alarmer, så en forpasset rotation ikke blokerer drift.
IAM-rollen på gateway-tasken håndterer autentificeringen mod Bedrock [kilde: AWS blogposten]. Fordelen er, at upstream credentials ikke udleveres til udviklermaskiner. Least-privilege-policyer bør begrænse modeller, regioner og API-sæt og være versionsstyrede. Når nye modeller lanceres, skal politikker kunne opdateres kontrolleret.
Audit-setninger bør være ensartede og søgbare. Log også policy-evalueringsresultat og endelig route-destination. Retention afhænger af interne krav og lovgivning. Blogindlægget angiver ikke retention-politikker, så det må defineres internt.
Observability, fejlhåndtering og backup
Metrics bør dække latency end-to-end, request-rate, antal streaming-chunks, fejlrate per upstream, DB connections og pool-udnyttelse samt opdateringshastighed på spend-counters. Alarmer giver mening ved DB-connection-mætning, 5xx-spikes, gentagne idle-timeouts og overskredne spend-thresholds.
Logs skal være konsise og korrelerbare: request-id, trace-id, bruger eller service-konto og policy-version. Gem ALB access logs i S3, centralisér gateway-applogs, og sæt RDS-parametergruppen til nødvendige logklasser. Backup/restore: RDS tilbyder snapshots og point-in-time recovery; vælg Multi-AZ for højere tilgængelighed [kilde: AWS RDS docs].
Failover for gateway-imaget kan håndteres med blue/green i ECS eller canary-udrulninger i EKS. Vær opmærksom på, at aktive streaming-sessioner kan blive afbrudt ved deploy. Planlæg udrulningsvinduer eller brug connection draining med tilstrækkelig tid. Det fremgår ikke af blogindlægget, men følger af at terminere forbindelser bag en ALB.
Koste og governance tradeoffs
Fargate holder platformteamet let, men prisen pr. vCPU-time kan være højere end EKS på reserverede noder. EKS og EC2 kræver til gengæld mere vedligehold. Der er ingen priseksempler i blogindlægget, så lav en TCO-sammenligning for jeres belastning. ALB, NAT og RDS er faste poster, der består også ved lav trafik.
RDS-størrelse afhænger af loginmønstre og concurrency. Mange korte sessions med lav TTL giver mange writes og hyppige counter-opdateringer. Connection pooling i gatewayen – eller via proxy – kan være forskellen på stabil drift og connection storms. Det er ikke beskrevet, men velkendt fra lignende systemer.
Chargeback lettes af per-bruger counters. Kombinér politikker med et cost-center-felt i identitetskilden, og lad gatewayen skrive både bruger og cost-center i audit-tabellen. Ressourcetags hjælper, men attributtering på brugerniveau er ofte det, der gør governance anvendeligt for forretningen.
Praktisk tjekliste før udrulning
- Netværkssti: VPN eller Direct Connect til VPC’en, korrekte security groups, og VPC endpoints for S3, Secrets Manager og Bedrock hvor muligt.
- Certifikater og ALB: Internt ACM-cert, ALB idle timeout sat over længste streaming-pause, access logs til S3.
- Secrets Manager: Statiske nøgler på plads, rotationsplan og alarmer.
- IAM-rolle: Least-privilege mod Bedrock, versionsstyret policy, begrænset til relevante regioner og modeller.
- RDS PostgreSQL: Multi-AZ, korrekt parametergruppe, testet backup/restore, schema for sessions/device codes/spend-counters, indeks på identity og tidsstempel.
- Route 53 privat zone: Associeret med relevante VPC’er, DNS-forwarding on-prem, klienter kan nå verifikationssiden.
- Observability: OTLP-collector, dashboards for latency/fejl/DB connections/idle timeouts/spend, alarmer på grænser og saturation.
- Cost attribution: Cost-center-felt, rapporter, adgang til audit-logs for finance.
- QA og test: Automatiserede login-tests, streaming med lange pauser, load ved samtidige logins samt negative tests for spend-grænser og race conditions.
Hvad dokumentationen ikke dækker fuldt ud
Blogindlægget beskriver arkitekturvalg og flows, men mangler priseksempler for typiske profiler. Der er heller ikke ydelsesbenchmarks for latency med streaming. RDS-schema for device codes, sessions og spend-counters er ikke skitseret, og der er ingen anbefalinger til retention eller indeks. Disaster recovery for RDS omtales kun via generelle AWS-funktioner.
Multi-region patterns, Route 53 private hosted zones på tværs af regioner samt konsekvenser for peering og routing er ikke behandlet. CI/CD for gateway-imaget – scanning, canary, rollback og påvirkning af aktive streams – er ikke beskrevet. OIDC-eksempler mod konkrete enterprise-IdP’er er heller ikke vist. Det er typisk områder, teams selv må specificere.
Konklusion og konsekvenser
Referencearkitekturen giver mening, når behovet for central styring, privat trafik og tydelig attributtering er højt. Fargate er et godt førstevalg for små platformteams. EKS eller EC2 er oplagt, hvor infrastruktur og værktøjer allerede er på plads. Stateless compute og state i RDS gør skalering og vedligehold håndterbart, men kræver disciplin på database-laget.
Organisatorisk skal der være klart ejerskab på identiteter, politikker og cost governance. Uden det bliver gatewayen et pænt diagram uden effekt. Teknologien er klar; processerne afgør, om det holder, når alle åbner editoren mandag morgen.
Test streaming med bevidst lange pauser og sæt timeouts derefter. Den fejl dukker først op i praksis.
Kilder
- Deploying Anthropic Claude apps gateway for AWS for enterprise workloads
- Documentation Get detailed technical guides and references for all AWS services and tools
- Building and Validating a Quantitative Trading Strategy with OctoBot, Walk-Forward Backtesting, Parameter Optimization, and Interactive Analysis
