Browse the bible
Foundations
Getting started
Capabilities
Security & governance
Workflows
Prompt library
Rollout playbook
Troubleshooting
Reference
Security & governance · Cowork on third-party platforms — running Claude Cowork on your own cloud

Cowork on Amazon Bedrock — running Claude Cowork inside your AWS tenant

Deploy Claude Cowork through Amazon Bedrock — conversation data stays in your AWS account, IAM-scoped, billed through your existing AWS agreement. Procurement and rollout shape included.

Updated 2026-04-28Read 8 min

TL;DR. Cowork on Bedrock is the deployment mode of Claude Desktop where model inference runs through Amazon Bedrock in the customer's own AWS account. Conversation data does not leave the AWS tenant; residency is determined by the AWS region selected for inference plus the user's device location. Billing is consumption-based through the existing AWS agreement, with no seat licensing from Anthropic. The trade-off is that three first-party features are unavailable — the Chat tab, Computer Use, and the Skills Marketplace. Best for AWS-heavy enterprises with platform-engineering capacity; overkill for general mid-market.

When Cowork on Bedrock is the right answer#

Three signals, all of which usually need to be true:

  • The organisation is materially committed to AWS — workloads, billing relationship, security controls, IAM model — and a new SaaS processor would create friction with that posture.
  • A compliance program (FedRAMP, HIPAA with PHI in scope, certain financial-services controls) requires inference to stay inside an existing AWS boundary the organisation has already certified.
  • Platform engineering or IT has the capacity to own MDM rollout, telemetry export, IAM scoping, and inference-budget management — Bedrock-deployed Cowork is admin-heavier than first-party Cowork.

If only one of these is true, hosted Cowork on Team or Enterprise is usually the simpler and faster path.

Architecture, in one diagram's worth of words#

The Claude Desktop app runs locally on the user's machine, with the Cowork tab loaded from a bundled local web application. At launch, the app reads MDM-managed configuration that sets inferenceProvider to bedrock, plus an inferenceBedrockRegion. Inference requests flow directly from the user's machine to the configured Bedrock endpoint over the customer's AWS network path; AWS IAM credentials authorise the calls. Conversation history persists on local disk. Tool execution runs in the same Cowork sandbox VM used in first-party Cowork.

The desktop app's only outbound calls to Anthropic are crash reporting, product analytics (scrubbed of conversation and user data), and auto-updates. Each can be disabled independently in the managed configuration.

Data residency posture#

Determined by two inputs and nothing else:

  • inferenceBedrockRegion — the AWS region where Claude inference runs (e.g., us-east-1, eu-central-1, ap-southeast-2). Conversations, files, and tool outputs go to this endpoint and are subject to AWS's regional isolation.
  • The user's device. Conversation history is stored on the user's local disk; the device's physical location is part of the residency story. Multi-region orgs typically deploy distinct MDM profiles per geography.

There is no Anthropic-side residency layer to negotiate. The DPA conversation is between the customer and AWS for inference, plus a much narrower one with Anthropic for the desktop app's diagnostic telemetry — which can be disabled.

Authentication and access#

  • No Anthropic account. The app runs in 3P mode with local device identity. There is no claude.ai login.
  • AWS IAM authorises inference calls. The customer scopes the IAM policy that the desktop app uses to invoke Bedrock — least-privilege is straightforward (only bedrock:InvokeModel* on the specific model ARNs in the chosen region).
  • MDM enforces config. Jamf, Kandji, Mosyle, Workspace ONE for macOS; Intune or Group Policy for Windows. End users cannot override an admin profile.
  • SSO via the OS layer. User identity lives in the customer's existing identity provider, surfaced to the desktop app through OS sign-in. Cowork itself does not implement an SSO flow on the 3P routes.

What's available, what's not#

The full feature matrix is on Cowork on 3P feature matrix. The headline subtractions for the Bedrock route:

  • Chat tab — Claude Desktop's standard chat interface is not available; only Cowork and Code tabs are.
  • Computer Use — currently in research preview on first-party only.
  • Skills Marketplace — the in-app discovery / install flow for skills. Skills the customer ships themselves (via MDM, or via the plugin mechanism) still run.

What is preserved: Cowork's full agentic loop (multi-step tasks, sub-agents, file creation), the Code tab, projects, artifacts, memory, file upload/export, MCP connectors, plugins, customer-deployed skills, and remote connectors.

Billing#

Consumption-based through the customer's existing AWS agreement: model invocations on Bedrock at the published per-token rate for the chosen Claude model and region. There is no separate Anthropic seat licensing on this route. From a procurement perspective:

  • The cost line lives in the AWS bill, not in a new SaaS contract.
  • Usage scales with actual workload — there is no unused-seat tax on idle users, but heavy-use power users can spend more than a flat seat would.
  • Build a forecasting model before rollout. Most mid-market deployments under-estimate inference spend in the first month because Cowork's agentic loops are token-heavier than chat.

Telemetry and audit#

Two independent paths:

  • Anthropic-bound telemetry (off by default in a hardened deployment): crash reports, product analytics, auto-updates. Each disabled via a managed configuration key. With all three off, the desktop app makes no outbound calls to Anthropic.
  • Customer-bound telemetry (recommended on): full session activity — prompts, tool calls, token counts — exported to the customer's OpenTelemetry collector. This is the audit substrate; do not skip it.

For regulated deployments, configure the OpenTelemetry export first, validate it carries the events the security team needs, and only then disable the Anthropic-bound paths.

Rollout shape#

A typical Cowork-on-Bedrock deployment for a mid-market regulated team — finance, legal, ops at a 200–1,500-person company — runs on a four-stage timeline:

  1. Pre-flight (weeks 1–2). AWS region selection, IAM policy authoring, model availability check, MDM profile drafting, OpenTelemetry collector readiness.
  2. Pilot (weeks 3–6). Five to ten users; full telemetry on; the Anthropic-bound paths still on for diagnostic purposes; weekly check-in on cost burn rate.
  3. Hardening (weeks 7–8). Anthropic-bound telemetry disabled; egress allowlist tightened; production MDM profile finalised; on-call playbook written.
  4. Rollout (week 9 onward). Per-function expansion, with a usage-monitoring dashboard live in the customer's existing observability stack.

Tinkso runs this in a 60-day engagement; teams attempting it in-house should budget 90.

Common procurement objections, answered#

"How is this different from just using Claude through Bedrock today?" Bedrock has supported the Claude API directly for some time. Cowork on Bedrock is the desktop application — the agentic Cowork experience, file system access, sub-agents, the Code tab — pointed at Bedrock for inference. It is not new model availability; it is a new deployment shape for the desktop product.

"Why not stay on hosted Cowork with an Enterprise contract?" If the compliance program accepts SaaS processors, that is the right answer. 3P is for the cases where a SaaS processor is excluded by policy or contract — typically defence, federal, healthcare-PHI, or specific financial-services controls.

"What's the support relationship?" Anthropic supports the desktop app and the model behaviour. AWS supports Bedrock availability and infrastructure. The customer — or Tinkso, on their behalf — owns the deployment surface: MDM, telemetry, IAM, and the inference budget.

Tinkso's take#

We deploy Cowork on Bedrock when one or both of these are true: the customer has an AWS-led architecture team that already runs Bedrock workloads in production, or the customer has a compliance constraint that explicitly forecloses first-party Cowork. In every other case, hosted Cowork on Enterprise is faster to stand up, cheaper to operate, and ships features sooner.

When we do deploy on Bedrock, we never skip three things: a written cost-forecasting note before pilot, the OpenTelemetry export wired up before the first user logs in, and a documented procedure for what happens when Anthropic ships a feature that requires first-party (today: Computer Use). Buyers who skip those end up renegotiating internally three months in.

Try this#

Run a 30-minute working session with platform engineering and security, mapping each section above to "we own this," "vendor-managed," or "needs decision." That worksheet is the first artifact of a Cowork-on-Bedrock procurement track.

Need help applying this?

Book a 30-minute call. We'll ask where you are, what your team needs, and which systems Cowork should touch.

Last reviewed: 28 April 2026 · The Cowork Bible · Tinkso