Passerelle Claude apps pour Amazon Bedrock, Google Cloud et Microsoft Foundry

• Pourquoi Claude apps gateway, ce qu’il ajoute par rapport à l’exécution de votre propre solution, et quand quelque chose d’autre convient mieux
• Un démarrage rapide avec les prérequis qui fait passer une passerelle de zéro à un développeur connecté
• Connecter les développeurs, y compris la définition de l’URL de la passerelle via les paramètres gérés
• Disponibilité et limitations couvrant les fonctionnalités Claude Code qui fonctionnent via la passerelle et ce que le serveur supporte

​

Pourquoi Claude apps gateway

• Identifiants : la clé API en amont ou l’identifiant cloud ne vit que dans votre infrastructure. Les développeurs s’authentifient avec SSO d’entreprise et reçoivent des jetons porteurs de courte durée, donc le déprovisionnement se fait dans votre IdP. Déprovisionner un utilisateur et son accès à la passerelle expire dans la durée de vie de la session, une heure par défaut.
• Contrôle d’accès : vos groupes IdP correspondent à des listes d’autorisation de modèles et à des politiques de paramètres gérés. La passerelle applique l’accès aux modèles côté serveur, rejetant les demandes pour les modèles non accordés, et sélectionne la politique de paramètres gérés de chaque groupe, que l’interface de ligne de commande applique au niveau des paramètres gérés. Différentes équipes obtiennent différents modèles, outils et permissions, et un développeur ne peut pas remplacer ce que sa politique verrouille.
• Livraison des paramètres : la passerelle livre les paramètres gérés aux clients connectés elle-même, remplaçant les paramètres gérés par le serveur de la console d’administration claude.ai.
• Télémétrie : chaque destination configurée, comme Datadog, Splunk ou ClickHouse, reçoit les métriques OpenTelemetry Protocol (OTLP) avec les nombres de jetons, le modèle, l’identité de l’utilisateur et la latence par défaut, avec les journaux et les traces comme des options par destination.
• Routage en amont : les clients parlent l’API Anthropic Messages à la passerelle, et la passerelle traduit pour chaque amont, qu’il s’agisse de Bedrock, de la plateforme Agent de Google Cloud, de Foundry ou de l’API Anthropic, avec basculement entre eux. Vous pouvez modifier les régions, les fournisseurs ou l’ordre de basculement sans que les développeurs le remarquent ou se reconfigurent.

​

Autres implémentations de passerelle

​

Démarrage rapide

​

Prérequis

​

Étapes

listen:
  host: 0.0.0.0
  port: 8080
  # Requis derrière tout proxy qui termine TLS. Utilisé pour l'IdP
  # redirect_uri et le document de découverte.
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com        # doit servir /.well-known/openid-configuration
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]        # rejeter les id_tokens en dehors de votre org
  userinfo_fallback: true                  # pour les IdPs dont l'id_token omet email/groups ; inoffensif sinon

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # limite également la latence de révocation lors du déprovisionnement IdP

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}    # ajouter ?sslmode=require pour Postgres géré

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {} # vide : chaîne de credentials AWS par défaut
# (IRSA, rôle de tâche EC2/ECS, variables d'env, ~/.aws)

# Les modèles sont traduits par amont automatiquement. Le catalogue intégré
# mappe claude-opus-4-8 à us.anthropic.claude-opus-4-8 et ainsi de suite pour chaque
# modèle Claude supporté par Bedrock. Définissez false et ajoutez une liste `models:` pour
# exposer uniquement des modèles spécifiques.
auto_include_builtin_models: true

services:
  gateway:
    image: <your-registry>/claude-gateway:<version>
    ports: ["8080:8080"]
    volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
    environment:
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
      GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
      GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
      # Identifiants AWS : en production, omettez ceux-ci et utilisez un rôle d'instance.
      # Pour les tests Compose locaux, transmettez les vôtres :
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
      AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
    depends_on:
      postgres:
        condition: service_healthy
  postgres:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U gw"]
      interval: 5s
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
  "issuer": "https://claude-gateway.internal.example.com",
  "device_authorization_endpoint": "…/oauth/device_authorization",
  "token_endpoint": "…/oauth/token",
  "grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
  "device_code": "…",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://claude-gateway.internal.example.com/device",
  "verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
  "expires_in": 600,
  "interval": 5
}

​

Connecter les développeurs

​

Définir l’URL de la passerelle

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}

​

Pipelines CI et machines distantes

​

Ce qui est appliqué aux développeurs

• Accès au modèle : les demandes pour les modèles que la politique n’accorde pas retournent 400, et le sélecteur /model est filtré à la liste d’autorisation availableModels de la politique. Définissez enforceAvailableModels: true dans la politique pour que l’option Par défaut se résolve à un modèle à l’intérieur de availableModels au lieu du défaut intégré de Claude Code ; sans cela, Par défaut reste sélectionnable et est rejeté au moment de la demande si ce modèle n’est pas accordé.
• Destination de télémétrie : quand le transfert de télémétrie est configuré, le point de terminaison d’export OTLP est épinglé à la passerelle, et la configuration poussée par la passerelle remplace les variables OTEL_* définies localement.
• Identifiants : le jeton de passerelle est le seul identifiant de la session. ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY, apiKeyHelper, et toute connexion claude.ai antérieure sont ignorés lors de la connexion, donc les développeurs n’ont pas besoin de se déconnecter de claude.ai d’abord.
• Paramètres gérés : les clés verrouillées ne peuvent pas être remplacées localement. L’interface de ligne de commande applique la politique au démarrage et à chaque sondage horaire.
• Démarrage : les sessions connectées se terminent au démarrage avec une erreur après environ 10 secondes quand la passerelle est inaccessible, plutôt que de démarrer sans leurs paramètres.
• Déprovisionnement : une session dont l’utilisateur est désactivé dans l’IdP expire dans ttl_hours quand le prochain rafraîchissement échoue.

​

Ce que l’organisation peut voir

​

Disponibilité et limitations

​

Prochaines étapes

• Développez gateway.yaml au-delà de la configuration minimale, par exemple pour ajouter RBAC par groupe, basculement multi-amont, ou destinations de télémétrie. La référence de configuration couvre chaque option.
• Passez de Compose à un déploiement de production sur Kubernetes ou Cloud Run, configurez correctement votre IdP, et examinez le modèle de sécurité. Le guide de déploiement et d’opérations couvre la configuration par IdP, les exigences d’image de conteneur, les sondes de santé et le dépannage.
• Mettez des plafonds de dépenses sur les développeurs individuels ou les groupes pour qu’une charge de travail incontrôlée ne puisse pas consommer tout votre engagement. Limites de dépenses couvre l’API d’administration et le fonctionnement de l’application.
• Pour un exemple complet travaillé sur Google Cloud, avec Cloud Run, Cloud SQL et Secret Manager, voir Déployer sur Google Cloud.