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 supported Runtime calls; gateway audit records for Mantle |
| 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 — to reduce the risk of concurrent requests exceeding the budget before final usage 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
Bedrock invocation logging covers supported calls through bedrock-runtime, including Responses and Chat Completions. It does not capture calls through bedrock-mantle. For Mantle, define the gateway records required for audit; token and cost records alone are not request/response capture.
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
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?
AWS currently states that Bedrock does not share customer content with model providers. Retention depends on the model and account or project settings. Models such as Claude Fable 5 and Fable 5.1 require aws_review, allowing retention for up to 30 days and review by AWS. For ZDR, enforce none and verify the model’s allowed_modes. See the current Bedrock retention controls.
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.
