Claude Code on Amazon Bedrock: AWS Setup & Rollout Guide

Claude Code on Amazon Bedrock is no longer just a setup question. The hard part is operating it like production infrastructure: short-lived AWS credentials, narrow model access, invocation logging, cost controls, workstation policy, and a clear boundary between Bedrock audit evidence and local developer telemetry.

This guide focuses on that production path. It shows how to set up Claude Code on Bedrock, where Claude Desktop 3P fits, when a self-hosted model path is worth the extra work, and what to lock down before a coding assistant becomes part of your engineering operating model.

Claude Code is Anthropic's AI-powered coding assistant that lives in your terminal, IDE, or browser. It reads your codebase, runs commands, writes and edits files, and handles complex multi-step engineering tasks — from debugging to feature implementation to refactoring — all guided by natural-language instructions.

For organizations running on AWS, Claude Code can connect directly to Amazon Bedrock, Claude Desktop can use Cowork on third-party (3P) mode with Bedrock for the Cowork and Code tabs, and self-hosted models can still be exposed inside your own VPC when that extra control is required. This guide walks through the paths end to end: prerequisites, configuration, IAM setup, model pinning, networking, enterprise rollout, and operational best practices.

Quick answer: Claude Code on Amazon Bedrock

Claude Code can use Amazon Bedrock as the AWS-hosted model path when teams need Claude access with IAM, regional controls, AWS billing, network design, and enterprise rollout guardrails. The practical setup is not only a model switch: validate Bedrock model access, SSO credentials, CLAUDE_CODE_USE_BEDROCK, AWS_REGION, model pins, repository controls, invocation logging, and data egress before broad developer adoption. Reserve ANTHROPIC_BASE_URL for gateway and self-hosted model paths.

Recommended AWS-native Bedrock pattern

For a production Claude Code rollout on AWS, the best-practice variant is not a personal API key or an unmanaged developer setup. Use Bedrock as the model control plane, authenticate engineers with SSO, constrain runtime IAM to approved profiles and backing model ARNs, and make Bedrock invocation logging the audit baseline.

• Workload boundary: run Claude Code on Bedrock from a dedicated AWS account or tightly scoped workload account, separate from unrelated application infrastructure.
• Human access: use IAM Identity Center / AWS SSO and short-lived runtime roles. Keep bootstrap permissions, model access, Marketplace subscription, and logging configuration out of the day-to-day engineer role.
• Runtime IAM: allow only bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, model/profile discovery, and read-only CloudWatch metrics. Scope resources to approved inference profiles and the backing Claude foundation-model ARNs in Regions the profile can route to.
• Runtime denies: deny calls outside the approved Region, deny bedrock:CallWithBearerToken unless a narrow exception is approved, and deny Bedrock admin actions plus Marketplace subscribe/unsubscribe from runtime roles.
• Models: pin Sonnet, Haiku, and Opus model/profile IDs and validate availability in the target account and Region before rollout.
• Audit: enable Bedrock invocation logging to CloudWatch Logs and S3 in the approved Region. Treat S3 log objects as sensitive production data because prompt, response, image, and document payloads may land there.
• Operations: configure CloudTrail, KMS, retention, log-delivery alarms, Bedrock budgets, total account budgets, Cost Anomaly Detection, and a versioned encrypted Terraform state backend with DynamoDB locking.
• Organization guardrail: use an SCP where possible to block unapproved models, unlogged Regions, bearer-token access, runtime admin actions, and Marketplace subscription from non-admin roles.

Quick Decision Matrix

Bedrock vs. Claude Team/Enterprise: AWS-Native Control or First-Party SaaS

The choice comes down to AWS-native control versus the first-party Claude app experience. Anthropic's own deployment overview positions Claude Team/Enterprise as the best experience for most organizations, while Bedrock is the best fit for AWS-native deployments.

Claude on Amazon Bedrock

Bedrock is the right fit for organizations with AWS-native deployments that want:

• AWS billing and governance. Bedrock consumption is usage-based and appears on your standard AWS bill. AWS also offers reserved capacity, batch inference, and other pricing tiers beyond on-demand. Bedrock spend may draw down an existing AWS Enterprise Discount Program (EDP) commitment; confirm eligibility with your AWS account team, as terms vary.
• Security controls anchored in AWS. Requests are governed through AWS IAM, processed within your selected region, encrypted at rest and in transit, and not shared with model providers. Optional PrivateLink and VPC connectivity provide additional network-level isolation.
• AWS application-building services. Beyond model invocation, Bedrock provides evaluation, fine-tuning, RAG (knowledge bases), agents, guardrails, and collaborative workflows through SageMaker Unified Studio.

The important caveat is now narrower: direct Bedrock access is a model/API path, not a Claude Team or Enterprise app subscription. Bedrock by itself does not include the standard Claude web, iOS, or Android apps, Claude plan administration, Anthropic-hosted conversation history, Projects, Artifacts, or Anthropic-managed connectors. Claude Desktop can now run in Cowork on 3P mode with inference routed through Bedrock, but that is a separately configured Desktop deployment with local storage, MDM/OS-managed settings, and different feature/admin parity from the standard Claude SaaS experience. If you need the simplest managed Claude app rollout with built-in collaboration and workplace connectors, compare Bedrock and Desktop 3P against Claude Team or Enterprise.

Claude Team and Enterprise (Seat-Based SaaS)

Claude Team and Enterprise plans operate outside the AWS ecosystem with a seat-based subscription model (standard and premium tiers, with optional extra usage and spend controls). What they deliver is fastest end-user adoption:

• Native web, iOS, Android, and desktop access to Claude
• Projects, Artifacts, and collaboration workflows
• Workplace connectors (Google Workspace available broadly; custom connectors also available beyond Team)
• Claude Code and Claude Cowork included
• Organizational admin, centralized billing, and security controls
• Enterprise adds SSO/SCIM, expanded retention, and advanced admin controls

Which Path Is Right?

Many of our customers adopt both: Bedrock for engineering teams and custom applications, plus a Claude Team or Enterprise plan for business users. Elevata can help you design this hybrid approach.

Scenario 1: Claude Code with Amazon Bedrock

AWS Bedrock provides fully managed access to Anthropic's Claude models without hosting or scaling infrastructure. For teams already operating on AWS, this is the most direct path to enabling Claude Code.

Prerequisites

• An AWS account with Bedrock access enabled
• Required AWS Marketplace permissions (detailed below)
• AWS CLI v2 installed and configured for the recommended SSO path. It is optional only for narrow bearer-token/API-key experiments.

Step 1: Enable Model Access

To use Claude through Amazon Bedrock, ensure your account has the required AWS Marketplace permissions, then complete Anthropic's one-time First Time Use form. After the form, access is granted immediately, though the initial subscription/setup can take several minutes before calls succeed consistently.

1. Navigate to Amazon Bedrock in the AWS Console.
2. Go to Model access and select the desired Claude models.
3. Complete Anthropic's use-case form (once per account). Access is granted immediately after submission.
4. Allow a few minutes for the initial subscription to process before making your first API call.

Step 2: Request Service Quota Increases

Default quotas may be insufficient for team-wide usage. Request increases proactively:

Step 3: Configure IAM Permissions

Separate the one-time bootstrap/admin role from the day-to-day engineer runtime role. Anthropic's setup example includes Marketplace subscription and model-access permissions because someone has to prepare the AWS account. That does not mean engineers should carry those permissions while coding.

Bootstrap/admin role. Use this for initial account setup, model access, Marketplace subscription, Bedrock invocation logging, budgets, and guardrail configuration. Keep it with the platform or cloud team, not every developer workstation.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockAccountBootstrap",
      "Effect": "Allow",
      "Action": [
        "bedrock:GetFoundationModel",
        "bedrock:ListFoundationModels",
        "bedrock:GetInferenceProfile",
        "bedrock:ListInferenceProfiles",
        "bedrock:PutUseCaseForModelAccess",
        "bedrock:PutModelInvocationLoggingConfiguration",
        "bedrock:GetModelInvocationLoggingConfiguration",
        "bedrock:DeleteModelInvocationLoggingConfiguration"
      ],
      "Resource": "*"
    },
    {
      "Sid": "MarketplaceModelEnablement",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaLast": "bedrock.amazonaws.com"
        }
      }
    }
  ]
}

Engineer runtime role. This is the role developers should use day to day. It invokes only approved Claude model or inference-profile resources, discovers model/profile metadata, and reads CloudWatch metrics. Replace the account ID, Region, and model/profile IDs with the resources you have validated in your account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeApprovedClaudeProfilesOnly",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-6",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-haiku-4-5-20251001-v1:0",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-opus-4-8",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6*",
        "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-6*",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-4-5*",
        "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-haiku-4-5*",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-4-8*",
        "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-opus-4-8*"
      ]
    },
    {
      "Sid": "DiscoverApprovedProfiles",
      "Effect": "Allow",
      "Action": [
        "bedrock:GetFoundationModel",
        "bedrock:ListFoundationModels",
        "bedrock:GetInferenceProfile",
        "bedrock:ListInferenceProfiles"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ReadOnlyBedrockMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyOutsideApprovedRegion",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    },
    {
      "Sid": "DenyBearerTokenRuntimeAccess",
      "Effect": "Deny",
      "Action": "bedrock:CallWithBearerToken",
      "Resource": "*"
    },
    {
      "Sid": "DenyRuntimeAdministration",
      "Effect": "Deny",
      "Action": [
        "bedrock:Create*",
        "bedrock:Put*",
        "bedrock:Update*",
        "bedrock:Delete*",
        "aws-marketplace:Subscribe",
        "aws-marketplace:Unsubscribe"
      ],
      "Resource": "*"
    }
  ]
}

Broad foundation-model/* and inference-profile/* resources are acceptable for a first tutorial. For production, start from an allowlist of the model IDs and application inference profiles you have enabled, tested, budgeted, and logged. When you allow cross-region inference profiles, include the backing foundation-model ARNs in every Region the profile can route to; otherwise engineers can hit confusing AccessDenied failures even when the profile ARN is allowed. Consider an Organizations SCP that denies Bedrock runtime calls outside approved Regions, denies bedrock:CallWithBearerToken, denies unapproved model resources, and blocks Marketplace subscription actions from runtime roles.

Step 4: Configure Claude Code Environment Variables

Keep the Region explicit even though current Claude Code releases can resolve it from AWS configuration. Explicit env keeps scripted rollouts deterministic and avoids mismatches between model access, invocation logging, budgets, and CloudWatch dashboards.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=your-bedrock-profile
export AWS_REGION=us-east-1
export ANTHROPIC_DEFAULT_SONNET_MODEL=us.anthropic.claude-sonnet-4-6
export ANTHROPIC_DEFAULT_HAIKU_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
export ANTHROPIC_DEFAULT_OPUS_MODEL=us.anthropic.claude-opus-4-8

According to the Claude Code on Amazon Bedrock documentation, as of Claude Code v2.1.172 the Bedrock Region resolves from AWS_REGION, then AWS_DEFAULT_REGION, then the active AWS profile's region in the shared credentials/config files, then us-east-1. Older versions required AWS_REGION more strictly. Use /status to confirm the resolved Region before rollout.

Step 5: Configure AWS Authentication

For SSO with credential refresh, add awsAuthRefresh to your Claude Code configuration:

{
  "awsAuthRefresh": "aws sso login --profile your-bedrock-profile",
  "env": {
    "AWS_PROFILE": "your-bedrock-profile",
    "AWS_REGION": "us-east-1"
  }
}

Bedrock API keys are useful for fast exploration because they avoid full AWS credential setup. They are also bearer credentials. For a secure enterprise posture, prefer SSO or temporary AWS credentials, keep the runtime policy narrow, and explicitly deny bearer-token invocation from developer roles.

Step 6: Pin Model Versions

Critical for production stability. Pin the Bedrock model or inference-profile IDs you have validated in your account. The example IDs below reflect one validated us-east-1 account view on June 30, 2026. Model availability changes by Region, account, endpoint, and release timing, so do not assume an example ID is enabled until AWS confirms it. For model-selection context, use the Claude Opus 4.8 benchmark guide; keep this guide focused on Bedrock rollout controls.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=your-bedrock-profile
export AWS_REGION=us-east-1
export ANTHROPIC_DEFAULT_SONNET_MODEL=us.anthropic.claude-sonnet-4-6
export ANTHROPIC_DEFAULT_HAIKU_MODEL=us.anthropic.claude-haiku-4-5-20251001-v1:0
export ANTHROPIC_DEFAULT_OPUS_MODEL=us.anthropic.claude-opus-4-8

Validate current availability before rollout:

aws bedrock list-foundation-models --region us-east-1 --by-provider Anthropic
aws bedrock list-inference-profiles --region us-east-1

For production, route model families through application inference profiles so you can apply tags, budgets, metrics, and promotion control per team or project. The following settings shape is conceptual; verify the current Claude Code settings contract in your environment before copying it into managed settings:

{
  "modelOverrides": {
    "claude-opus-4-8": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/opus-48-prod",
    "claude-sonnet-4-6": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/sonnet-46-prod",
    "claude-haiku-4-5-20251001": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/haiku-45-prod"
  }
}

Keep broad model ARNs in tutorials only. The production posture is an explicit allowlist, plus a change process for adding or retiring models.

Step 7: Enable AWS Guardrails (Optional)

Create a Guardrail in the Bedrock console, publish a version, then add the headers:

{
  "env": {
    "ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: your-guardrail-id\nX-Amzn-Bedrock-GuardrailVersion: 1"
  }
}

Cross-Region Inference

Cross-region inference profiles (model IDs prefixed with us. or eu.) allow Bedrock to route requests across configured regions to improve throughput and performance. Enable cross-region inference on your Guardrails if using these profiles.

Scenario 2: Claude Desktop Cowork on 3P with Bedrock

How to enable the setup UI

For single-machine evaluation, the official setup path is to open Claude Desktop, go to Help -> Troubleshooting -> Enable Developer mode, then Developer -> Configure third-party inference. That screen validates provider fields and exports a .mobileconfig file on macOS or a .reg file on Windows for MDM distribution. For rollout, prefer MDM over manual per-user configuration.

Minimum Bedrock configuration

The relevant Bedrock keys are inferenceProvider=bedrock, inferenceBedrockRegion, one credential method, and inferenceModels. Anthropic documents two authentication methods: inferenceBedrockBearerToken, which requires bedrock:CallWithBearerToken on the underlying principal, or inferenceBedrockProfile, which uses an AWS profile from ~/.aws/config and requires bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for the inference profiles and foundation models used. If the organization uses AWS SSO, the AWS profile path is the most natural pilot route; for production, validate credential refresh and MDM distribution.

{
  "enterpriseConfig": {
    "inferenceProvider": "bedrock",
    "inferenceBedrockRegion": "us-east-1",
    "inferenceBedrockProfile": "claude-bedrock",
    "inferenceModels": "[\"us.anthropic.claude-sonnet-4-5-20250929-v1:0\"]",
    "deploymentOrganizationUuid": "REPLACE_WITH_REAL_UUID"
  }
}

Important: array-typed keys such as inferenceModels must be written as JSON strings. In .mobileconfig, that means one string value containing [...], not a native plist array. Configure a real UUID for deploymentOrganizationUuid before rollout; if you leave a shared placeholder, telemetry is tagged with a generic value that Anthropic cannot distinguish from other unconfigured deployments. For Bedrock, use model IDs or inference-profile IDs available in the selected region and validate with aws bedrock list-inference-profiles before rollout.

Base URL, PrivateLink, and Bedrock gateway

If you leave inferenceBedrockBaseUrl unset, Desktop uses the public regional Bedrock endpoint. For environments that require a private path, the key can point to a Bedrock endpoint through PrivateLink or to an LLM gateway representing Bedrock, always over https://. Even with a gateway, keep the scope Bedrock-centered: IAM, CloudTrail, region, model, quota, and cost remain the primary decisions.

Code tab: still validate separately

The Code tab in Cowork on 3P uses the same Claude Code CLI engine, but Anthropic notes that some Cowork on 3P keys do not yet propagate to Code-tab sessions exactly the way they apply to the Cowork tab. For enterprise deployment, treat the Code tab as a separate validation path and also distribute Claude Code managed-settings.json when you need to pin policies, models, or sandboxing directly for coding sessions.

Desktop 3P + Bedrock validation checklist

• Confirm the Claude Desktop version and that the third-party inference setup UI appears.
• Validate inferenceProvider=bedrock, region, AWS profile or bearer token, and exposed models.
• Confirm the AWS profile inside the sandbox resolves credentials and refreshes through SSO or a credential process.
• Test Cowork and Code separately against a small repository before opening monorepos.
• Configure allowedWorkspaceFolders, coworkEgressAllowedHosts, disabled tools, OTel, and token limits where applicable.
• Confirm CloudTrail, budgets, Bedrock metrics, and local logs before broad rollout.

Scenario 3: Self-Hosted Models on AWS

Organizations that need to run open-source or third-party models can host them within their own AWS VPC and connect Claude Code to these self-managed inference endpoints. This provides full control over model selection, data residency, and cost, but requires additional infrastructure management and comes with compatibility limitations.

Provision GPU Compute

Deploy an Inference Server

Your server must implement the Anthropic Messages API format (/v1/messages):

• vLLM (Recommended): Natively supports the Anthropic Messages API with high-throughput inference. vLLM has first-party documentation specifically for Claude Code via its Anthropic-compatible API.
• LiteLLM Proxy: Translation layer for models that only support OpenAI-compatible endpoints.

Compatibility Notes

• Limited features: When ANTHROPIC_BASE_URL points to a non-first-party host, MCP tool search is disabled by default unless the proxy forwards the needed blocks.
• LiteLLM security: Be aware that LiteLLM versions 1.82.7 and 1.82.8 were flagged with a security advisory in Anthropic's gateway docs. Verify you are using a patched version.
• Feature parity: Parity depends on the server/proxy and model capabilities. For example, MCP tool search is disabled by default on non-first-party hosts unless the proxy forwards tool_reference blocks.

Networking and Security

• Inference server in a private subnet via VPN or AWS Client VPN
• Internal ALB with TLS termination
• Restrictive security groups + CloudWatch monitoring
• AWS PrivateLink for zero-trust patterns

Configure Claude Code

export ANTHROPIC_BASE_URL=https://your-vllm-endpoint.internal
export ANTHROPIC_AUTH_TOKEN=your-auth-token

Scenario Comparison

Best Practices for Production

Application Inference Profiles

Use Bedrock application inference profiles for tagged cost tracking and CloudWatch metrics by team, project, or environment. This provides granular visibility that simple Cost Explorer tags cannot. Use them later for per-team and per-project attribution once the initial rollout is stable.

Prompt Caching

Claude Code is a strong fit for Bedrock prompt caching, which can significantly reduce latency and costs for repetitive system context and codebase content. Check regional availability, as prompt caching may not be available in all regions.

Enterprise LLM Gateway

For centralized authentication, rate limiting, and cost controls, you can deploy an LLM Gateway in front of Bedrock via ANTHROPIC_BEDROCK_BASE_URL. If the gateway or a self-hosted model path bypasses Bedrock runtime invocation, implement equivalent centralized request/response logging, identity attribution, retention, and access controls because native Bedrock invocation logging no longer covers the full path.

Observability and Audit

Do not treat local Claude Code OpenTelemetry as the audit source of truth. It is useful for adoption, latency, UX, terminal/tool metrics, and developer-experience analysis, but it cannot be required from every engineer terminal and it does not replace AWS-side evidence.

The production audit baseline is Bedrock model invocation logging to CloudWatch Logs and/or S3, plus CloudTrail and AWS billing/cost telemetry. CloudTrail records Amazon Bedrock API activity, but prompt and response capture requires Bedrock invocation logging. For production, use CloudWatch Logs for operational review and S3 for long-term retention and large-payload delivery. Large payloads, image data, and document data may be delivered to S3, so the log bucket is sensitive production data and needs its own access review.

There is also a hard boundary: AWS model invocation logging is currently supported for calls through the bedrock-runtime endpoint, including InvokeModel and InvokeModelWithResponseStream. AWS notes that calls through other endpoints, such as the Responses API on bedrock-mantle, are not currently captured by invocation logging. If you use Mantle, a gateway, or self-hosted models, design equivalent logging before calling the rollout auditable.

IAM Policy Guardrails

• Do not give engineers aws-marketplace:Subscribe in day-to-day runtime roles.
• Do not give engineers Bedrock logging, model-access, or admin configuration permissions in runtime roles.
• Prefer a runtime allowlist of approved inference profiles and model IDs.
• Add explicit denies for runtime calls outside approved/logged Regions, bedrock:CallWithBearerToken, Bedrock create/update/delete/admin actions, and Marketplace subscribe/unsubscribe.

Terraform and State

Keep infrastructure code separate from helper code and templates. Put Bedrock logging, budgets, profiles, IAM, and guardrails under infra/bedrock; bootstrap the state backend separately under infra/state-backend. The state backend should use S3 versioning, SSE-KMS encryption, Block Public Access, and DynamoDB locking. Keep Terraform state and tfvars out of git.

Cost and Credits

Do not assume promotional credits or AWS funding cover every path. Confirm whether Bedrock, API Gateway, CloudWatch Logs, S3, NAT, and any gateway usage are covered before rollout. Create a Bedrock-specific budget, a total account budget, and an anomaly subscription. Measure value as cost per successful task, not only token spend.

Security and Compliance

Enable CloudTrail, Bedrock invocation logging, log-retention controls, KMS encryption, and access reviews for every log destination. Use Guardrails where content filtering is required, but treat them as one control in the request path, not as a substitute for IAM, logging, and approval gates. For self-hosted or gateway-backed models, implement inference-server access logging and centralized request/response capture before production use.

Troubleshooting

• Region issues: aws bedrock list-inference-profiles --region your-region
• "On-demand throughput isn't supported" error: Use an inference profile ID rather than a base model ID.
• Credential expiry: Configure awsAuthRefresh for automatic re-authentication.
• Self-hosted endpoint: Must implement /v1/messages. Use LiteLLM Proxy (patched version) for OpenAI-only endpoints.
• Desktop 3P does not launch in Bedrock mode: confirm inferenceProvider=bedrock, valid credentials, inferenceBedrockRegion, and inferenceModels as a JSON string.
• Cowork works but Code does not follow the same policy: validate the Code tab separately and distribute Claude Code managed-settings.json when you need to pin policies for coding sessions.

Note: Claude Code uses the Bedrock Invoke API and does not support the Converse API.

FAQ

What infrastructure do I need to deploy Claude Code on AWS?
At minimum, you need an AWS account with Bedrock access or a private Anthropic-compatible inference endpoint, IAM permissions for model access and Marketplace subscription, explicit region and network configuration, and operational controls such as model pinning, logging, and guardrails.

Does Bedrock include Claude web?
Not as the standard SaaS experience. Bedrock provides the model API and AWS development services; Claude web/iOS/Android apps, plan administration, hosted history, Projects, Artifacts, and managed connectors remain part of Claude Team and Enterprise plans. What changed is Desktop: Claude Desktop can use Bedrock in Cowork on 3P mode, with inference on Bedrock, local storage, and MDM/OS-managed configuration.

Can Claude Desktop now use Bedrock without sending conversations to Anthropic infrastructure?
Yes, for Cowork on 3P with inferenceProvider=bedrock, Anthropic documents that prompts, responses, files, and tool outputs are sent to the configured inference endpoint and stored on the local device, not Anthropic first-party infrastructure. Still, crash reports, analytics, updates, OTel, egress, and local policies need to be configured according to the organization’s security profile.

Do I need model access approval?
There is no manual approval queue. With the right AWS Marketplace permissions, complete Anthropic's First Time Use form and access is granted immediately. Initial setup may take a few minutes.

Are Bedrock API keys safe for production?
Bedrock API keys can be useful for exploration, but they are not recommended for human production workstation use. Prefer SSO or temporary role credentials, and deny bedrock:CallWithBearerToken in runtime roles unless a narrowly approved exception exists.

What breaks with self-hosted models?
Feature parity depends on the server/proxy and model capabilities. The best-documented caveat is MCP tool search: it is disabled by default on non-first-party hosts unless the proxy forwards tool_reference blocks. Specific LiteLLM versions (1.82.7–1.82.8) have known security advisories.

How Elevata Can Help

Setting up Claude Code is just the beginning. As an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, Elevata helps organizations build the complete AI-powered development platform on AWS.

• Claude Code and Claude Cowork on Amazon Bedrock deployment — end-to-end setup for Bedrock, Claude Desktop 3P, Cowork on 3P, and self-hosted scenarios, including IAM, MDM, managed settings, AWS profiles, Code-tab controls, and onboarding automation.
• AI infrastructure — GPU sizing, inference optimization, application inference profiles, prompt caching, Bedrock invocation logging, OTel enrichment, and cost/usage dashboards.
• Hybrid plan design — deciding where Bedrock and Claude Team/Enterprise each fit and building the integrations.
• Elevata Orbit — on-demand senior AWS engineers for setup, optimization, and ongoing operations.

Contact us at elevata.io to discuss your Claude Code deployment, AI strategy, or AWS infrastructure needs.