AI administrators deploying Claude Code and Claude…
AI administrators deploying Claude Code and Claude Desktop across their workforce need centralized controls over authentication, model access, cost attribution, and spend enforcement. These controls reduce operational overhead and apply governance consistently at scale.
Claude apps gateway provides a self-hosted governance layer between these applications and Amazon Bedrock or Claude Platform on AWS .
Building on our launch post , this post presents a production reference deployment covering end-to-end architecture, enterprise deployment patterns, cost, and implementation resources.
This section covers the reference deployment topology and how requests flow through the gateway.
Claude apps gateway ships in the same Claude Code CLI binary that developers already run. Started with claude gateway --config gateway.yaml , it runs in server mode and loads its YAML configuration at startup. In this reference deployment, the container runs on AWS Fargate inside your virtual private cloud (VPC). The same image can run on Amazon Elastic Kubernetes Service (Amazon EKS) or Amazon Elastic Compute Cloud (Amazon EC2) if either better matches your existing setup.
The reference architecture uses the following components:
Compute and state: Each AWS Fargate task runs one stateless gateway container. Amazon Relational Database Service (Amazon RDS) for PostgreSQL stores short-lived sign-in state, including device codes and sessions. When spend limits are enabled, it also stores per-user spend counters and audit records. Auth state lives in the database rather than in a task. This means any task can serve any request, with no sticky sessions required on the load balancer.
Ingress and private DNS: An internal Application Load Balancer terminates TLS using an AWS Certificate Manager certificate. An Amazon Route 53 private hosted zone resolves the gateway to private IP addresses reachable through a VPN, AWS Direct Connect , or equivalent private connectivity.
Service connectivity: VPC endpoints keep supported AWS service traffic private, while a NAT gateway provides other required egress.
Upstream credentials: The gateway authenticates to Amazon Bedrock using the AWS Identity and Access Management (IAM) role assigned to the gateway task. The Claude Platform on AWS API key and other static credentials remain in AWS Secrets Manager . No upstream credentials are distributed to developer machines.
Operational note: Configure the load balancer idle timeout to exceed the longest expected interval without data. The default is 60 seconds. The load balancer terminates connections that remain idle longer than the configured timeout. Check both delayed non-streaming responses and pauses between streaming chunks.
**Figure 1: Reference architecture for Claude apps gateway on AWS
Sign-in (once per session). The platform team distributes managed settings that point Claude Code and Claude Desktop to the gateway’s private URL. When a developer runs /login , the client starts the OAuth 2.0 device authorization grant and opens a browser to authenticate through your OpenID Connect (OIDC) identity provider. The browser must also reach the gateway’s private endpoint because the gateway serves the device verification page. After authentication, the gateway issues a short-lived bearer token, valid for one hour by default. The session subsequently refreshes silently in the background.
Inference (every request). Every inference request carries the bearer token. The gateway validates it, resolves the developer’s identity and group membership, applies the matching policy, evaluates the applicable spend cap, and routes the request to Amazon Bedrock or Claude Platform on AWS. The response streams back to the client. The client emits usage metrics, which the gateway forwards over the OpenTelemetry Protocol (OTLP) to a collector you configure. The metrics are attributed to the authenticated identity used for policy evaluation.
For deployment scripts and configuration templates, refer to the accompanying repository . For operational guidance, refer to the deployment guide . For device code verification and token lifecycle details, refer to the Claude apps gateway documentation .
The gateway addresses five governance needs, each described in the following sections.
The gateway delegates authentication to your OIDC identity provider. Developers sign in once through browser SSO. The gateway issues a short-lived token and handles silent refresh in the background. The gateway supports OIDC-approved providers including Okta , Microsoft Entra ID , Auth0 , Keycloak , or Amazon Cognito , for example.
This gives you centralized OIDC authentication with no upstream credentials on developer machines, instant offboarding through identity provider removal, and consistent per-user attribution across requests without custom instrumentation.
The gateway keeps no user directory of its own. There are no accounts to pre-create and no SCIM sync to configure. Whatever groups your identity provider assigns to a user are the groups the gateway uses for policy matching, 1:1 with no translation layer. Manage users and groups entirely in your identity provider, and the gateway picks up changes at the next session refresh. Offboarding is removing the user from your identity provider. Their session expires within the configured time to live (1 hour by default), with no credential rotation required.
The following example shows a gateway configured with Microsoft Entra ID:
oidc: issuer: https://login.microsoftonline.com/<tenant-id>/v2.0 client_id: ${OIDC_CLIENT_ID} client_secret: ${OIDC_CLIENT_SECRET} allowed_email_domains: [company.com] groups_claim: roles
Note: Microsoft Entra ID doesn’t include group or role claims by default. If your policies use match: {groups: [...]} with Entra app roles, add groups_claim: roles to your OIDC configuration. Without this step, the gateway cannot resolve group membership and all users match only the catch-all policy.
For per-identity-provider setup instructions, refer to the identity provider setup guide . The following images show the sign-in experience from the developer’s perspective, for both Claude Code and Claude Desktop.
**Figure 2: Authenticating through the gateway
**Figure 3: The gateway delegates to your existing OIDC identity provider
**Figure 4: Authorizing the device in the browser
**Figure 5: Configuring inference with Amazon Bedrock through the gateway for Claude Desktop
The gateway enforces model access server-side and distributes tool permissions as managed settings, scoped by identity provider group. You define which models and capabilities each team gets in a single YAML block. Policies are evaluated in declaration order. The first match is selected, then merged onto the match: {} catch-all base. End the list with a match: {} policy. It acts as a catch-all for users whose groups don’t match a specific policy earlier in the list. Without one, unmatched users receive full catalog access. Changes propagate to connected clients within one hour, requiring no action from developers.
Managed: policies:
Note: Include desktop: {} in every policy entry to turn on Claude Deskto…
本条由桃子采集流水线（启发式模式）自动整理，原文见文末信源。
