Claude apps gateway på AWS - selvhostet

De fleste virksomheder, der har taget Claude Code eller Claude Desktop i brug bredt, kender mønsteret. Enkelte teams får adgang, flere følger efter, og pludselig er der ti forskellige API-nøgler i omløb uden nogen central oversigt. Det er ikke ondsindet, det sker bare, fordi udviklerværktøjer spreder sig organisk. Problemet er, at hver enkelt nøgle typisk har fuld adgang, ingen politik for hvilke modeller der må bruges til hvad, og ingen samlet omkostningsstyring. Når regningen kommer, er den ofte en overraskelse, fordi ingen kunne se forbruget undervejs. Den overraskelse er velkendt i branchen, netop fordi forbruget sjældent er synligt, før fakturaen lander.

Gateway-arkitekturen retter op på det ved at flytte kontrollen fra den enkelte udvikler til organisationen. I stedet for at hver bruger taler direkte med Anthropics API, går al trafik gennem et lag, som virksomheden selv driver og har fuldt indblik i.

Kernen i løsningen er en gateway, der kører i virksomhedens egen AWS-konto og fungerer som det eneste sted, hvor Claude Code og Claude Desktop kan hente modeladgang fra. Gatewayen håndterer autentificering, ruter forespørgsler videre til den rette model, og logger alt, hvad der går igennem. Fordi den er selvhostet, forlader trafikken aldrig virksomhedens eget miljø, før den rammer selve modelendpointet. Det gør det lettere at overholde interne sikkerhedskrav og compliance-regler, der stiller krav om dataplacering og sporbarhed.

Arkitekturen er bygget, så den kan skaleres med almindelige AWS-byggeklodser: containerdrift, autentificering via eksisterende identitetsudbydere og standard observability-værktøjer. Virksomheder, der allerede har en AWS-baseret infrastruktur, kan integrere gatewayen uden at skulle opbygge et helt nyt driftsmiljø fra bunden.

Det mest konkrete gevinst ved gatewayen er, at adgangsstyring flytter fra individuelle API-nøgler til centrale politikker. En administrator kan definere, hvilke teams der må bruge hvilke modeller, hvilke funktioner der er tilgængelige for hvem, og hvilke grænser der gælder for forskellige brugergrupper. Man styrer adgang gennem roller og politikker, ikke gennem individuelle hemmeligheder, som ingen har det fulde overblik over.

Jeg har ikke et præcist tal på, hvor mange organisationer der rammer denne væg, men mønstret gentager sig: en håndfuld nøgler bliver til et dusin, og pludselig er der ingen, der ejer loftet. Det er typisk der, en AI-udrulning enten skaleres roligt til hele organisationen, eller ender som et skygge-IT-problem.

Det gør det også markant lettere at reagere, hvis noget går galt. Skal en bestemt bruger eller et team midlertidigt afskæres fra adgang, sker det ét sted i gatewayens konfiguration i stedet for at skulle spore og tilbagekalde nøgler spredt ud over flere systemer.

Den anden store gevinst er synlighed i forbruget, mens det sker, ikke bagefter. Gatewayen logger token-forbrug og API-kald pr. team, pr. bruger og pr. model, hvilket giver et løbende billede af, hvor pengene bliver brugt. Det åbner for reelle budgetgrænser: en organisation kan sætte lofter for, hvor meget et team må bruge på en given model i en given periode, og få besked, før grænsen overskrides, i stedet for at opdage det på en faktura en måned senere.

Uden den slags synlighed kan selv en lille pilot ende med at koste langt mere end forventet, simpelthen fordi ingen havde overblik over, hvor mange kald der reelt blev sendt af sted.

Gateway-modellen giver virksomheder en vej fra en uformel pilot til en driftssikker opsætning, uden at de skal skifte værktøj eller omskrive, hvordan udviklerne arbejder til daglig. Det er en forskel, der betyder noget for enhver virksomhed, som har planer om at lade AI-værktøjer blive en fast del af udviklerhverdagen frem for et midlertidigt eksperiment. Der er stor forskel på et system, man kan vise frem, og et system, man rent faktisk tør sætte i produktion.