Quick Answer
Yes. As of 2026-04-21, teams can run Claude Cowork through Amazon Bedrock instead of Anthropic-hosted inference. The practical value is simple: knowledge workers get the Cowork desktop app for document analysis, multi-step research, file work, MCP connections, and scheduled tasks, while model inference, billing, and Bedrock API logging stay in the AWS environment you already manage. AWS announced the launch on 2026-04-21, and Anthropic's Cowork on 3P overview checked on 2026-04-22 says that for Bedrock deployments, conversation content stays off Anthropic infrastructure.
As of 2026-04-22, Anthropic documents two limits that matter in procurement and compliance reviews. First, the app still sends operational telemetry by default unless you disable it in managed configuration. Second, Cowork activity is not captured in Audit Logs, the Compliance API, or Data Exports, so OpenTelemetry helps with monitoring but does not replace formal audit logging for regulated workloads. Anthropic spells out those boundaries in its telemetry and egress docs and its Cowork monitoring guidance.
This setup is best for companies that already use AWS, need tighter data residency or procurement control, and want a desktop research workflow without buying another seat-based AI product. It is a poor fit if your team expects the full Claude Enterprise surface, because Anthropic's 3P feature matrix checked on 2026-04-22 still omits the Chat tab, Computer Use, Voice mode, Claude in Chrome, Anthropic 1P connectors, and project/plugin sharing. The public Anthropic plugin marketplace is also unavailable, though org-distributed plugins still work.
What Changed On 2026-04-21
AWS published an official launch post for Claude Cowork in Amazon Bedrock on 2026-04-21. That matters because Bedrock already had Claude models and Anthropic already had Cowork, but there was a missing middle layer for companies that wanted the Cowork experience without moving inference and billing back to Anthropic's first-party stack.
The launch closes that gap. AWS positions it as a way to extend Claude from developer workflows into broader knowledge work inside the same AWS control plane. Anthropic's third-party Cowork docs describe the same deployment mode as Cowork on 3P, where model inference goes to a provider you configure and conversation history stays on the user's device.
For an IT buyer or internal tools lead, this is not a generic AI headline. It changes the deployment choice. Until now, the usual decision was either:
- use Claude Enterprise and accept Anthropic-hosted inference
- build directly on Bedrock and give employees a custom internal app
Now there is a third path: keep the packaged desktop workflow, but route inference through Bedrock.
When This Setup Makes Sense
Use Claude Cowork in Amazon Bedrock when most of these are true:
- your company already has AWS IAM, CloudTrail, and network controls in place
- procurement prefers usage-based cloud billing over another seat contract
- you need region selection or geographic cross-Region controls inside AWS
- your users mainly need document analysis, research, synthesis, and file-based workflows
- device management through Jamf, Intune, Group Policy, or another MDM is already normal in your environment
Skip it when your real need is closer to a normal SaaS chatbot rollout:
- you want a web admin console for user management
- you need the Chat tab, Claude in Chrome, Voice mode, or Computer Use
- your team does not want to manage desktop configuration through MDM or OS policy
- you are not already committed to AWS for identity, logging, and network policy
Decision Table
| Question | Better answer | Why |
|---|---|---|
| Need Claude with AWS-side inference and billing? | Claude Cowork in Bedrock | AWS handles the inference path and billing |
| Need the broadest Claude Enterprise feature set? | Claude Enterprise | Cowork on 3P still has feature gaps |
| Need in-region controls or geographic routing? | Claude Cowork in Bedrock | Bedrock supports regional and cross-Region inference profiles |
| Need zero device management work? | Claude Enterprise | Cowork on 3P is configured through MDM or local policy |
| Need one desktop workflow for internal research and document work? | Claude Cowork in Bedrock | This is the main product shape AWS just announced |
What You Need Before Rollout
Before you start, confirm these prerequisites.
| Item | What to verify | Why it matters |
|---|---|---|
| Claude Desktop | Latest Claude Desktop for macOS 13+ or Windows 10/11; on Windows, enable Virtual Machine Platform and reboot once | Cowork on 3P uses the regular Claude Desktop app, and unsupported OS/runtime setup will block the pilot before Bedrock auth even starts |
| Bedrock access | Claude models enabled in your target AWS Region | The app needs a real Bedrock backend, not just an AWS account |
| Auth method | inferenceBedrockProfile, inferenceBedrockBearerToken, or inferenceCredentialHelper |
Anthropic's 3P config needs one supported credential path |
| Model list | Exact Bedrock inference-profile ID(s) you want to expose in inferenceModels |
Bedrock rollouts require an explicit model picker entry |
| Device management | Jamf, Intune, Group Policy, or another MDM | Managed rollout is the intended enterprise path |
| Firewall review | Bedrock endpoint, any Anthropic telemetry/update hosts you keep enabled, and your OTLP collector if you use one | Network policy can break the rollout before users even see Cowork |
| Pilot group | A small internal team with one concrete workflow | You want to validate useful output, not just successful login |
One detail that is easy to miss: Anthropic's current configuration reference stores managed values as strings in the OS preference store. That means booleans become "true" or "false", and array-typed keys such as inferenceModels and coworkEgressAllowedHosts must be JSON arrays encoded inside strings rather than native plist or registry arrays.
Step 1: Choose Your Bedrock Authentication Method
Anthropic's current configuration reference gives Bedrock teams two common auth paths in the setup UI, plus a credential-helper path for more locked-down environments.
| Method | Config key | Good for | Watch out for |
|---|---|---|---|
| AWS named profile | inferenceBedrockProfile |
Teams already using AWS CLI, SSO, or managed local profiles | The underlying principal needs bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream |
| Bedrock bearer token / API key | inferenceBedrockBearerToken |
Faster pilot setups and tools that prefer token auth | The underlying principal needs bedrock:CallWithBearerToken |
| Credential helper | inferenceCredentialHelper |
Enterprises that mint short-lived credentials from SSO or internal tooling | The helper must return valid provider credentials before the session starts |
AWS also published Bedrock API keys as a newer auth path for developer onboarding. The official AWS post says short-term keys can last up to 12 hours, while long-term keys can be set from 1 day to no expiration. For enterprise rollout, that does not automatically mean bearer token is the best option. If your company already governs AWS access through SSO and named profiles, profile-based auth is usually easier to audit and rotate.
If your environment forbids static tokens entirely, Anthropic also supports inferenceCredentialHelper so the app can fetch a short-lived credential at session start instead of storing a bearer token locally.
Step 2: Build The Configuration On One Test Machine First
Anthropic's current installation guide recommends a staged rollout: evaluate on one machine, allow required egress, export the validated configuration, then deploy it broadly.
The fastest safe path is:
- Install Claude Desktop from claude.com/download on a test machine.
- Open Help -> Troubleshooting -> Enable Developer Mode.
- Open Developer -> Configure third-party inference.
- Set the inference provider to
bedrock. - Fill in your AWS Region, either the Bedrock profile or bearer token, and at least one Bedrock model / inference-profile ID for the picker.
- Export a tested
.mobileconfigfor macOS or.regfile for Windows.
Anthropic's docs say the configuration window can also show the exact egress hosts required by the settings you chose. Use that output. Do not guess the firewall allowlist from memory.
Step 3: Understand The Keys That Actually Matter
You do not need every available key for a first pilot. You do need the right small set. The example below mirrors Anthropic's managed-preference format from Anthropic's configuration reference, where booleans and array-typed values are written as strings.
{
"enterpriseConfig": {
"inferenceProvider": "bedrock",
"inferenceBedrockRegion": "us-west-2",
"inferenceBedrockProfile": "company-bedrock",
"inferenceModels": "[\"<your-bedrock-inference-profile-id>\"]",
"deploymentOrganizationUuid": "11111111-2222-3333-4444-555555555555",
"disableDeploymentModeChooser": "true"
}
}
What each key does:
inferenceProvider: turns on third-party inference mode and points Claude Desktop at Bedrock.inferenceBedrockRegion: selects the AWS Region for inference.inferenceBedrockProfile: uses an AWS named profile already present on the machine.inferenceModels: required model list for Bedrock. Use the exact inference-profile ID you want users to see in the picker.deploymentOrganizationUuid: identifies your deployment for support and telemetry attribution.disableDeploymentModeChooser: sends users directly into the managed deployment mode instead of offering a first-run choice.
If you are testing a single unmanaged machine, Anthropic's docs say local config lives under ~/Library/Application Support/Claude-3p/claude_desktop_config.json inside the enterpriseConfig key on macOS. In a real rollout, a managed profile wins and local values are ignored.
Step 4: Make The AWS Side Match The Product Promise
The product story only holds if the AWS setup is real.
AWS and Anthropic both point to the same enterprise controls:
- inference runs in Bedrock in the AWS Region or inference profile you configure
- CloudTrail logs Bedrock API calls, including cross-Region requests in the source Region
- OpenTelemetry can export prompts, tool calls, file access, token counts, and errors to your own collector if you configure
otlpEndpoint - VPC endpoints can keep traffic off the public internet path where your architecture requires it
- Bedrock offers in-Region, geographic cross-Region, and global cross-Region inference profiles
That still leaves an important compliance limit. Anthropic's telemetry docs and Cowork monitoring guidance checked on 2026-04-22 say Cowork activity is not captured in Audit Logs, the Compliance API, or Data Exports, and its OpenTelemetry stream does not replace formal audit logging for compliance purposes. If your organization needs formal audit trails for regulated workloads, treat Bedrock logging as partial coverage rather than a full compliance answer.
The tradeoff on routing is clear in the AWS cross-Region inference docs and global cross-Region docs checked on 2026-04-22:
| Option | Best for | Limitation |
|---|---|---|
| Single Region | strict locality and simpler review | lower burst capacity |
| Geographic cross-Region inference | residency rules inside a geography such as US or EU | standard pricing and less throughput than global |
| Global cross-Region inference | maximum throughput and approximately 10% lower pricing in AWS docs checked on 2026-04-22 | not suitable for teams with strict geographic residency requirements, and SCPs must allow aws:RequestedRegion = "unspecified" |
If compliance is driving the project, pick the geography-constrained option first and treat global routing as an optimization only after policy review.
Step 5: Know Which Features Your Users Will Not Get
This is where many internal rollouts go sideways. Users hear "Claude Desktop in AWS" and assume they will get everything on claude.ai. Anthropic's feature matrix checked on 2026-04-22 says that is not true.
| Feature | Cowork on 3P status |
|---|---|
| Cowork tab | Available |
| Code tab | Available |
| Projects, artifacts, file upload, scheduled tasks, local and remote MCP | Available |
| Chat tab | Not available |
| Computer Use | Not available |
| Voice mode | Not available |
| Claude in Chrome | Not available |
| Anthropic 1P connectors | Not available yet |
| Project and plugin sharing | Not available |
| Public Anthropic plugin marketplace | Not available, though org-distributed plugins still work |
| Memory | Available, but stored on device rather than Anthropic infrastructure |
That means the rollout message should be honest. This is a strong desktop workflow for research, document work, and controlled tool use. It is not a one-for-one replacement for every first-party Claude surface.
A Good First Internal Use Case
The AWS launch post gives a product-manager example: upload customer meeting notes and requirements, connect Claude to documentation and web search through MCP, then ask for a grounded product brief.
That is a good pilot because it has a clear input, a reviewable output, and obvious acceptance criteria.
You can start with a prompt like this:
You are helping prepare an internal product brief.
Inputs in this workspace:
- customer interview notes
- current project requirements
- latest architecture constraints
Task:
1. Extract the repeated customer requests.
2. Flag conflicts between requests and current requirements.
3. Draft a one-page product brief with risks, open questions, and a recommended scope.
4. Cite which uploaded file supports each major recommendation.
Return format:
- Problem statement
- Recommended scope
- Risks and constraints
- Open questions
- Source mapping
This is a better pilot than a vague "show us what Cowork can do" session. The output is easier to judge, and the failure cases are easier to spot.
The Biggest Rollout Mistakes
Treating 3P Cowork like a pure SaaS switch
It is not. Anthropic's own docs make MDM, policy keys, and network egress part of the deployment. If your team hates desktop policy management, that friction is part of the cost.
Ignoring feature gaps until after launch
If users expect Chat, browser features, or Computer Use, tell them up front that those are missing in the current 3P deployment.
Using the wrong auth method for the company you actually have
Bearer tokens are useful, but they are not automatically the most governable option. In AWS-heavy environments, named profiles and existing IAM patterns may be the cleaner long-term choice.
Piloting without a bounded workflow
A generic trial creates generic feedback. Start with one document-heavy workflow, one team, and one acceptance rubric.
FAQ
Is Claude Cowork in Amazon Bedrock sold per seat?
Not for inference usage. Anthropic's feature matrix and AWS's launch post describe Cowork on 3P as token-based consumption billed by the cloud provider rather than Anthropic seat licensing. Separately, Anthropic's legal page says the Claude Desktop application still remains subject to Anthropic's commercial terms.
Does Anthropic see our prompts and files in this setup?
Anthropic's 3P docs checked on 2026-04-22 say that for Bedrock and Vertex deployments, prompts, responses, files, and tool outputs go to your configured inference endpoint and are stored on the local machine. Anthropic still documents separate crash reporting, analytics, and auto-update paths, and says those can be configured or disabled.
Is this suitable for regulated workloads?
Not by default. Anthropic's Cowork documentation checked on 2026-04-22 says activity is not captured in Audit Logs, the Compliance API, or Data Exports, and its OpenTelemetry export does not replace those controls for compliance purposes.
Can we roll this out without MDM?
You can evaluate it on a single machine with local configuration, but Anthropic's documentation positions MDM or OS policy as the standard rollout path for organizations.
Is this better than building our own internal Bedrock app?
It is better when you want a ready-made desktop workflow now. It is worse when you need deep product customization, your own UX, or tighter integration into internal systems than MCP and managed desktop policy can provide.
Bottom Line
Claude Cowork in Amazon Bedrock is a real new deployment option, not just another AI partnership announcement. For AWS-centered teams, the appeal is straightforward: you keep the Cowork desktop workflow while moving inference, billing, region control, and Bedrock-side API logging into AWS.
That does not make it the default answer for everyone. The setup asks you to own device policy, network policy, and user expectation management, while still deciding what to do about Anthropic telemetry, desktop update policy, and the lack of formal Cowork audit trails. If you already have those muscles, this is a practical way to give non-developers a more capable internal AI desktop. If you do not, Claude Enterprise will usually be simpler.
Verification Note
Verified on 2026-04-22.
- Checked the AWS launch post for the 2026-04-21 announcement, Bedrock positioning, supported workflow examples, data-control claims, and the statement that pricing is consumption-based through AWS:
https://aws.amazon.com/blogs/machine-learning/from-developer-desks-to-the-whole-organization-running-claude-cowork-in-amazon-bedrock/ - Checked Anthropic's Cowork on 3P overview for local conversation storage, Bedrock and Vertex data-routing claims, security posture, and target deployment scenarios:
https://claude.com/docs/cowork/3p/overview - Checked Anthropic's installation guide for the staged rollout flow, Developer menu path, export formats, and managed-vs-local configuration behavior:
https://claude.com/docs/cowork/3p/installation - Checked Anthropic's configuration reference for required Bedrock keys, config precedence, array-string handling, model-list requirements, optional credential helper support, and IAM permission requirements for
inferenceBedrockProfileandinferenceBedrockBearerToken:https://claude.com/docs/cowork/3p/configuration - Checked Anthropic's 3P feature matrix for current missing features, token-based pricing, org-plugin marketplace behavior, and on-device memory behavior:
https://claude.com/docs/cowork/3p/feature-matrix - Checked Anthropic's telemetry and egress page for default telemetry categories, disablement controls, and
otlpEndpointbehavior:https://claude.com/docs/cowork/3p/telemetry - Checked Anthropic's legal and compliance page for commercial-terms applicability and current 3P compliance posture:
https://claude.com/docs/cowork/3p/legal - Checked Anthropic's OpenTelemetry and Team/Enterprise Cowork guidance for current audit-log, Compliance API, and Data Export limitations:
https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetryandhttps://support.claude.com/en/articles/13455879-use-claude-cowork-on-team-and-enterprise-plans - Checked AWS Bedrock documentation for current cross-Region inference tradeoffs, CloudTrail behavior in the source Region, and the approximate 10% savings note for global routing:
https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.htmlandhttps://docs.aws.amazon.com/bedrock/latest/userguide/global-cross-region-inference.html - Checked AWS's Bedrock API key announcement for current short-term and long-term API key behavior:
https://aws.amazon.com/blogs/machine-learning/accelerate-ai-development-with-amazon-bedrock-api-keys/