On this page · 11 sections
Summary. Anthropic shipped the Claude apps gateway in early July 2026: Google Cloud published its deployment guide on July 1 and AWS on July 8. It is a self-hosted control plane that puts identity, policy, telemetry, routing and spend for Claude Code and Claude Desktop in one place. The gateway runs as a single stateless container backed by a PostgreSQL database, listens on port 8080, and issues short-lived sign-in tokens that expire in one hour by default, so no long-lived keys sit on developer laptops. You route inference to Amazon Bedrock, Claude Platform on AWS, Google Vertex, or Microsoft Foundry, and set daily, weekly and monthly spend caps per user, group or organisation. The cost pressure is real: Claude Sonnet 5 runs at an introductory $2 per million input tokens and $10 per million output tokens through August 31, 2026 (then $3 and $15), and Claude Opus 4.8 at $5 and $25, so an uncapped fleet of coding agents can build a bill quickly. This guide covers what the gateway does, how to deploy it on AWS and Google Cloud, the trade-offs between upstreams, and where it stops.
What the gateway actually is
The Claude apps gateway is delivered by Anthropic inside the same Claude Code CLI binary your developers already run. There is no separate agent to install. You run one stateless container on your own infrastructure, backed by a PostgreSQL database that stores short-lived sign-in state and rate-limit counters. Because the client and the gateway are built together, the /login flow is gateway-aware: the client picks up managed settings at sign-in and the gateway enforces policy on every request.
As AWS's Dani Mitchell, a senior generative AI specialist solutions architect, and his co-authors describe it, the gateway is "a self-hosted control plane that gives organizations a single point of control over access, cost, and policy for Claude Code and Claude Desktop." That framing matters because the alternative, at any real headcount, is chaos: one cloud credential per developer, settings pushed to every laptop by hand, and spend that nobody can see until the invoice lands.
The gateway shipped for four upstreams: Amazon Bedrock, Claude Platform on AWS, Google Vertex (through the Gemini Enterprise Agent Platform), and Microsoft Foundry. In every case the model IDs are the same strings you use on the Claude API, claude-sonnet-5 and claude-opus-4-8, with no Bedrock ARNs or inference profiles to wire up.
The problem it solves
Before the gateway, rolling Claude Code past a pilot meant handing each engineer a cloud credential and pushing a managed-settings.json file to every machine over device management. On Google Cloud that looked like setting CLAUDE_CODE_USE_VERTEX=1, pointing at a project, and granting roles/aiplatform.user per person. That works for a handful of engineers and falls apart at scale, because there is no per-developer usage attribution and no easy way to cap spend.
The gateway closes that gap. Onboarding a developer becomes adding them to an identity provider (IdP) group; offboarding becomes removing them, after which their session fails at the next refresh. Nothing sensitive lands on the laptop: no service-account keys, no API keys, no project IDs.
| Task | Without the gateway | With the gateway |
|---|---|---|
| Developer credentials | One cloud credential provisioned per person | Browser SSO; a one-hour token, no static keys |
| Settings distribution | Push managed-settings.json to every laptop |
Policy applied at sign-in, enforced server-side |
| Model access | Whatever each developer configures locally | Central allowlist, re-checked on every request |
| Spend control | Visible only on the monthly bill | Daily, weekly and monthly caps per user or group |
| Offboarding | Rotate or revoke keys manually | Remove from the IdP; session dies within the hour |
The five controls it enforces
The gateway holds five responsibilities. Each replaces something a platform team would otherwise script and maintain on its own.
| Control | What it does | Where the data lands |
|---|---|---|
| Identity | Acts as an OIDC relying party against Google Workspace, Microsoft Entra ID, Okta or any standards-compliant provider; issues a short-lived session token | Your IdP; sign-in state in PostgreSQL |
| Policy | Central managed settings by IdP group: allowed models, tool permissions, environment variables and hooks, re-checked on every /v1/messages call |
gateway.yaml on the server |
| Telemetry | Stamps a claude_code.token.usage metric carrying the verified email and groups from the signed session token, then ships it over OTLP |
A collector you run: CloudWatch, Managed Prometheus, Cloud Monitoring, Grafana or Datadog |
| Routing | Holds the upstream credential and forwards inference to Bedrock, Claude Platform on AWS or Vertex, with optional failover across regions or accounts | Your cloud account; inference stays in your perimeter |
| Spend caps | Daily, weekly and monthly limits per organisation, group or user; returns a 429 once a cap is hit | A token ledger in PostgreSQL |
Two details make the policy and telemetry controls trustworthy rather than cosmetic. Policy is enforced on the server: editing the local managed-settings.json on a laptop changes nothing, because the gateway re-checks the allowed-model list on every call, and rule updates reach the whole fleet within the hour. Telemetry uses the identity from the signed session token, not the client-set OTEL_RESOURCE_ATTRIBUTES a developer could spoof, so per-user attribution actually holds up.
The one honest caveat is on cost. Spend caps meter tokens at list price, which means committed-use discounts and negotiated rates do not show up in the gateway's numbers. The Anthropic and Google Cloud engineers who wrote the Vertex guide are blunt about this: treat the cap as a runaway-usage guardrail, not a substitute for bill reconciliation. If you already model coding-agent spend, our note on how to route traffic between models to control API spend pairs well with a hard cap here.
Deploying on AWS with Amazon Bedrock
On AWS the gateway reads a single gateway.yaml at startup, with secrets kept in environment variables. The Bedrock upstream uses the container's IAM role, so there are no static credentials to manage. To route through Claude Platform on AWS instead of Bedrock, you swap the upstreams block:
upstreams:
- provider: anthropicAws
region: us-east-1
workspace_id: wrkspc_...
auth: {} # AWS default credential chain (IAM role)
The container runs stateless on Amazon ECS, Amazon EKS or Amazon EC2, sits behind an internal Application Load Balancer with a TLS certificate from AWS Certificate Manager, and uses Amazon RDS for PostgreSQL to store short-lived sign-in state. Developers reach it over your private network, and the gateway calls the upstream with its IAM task role. Choose Bedrock when data must stay inside the AWS security boundary; choose Claude Platform on AWS when you want Anthropic's native platform behaviour with AWS authentication and billing.
Deploying on Google Cloud with Vertex
On Google Cloud the same binary runs as a stateless container on Cloud Run (Google Kubernetes Engine works equally well), with Cloud SQL for PostgreSQL holding the device-code sign-in state and the spend ledger. The setup is four steps: enable the Agent Platform, Cloud SQL and Secret Manager APIs and create a claude-gateway service account with roles/aiplatform.user; write gateway.yaml; deploy to Cloud Run; then onboard developers through managed settings.
listen:
port: 8080
public_url: https://claude-gateway.example.internal
oidc:
issuer: https://accounts.google.com # Google Workspace
client_id: <client-id>.apps.googleusercontent.com
client_secret: ${OIDC_CLIENT_SECRET} # from Secret Manager
allowed_email_domains: [yourco.com]
upstreams:
- provider: vertex
region: us-east5
project_id: <your-project>
auth: {} # application default credentials via the Cloud Run service account, no key file
The deploy runs the gateway with its own OIDC, so clients carry no Google Cloud token of their own:
gcloud run deploy claude-gateway \
--service-account="claude-gateway@${PROJECT_ID}.iam.gserviceaccount.com" \
--set-secrets=/etc/claude/gateway.yaml=gateway-config:latest \
--ingress=internal \
--no-invoker-iam-check
To onboard, push forceLoginMethod: "gateway" and forceLoginGatewayUrl to developer machines through your device-management channel, or write the file by hand at /Library/Application Support/ClaudeCode/managed-settings.json on macOS or /etc/claude-code/managed-settings.json on Linux for a first trial. The developer runs claude /login, confirms the pre-filled gateway URL, signs in through Google Workspace in the browser, and is connected. Inference stays inside the Google Cloud project, so quota, the data processing agreement and billing are unchanged.
AWS vs Google Cloud: which upstream
Both deployments give you the same five controls; the difference is the surrounding plumbing and where inference runs. If you are building agents on top of this, our guide to enterprise AI agent development covers the layers above the gateway.
| Dimension | Amazon Bedrock (AWS) | Google Vertex (Google Cloud) |
|---|---|---|
| Compute host | ECS, EKS or EC2 behind an internal ALB | Cloud Run or GKE, internal ingress |
| State store | Amazon RDS for PostgreSQL | Cloud SQL for PostgreSQL |
| Upstream value | provider: anthropicAws or Bedrock |
provider: vertex, region such as us-east5 |
| Credential model | Container IAM role, no static keys | Cloud Run service account, application default credentials |
| Telemetry sink | CloudWatch or Managed Prometheus | Cloud Monitoring, Grafana or Datadog |
| Where inference runs | Inside your AWS account or Anthropic | Inside your Google Cloud project |
The practical rule is boring but correct: run the gateway on the cloud you already operate. The state database, identity integration and telemetry collector all reuse services your platform team already runs, so the incremental work is small. Microsoft Foundry is the fourth supported upstream if your organisation standardises on Azure.
What the gateway does not do
The gateway governs access, policy, routing, telemetry and spend. It does not sandbox what an agent can do inside your repository or your network, so tool permissions and the review of agent actions still matter. Its spend numbers are at list price, which is a ceiling for runaway usage, not a finance-grade cost report. And it does not judge the quality of the code your agents produce. For that, treat rollout as a measurement problem and track output the way you track any change, which is the argument in our piece on how to measure AI coding agent output with DORA metrics and CloudWatch. Because agents run tools, keep your prompt-injection guardrails in place as well; the gateway does not replace them.
India-specific considerations
For teams in India the gateway removes a specific headache. Instead of distributing cloud keys to every engineer across offices and contractors, access flows through a single IdP, and the one-hour token means a departing contractor loses access the same day. Inference stays in the region you configure, which helps when you are aligning data handling with the Digital Personal Data Protection Act, 2023. On cost, the caps are a useful guardrail, but Indian teams should still watch the rupee value of token spend rather than the list-price meter; our comparison of Claude pricing in rupees for Indian teams shows how quickly the numbers move at scale. Spend caps expressed per group let a GCC or a services team give a pilot squad a small monthly budget before a wider rollout.
How eCorpIT can help
eCorpIT is a Gurugram technology organisation, founded in 2021, with CMMI Level 5 and MSME certification and partner relationships with AWS, Microsoft and Google. Our senior engineering teams deploy the Claude apps gateway on your Bedrock or Vertex account, wire it to your OIDC provider, set group-scoped model and tool policies, and connect telemetry to the collector you already run, so a Claude Code rollout stays governed from day one. We also help teams model and cap AI spend as part of a broader cloud FinOps engagement. To scope a gateway deployment or an enterprise Claude Code rollout, contact us.
FAQ
References
- Introducing Claude apps gateway for AWS — AWS Machine Learning Blog, July 8, 2026.
- Introducing the Claude apps gateway for Amazon Bedrock and Google Cloud — Claude by Anthropic.
- Get started with the Claude apps gateway for Google Cloud — Google Cloud Blog, July 1, 2026.
- Claude apps gateway — Claude Code documentation.
- Claude apps gateway on Google Cloud — Claude Code documentation.
- Claude apps gateway configuration reference — Claude Code documentation.
- Introducing Claude Sonnet 5 — Anthropic, June 30, 2026 (pricing and model IDs).
- Claude pricing — Anthropic.
- AWS centralizes access, spending, and governance for Claude — Help Net Security, July 9, 2026.
- AWS Ships Claude Apps Gateway as Self-Hosted Control Plane for Claude Code and Claude Desktop — InfoQ.
- Anthropic Adds Enterprise Gateway to Simplify Claude Code Access on AWS and Google Cloud — DevOps.com.
_Last updated: July 26, 2026._
