Running Claude Code on Bedrock, Vertex, or Your Own Models With an Enterprise AI Gateway

TL;DR

• Claude Code natively supports Amazon Bedrock and Google Vertex AI through environment variables, so teams can run the agent against Claude models inside their own cloud accounts under existing IAM, billing, and data-residency controls.
• Native Claude Code Bedrock and Vertex configurations point at exactly one provider each; an AI gateway sits in front of all of them and unifies Bedrock, Vertex, and self-hosted models behind a single endpoint.
• Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second and exposes 1000+ models through one OpenAI-compatible API, so pointing Claude Code at it is a one-line base-URL change.
• With a gateway in place, Claude Code gains LLM routing, automatic fallback between providers, and adaptive load balancing across API keys and regions without any change to the agent.
• Governance for Claude Code traffic (virtual keys, budgets, rate limits, audit logs) is enforced once at the gateway instead of being copied into every developer's shell configuration.

Claude Code, Anthropic's terminal-based coding agent, connects to models three ways: the Anthropic API, Amazon Bedrock, and Google Vertex AI. Running Claude Code on Bedrock or Vertex keeps inference inside your own cloud account, under the IAM, billing, and data-residency controls you already operate. Bifrost, the open-source AI gateway built by Maxim AI, sits in front of those providers and unifies them behind one endpoint, so a single Claude Code Bedrock or Vertex setup gains LLM routing, automatic fallback, and adaptive load balancing across every model you run. This guide covers how to wire Claude Code to Bedrock, Vertex, and self-hosted models, and what a gateway adds on top of the native integration.

Why teams run Claude Code on Bedrock, Vertex, or their own models

Teams run Claude Code on Bedrock, Vertex, or self-hosted models to keep prompts, source code, and completions inside infrastructure they already govern. Bedrock and Vertex route inference through an existing AWS or Google Cloud account, so the same IAM roles, VPC boundaries, billing, and compliance posture that cover the rest of the stack now cover the coding agent.

For regulated organizations, the Anthropic first-party API is often a non-starter because it moves traffic to a third-party endpoint. Amazon Bedrock and Google Vertex AI solve that by serving Claude models from within the cloud perimeter. The trade-off is fragmentation: each provider is configured separately, has its own regional model availability, and enforces its own quotas. A gateway resolves that fragmentation, which is the subject of the Claude Code gateway architecture that centralizes routing, governance, and cost control. The rest of this guide builds on that foundation with concrete configuration steps.

How Claude Code natively connects to Bedrock and Vertex

Claude Code connects to Bedrock and Vertex through environment variables, with no code changes to the agent. Setting CLAUDE_CODE_USE_BEDROCK=1 routes requests through your AWS credentials to Amazon Bedrock; setting CLAUDE_CODE_USE_VERTEX=1 routes them through Google Cloud credentials to Vertex AI. Each variable pins Claude Code to that single provider.

For a Claude Code Bedrock setup, you export CLAUDE_CODE_USE_BEDROCK=1, provide AWS credentials, and set the region and model IDs, as documented in Anthropic's Claude Code on Amazon Bedrock guide. Amazon Bedrock itself must have the relevant Claude models enabled in that account and region, per the AWS Bedrock documentation.

A Claude Code Vertex setup mirrors this: you set CLAUDE_CODE_USE_VERTEX=1, a Google Cloud project and region, and grant model access through Claude on Google Cloud's Vertex AI partner models, following Anthropic's Claude Code on Vertex AI guide.

The native path works, but it is single-provider by design. If you want Claude Code to reach Bedrock and Vertex at the same time, or to fail over from one to the other, the environment-variable approach cannot express that. Bifrost, the AI gateway, adds that capability without touching Claude Code, and its Claude Code integration documents the exact wiring. This is also the pattern in the walkthrough on routing Claude Code through AWS Bedrock with Bifrost.

Where a native setup stops and an AI gateway begins

An AI gateway is a unified entry point that authenticates, routes, and observes traffic to multiple LLM providers behind a single API. Native Claude Code environment variables bind the agent to one provider at a time; the open-source Bifrost gateway removes that limit by presenting Bedrock, Vertex, self-hosted models, and 20+ other providers through one OpenAI-compatible endpoint.

The gap is concrete. A native Claude Code Bedrock configuration cannot fall back to Vertex when a Bedrock region throttles, cannot balance load across three Bedrock API keys, and cannot enforce a per-team budget. Bifrost adds only 11 microseconds of overhead per request at 5,000 requests per second, so this consolidation costs almost nothing at runtime, as the published Bifrost benchmarks show. The table below summarizes what changes.

Teams that want the full picture of provider coverage can review the supported providers matrix, which lists every model and provider reachable through one configuration. The approach also generalizes beyond Claude models, as shown in the guide to using Claude Code with any model or provider through Bifrost.

Pointing Claude Code at an LLM gateway

An LLM gateway is the routing and policy layer between a client like Claude Code and every model provider behind it. To point Claude Code at Bifrost, you set ANTHROPIC_BASE_URL to the gateway address and supply a virtual key; Claude Code continues to speak the Anthropic API format while Bifrost forwards each request to Bedrock, Vertex, or another configured provider.

Because Bifrost is a drop-in replacement, this is a base-URL change rather than a rewrite. The agent still uses the Anthropic wire format it already knows, and the Bifrost platform translates to whatever provider handles the request. Configuration steps for this exact flow, including running the gateway locally, are covered in the guide to running Claude Code with OpenAI, Gemini, Bedrock, and any LLM using the Bifrost CLI.

A minimal Claude Code configuration against the gateway looks like this:

export ANTHROPIC_BASE_URL="<http://localhost:8080>"
export ANTHROPIC_AUTH_TOKEN="<bifrost-virtual-key>"
claude

From here, which physical provider serves the request is a gateway decision, not a Claude Code decision. That separation is what makes routing, fallback, and load balancing possible, and it is set up through the Claude Code integration steps for Bifrost.

LLM routing across Bedrock, Vertex, and self-hosted models

LLM routing is the gateway logic that decides which provider, model, and key handles each request. With Bifrost as an LLM gateway, you define routing rules that map a requested model to a target: a coding task can go to Claude on Bedrock in us-east-1, a cheaper summarization task to a self-hosted model, and a fallback path to Vertex, all transparent to Claude Code.

Bifrost supports weighted provider routing and explicit routing rules that direct traffic by model, provider, and key. This lets one Claude Code Bedrock deployment reach multiple back ends without any of that logic living in developer shell profiles. Routing decisions are centralized, versioned in the gateway configuration, and identical for every engineer.

Common routing patterns for Claude Code teams include:

• Primary-plus-fallback: send all traffic to Bedrock, fall back to Vertex on error.
• Cost-tiered: route lightweight requests to a self-hosted model and reserve Claude on Bedrock for complex tasks.
• Region-aware: keep EU traffic on an EU Bedrock region and US traffic on a US region for data residency.

Choosing between gateways for this use case is compared directly in the roundup of the best LLM gateways for Claude Code multi-model routing, and the mechanics of routing, fallback, and governance together are detailed in the breakdown of LLM gateway routing, fallback, and governance in Bifrost.

Automatic fallback when a provider degrades

Automatic fallback is a gateway behavior that reroutes a request to a healthy provider when the primary one returns errors or times out. When a Bedrock region throttles or a Vertex endpoint returns 5xx responses, Bifrost retries the request against the next provider in the fallback chain, and Claude Code receives a normal response instead of a failure.

This matters because provider-level incidents are routine at scale, and a native Claude Code Bedrock configuration has no path to recover from them. Bifrost supports automatic fallbacks across providers and models with no downtime, so a Bedrock outage degrades to Vertex or a self-hosted model rather than halting every developer. The fallback chain is ordered, so you control the preference and the blast radius.

Fallback and routing together are what turn a set of independent providers into a resilient system. The design patterns for this at organizational scale are covered in the guide to an enterprise AI gateway for automatic fallback and routing, which walks through configuring chains that span AWS, Google Cloud, and private infrastructure.

Adaptive load balancing across providers and keys

Adaptive load balancing distributes requests across multiple API keys, providers, and regions based on real-time health and capacity rather than a fixed split. For Claude Code teams hitting Bedrock and Vertex quotas, the Bifrost gateway spreads traffic across several keys so no single key exhausts its rate limit, and shifts weight away from providers that are degrading.

Bifrost offers weighted distribution through key-management load balancing in the open-source gateway, and adaptive load balancing with predictive scaling and provider health monitoring in the enterprise tier. The difference matters under sustained load: adaptive load balancing reacts to live latency and error signals, so a slow Bedrock region gets less traffic automatically instead of continuing to receive its fixed share.

For a team of fifty engineers all running Claude Code against Bedrock, adaptive load balancing is often the difference between smooth operation and constant 429 errors. Spreading requests across a pool of keys multiplies effective throughput, and doing it adaptively keeps the pool healthy without manual tuning.

Running Claude Code on self-hosted LLMs

Claude Code can run against a self-hosted LLM by pointing the gateway at a local inference server and routing the agent's requests there. Bifrost connects to self-hosted models served through vLLM, Ollama, and SGLang, so a self-hosted LLM appears in Claude Code's routing table alongside Bedrock and Vertex under the same OpenAI-compatible API.

This is useful for cost control and for air-gapped or highly regulated environments. A self-hosted LLM handles routine or sensitive completions on infrastructure you fully control, while Bedrock or Vertex serves the harder tasks. Because the gateway can be deployed inside your own VPC with no public network egress, prompts and completions never leave your perimeter. The full set of private-deployment options is described on the Bifrost Enterprise page.

Running a self-hosted LLM behind the gateway also means the same routing, fallback, and governance apply to it. There is no separate code path for open models, which is why the same any-model, any-provider Claude Code setup covers self-hosted back ends without new configuration.

Governance and observability for Claude Code traffic

Governance is the layer that controls who can use which models, at what cost, and with what audit trail. When Claude Code runs through the Bifrost gateway, virtual keys, budgets, and rate limits are enforced once at the gateway instead of being scattered across every developer's environment variables, and every request is logged for observability.

Bifrost governance assigns each team or developer a virtual key with its own budget and permissions, so a Claude Code Bedrock deployment can cap spend per team and block access to models a group should not use. The governance capabilities for AI traffic include hierarchical cost control, rate limits, and immutable audit logs suitable for SOC 2, GDPR, and HIPAA reviews. This centralization is the core argument of the Claude Code gateway model for routing, governance, and cost control.

On the observability side, Bifrost exports native Prometheus metrics and OpenTelemetry traces, so latency, error rates, and per-provider spend for Claude Code are visible in existing dashboards. Combined with the performance and overhead benchmarks, teams get a full picture of what their coding-agent traffic costs and how each provider behaves under load. The complete governance toolkit makes these controls the default rather than an afterthought.

Frequently Asked Questions

Does Claude Code support Bedrock and Vertex without a gateway?

Yes. Claude Code natively supports Amazon Bedrock via CLAUDE_CODE_USE_BEDROCK=1 and Google Vertex AI via CLAUDE_CODE_USE_VERTEX=1, using your cloud credentials. Each variable binds Claude Code to one provider. A gateway is only needed when you want multiple providers, automatic fallback, load balancing, or centralized governance across a Claude Code Bedrock or Vertex deployment.

How do I point Claude Code at an AI gateway?

Set ANTHROPIC_BASE_URL to the gateway address and supply a virtual key as the auth token. Because Bifrost is a drop-in replacement that speaks the Anthropic API format, Claude Code needs no code changes. From that point, the gateway decides which provider (Bedrock, Vertex, or self-hosted) serves each request based on your routing rules.

What is the performance cost of adding a gateway?

Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks. For an interactive coding agent, that overhead is not perceptible. The routing, automatic fallback, and adaptive load balancing the gateway provides typically improve effective latency by steering traffic away from throttled or degraded providers.

Can I mix Claude on Bedrock with self-hosted models?

Yes. A gateway routes different request types to different back ends, so Claude on Bedrock can handle complex coding tasks while a self-hosted LLM served through vLLM or Ollama handles routine completions. All of them sit behind one OpenAI-compatible endpoint that reaches every supported model and provider, and the same LLM routing and fallback rules apply uniformly across every model.

How does automatic fallback work across Bedrock and Vertex?

You define an ordered fallback chain in the gateway. When the primary provider returns errors or times out, the request is retried against the next provider in the chain. A Bedrock region throttling to 429 can fall back to Vertex or a self-hosted model, and Claude Code receives a normal response instead of a failure, with no client-side retry logic.

Is a gateway deployment compatible with air-gapped environments?

Yes. Bifrost can be deployed inside your own VPC with no public network egress, and it connects to self-hosted models running on private infrastructure. Prompts and completions from Claude Code stay within your perimeter, which suits regulated and air-gapped environments while still providing routing, load balancing, and governance.

Run Claude Code on any provider with one gateway

Running Claude Code on Bedrock, Vertex, or self-hosted models no longer means choosing one provider and living with its limits. A gateway consolidates them behind a single endpoint and adds LLM routing, automatic fallback, adaptive load balancing, and governance to every Claude Code Bedrock or Vertex configuration without changing the agent. To see how Bifrost can unify your Claude Code infrastructure across every provider you run, book a demo with the Bifrost team.