Claude Apps Gateway: Anthropic's New Control Plane for Claude Code on Bedrock and Google Cloud

If you've ever tried to roll out Claude Code to more than a handful of developers on Amazon Bedrock or Google Cloud, you already know the pain: a cloud credential per developer, settings pushed by hand to every laptop, and no single place to see who's spending what. This week Anthropic shipped a fix — the Claude apps gateway, a self-hosted control plane that puts corporate SSO, centralized policy, and per-user cost tracking in front of Claude Code deployments running on third-party cloud infrastructure.

This isn't a small config tweak. It's a genuine architecture shift for how regulated and security-conscious organizations run Claude Code at scale, and it lands right as Claude Certified Architect (CCA) candidates are being tested on exactly this kind of enterprise deployment pattern. Here's what the gateway does, how it's built, and how to stand one up.

The Problem It Solves

Before this release, running Claude Code through Amazon Bedrock or Google Cloud meant one of two paths: give every developer their own cloud credential (a provisioning and offboarding headache), or route everything through a shared key (which makes per-user attribution and access control nearly impossible).

Anthropic describes the old flow plainly: teams were "provisioning a cloud credential per developer, manually pushing settings to every laptop, and standing up separate tooling to see per-developer spend." For an org running Claude Code across dozens or hundreds of engineers, that's three separate operational burdens stacked on top of each other — identity, policy, and cost — with no shared source of truth.

The gateway collapses all three into one deployable service that IT actually owns.

What the Gateway Actually Does

The Claude apps gateway sits between your developers' Claude Code clients and your model provider (Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or the Anthropic API directly). Developers never see or hold a raw API key or cloud credential — they sign in with your corporate identity provider instead, and the gateway does the rest.

1. SSO instead of API keys

The gateway acts as an OpenID Connect (OIDC) relying party against Google Workspace, Microsoft Entra ID, Okta, Keycloak, Dex, or any OIDC-compliant provider. Developers authenticate through the standard device sign-in flow and receive a short-lived bearer token — one hour by default. The upstream cloud credential lives only on the gateway, never on a developer's machine.

That has a practical security payoff: offboarding a developer is just deprovisioning them in your IdP. Their gateway session expires at the next refresh, and there's no lingering API key to rotate or revoke.

2. Per-group model access and managed settings

IdP groups map directly to model allowlists and managed settings policies. The gateway enforces model access server-side — a request for a model outside a group's policy gets rejected with a 400, and the model picker in the CLI only shows what that group is allowed to use. This is the piece that matters most for larger orgs: a data science team can get Opus 4.8, while a support-tooling team is locked to a cheaper Sonnet-tier model, all enforced centrally rather than by developer honor system.

3. Spend limits and cost attribution

Admins can set daily, weekly, and monthly spend limits at the organization, group, or individual user level. Combined with usage telemetry, this finally gives finance and engineering leadership a real answer to "who is spending what on Claude Code" — something that was nearly impossible to get cleanly with shared or per-developer keys before.

4. Telemetry that goes to your observability stack

Every request gets stamped with a usage metric and relayed over the OpenTelemetry Protocol (OTLP) to a collector you configure — Datadog, Splunk, ClickHouse, or anything else that speaks OTLP. Crucially, the gateway's data plane sends nothing to Anthropic unless the Anthropic API is one of your configured upstreams. For orgs with strict data residency requirements, that's often the deciding factor.

5. Routing and failover across providers

The gateway translates the Anthropic Messages API into whatever format each upstream expects, so you can point Claude Code at Bedrock, Google Cloud, Foundry, or the Anthropic API — and even set failover order between them — without developers noticing or reconfiguring anything on their end.

Deployment Architecture

The gateway ships inside the same claude binary developers already install — there's no separate download. Running claude gateway --config gateway.yaml turns that binary into a server instead of a CLI.

Key architectural facts worth knowing if you're evaluating this for your infrastructure:

• Single stateless container, deployed on Linux, backed by PostgreSQL 14+
• Requires Claude Code v2.1.195 or later on both the gateway host and every developer machine
• Must be deployed on a private network address (RFC 1918, CGNAT, IPv6 ULA, or loopback) — Claude Code refuses to /login against a gateway with a public IP, by design, since a compromised gateway could otherwise push malicious settings to developer machines
• Boot is fail-closed: if Postgres, OIDC discovery, or upstream credentials aren't reachable, the gateway exits rather than serving traffic in a degraded state
• No Helm chart or admin UI yet — configuration is a single gateway.yaml, and changes require a redeploy

Minimal config example

yamllisten:
  host: 0.0.0.0
  port: 8080
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}
  ttl_hours: 1

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}

That five-section file — listen, oidc, session, store, upstreams — is enough for a working sign-in loop against Bedrock's default model catalog. From there you layer on per-group RBAC, multi-upstream failover, and telemetry destinations.

What's Not Supported Yet

Worth knowing before you plan a rollout — a handful of Claude Code features don't work through the gateway today:

• Server-side web search — disabled, since the CLI can't verify which upstream provider supports it
• 1-hour prompt cache TTL — gateway sessions fall back to the standard 5-minute TTL
• First-party-only optimizations like global cache scope and token-efficient tools
• SAML/LDAP — OIDC only; front it with a bridge if your IdP doesn't speak OIDC natively
• Multi-tenant setups — one OIDC issuer per gateway instance; run separate gateways for separate tenants
• CI/unattended pipelines — there's no service-token flow; the device sign-in flow always needs a human to approve in a browser

None of these are dealbreakers for most enterprise rollouts, but they matter if your team leans heavily on web search or runs Claude Code inside CI.

Why This Matters for CCA Candidates

If you're preparing for the Claude Certified Architect (CCA-F) exam, this release is directly relevant to Domain 3: Claude Code Configuration & Workflows and touches Domain 1: Agentic Architecture & Orchestration — both weighted heavily on the exam blueprint. Enterprise deployment patterns like identity-based access control, centralized policy enforcement, and telemetry routing are exactly the kind of "how do you run this safely at scale" questions the exam probes for architects working with partner companies.

Understanding why Anthropic built the gateway the way it did — stateless container, fail-closed boot, private-network-only sign-in — is a good proxy for the security reasoning the exam expects you to apply when you're the one designing a Claude Code rollout for a regulated enterprise.

Getting Started

If you're evaluating the gateway for your organization:

Full configuration reference and per-IdP setup instructions are in Anthropic's Claude Code docs.

Key Takeaways

• The Claude apps gateway is a self-hosted control plane that adds SSO, per-group model access, spend limits, and OTLP telemetry to Claude Code running on Bedrock, Google Cloud, or Foundry
• It ships inside the existing claude binary — no separate install — and requires Claude Code v2.1.195+
• Deployment is a single stateless container backed by PostgreSQL, and it must sit on a private network address for security reasons
• Some first-party features (web search, 1-hour cache TTL, CI pipelines) aren't supported through the gateway yet
• This is squarely enterprise architecture territory — directly relevant to CCA exam domains on Claude Code configuration and agentic architecture

Next Steps

Studying for the Claude Certified Architect exam and want to make sure enterprise deployment patterns like this one stick? Check out AI for Anything's CCA practice test bank for scenario-based questions covering Claude Code configuration, MCP integration, and production architecture — built to mirror the real exam's five competency domains.