AWS introduced Claude apps gateway for AWS on July 8, 2026: a self-hosted control plane that puts identity, policy, telemetry, routing, and spend for Claude Code and Claude Desktop behind one gateway, instead of leaving each developer laptop to manage its own cloud credentials and model access. When the platform vendor ships that as a first-party product, it says something about how coding agents are meant to be run: not tool by tool on individual laptops, but through a governance layer the organization owns. For most teams the question is no longer whether developers can reach frontier models. It is where identity, cost, and audit live once those agents are everywhere.
Our Amazon Bedrock gateway started with Claude Code, then the requirement widened. Engineering teams do not live in one AI surface; they move between terminal agents, desktop assistants, and tools that speak OpenAI-compatible APIs. So we extended the same control plane across Claude Code, Claude Desktop in third-party Bedrock mode, and Codex, all routed through governed AWS infrastructure. This is a report on what that took, and where the design decisions actually mattered.
A control plane is becoming the default
A gateway like this becomes the single control point: developer machines stop holding long-lived cloud credentials, and model access stops depending on whatever each local tool happens to support. The gateway holds the upstream credential, centralizes OIDC sign-in and managed policy, routes to Amazon Bedrock or Claude Platform on AWS, enforces spend caps, and issues short-lived tokens to clients — all on infrastructure you run. A platform vendor shipping this first-party is the signal that matters: it moves the pattern from something a few teams build by hand to the expected way to run coding agents inside an organization. Our own gateway follows the same thesis; what differs is the range of client surfaces it covers, not the principle.
| Question | Practical answer |
|---|---|
| What is becoming standard? | A self-hosted control plane for coding agents — centralized identity, managed policy, telemetry, routing, and spend caps — now shipped as a first-party AWS product for Claude Code and Claude Desktop. |
| What does Elevata add? | The same governed access pattern extended across Claude Code, Claude Desktop 3P on Bedrock, and Codex. |
| What should not be inferred? | Codex is not part of the Claude apps gateway for AWS announcement. It is Elevata's extension of the same architectural thesis. |
Where Elevata extends it
Same control plane, wider reach. The table below reads as a set of design decisions: where our gateway matches AWS's pattern, and where it goes further to cover a third client surface.
| Area | Claude apps gateway for AWS | Elevata gateway |
|---|---|---|
| Primary clients | Claude Code and Claude Desktop | Claude Code, Claude Desktop 3P, and Codex |
| Identity | OIDC identity boundary, short-lived tokens | OIDC identity boundary, short-lived tokens |
| Claude Code path | Gateway-aware Claude flow | Native Bedrock Runtime routing |
| Claude Desktop path | Gateway-managed Claude apps | Third-party Bedrock provider mode |
| Codex path | Not the focus of the announcement | OpenAI Responses-compatible endpoint routed to Bedrock |
| Credentials | Gateway holds the upstream credential | Gateway holds the upstream credential; the task role signs Bedrock requests |
| Spend control | Gateway spend caps | Precheck, commit, reservations, and per-principal plus global stream caps |
| Audit posture | Customer-controlled telemetry | Bedrock invocation logs for native paths; gateway usage records for the rest |
| Operational hardening | Product gateway path | Keepalives, slow-body handling, exception frames, streaming telemetry, and real e2e smoke tests |
How the architecture works
All three clients hit the same gateway behind an OIDC identity boundary; what changes per client is the protocol the gateway has to speak and the route it exposes.
For Claude Code, we route native Bedrock Runtime requests. We chose the native path over a Claude-aware flow because it keeps the client on the protocol it already speaks: the gateway authenticates the request, checks spend state, signs the Bedrock call with the task role, forwards to Amazon Bedrock, and records usage — no client-side cloud credentials involved.
For Claude Desktop, we use its third-party Bedrock provider mode. The same gateway speaks its third-party Bedrock provider protocol, so Chat, Cowork, and Claude Code for Desktop reach Bedrock without a Claude.ai account or local AWS credentials. A no-argument credential helper hands the client short-lived tokens, and managed Desktop configuration gates local tools such as Bash to company policy.
For Codex, we expose an OpenAI Responses-compatible endpoint so Codex can treat the gateway as an ordinary OpenAI-compatible provider. Behind that endpoint the gateway authenticates the user, applies the same spend controls, mints a short-lived Bedrock token from the task role, and forwards to Bedrock. This is the surface AWS's announcement does not cover, and the reason we built it: teams were already asking for it.
The payoff is one access plane for different clients: each tool keeps its own protocol and expectations, while identity, cost, routing, and audit stay centralized — and observable, as the dashboard above shows.
What we learned
1. Short-lived tokens beat local credentials
The most important gain is not cosmetic. When laptops stop carrying direct cloud credentials, the company reduces leakage surface, simplifies offboarding, and forces model access through a point where policy and cost can be enforced.
2. Streaming is a reliability concern, not a UI detail
The hard part was not merely calling Bedrock. It was preserving each client's expectations during streaming. SSE and AWS eventstream paths need keepalives, anti-buffering headers, stream concurrency caps, slow request-body handling, bounded telemetry parsing, and in-band exception frames. Without that, gateway failures can look like clean empty responses to the client.
3. Spend control needs to happen before and during the call
Logging spend after completion is necessary but not enough. The gateway prechecks spend before forwarding, records usage after completion, accounts for cache-read and cache-write token buckets where available, and reserves estimated spend for active streams — so concurrent requests cannot outrun a cap before final accounting arrives. The dashboard at the top of this article is the output of that accounting: it is how we see, per model, that cache-heavy Claude Code traffic runs at a fraction of the cost per request of lower-cache clients.
4. Client policy is not the same as gateway enforcement
Managed settings in Claude Code or Claude Desktop are useful for experience, standardization, and reducing mistakes. But they live on the client, where a determined user can work around them. Critical controls have to be enforced at the gateway instead: identity, allowed models, spend, upstream routing, stream limits, and failure behavior.
5. Audit has to respect the endpoint, not just the provider
A common trap is assuming every call to Bedrock passes through the same audit plane. It does not. Native Bedrock Runtime traffic can use Bedrock invocation logging as its content-and-metadata baseline; a Responses-compatible path reconciles against the gateway's own usage records until invocation-logging coverage is equivalent. In an AI gateway, endpoint and protocol decide what your audit trail actually contains — design for that difference rather than papering over it.
6. E2E smoke tests need real clients
A synthetic HTTP test does not prove that Claude Code, Claude Desktop, or Codex will behave correctly. Smoke tests have to exercise login, the credential helper, Runtime routes, Desktop provider routes, the Responses-compatible endpoint, streaming, and the error paths each client actually hits — because each one fails differently.
Frequently asked questions
Has AWS endorsed Elevata's implementation?
No. This article describes an Elevata implementation aligned with the architectural pattern AWS announced. It does not imply endorsement, certification, or approval by AWS.
Is Codex part of Claude apps gateway for AWS?
No. AWS's announcement focuses on Claude Code and Claude Desktop. Codex support is Elevata's extension: an OpenAI Responses-compatible endpoint that the gateway routes to Bedrock.
Does routing through Bedrock expose our prompts to the model providers?
No. Amazon Bedrock runs each model in an isolated deployment account and applies zero data retention by default, so the model providers cannot see your prompts or completions and AWS does not store them. The exception today is Claude Fable 5, which requires opting in to retaining traffic and sharing it with Anthropic for abuse review — exactly the kind of decision the gateway exists to make and enforce, model by model.
Does adding a client mean building a new gateway?
No. The identity boundary, spend accounting, and audit are shared; each new client adds a protocol adapter and a route, not a parallel control plane. That is why extending from Claude Code to Claude Desktop and Codex did not multiply the surface we have to secure.
Does this remove the need for client policies?
No. Client-side managed policies still matter for experience and defaults. The difference is that critical decisions are also enforced at the gateway, where users cannot simply bypass local configuration.
Where governance lives
The decision this forces is not which AI tool to standardize on — teams will keep using several. It is where governance lives. Put identity, credentials, cost, audit, and routing in one gateway, and you can add client surfaces without turning each laptop into an island of credentials and local policy.
If your team is weighing Claude Code, Claude Desktop, Codex, or internal Bedrock agents, Elevata can help design the first gateway and validate it with real clients.
Related reading: Claude Code on AWS, Codex and OpenAI Agents on Amazon Bedrock, and governed AI agent sandboxes on AWS.
