Running Claude Apps Gateway on AWS - What the Gateway Holds and Enforces, What Stays on Developer Machines, and Where the Worked Example Stops

First Published: 2026-10-14
Last Updated: 2026-10-14

Claude Code includes a server called the Claude apps gateway. This gateway is a self-managed server that the organization places between a developer's Claude Code and the provider of the models. It is started using the command claude gateway --config gateway.yaml. Claude Code's documentation describes the role of the Claude apps gateway as follows:

The gateway holds the upstream credential, enforces model access and managed settings by IdP group, and relays usage telemetry to your own observability stack.

Developers sign in through their organization's identity provider (IdP) and receive short-lived tokens from the gateway. Developers will no longer need to hold AWS credentials or API keys. Instead, the management of upstream credentials, the signing key for session tokens, the IdP client secret, and the database connection details will be shifted to the gateway and its surrounding AWS components. Anthropic has published a worked example page for running the Claude apps gateway on AWS. The page begins with the following disclaimer:

The configuration is a working example for customer-managed infrastructure rather than a supported production deployment; use it to see how the pieces fit together before adapting it to your own environment.

This article maps, line by line, which of four parties holds, enforces, or does not hold the upstream credential, sessions, settings, and telemetry when you run the Claude apps gateway on AWS: the developer machine, the gateway, the AWS pieces, and the IdP. Using what the sources say, it also shows how long the access of a developer who leaves the organization can continue, and which parts of Anthropic's AWS worked example stay an example. Where the sources disagree, and where a statement was not found after searching, this article shows both statements with the verification date. This article is not a step-by-step construction guide, nor is it an endorsement of this particular configuration. This article did not create any AWS resources and did not start the gateway.

Related articles on this site:

1. Introduction — Scope, Version, and Verification Date
2. Vocabulary and Table Columns
3. What the Developer Machine, the Gateway, the AWS Pieces, and the IdP Each Hold
4. Sign-In, and How Long It Takes for Access to End
5. Enforcing Models and Settings, and the Routes That Skip the Gateway
6. The Pieces of Anthropic's AWS Worked Example, and What Stays an Example
7. Upstreams on AWS — Amazon Bedrock, the Mantle Endpoint, and Claude Platform on AWS
8. Where the Sources Disagree and Where No Statement Was Found
9. Frequently Asked Questions about Running Claude Apps Gateway on AWS
10. Summary
11. References

1. Introduction — Scope, Version, and Verification Date

This chapter sets the scope of this article, the verification date and version, and the sources read. It then separates words that refer to different things under the same spelling.

1.1 Scope of This Article, and What It Does Not Cover

This article addresses the following topics:

When you run the Claude apps gateway on AWS, what each of the four parties holds, enforces, relays, and does not hold: the developer machine, the gateway, the AWS pieces, and the IdP (Section 3).
Developer sign-in, and how long it takes for access to end (Section 4).
Enforcing model access and managed settings per IdP group, and how the sources treat routes that skip the gateway (Section 5).
The pieces of Anthropic's AWS worked example, and what stays an example (Section 6).
The differences between Amazon Bedrock, the Mantle endpoint of Amazon Bedrock, and Claude Platform on AWS (Section 7).
Places where the sources disagree, and statements that were not found (Section 8).

This article does not cover the following:

The general mechanism for directing Claude Code to any gateway using ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. This is covered in Section 4.3 of the existing article Claude Code on Pay-As-You-Go API Billing.
What an LLM gateway that translates formats drops. This is covered in the existing article What a Translating LLM Gateway Drops. Section 1.3 of that article says that the Claude apps gateway is a different thing.
Gateways placed in front of MCP servers and layers of control for Claude Code. This is covered in the existing article Hardening and Governance Guide for Claude Code and Claude Desktop.
Configuring Claude Code to be used through an internal proxy. This is covered in the existing article Practical Guide to Deploying Claude Code and Claude Desktop Behind a Corporate Proxy.
The differences between the bedrock-runtime and bedrock-mantle endpoints in Amazon Bedrock. This is covered in the existing article Amazon Bedrock Inference Endpoints and API Keys.
The worked example for Google Cloud, the Microsoft Foundry and Anthropic API upstreams, and the details of Claude Desktop settings.
The spend limits feature, and settings tied to usage amounts. This article does not discuss amounts of money.

1.2 Verification Date, Version, and Materials Reviewed

This article's content was verified on October 13, 2026, using the following materials:

Claude Code Documentation: The entry page for the Claude apps gateway, the configuration reference page, the deployment and operations page, the worked example page, the gateway overview page, the Other LLM gateways page, and the settings reference page (titled "All settings").
Claude Code CHANGELOG: The latest version as of October 13, 2026, is marked with the heading ## 2.1.296.
Amazon Bedrock User Guide: The page detailing the Anthropic Claude Messages API requests and responses, the entry page for the Messages API, and the model card for Claude Opus 5.5.
Claude Platform on AWS User Guide: The page "What is Claude Platform on AWS?" and the page comparing Claude Platform on AWS and Amazon Bedrock.
Elastic Load Balancing User Guide: The section on IP address types for Application Load Balancers.
Amazon RDS User Guide: The page on SSL for RDS for PostgreSQL.

The Claude Code documentation pages do not include version numbers or dates. This article references the pages read on October 13, 2026, alongside the latest version in the CHANGELOG (## 2.1.296). The documentation describes the gateway's protocol as follows:

Breaking changes to the protocol are announced in advance, but indefinite backwards compatibility isn't guaranteed.

The available settings are expanding with each version. For example, the CHANGELOG for version ## 2.1.295 mentions the addition of a list of models for each gateway upstream, as well as the ability for developers to specify the gateway in their user settings. The CHANGELOG for ## 2.1.296 notes the addition of the code key to managed.policies[]. When you read this article, reread the documentation for newer versions (Section 8.3).

No indication of the release status, such as beta, preview, or GA, was found on the Claude apps gateway pages (Section 8.2). This article does not include any information regarding the status.

1.3 Words That Share the Same Spelling but Refer to Different Things

In this article, the same word is used to refer to different things. To avoid misreading, this article separates them first.

gateway (the 6 distinctions made in this article): (1) Claude apps gateway. This is the subject of this article, a server that is launched with claude gateway. When this article refers to "gateway," it refers to this. (2) An LLM gateway that Claude Code is pointed at with ANTHROPIC_BASE_URL. Claude Code's documentation covers it on the Other LLM gateways page. (3) The MCP gateway, placed in front of the MCP server. (4) The Gateway for Amazon Bedrock AgentCore. (5) Amazon API Gateway. (6) Cloud gateway. This is the name of the /login screen for Claude Code, and is the screen for signing in to (1). This article will refer to (2) through (5) by their respective names.
token (the 4 distinctions made in this article): (1) Gateway session token. This is a bearer token signed by the gateway using session.jwt_secret and provided to the developer machine; it is a JSON Web Token (JWT) using the HS256 algorithm. (2) IdP token. This is the ID token and refresh token returned by the IdP to the gateway. (3) Upstream credentials. These are AWS credentials or API keys that the gateway presents to upstreams such as Amazon Bedrock. This article will refer to these as "upstream credentials" rather than simply "token." (4) Authentication value for the OTLP destination. This is the value sent by the gateway in the header to the telemetry destination. When this article uses the term "token," it will specify which type of token is being referenced.
managed settings (the 3 distinctions made in this article): (1) Client-side managed settings. These are files (e.g., managed-settings.json), macOS plist files, or Windows registry policies that organizations place on developer machines using MDM or similar methods. (2) Managed settings distributed by the gateway. These are the settings distributed by the gateway's managed.policies[] and provided to the signed-in Claude Code. (3) Server-managed settings. These are settings distributed through the claude.ai management console. The gateway's entry page says that (2) takes the place of (3).
upstream: This refers to the destination to which the gateway forwards inference requests. This article discusses Amazon Bedrock, the Mantle endpoint of Amazon Bedrock, and Claude Platform on AWS.
revocation: In this article, revocation means that a developer can no longer use models through the gateway. Turning off an account in the IdP is called disabling it in the IdP.

2. Vocabulary and Table Columns

This chapter defines the columns and values used in the tables within this article. The columns and values are borrowed from Sections 2.3 and 2.4 of the existing article How AWS Lambda Authenticates to Apache Kafka, and the additional values introduced in this article will be defined in this chapter.

2.1 Common Columns

The credential table in Section 3 shares the following five columns:

Held By: Who holds the long-lived credential or secret
Refreshed By: Who refreshes the short-lived token or credential
Presented As: What it is presented as, to the other side
What You Configure: What the user configures
Where the Source Says So: The source for the row, given as the page title and section name

The first column of the table is Credential or Secret. This column describes the type of credential or secret.

2.2 Values for `Held By`, `Refreshed By`, and `Presented As`

Values with the same meaning use the spelling of the existing article as is. Values that this article adds are not marked; instead, their meaning is defined here.

The possible values for Held By are:

Secrets Manager (your secret): Kept in an AWS Secrets Manager secret that the user creates. On the Amazon ECS track of the AWS worked example, the task execution role reads it and passes it to the gateway container as an environment variable (Section 6.2).
Not stored (the ECS task role or the EKS IRSA role): The secret is not stored anywhere. The gateway utilizes either the Amazon ECS task role or an Amazon EKS IAM Roles for Service Accounts (IRSA) role.
The developer machine: The developer machine holds it.
The source does not say.: The documentation does not specify.

The possible values for Refreshed By are:

The AWS SDK in the gateway: The AWS SDK inside the gateway refreshes the credentials internally.
Claude Code on the developer machine: Claude Code on the developer's machine refreshes the gateway's session token before its expiration.
The gateway: The gateway presents the IdP's refresh token to the IdP and refreshes the IdP tokens.
Not applicable: There is no short-lived token to refresh. The user replaces the value, and that operation goes in the What You Configure column.
The source does not say.: The documentation does not specify.

The possible values for Presented As are:

Signed with the gateway's AWS credentials: The gateway signs each request to the upstream using its own AWS credentials.
Gateway bearer token (HS256 JWT): Claude Code on the developer machine presents the gateway's session token to the gateway as a bearer token.
OIDC client secret (to your IdP): The gateway presents its client secret to the IdP's token endpoint.
Database credentials (to PostgreSQL): The gateway presents its connection credentials to PostgreSQL.
Not presented: Nothing is presented.
The source does not say.: The documentation does not specify.

2.3 When the Source Does Not Say, and When the Sources Disagree

In each table cell, this article writes only what the source says, or a summary of it. Where the source does not say something, the cell reads The source does not say. Before writing that, this article searches the full text of the source, the pages its links point to, and other pages from the same provider. Those other pages are the Claude apps gateway entry page, the configuration reference, the deployment and operations page, the AWS worked example page, the settings reference page, and the CHANGELOG. The searches use the words of the row's subject and the terms gateway, ttl, revocation, Pod Identity, and anthropic-beta.

When the sources disagree, this article places both statements side by side with their sources and leans toward neither. The English for this is always the sources disagree. Section 8.1 collects the places where the sources disagree in this article. Section 8.2 collects the statements that were not found after searching, with the places and terms searched. That a statement was not found does not mean that the behavior does not exist.

3. What the Developer Machine, the Gateway, the AWS Pieces, and the IdP Each Hold

This chapter shows where the credentials and secrets are when you put a gateway in place, and then what each of the four parties holds, enforces, relays, and does not hold.

3.1 What Leaves the Developer Machine When You Put a Gateway in Place

The gateway entry page lists credentials as the first reason for implementing a gateway, and states:

Credentials: the upstream API key or cloud credential lives only in your infrastructure. Developers authenticate with corporate SSO and receive short-lived bearer tokens, so offboarding happens in your IdP.

The AWS worked example page also says that, with Amazon Bedrock as the upstream, no model credentials are placed on developer machines.

Their Claude Code sessions reach Claude models on Amazon Bedrock through the gateway's IAM role, so no model credentials land on developer machines.

What stays on the developer machine is the gateway session token and the client-side managed settings. The gateway entry page says that in a Claude Code session signed in to the gateway, the gateway session token is the session's only credential. An earlier claude.ai login and Anthropic profiles are not used while signed in.

The threat model section of the deployment and operations page builds on this arrangement. It states that the developer's laptop is not treated as a trusted device, and that the developer only possesses a short-lived JWT, not the upstream keys.

Figure 1 shows what flows between the four parties and who holds what.

What the Claude Apps Gateway Holds, and What Stays on the Developer Machine

3.2 Credentials and Secrets Table

The following table lists the credentials and secrets of the AWS worked example, with Amazon Bedrock as the upstream.

Credential or Secret	Held By	Refreshed By	Presented As	What You Configure	Where the Source Says So
Upstream credential (Amazon Bedrock)	`Not stored (the ECS task role or the EKS IRSA role)`	`The AWS SDK in the gateway`	`Signed with the gateway's AWS credentials`	`auth: {}` in `upstreams`. Three actions, including `bedrock:InvokeModel`, on the task role or the IRSA role	Deploy Claude apps gateway on AWS, Write gateway.yaml; configuration reference, `upstreams`
Gateway session token	`The developer machine`	`Claude Code on the developer machine`	`Gateway bearer token (HS256 JWT)`	`session.ttl_hours`. The default is 1	Configuration reference, `session`; entry page, Connect developers
Session token signing key (`session.jwt_secret`)	`Secrets Manager (your secret)`	`Not applicable`	`Not presented`	A value of at least 32 bytes. To replace it, add a new value to the beginning of the array	Deploy Claude apps gateway on AWS, Store secrets; deployment and operations page, JWT secret rotation
IdP client secret (`oidc.client_secret`)	`Secrets Manager (your secret)`	`Not applicable`	`OIDC client secret (to your IdP)`	The value of the OAuth client registered with your IdP	Deploy Claude apps gateway on AWS, Store secrets; configuration reference, `oidc`
PostgreSQL connection string (`store.postgres_url`)	`Secrets Manager (your secret)`	`Not applicable`	`Database credentials (to PostgreSQL)`	A connection string with `sslmode=verify-full`	Deploy Claude apps gateway on AWS, Provision Amazon RDS for PostgreSQL
IdP tokens (ID token and refresh token)	`The source does not say.`	`The gateway`	`The source does not say.`	`oidc.scopes`, whose default includes `offline_access`	Configuration reference, `oidc`; deployment and operations page, Identity provider setup

The Refreshed By cell of the upstream credential reads The AWS SDK in the gateway because the upstreams section of the configuration reference says the following:

Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry clients are built once at startup, and their SDKs refresh credentials internally, so rotating cloud credentials doesn't require a restart.

Similarly, the Refreshed By cell of the IdP tokens reads The gateway because the description of oidc.scope_on_refresh states that the gateway exchanges a refresh token (when the gateway exchanges a refresh token). No statement was found on where the gateway holds the IdP tokens (Section 8.2). The outage behavior section of the deployment and operations page says that session refreshes do not touch PostgreSQL (Section 4.5).

The Presented As cell of the session token signing key reads Not presented because the gateway only uses this value to sign and validate its own session tokens; it is not presented to anyone else.

3.3 What Each of the Four Parties Holds, Enforces, Relays, and Does Not Do

The following table lists what each of the four parties holds, enforces, relays, and does not do. The AWS pieces row describes the pieces of the AWS worked example. The basis for the cells follows the table, row by row.

Party	Holds	Enforces	Relays	Does Not
Developer machine	The gateway session token. The fingerprint of the gateway's TLS certificate, recorded at the first connection. The client-side managed settings	When the client-side managed settings include `allowedProviders`, Claude Code refuses sessions not set up for a Cloud gateway (Section 5.4)	Claude Code sends its OTLP exports to the gateway	Does not hold the upstream credential
Gateway	The right to use the upstream credential. The session token signing key. The IdP client secret. `gateway.yaml`, including `managed.policies[]`	Model access per IdP group (requests for models that are not allowed get 400). Selecting and delivering managed settings per group. When set, the email domains and groups of the people who may sign in	Forwards inference requests to the upstream. Forwards OTLP exports to the configured destinations as received	Does not log prompt or completion content. Does not store telemetry. Keeps no user directory. Has no way to revoke a single session
AWS pieces	The three Secrets Manager secrets. In RDS for PostgreSQL, device sign-in state and rate-limit counters. The permissions of the task role or the IRSA role	What can reach the gateway, through security groups and the internal Application Load Balancer (ALB)	The ALB relays HTTPS between the developer machine and the gateway	The worked example page describes no setting that closes the direct route from developer machines to the upstream (Section 5.4)
IdP	Developer accounts and groups	Assignment of the OAuth client (the source says to assign it to the users or groups who should have gateway access). A developer disabled in the IdP loses the gateway session at the next refresh	Passes the developer's email address and groups to the gateway in the ID token or from the userinfo endpoint	Does not issue gateway session tokens

The basis for this table is as follows:

Developer machine row: The Connect developers section of the entry page says that Claude Code fingerprints the gateway's TLS leaf certificate on the first connection and pins it per hostname. The pin is checked again at sign-in, on session refreshes, and on managed settings fetches, and is not used for inference requests. Requests that go through an HTTPS proxy skip this check.
Gateway row, Holds: The threat model section of the deployment and operations page says that the gateway host holds the upstream credential and delivers managed settings to developers, so control over the gateway's configuration is comparable to control over your MDM.
Gateway row, Enforces: The What's enforced on developers section of the entry page says that requests for models that are not allowed return 400, and that the /model picker is narrowed to the allowed models. The managed section of the configuration reference says that availableModels is also enforced on the server-side /v1/messages endpoint.
Gateway row, Does Not: The entry page says The gateway doesn't log or store prompt or completion content. The AWS worked example page says that the gateway does not store telemetry (doesn't buffer, aggregate, or store telemetry). The managed section of the configuration reference says that the gateway keeps no user directory (The gateway keeps no user directory of its own.). Section 4.4 covers per-session revocation.
AWS pieces row: The store section of the configuration reference says that PostgreSQL holds device grants and rate-limit counters. Using the spend limits feature adds PostgreSQL tables, but this article does not cover that feature.
IdP row: The Identity provider setup section of the deployment and operations page says to register an OAuth client with the IdP and assign it to the users or groups who should have gateway access. Separately, the oidc section of the configuration reference says that you can narrow who may sign in based on email address domains and groups using the gateway's allowed_email_domains and allowed_groups settings. The gateway performs both of these checks, so they are listed in the gateway row of this table.

3.4 What Telemetry Transmits and What the Organization Sees

The gateway relays OTLP telemetry. The gateway's entry page describes what the organization sees as follows:

Usage telemetry carries the developer's identity, token counts, model, and latency to the organization's collector. The gateway doesn't log or store prompt or completion content. Whether richer telemetry such as logs and traces is collected, which can include commands and file paths, is the organization's per-destination choice.

For each destination, you can choose whether to send metrics, logs, and traces. The default is to send only metrics. The telemetry section of the configuration reference says that logs and traces can carry Bash commands, tool inputs, and file paths, and says to turn them on only for destinations with the access controls and retention policy that such data needs.

Claude Code stamps the IdP identity attributes (user.id, user.email, user.groups) on the exports of sessions signed in through /login. The gateway relays telemetry only to the destinations that the organization lists in telemetry.forward_to. The data flow table on the deployment and operations page says that the gateway sends none of the telemetry, identity, managed settings, or audit logs to Anthropic. Inference requests go to Anthropic only when the Anthropic API is configured as an upstream.

4. Sign-In, and How Long It Takes for Access to End

This chapter shows how developers sign in to the gateway, the lifetime of the gateway session token, and how long it takes for access to end.

4.1 IdP Requirements — OIDC Only, One Issuer

The gateway only supports Identity Providers (IdPs) that adhere to OpenID Connect (OIDC). The table outlining prerequisites on the entry page provides examples such as Okta, Microsoft Entra ID, Google Workspace, Keycloak, and Dex, and states that other OIDC-compliant IdPs are also acceptable. The same table says the following:

SAML and LDAP aren't supported.

The availability and limitations table on the entry page says that multiple OIDC issuers are not supported.

One issuer per gateway. Run separate instances

For organizations that only utilize SAML IdPs, the same table indicates that an OIDC bridge should be placed in front. The IdP names listed in the prerequisites table are examples. This article does not verify individual IdPs.

4.2 Sign-In Process

The developer sign-in process is divided into two stages. The threat model section of the deployment and operations page says the following:

The CLI-to-gateway leg uses the RFC 8628 device grant, and the gateway's authorization-code exchange with the IdP runs PKCE in the default configuration, so an intercepted IdP authorization code is useless.

From the Cloud gateway screen of /login, Claude Code on the developer machine asks the gateway for a device sign-in. The developer opens the gateway's verification page in a browser and signs in to the IdP. The gateway receives an ID token from the IdP and reads the email address and groups. The gateway then issues its own session token and passes it to the developer machine.

This sign-in process assumes that a user will open a browser. The entry page states that there is no service-token flow for unattended CI pipelines, and says to configure such pipelines against the upstream directly. On a machine where a developer has signed in, claude -p runs and Agent SDK sessions also use the gateway session, and the gateway's policy applies to them.

4.3 The Session Token Lifetime — 1 Hour by Default, and 8 Hours in the Worked Example

The lifetime of the gateway session token is set by session.ttl_hours. The session section of the configuration reference gives the default as 1. The entry page describes the time before access is terminated for developers who have left the company, as follows:

Deprovision a user and their gateway access expires within the session lifetime, one hour by default.

The gateway.yaml in the entry page's quickstart also sets ttl_hours to 1.

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # also bounds revocation latency on IdP deprovision

The gateway.yaml on the AWS worked example page sets ttl_hours to 8.

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}              # EKS: ${file:/secrets/jwt-secret}
  ttl_hours: 8                                   # bounds deprovision latency; lower
                                                 # toward 1 for tighter revocation

The default is 1, and 8 is the value that the worked example chose. The worked example's comment says to lower it toward 1 for tighter revocation. This article does not say which value to use.

4.4 Three Ways Access Ends

The gateway verifies the gateway session token locally with the signing key. The JWT secret rotation section on the deployment and operations page states:

Rotation is also the only way to force sessions out before they expire: bearer tokens validate locally against the JWT secret, so there is no per-session revocation. Replacing the secret outright, without keeping the old one in the array, invalidates every outstanding session at once. For individual offboarding, deprovision the user in your IdP; their session ends within ttl_hours.

From this statement, the ways access ends split into three:

Stopping one developer: Disable the developer in the IdP. The next session refresh fails, and the session ends within ttl_hours. The What's enforced on developers section of the entry page also says that the session of a user disabled in the IdP expires within ttl_hours when the next refresh fails.
Stopping everyone at once: Replace the signing key without keeping the old value in the array. Every session issued up to that point becomes invalid. The deployment and operations page says this is the only way to force sessions out before they expire.
The developer signs out: /logout removes the gateway credential from the developer machine. The entry page says that the gateway in the claude executable does not advertise a revocation_endpoint, so a sign-out ends the session only on that developer's machine.

The sources describe no way to end only one developer's session from the server side without waiting for ttl_hours. The documentation says so explicitly: there is no per-session revocation.

To replace the signing key on a schedule, add the new value to the beginning of the array and roll the deployment. After the ttl_hours plus a grace period have passed, remove the old value. This process does not terminate existing sessions.

4.5 When the IdP Cannot Issue Refresh Tokens, and When the IdP or PostgreSQL Goes Down

Session refreshing relies on the IdP's refresh token. The Identity provider setup section of the deployment and operations page says that refresh tokens drive both silent renewal and deprovisioning, and addresses IdPs that cannot issue refresh tokens as follows:

If your IdP can't issue refresh tokens at all, the gateway still works, but there is no silent renewal, so developers re-run the browser login when their session expires. To keep that from happening every hour, raise session.ttl_hours to 8 or 12. The tradeoff is deprovisioning latency, because without refresh tokens a disabled user keeps access until the longer TTL elapses.

Extending the ttl_hours value reduces the number of browser sign-ins required and increases the time that developer access remains valid after being disabled on the IdP. The documentation presents these two factors as a trade-off.

The outage behavior section of the deployment and operations page describes what the gateway does when PostgreSQL goes down:

Existing sessions: bearer tokens validate locally with the JWT secret, session refreshes don't touch the store, and the gateway process can still serve inference

The same section states that new sign-ins will fail while PostgreSQL is unavailable. This is because device sign-in state and rate-limit counters are in PostgreSQL. However, with the default behavior of /readyz, every replica reports not ready once PostgreSQL is unreachable. Where traffic only reaches replicas that report ready, even inference that the gateway could serve does not reach it. store.readiness_grace_seconds allows you to delay this report by a specified number of seconds (Section 6.4).

When the IdP is down, existing sessions continue to function until their ttl_hours expires, and new sign-ins will fail. Session refreshing will receive a response requesting a retry, and will succeed once the IdP is back online.

4.6 Time to Reflect Group Changes and Policy Changes

The managed section of the configuration reference describes two propagation clocks.

Policy contents: When you edit a policy in gateway.yaml and redeploy the gateway, connected Claude Code instances receive it on their next managed settings fetch. The fetch happens within an hour. Some changes, however, apply only at the next launch.
Group membership: If you modify a developer's group in the IdP, the associated policy for that developer will change. The change takes effect at the next session issuance, that is, the next refresh, and session.ttl_hours bounds it.

On the Amazon ECS track of the AWS worked example, gateway.yaml is inside the container image. After editing a policy, rebuild the image and deploy it under a new tag (Section 6.2).

5. Enforcing Models and Settings, and the Routes That Skip the Gateway

This chapter shows what the gateway enforces for each IdP group, the settings placed on developer machines, and how the sources treat routes that skip the gateway.

5.1 `managed.policies[]` — The First Matching Policy and the Base Policy

The gateway's enforcement goes in managed.policies[] in gateway.yaml. The managed section of the configuration reference says that policies are evaluated from the top, that the first match is selected, and that it is merged onto the match: {} catch-all policy. How a key merges depends on its type.

Allow lists (availableModels and permissions.allow): The list of the specific policy replaces the list of the base.
Deny lists and hook arrays (permissions.deny, permissions.ask, and others): They take the union of the base and the specific policy. The source says this is so that organization-wide denials and audit hooks are not lost due to role-specific overrides.
Record-typed keys (env, modelOverrides, skillOverrides): These are shallowly merged.

For developers who do not match any of the policies, the same section describes the following:

An authenticated user who matches no policy gets the gateway's defaults, which means every model in the catalog and no managed settings. Add a match: {} catch-all last if you want a guaranteed default policy.

Policy matching is performed using the match section's groups and email_domain. groups performs a case-sensitive comparison with the group values obtained from the IdP. Because Microsoft Entra ID emits object IDs rather than group names, the worked example page says to match on those GUIDs.

The following YAML is an example used in this article. The documentation examples use IDs for older model generations, so this article replaced them with the current-generation IDs as of October 13, 2026. The group names are also example values that this article chose.

managed:
  policies:
    # Specific groups first.
    - match: { groups: [eng-contractors] }
      code:
        availableModels: [claude-sonnet-5-5]
        permissions: { deny: ["WebFetch", "WebSearch"] }
    # Catch-all base last: every authenticated user.
    - match: {}
      code:
        availableModels: [claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5]
        enforceAvailableModels: true

In this example, the eng-contractors policy replaces the base availableModels list with its own and inherits enforceAvailableModels from the base policy. The code key requires that the gateway version be 2.1.296 or later. Older gateway versions will fail to start if they encounter this key. In older gateway versions, the same content should be placed under the cli key. Mixing code and cli in a single file will prevent the gateway from starting.

No list of the model IDs that the gateway's built-in catalog includes was found in the sources (Section 8.2). A comment in the gateway.yaml of the entry page's quickstart says that the built-in catalog maps each Claude model that Amazon Bedrock supports in the same way as it maps claude-opus-4-8 to us.anthropic.claude-opus-4-8. The model card for Claude Opus 5.5 in the Amazon Bedrock user guide states that the model was released on September 22, 2026, and lists us.anthropic.claude-opus-5-5 and other IDs as Geo inference IDs on bedrock-runtime.

5.2 What the Gateway Enforces, and What It Does Not

The "What's enforced on developers" section on the gateway's entry page lists guarantees that apply to all sessions signed in via /login. The following are relevant to this article:

Model access: Requests for models that are not allowed return 400. This also covers the model a session starts on before the developer picks one.
Telemetry destination: Claude Code sends its OTLP/HTTP exports to the gateway rather than to a destination set on the machine. When a policy names the organization's collector as the destination, Claude Code sends directly to it.
Credentials: The gateway session token becomes the sole credential for that session.
Managed settings: Locked keys cannot be overridden on the machine.
Startup with the gateway unreachable: Signed-in sessions exit at startup with an error after about 10 seconds, rather than starting without their settings.
Deprovisioning: The session of a user disabled in the IdP expires within ttl_hours when the next refresh fails.

Regarding models, the gateway overview page states that the gateway does not select models. Developers pick the model with /model and other ways, and the gateway narrows that choice with each group's availableModels. When availableModels leaves out Claude Code's default model, the session's requests get 400 until the developer picks a model. The configuration reference says to set enforceAvailableModels: true in the same policy.

5.3 Settings on Developer Machines

The gateway cannot tell developer machines where the gateway is. The "Client-side managed settings" section of the configuration reference explains the reason for this as follows:

The gateway can't push the login keys itself, because they're what tell the client where the gateway is.

So the organization places the following keys in the client-side managed settings of developer machines.

Setting	Where It Must Be Set	What It Does	Minimum Claude Code Version	Where the Source Says So
`forceLoginMethod: "gateway"`	Client-side managed settings. On 2.1.295 or later, the developer's user settings also work, but only on a machine with no client-side managed settings.	Opens `/login` on the Cloud gateway screen. Set in client-side managed settings, it makes Claude Code stop using an earlier login or API key on that machine	2.1.195 (the minimum version for gateway sign-in itself)	Settings reference, `forceLoginMethod`
`forceLoginGatewayUrl`	Same as `forceLoginMethod`.	Sets the gateway URL that the Cloud gateway screen connects to. Without it, the screen tells the user to contact their IT administrator	2.1.195 (the minimum version for gateway sign-in itself)	Settings reference, `forceLoginGatewayUrl`
`parentSettingsBehavior: "merge"`	Client-side managed settings	Lets Claude Desktop pass the gateway's egress allowlist to the Claude Code sessions it launches.	Not found (Section 8.2)	Entry page, Deliver policy to Claude Desktop sessions
`allowedProviders: ["gateway"]`	Client-side managed settings. Not on the gateway server	Claude Code refuses sessions not set up for a Cloud gateway, at startup, at login, and when they contact the API.	2.1.285	Configuration reference, Client-side managed settings; settings reference, `allowedProviders`
`gatewayInternalNetworks`	Client-side managed settings	Declares public IPv4 blocks that the organization owns as its internal network. `/login` accepts a gateway only when both the gateway and the machine are inside the block.	2.1.268	Entry page, Allow a gateway on public address space you own

The entry page shows this example of client-side managed settings:

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

The forceLoginMethod and forceLoginGatewayUrl settings do not take effect even when configured in the managed settings provided by the gateway. The configuration reference says to leave these two keys out of the gateway payload. The reason is that the login keys reach only Claude Code instances that are already connected.

The login picker has no gateway option. The only way for developers to name a gateway themselves is their user settings, on 2.1.295 or later. The AWS worked example page also says, in its last step, to push the client-side managed settings to each machine with MDM.

5.4 Routes That Skip the Gateway — What Claude Code Refuses, and What the Network Closes

Putting a gateway in place does not make the gateway the only route to a model. The Deployment section of the deployment and operations page says:

Bypass: the gateway doesn't enforce that the only route to a model goes through it. A developer with their own credential can still call the provider directly, so closing that path is a network policy decision, for example blocking egress to api.anthropic.com except from the gateway.

The sources handle these routes in two stages.

The first stage is what Claude Code on the developer machine refuses. When the client-side managed settings include allowedProviders: ["gateway"], Claude Code refuses any session on that machine that is not set up for a Cloud gateway. The configuration reference says the key's purpose is to stop developers from bypassing the gateway with a cloud-provider environment variable or an ANTHROPIC_BASE_URL of their own. Simply setting forceLoginMethod: "gateway" will not trigger this rejection. The settings reference describes this as follows:

If you select a cloud provider through CLAUDE_CODE_USE_BEDROCK or a similar environment variable, the session doesn't need the gateway sign-in.

The second stage is the route outside Claude Code. On the route where developers call the upstream directly with their own credentials, the deployment and operations page says that the gateway does not enforce that it is the only route, and that closing it is a network policy decision. The source's example is blocking egress to api.anthropic.com from anywhere except the gateway. The source says that blocking it also breaks the WebFetch domain safety check, which queries api.anthropic.com from the developer machine, and says to turn that check off with the managed setting skipWebFetchPreflight: true.

No statement was found on how to close the route from developer machines to Amazon Bedrock when the upstream is Amazon Bedrock (Section 8.2). This article does not describe a way either.

5.5 Gateway Address Must Be Private

Claude Code only connects to gateways that have private addresses. The quickstart on the entry page says:

Claude Code only connects to a gateway whose address is private. This is a security guard, because a trusted gateway can push settings that run commands on developer machines.

At /login, the gateway's hostname must resolve only to private addresses. The prerequisites table lists the following as private addresses: RFC 1918, link-local, and CGNAT addresses in the 100.64.0.0/10 range, as well as ULA IPv6 addresses within the fc00::/7 range, and loopback addresses. When the developer machine sends HTTPS through a corporate proxy, the proxy hostname must also resolve to a private address. Otherwise, the gateway hostname should be added to the NO_PROXY list.

This requirement is relevant to the internal ALB configuration described in Section 6.3. On the gateway side, you can restrict the accepted source IP ranges using the access_control.allow_cidrs setting. The configuration reference states that when this list is empty, the gateway will respond to all source connections and will issue a warning at startup.

6. The Pieces of Anthropic's AWS Worked Example, and What Stays an Example

This chapter lists the pieces that Anthropic's AWS worked example page uses, and then the values that stay as the example set them, with what the page says about them. This article does not evaluate the worked example.

6.1 What the Worked Example Is

The AWS worked example page says in its opening note that the page walks through one way to run the gateway on AWS, and states that the configuration is a working example rather than a supported production deployment (quoted at the beginning of this article). The Terraform reference section of the same page gives the same disclaimer for its companion code bundle.

Like this page, the bundle is a working example for customer-managed infrastructure rather than a supported production deployment; review and adapt it to your own environment before relying on it.

The worked example page leaves the platform-agnostic requirements to the deployment and operations page. The Next steps section of the worked example page also links to AWS-maintained deployment samples (AWS samples for Claude apps gateway). This article has not read those samples.

Figure 2 shows the pieces of the worked example and the traffic between them.

The Worked Example on AWS (an Example, Not a Supported Production Deployment)

6.2 The Pieces

For compute, the worked example page shows two tracks: Amazon ECS on AWS Fargate, and Amazon EKS. The following table lists the pieces of the worked example.

AWS Piece	Role in the Example	Configuration in the Example	Where the Source Says So
Amazon ECS service (on AWS Fargate) or Amazon EKS Deployment	Hosts the gateway container	Deployed within a private subnet and without a public IP address.	Architecture, Deploy
Amazon ECR repository	Stores the gateway image	Configured to prevent tag modification and includes image scanning upon push.	Build and push the image to Amazon ECR
Amazon RDS for PostgreSQL	Provides the gateway's `store`	PostgreSQL 16. Deployed within a private subnet and not publicly accessible. Storage is encrypted. `rds.force_ssl=1` is enabled.	Provision Amazon RDS for PostgreSQL
AWS Secrets Manager	Holds three: the session token signing key, the IdP client secret, and the PostgreSQL connection string	On Amazon ECS, the task definition's `secrets` field passes them as environment variables. On Amazon EKS, they are mounted as files at `/secrets`.	Store secrets in AWS Secrets Manager
IAM role	Allow the gateway to call Amazon Bedrock.	Includes permissions for `bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream`, and `bedrock:CountTokens`. In Amazon ECS, this is a task role; in Amazon EKS, it's an IRSA role.	Create the IAM roles
Internal Application Load Balancer	Receives HTTPS from developer machines	Configured with `--ip-address-type ipv4`. TLS policies are specified. Idle timeout is set to 3600 seconds. Health checks are performed on `/readyz`.	Deploy

On Amazon ECS, the worked example keeps two roles apart. The gateway's AWS SDK uses the task role at runtime, and the role only has permission to call Amazon Bedrock. The Amazon ECS agent uses the execution role to pull the image and to pass the Secrets Manager values to the container. The permission to read Secrets Manager is on the execution role. On the Amazon EKS track, the same two policies go on the IRSA role. The Secrets Manager policy is needed only when the pods read Secrets Manager themselves.

Where gateway.yaml lives also differs between the two tracks. On the Amazon ECS track, the image build copies gateway.yaml into the image. So the worked example page says to rebuild the image under a new tag after a config change. On the Amazon EKS track, gateway.yaml is loaded from a ConfigMap.

On bedrock:CountTokens, the ## 2.1.295 CHANGELOG says that a gateway with an Amazon Bedrock upstream now gets the token counts that /context and large file reads use from AWS's CountTokens API, instead of from a one-token model request, and says to grant bedrock:CountTokens for it.

6.3 The Reasons the Worked Example Gives for Its Values

The worked example page includes explanations for several values.

Making the internal ALB IPv4 only: The worked example page says the following:

--ip-address-type ipv4 matters: an internal dual-stack ALB publishes public-range AAAA records, which the /login private-network check rejects

The Elastic Load Balancing user guide also says that a dual-stack ALB gets an AAAA DNS record.

Setting trusted_proxies to the ALB's subnets: The gateway reads X-Forwarded-For only when the TCP peer is in trusted_proxies. The worked example sets trusted_proxies to the CIDRs of the subnets that the ALB nodes take their addresses from. The worked example page says that this trusts every host in those subnets as a proxy, and says not to let the subnets overlap the ALB's ingress source, and not to share the subnets with untrusted workloads. If not configured, rate limiting and audit events will be logged with the ALB's address.
Setting public_url to your own hostname: The internal ALB's own *.elb.amazonaws.com name resolves to private addresses, but it cannot carry your ACM certificate. The worked example puts its own hostname in a Route 53 private hosted zone and points it at the ALB.
Connecting to PostgreSQL with sslmode=verify-full: The gateway verifies the chain and hostname of the RDS server certificate. The worked example copies the RDS certificate bundle into the image and trusts it with the NODE_EXTRA_CA_CERTS environment variable. Because AWS appends new regional CAs to the bundle, the worked example page says to download it on every build.
Using a parameter group with rds.force_ssl=1: The Amazon RDS user guide states that for RDS for PostgreSQL version 15 and later, the default value for rds.force_ssl is 1. The worked example, using PostgreSQL 16, explicitly sets this parameter to 1 within the parameter group.
Setting the ALB idle timeout to 3600 seconds: By default, the ALB closes connections that have no data transmission for 60 seconds. The troubleshooting table on the worked example page notes that gateway versions 2.1.229 and later send an SSE ping event when stream data is interrupted for approximately 15 seconds when used with Amazon Bedrock and Claude Platform on AWS, and that this keeps a quiet stream inside the default 60-second timeout. The worked example extends this to 3600 seconds for added buffer.

6.4 Values That Stay as the Example Set Them

The following table lists the values selected by the worked example, as well as those that were not explicitly set within that configuration, along with relevant information from the documentation. This article does not say which value to use.

Item	Value in the Example	What the Source Says About It
`session.ttl_hours`	8	The default is 1. The worked example's comment says to lower it toward 1 for tighter revocation (Section 4.3).
`store.readiness_grace_seconds`	Commented out (default is 0)	Set it to keep passing the health check through an RDS failover. The gateway must be on 2.1.282 or later.
ECS Service `desired-count`	1	The worked example page does not explain why this is set to 1. The deployment and operations page says that the replicas are stateless and coordinate through PostgreSQL.
RDS Instance Class	`db.t4g.micro`, 20 GiB storage	The entry page says that the smallest PostgreSQL tier is enough.
Region and Model List	A US region. The gateway's built-in catalog (`us.anthropic.*`).	In a region outside the US, add a `models:` list with that geo's inference profile IDs, and change the ARN prefix of the IAM policy to match.
IdP	Okta	Only the `oidc` section is specific to Okta. A note on the worked example page describes the differences when switching to Microsoft Entra ID.
Route to Amazon Bedrock	Through a NAT gateway	You can create an interface VPC endpoint for `bedrock-runtime` and point the upstream `base_url` to it. The IdP still needs egress to the internet.
`access_control.allow_cidrs`	Not present in the worked example (`gateway.yaml`).	The worked example limits what the ALB accepts to the corporate CIDR with a security group. The configuration reference says that the gateway logs a warning at boot when the list is empty.
Amazon EKS Logs	Left at the default	The worked example page notes that in Amazon EKS, pod logs are not sent to CloudWatch by default, and audit logs will be lost until log collection is enabled.
Terraform bundle	Only the Amazon ECS on AWS Fargate track	The VPC and private subnets stay prerequisites and are passed in as variables. The Amazon EKS track is not in the Terraform bundle.

Regarding PostgreSQL versions, the prerequisites table on the entry page specifies that PostgreSQL 11 or later is required, and notes that versions 11, 12, and 13 require a gateway version of 2.1.290 or later. The same table says that the PostgreSQL project no longer maintains these three versions, and says to use a newer one where you can. The worked example uses 16.

6.5 The Upstream Authenticates Through the Default Credential Chain

The worked example's upstreams section is defined with auth: {}. The worked example page states:

The upstreams block points at Bedrock with auth: {}, so the gateway authenticates via the AWS default credential chain from the task role on ECS or the IRSA role on EKS.

The Amazon Bedrock section of the configuration reference states that an empty auth setting utilizes the AWS SDK's default credential chain, which includes environment variables, ~/.aws/credentials, ECS task roles, EC2 instance metadata, and Amazon EKS IRSA. The existing article The AWS Credential Provider Chain Across SDKs and the CLI details what the AWS SDK searches for and in what order within that chain. The differences between IRSA and EKS Pod Identity are discussed in the existing article Amazon EKS Pod Identity and IRSA Decision Guide.

The worked example and the configuration reference describe only IRSA for the Amazon EKS track. The words EKS Pod Identity were not found on the gateway pages (Section 8.2). This article says neither that it works with EKS Pod Identity nor that it does not.

The worked example page states that Fargate task roles and IRSA do not use EC2 instance metadata. It also says that on Amazon EKS, an egress NetworkPolicy may block 169.254.169.254 for the gateway pods.

How the ECS task role credential endpoint and the EC2 instance metadata service each check the caller, and what the sources say about closing them, is compared with the endpoints of Amazon EKS and AWS Lambda in the companion article Metadata Endpoints Across AWS Compute.

7. Upstreams on AWS — Amazon Bedrock, the Mantle Endpoint, and Claude Platform on AWS

This chapter shows how the three upstreams on AWS differ, and how anthropic-beta is handled. This article does not say which upstream to use.

7.1 A Table of the Three Upstreams

The following table lists the AWS upstreams that you can write in the gateway's upstreams.

Upstream	`provider`	Minimum Gateway Version	Authentication	Where the Source Says So
Amazon Bedrock (`bedrock-runtime`)	`bedrock`	2.1.195 (the minimum version of the gateway itself)	The AWS SDK's default credential chain with an empty `auth`. Otherwise, explicit AWS credentials or an Amazon Bedrock API key	Configuration reference, Amazon Bedrock
The Mantle endpoint of Amazon Bedrock	`mantle`	2.1.283	The same `auth` keys and rules as the Amazon Bedrock upstream	Configuration reference, Amazon Bedrock Mantle endpoint
Claude Platform on AWS	`anthropicAws`	2.1.198	A Claude Platform on AWS API key, or SigV4. `workspace_id` is required	Configuration reference, Claude Platform on AWS

The timeouts.upstream_ttfb_ms setting determines how long the gateway will wait for an upstream to begin responding. The configuration reference specifies a default value of 120000 milliseconds for this setting. Whether the setting applies to the AWS upstreams is a place where the sources disagree (Section 8.1, item 1).

The existing article Amazon Bedrock Inference Endpoints and API Keys covers what the bedrock-runtime and bedrock-mantle endpoints of Amazon Bedrock each accept, and which IAM action each checks.

7.2 What Does Not Apply on the Mantle Upstream

A mantle upstream requires a models list, and only the models in it are sent to that upstream. The configuration reference says that two settings of the Amazon Bedrock upstream do not extend to the Mantle upstream.

guardrail: The gateway applies no Amazon Bedrock guardrail to requests it sends to Mantle. So when a mantle upstream is listed while any bedrock upstream sets guardrail, the gateway refuses to start.
assume_role: A mantle upstream takes no assume_role. Requests that Mantle serves are sent with the credentials of the mantle upstream's own auth.

assume_role is a setting on the Amazon Bedrock upstream: the gateway assumes an IAM role per developer and puts the developer's email address in the session name. This allows AWS to differentiate requests from each developer. A gateway version of 2.1.281 or later is required. This article will not provide further details on this setting.

7.3 The Claude Platform on AWS Upstream

The Claude Platform on AWS user guide describes the differences between it and Amazon Bedrock as follows:

Unlike Amazon Bedrock, where AWS operates the inference stack, Anthropic operates Claude Platform on AWS.

The gateway's configuration reference describes the Claude Platform on AWS upstream as follows:

Claude Platform on AWS serves the first-party Anthropic API on AWS infrastructure at aws-external-anthropic.<region>.api.aws. It uses first-party model IDs, honors anthropic-beta headers as sent, and serves count_tokens, so none of the Bedrock-specific translation applies.

On IAM roles, the same section says the following:

The platform runs in a separate AWS account from Amazon Bedrock and signs SigV4 requests for its own service name, aws-external-anthropic, so a Bedrock-scoped IAM role doesn't authorize it.

The opening note of the AWS worked example page also says that, for a Claude Platform on AWS upstream, the upstream entry, credentials, and IAM permissions differ from the page's Amazon Bedrock ones, and that the rest of the page applies unchanged.

7.4 Handling of `anthropic-beta`

Claude Code sends anthropic-beta values when it uses beta features. The availability and limitations section of the gateway's entry page says that the gateway delivers those values to every upstream. Regarding Amazon Bedrock, it states:

For Amazon Bedrock, which ignores the header, the gateway moves the values into the request body's anthropic_beta field; the other upstreams receive the header as sent.

The Amazon Bedrock user guide describes anthropic_beta as a field of the request body of the Anthropic Claude Messages API:

anthropic_beta – (Optional) The anthropic beta parameter is a list of strings of beta headers used to indicate opt-in to a particular set of beta features.

No AWS statement was found that says Amazon Bedrock ignores the anthropic-beta HTTP header (Section 8.2). This article writes that Amazon Bedrock ignores the header as a statement of Claude Code's documentation. In the row for beta features, the comparison table of the Claude Platform on AWS vs Amazon Bedrock page says Pass through with anthropic-beta headers for Claude Platform on AWS and Requires AWS support for Amazon Bedrock.

The entry page's sentence does not tell whether a mantle upstream receives anthropic-beta as a header or in the body. The sentence separates Amazon Bedrock from the other upstreams and does not name the Mantle endpoint.

The general case, what happens depending on how a gateway handles anthropic-beta values, is covered in the existing article What a Translating LLM Gateway Drops.

8. Where the Sources Disagree and Where No Statement Was Found

This chapter collects the places where the sources disagree and the statements that were not found, as touched on in Sections 1 through 7. This article does not call either source wrong. All verification dates are October 13, 2026.

8.1 Where the Sources Disagree

The following table lists the places where the sources disagree.

#	Topic	One Source Says	Another Source Says	Section
1	The upstreams that `timeouts.upstream_ttfb_ms` applies to	The `## 2.1.295` CHANGELOG says `Added support for timeouts.upstream_ttfb_ms on the Claude apps gateway's Bedrock, Vertex, Foundry and other cloud upstreams`	The configuration reference says, in two places, that the setting applies only to the Anthropic API upstream and that on the other upstreams the gateway waits up to one hour for the response to start. Two places on the deployment and operations page also describe it as the behavior on the `provider: anthropic` upstream.	Section 7.1
2	The version the gateway first shipped in	The prerequisites table on the entry page says `The claude gateway subcommand and the gateway sign-in flow ship in v2.1.195.`	The `## 2.1.195` section of the CHANGELOG has no gateway line. The first gateway line in the CHANGELOG is in `## 2.1.198`: `Gateway: added Claude Platform on AWS (anthropicAws) as an upstream provider`	Section 7.1
3	Amazon Bedrock and the `anthropic-beta` header	The gateway's entry page says that Amazon Bedrock ignores the header, and that the gateway moves the values into the body's `anthropic_beta`.	The Amazon Bedrock user guide describes the body field `anthropic_beta`. No AWS statement was found that says it ignores the HTTP header. The Claude Platform on AWS vs Amazon Bedrock page gives the beta features of Amazon Bedrock as `Requires AWS support`.	Section 7.4

Regarding item 1, the two locations mentioned in the configuration reference are:

That setting doesn't apply to the other providers, where the gateway waits up to one hour for an upstream to start responding.

Applies to the direct Anthropic upstream path; on every other provider the gateway waits up to one hour for the response to start.

The CHANGELOG is a record that announces what each version adds, and the configuration reference carries no version number. This article does not say which of the two is the behavior of 2.1.296. This article did not start the gateway to check.

On item 2, this article does not call the 2.1.195 statement wrong. This is because the sources do not say whether the CHANGELOG lists every addition. The entry page says that public builds before 2.1.195 do not include the claude gateway subcommand.

8.2 Statements That Were Not Found

The following table lists the statements that were looked for on October 13, 2026 and not found, with the places and terms searched. That a statement was not found does not mean that the behavior does not exist.

What Was Looked For	Where and How It Was Looked For	Result
Whether the gateway can get the upstream credential through EKS Pod Identity on Amazon EKS	Searched the entry page, the configuration reference, the deployment and operations page, the AWS worked example page, the gateway overview page, and the CHANGELOG using the terms `Pod Identity` and `pod-identity`.	Not found. The worked example and the configuration reference describe only IRSA (Section 6.5)
AWS documentation stating that Amazon Bedrock ignores the `anthropic-beta` header in HTTP requests.	Searched the Amazon Bedrock user guide's Messages API requests and responses page and the Messages API entry page using the term `beta`. Also searched AWS documentation using the combined terms `anthropic-beta`, `header`, and `InvokeModel`.	Not found. What the user guide describes is the body field `anthropic_beta` (Section 7.4)
The release status of the gateway (beta, preview, GA)	Searched the gateway's four pages and the gateway overview page using the terms `preview`, `generally available`, and `beta`.	Not found. Every occurrence of `beta` refers to beta headers or beta features, such as `anthropic-beta`, and not to the gateway's release status.
Where the gateway holds the IdP refresh token	Searched the configuration reference and deployment and operations page using the terms `refresh token`, `refresh_token`, and `store`.	Not found. What the sources say is that refresh tokens drive renewal and deprovisioning, and that session refreshes do not touch PostgreSQL (Sections 3.2 and 4.5).
The model IDs that the gateway's built-in catalog includes	Searched the gateway's four pages using the terms `opus-5-5`, `sonnet-5-5`, `haiku-5-5`, `Opus 5.5`, and `Fable`.	Not found. The pages provide examples using older model IDs such as `claude-opus-4-8`, `claude-sonnet-4-6`, and `claude-haiku-4-5` (Section 5.1).
With an Amazon Bedrock upstream, how to close the direct route from developer machines to Amazon Bedrock	Searched the deployment section of the deployment and operations page and the AWS worked example pages using the terms `bypass`, `egress`, and `bedrock`.	Not found. The documentation provides examples of egress communication to `api.anthropic.com` (Section 5.4).
The minimum version of Claude Code that supports the `parentSettingsBehavior`.	Searched the entry page, configuration reference, and settings reference using the key name and the terms `Requires` and `v2.1`.	Not found. The gateway's sign-in process requires a developer machine with version 2.1.195 or later (Section 5.3).

8.3 What Changes When the Sources Are Updated

The following statements in this article change when the sources are updated. When you read this article, reread these pages.

The configuration reference and the CHANGELOG (Section 8.1, items 1 and 2; the settings grow with each version)
The availability and limitations table on the entry page (Section 7.4 and Section 8.1, item 3; the handling of anthropic-beta and the list of features that are not available)
The AWS worked example page (Section 6; the worked example's values and how it writes the Amazon EKS track)
The model IDs in the documentation's examples (Section 5.1. When they change to the current generation's IDs, this article's replacement is no longer needed.)

9. Frequently Asked Questions about Running Claude Apps Gateway on AWS

Q1. If a gateway is implemented, will developers no longer be able to directly call Amazon Bedrock?

Putting a gateway in place alone does not stop them. The deployment and operations page says that the gateway does not enforce that it is the only route. With allowedProviders: ["gateway"] in the client-side managed settings, Claude Code refuses sessions not set up for a Cloud gateway. forceLoginMethod: "gateway" alone does not stop a session that selects Amazon Bedrock with CLAUDE_CODE_USE_BEDROCK. The sources treat the route where developers call the upstream directly with their own credentials as a network policy decision (Section 5.4).

Q2. When does the access of a developer who leaves end?

When you disable the developer in the IdP, the next session refresh fails, and access ends within session.ttl_hours. The default is 1 hour, and the AWS worked example sets 8 hours. The sources describe no way to stop only one developer from the server side without waiting for ttl_hours. To invalidate all sessions at once, you must replace the signing key, ensuring that no previous values remain (Section 4.4).

Q3. Can Anthropic's AWS worked example be used directly in a production environment?

The worked example page says that the configuration is a working example rather than a supported production deployment, and says to adapt it to your own environment. The Terraform bundle carries the same disclaimer. This article does not evaluate the worked example. Section 6.4 lists the values chosen by the worked example, as well as those that it does not configure.

Q4. Can EKS Pod Identity be used instead of IRSA in Amazon EKS?

The sources do not say. The worked example and the configuration reference describe only IRSA for the Amazon EKS track, and the words EKS Pod Identity were not found on the gateway pages. The configuration reference says that an empty auth uses the AWS SDK's default credential chain (Sections 6.5 and 8.2).

Q5. Does the gateway log developers' prompts?

The gateway's entry page says that the gateway neither logs nor stores prompt or completion content. By default, telemetry is metrics only. When you turn on logs and traces for a destination, Bash commands, tool inputs, and file paths can reach that destination (Section 3.4).

Q6. Can the gateway be used from the CI pipeline?

The entry page says that there is no service-token flow for unattended pipelines. Gateway sign-in always runs the browser device flow. The documentation indicates that these pipelines should be directly connected upstream (Section 4.2).

Q7. Which should be the upstream, Amazon Bedrock or Claude Platform on AWS?

This article does not recommend either one. Anthropic operates Claude Platform on AWS, and AWS operates the inference stack of Amazon Bedrock. On the gateway side, a Claude Platform on AWS upstream needs gateway 2.1.198 or later, requires workspace_id, and is not authorized by an Amazon Bedrock IAM role (Section 7.3).

10. Summary

The upstream credential leaves the developer machine: Developers sign in with the organization's IdP and receive a gateway session token (an HS256 JWT). The upstream credential is on the gateway side, and in the AWS worked example it is the task role or the IRSA role. What stays on the developer machine is the gateway session token, the gateway's TLS certificate fingerprint, and the client-side managed settings.
Secrets move to the gateway and the AWS pieces around it: The AWS worked example keeps the session token signing key, the IdP client secret, and the PostgreSQL connection string in Secrets Manager. What PostgreSQL holds is device sign-in state and rate-limit counters.
The gateway enforces models and settings per IdP group: Requests for models that are not allowed return 400, and locked keys cannot be overridden on the machine. Developers who do not match any policy can use every model in the catalog and do not receive managed settings.
The gateway does not record the content of prompts: Telemetry is only relayed to destinations configured by the organization; the gateway does not store it. Logs and traces are destination-specific choices.
The sources describe three ways for access to end: If disabled in the IdP, access will terminate within ttl_hours. Replacing the signing key without retaining old values will invalidate all sessions simultaneously. /logout only clears the gateway credential on the developer machine. There is no per-session revocation. The default value for ttl_hours is 1, and the worked example uses 8.
Routes that skip the gateway are handled in two stages: On the Claude Code side, allowedProviders: ["gateway"] in the client-side managed settings refuses sessions not set up for a Cloud gateway. Routes outside Claude Code are a network policy decision.
The worked example is an example: Anthropic states that the configuration is a working example rather than a supported production deployment. The replica count, instance class, region, IdP, ttl_hours, the grace period for PostgreSQL outages, and other values stay at the example's values.
The sources disagree: This article lists three places: the upstreams that timeouts.upstream_ttfb_ms applies to, the version the gateway first shipped in, and the anthropic-beta header in Amazon Bedrock. Seven statements were not found, among them EKS Pod Identity, an AWS statement that Amazon Bedrock ignores the header, the release status, where the IdP refresh token is held, and the built-in model catalog.

11. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi