Claude on your terms: a practical guide to Claude Desktop on Amazon Bedrock

There’s a good chance people in your company already use Claude. Some on the free tier, some on personal Pro subscriptions, most of them pasting work content into a chat window that nobody in IT has ever reviewed. AI adoption tends to happen bottom-up, on consumer accounts, outside the company’s security perimeter and outside its billing.

Since this spring there’s been a clean way out. The full Claude Desktop experience (Chat, Claude Cowork for working with files, and Claude Code for engineers) can run entirely on Amazon Bedrock, in your own AWS account. It’s the same application your users already know, but every model call goes to an AWS region you choose and shows up on your AWS bill.

This guide covers three levels of setup: the first two step by step, the third as a short introduction at the end, because it deserves an article of its own:

1. The quick start — one Amazon Bedrock API key, one laptop, about fifteen minutes. A good way to see it working in practice, and enough if you’re solo or in a small team.
2. SSO for the whole organization — every user signs in with their own corporate identity through AWS IAM Identity Center. This is the path for a proper rollout, when there are many users to manage and orchestrate.
3. The Claude Apps Gateway — a self-hosted control plane that adds per-group policies and hard spend limits on top of everything above.

Before the hands-on part, a quick look at what you actually get in this setup and what you give up.

What you actually get (and what you don’t)

Claude Desktop on Amazon Bedrock is not a separate corporate edition. It’s the regular Claude desktop app, just running with model inference on Amazon Bedrock instead of Anthropic’s servers. Inside the app you get three surfaces:

• Chat — the familiar conversational Claude, for quick answers and everyday questions.
• Claude Cowork — the agentic workspace: point it at files and folders and it does multi-step work that ends in a deliverable, not just a reply. Think research across twenty PDFs, or cleaning up a quarter’s worth of spreadsheets.
• Claude Code — full agentic coding, embedded in the same app, for the engineering teams.

Access doesn’t have to be all-or-nothing, either. Which surfaces are enabled is part of the managed configuration file your IT distributes (more on that file in a moment), so different groups can receive different profiles: Chat for the whole company, Cowork for the analysts, Claude Code only for engineering.

There’s no per-seat license from Anthropic in this setup. You pay for tokens, through Amazon Bedrock, on the AWS bill you already have. A user who tries Claude twice a month costs you close to nothing, and there’s no shelf of unused licenses to explain at renewal time.

The other big reason to run Claude this way is where the data goes. In this mode the app routes model inference exclusively through Amazon Bedrock: prompts and files go to the AWS regions you configure and nowhere else, and neither your inputs nor Claude’s outputs are used to train the models. You pick the geography through Bedrock inference profiles: a single region, a group of regions within one geography, or global routing for maximum availability. If you plan to run this in an EU organization, this matters: you can pin inference to European regions like Frankfurt and keep the data inside the EU. And it’s all auditable with AWS tools your team already uses: AWS CloudTrail for the audit log, Amazon VPC endpoints for network isolation, Amazon CloudWatch for usage metrics.

Now for what you give up. Some features stay behind on Anthropic’s own platform and aren’t available in this mode: Claude Design, Computer Use, voice mode, and Claude in Chrome among them. This setup is also not Claude Enterprise: there’s no claude.ai admin console, no SCIM provisioning, no Claude on web and mobile. The trade is control over the inference path in exchange for running things yourself. For most teams the core Chat–Cowork–Code workflow is all they need, but check the missing pieces against your own plans before committing.

Three ways to let people in

The setup itself is less complicated than it sounds. Claude Desktop needs to know four things: which provider to send inference to, in which region, which models to offer, and how to authenticate. The first three are a few fields you’ll see in a minute. The last one, authentication, is the real decision, because it determines how secure the setup is, what you can see, and what you can control.

To keep the three options straight, let’s build an analogy of an office building, where each setup is a different way of letting people in.

Option one: the shared key (a Amazon Bedrock API key). You generate one API key and put it in the app’s configuration. That’s the whole setup, and it’s what we’ll do in the quick start. It works like a single shared key to the office front door: anyone holding it gets in, nobody can tell afterwards who exactly was there, and if it leaks you change the lock and hand a new key to everyone. On the AWS bill you see one total, not who spent what. Fine for testing and small teams; not something to roll out company-wide.

Option two: a personal badge for everyone (SSO with AWS IAM Identity Center). Here the API key disappears entirely. Each person signs in with their own company login, and behind the scenes the app receives temporary credentials that expire and renew on their own. It’s the office badge system: the entry log shows who came in and when, and when someone leaves the company, you deactivate their badge in one place. You can finally see usage per person, and there’s no long-lived secret sitting on anyone’s laptop. What this doesn’t give you is hard enforcement: the app can carry a per-user soft token cap in its configuration, but nobody actually gets stopped at the door for spending too much; that only comes with option three.

Option three: the reception desk (the Claude Apps Gateway). In the first two options, every laptop talks to AWS directly. Here you put a small service of your own in between, and every request passes through it, the way every visitor passes a reception desk: it checks badges, decides which floors each group can access (different models for different teams), logs every entry, and can refuse entry once someone hits their limit. Hard spend caps and per-group policies live here and only here. It’s also the only option where you run a service of your own, which makes it the biggest commitment of the three.

There’s technically a fourth option (a named AWS profile, for developers who already use the AWS CLI every day), but it solves the same problem as the badge for a narrower audience, so we’ll leave it at this mention.

One practical note before we start clicking. In the quick start, you’ll set everything by hand in the app’s settings window. In a company rollout nobody walks desk to desk: that same settings window exports the whole configuration to a small file, and your IT team distributes it to every company laptop with the tooling it already uses to manage employee computers (Microsoft Intune, Jamf, or Group Policy, whichever your organization runs). Claude Desktop reads the file on launch, and every setup in this article ends with exactly such a file.

The 15-minute version: API Key

Time to see it working. This is option one from the previous section, the API-key approach. You need two things: an AWS account with Claude models enabled in Amazon Bedrock, and the regular Claude Desktop app from Anthropic installed on your machine: the same download everyone else uses, no special build. If your AWS account is fresh, go to the Amazon Bedrock console and enable the Claude models under Model access first. There’s a one-time use-case form from Anthropic for the account, and that’s the one prerequisite that can stretch the fifteen minutes.

Step 1: Generate an API key

In the Amazon Bedrock console, open API keys and generate a long-term key. Two things I liked here. You can give the key a short expiry (mine got two days, since this was a test). And the console quietly creates a dedicated IAM user for the key and attaches AWS’s managed Bedrock access policy to it, covering the bedrock:CallWithBearerToken permission the key needs, so there’s no manual IAM work at all.

Step 2: Enable Developer Mode in Claude Desktop

The menu you need is hidden by default. In the app, go to Help → Troubleshooting → Enable Developer Mode, and a Developer menu appears in the menu bar. Worth noting: you don’t sign in to the app at any point. I did the whole setup straight from the sign-in screen, no claude.ai account involved.

Step 3: Point the app at Amazon Bedrock

Open Developer → Configure Third-Party Inference…. In the Connection section, set the inference provider to Bedrock, pick your AWS region (eu-central-1 in my case), set the credential kind to Static API key and paste the key from step 1. There’s a Test connection button right next to the credentials, and an Export menu in the top corner that we’ll come back to.

Step 4: Pin your models

With an API key, the app can auto-discover Claude models available in your account, and at first that feels like magic — until you pick one from the list and get an access-denied error. Discovery can surface models your account can’t actually invoke, legacy versions among them.

Step 5: It’s ready

That’s the whole setup: Chat, Cowork, and Claude Code now run against your own AWS account. As a final confirmation, I opened a session and asked Claude which model it’s running on, checking that it comes back with the full Amazon Bedrock model ID, region prefix included. It answered with eu.anthropic.claude-sonnet-4-5-20250929-v1:0, and the app shows a small “Bedrock” label next to the username in the corner. Inference is going exactly where it should.

So, is fifteen minutes honest? In my case yes, comfortably. The one fair caveat: Claude models were already enabled in the account. If you’re starting from zero, the model-access request adds time that isn’t entirely in your control.

One more thing before we scale up. That Export menu in the corner of the configuration window packages everything you just clicked into a .mobileconfig file for macOS or a .reg file for Windows. This is the bridge to the next section: instead of one laptop configured by hand, your device management pushes a file like that to every laptop in the company.

Scaling up: SSO for the whole organization

This is option two, the personal badge: no API key anywhere, everyone signs in as themselves. The badge system on the AWS side is IAM Identity Center, and setting it up means connecting three pieces: users (the people), a permission set (what their badge opens), and an assignment (which AWS account they can enter). It’s more clicking than the quick start, but all of it is one-time work for whoever administers your AWS. End users only ever see a sign-in page.

Step 1: Enable IAM Identity Center

Enable it at the organization level, or confirm it already is. Note the region it runs in: it can be different from your Amazon Bedrock region, and you’ll need both values later.

Step 2: Decide where users come from

For a pilot, create users directly in Identity Center’s built-in directory. For a real rollout, connect the identity provider your company already uses (Microsoft Entra ID, Okta, Google Workspace) as the identity source, so people sign in with the corporate login they already know. Everything below works the same either way.

Step 3: Create a permission set

This is the badge template. It only needs to allow Amazon Bedrock inference, and it’s worth scoping it to exactly that instead of a blanket "Resource": "*":

{  "Version": "2012-10-17",  "Statement": [{    "Effect": "Allow",    "Action": [      "bedrock:InvokeModel",      "bedrock:InvokeModelWithResponseStream"    ],    "Resource": [      "arn:aws:bedrock:<region>:<account-id>:inference-profile/eu.anthropic.*",      "arn:aws:bedrock:*::foundation-model/anthropic.*"    ]  }]}

Two notes on the resource list. It names both ARN families on purpose: a call through a cross-region inference profile needs permission on the profile and on the underlying foundation models, so granting only one of them fails. And it’s scoped to Anthropic models in one geography (eu.anthropic.*; swap the prefix for yours), which matters because the model list you set in the app is a picker filter, not a security boundary; IAM is where access is actually enforced, so keep the grant as narrow as the deployment allows.

Give it a clear name like ClaudeDesktopBedrock; you’ll type it into the app’s configuration later. And set the session duration to 8–12 hours: it decides how long someone works before signing in again, so make it cover a full working day.

Step 4: Assign users to the account

Still in Identity Center, select the AWS account that hosts Amazon Bedrock and assign your users or groups to it with the permission set from step 3. Then write down four values, because the app will ask for exactly these:

• AWS access portal URL — it looks like https://d-xxxxxxxxxx.awsapps.com/start
• Identity Center region — its home region, not necessarily your Amazon Bedrock region
• AWS account ID — the 12 digits of the account that hosts Bedrock
• Permission set name — ClaudeDesktopBedrock in our example

Step 5: Configure the app

Open Claude Desktop and go to Developer → Configure Third-Party Inference…, the same window as in the quick start. Remove the API key and switch Credential kind to Interactive sign-in, then fill in the four fields with the values from step 4: AWS SSO start URL, AWS SSO region, AWS SSO account ID, and AWS SSO role name (that’s the permission set name). All four are required (the window keeps count at the bottom until they’re in), and a partial set is ignored, leaving only a warning in the logs.

The model list is on you again, and this time it’s mandatory: with Interactive sign-in there is no auto-discovery, so enter the inference-profile IDs exactly like in the quick start’s step 4. The first entry becomes the default model, and the Display name field is worth filling in: your users will see “Claude Sonnet 4.5” in the model picker instead of a raw model ID.

Step 6: Export and hand it over

Hit Export, take the .mobileconfig or .reg file to your IT team, and from here it’s routine device management: the file goes out to company laptops like any other managed setting. A new employee installs Claude Desktop, and the right configuration is already waiting on their machine.

What the user experiences is the part I like most about this path. On first launch the app shows a Sign in with AWS page. One click opens the browser: the corporate login they use every day, a short verification code to compare between the app and the browser, and they’re back in the app, ready to work. No AWS CLI, no terminal, nothing to set up by hand. From then on the app mints temporary AWS credentials for each session and refreshes them quietly in the background; only when the portal session finally expires does a “Sign in again” prompt appear inside the app. And on the AWS side, every model call in AWS CloudTrail now carries the name of the person who made it — the badge doing exactly what badges are for.

Two details worth knowing before you call it done. The Test connection button reports that it can’t verify the connection in this mode. That’s expected behavior, not a failure: the app simply can’t sign Amazon Bedrock requests outside a running session. And one configuration file means one AWS account and one permission set for everyone who receives it. To give different groups different Amazon Bedrock permissions, you deploy separate configuration profiles with different role names.

Things to watch out for

A handful of notes that don’t fit neatly into any step, but will save you a support ticket or two.

Bedrock quotas. Amazon Bedrock enforces per-model, per-region quotas on requests and tokens per minute, and on a fresh account they tend to be conservative. A single tester won’t notice; fifty people using Cowork will. Check the Service Quotas console for your models before a wider rollout and request increases early, because they’re reviewed rather than granted on the spot.

Models and regions. The model list you configure has to match what your account can actually invoke in the region you set, which is exactly why the quick start’s discovery gotcha exists. Stick to inference-profile IDs you’ve tested, and remember that a model available in us-east-1 isn’t automatically available in eu-central-1.

Network egress. If your company runs a strict firewall, two things matter. The app documents its own required hostnames in the Egress section of the configuration window; export that list for your network team. Separately, the coworkEgressAllowedHosts setting controls what Cowork and Code sessions can reach from their sandbox (web fetches, shell commands, package installs), with wildcard and port support, like ["api.github.com", "*.corp.com", "pypi.org:443"]. It governs agent tool traffic only; inference and MCP connections have their own configuration.

Telemetry, in both directions. The app sends crash reports and product analytics (no message content) to Anthropic; both can be switched off with the disableEssentialTelemetry and disableNonessentialTelemetry keys if policy demands it. More interesting is the other direction: point otlpEndpoint at your own OpenTelemetry collector and usage metrics flow into your own observability stack: Amazon CloudWatch, Grafana, whatever you run. Message content is never included unless you explicitly opt specific categories in.

Per-user token caps. The Limits section of the configuration (inferenceMaxTokensPerWindow together with inferenceTokenWindowHours) sets a per-user token cap over a tumbling time window. Useful as a brake, but know what you’re getting: it’s counted client-side and it’s a soft cap, not a wall. Spending limits that actually block requests are the gateway’s job, in the next section.

Updates. By default the app updates itself from Anthropic’s servers. On managed fleets you can cap how long an update can be postponed (autoUpdaterEnforcementHours) or disable auto-updates entirely and push versions yourself (disableAutoUpdates). Worth deciding deliberately, because “everyone on whatever version” and “IT ships every release” are different support models.

When you outgrow this: the Claude Apps Gateway

Sooner or later, someone will ask the questions the badge can’t answer. Can contractors get only the cheaper model? Can we give everyone in a team a monthly budget — and have the cap actually stop requests? That’s when you need the reception desk from our analogy, and it now has an official implementation: the Claude Apps Gateway, announced by Anthropic in mid-2026.

The gateway is a self-hosted service (a single stateless container backed by a PostgreSQL database) that you run on your own private network, and it changes the architecture in one fundamental way: laptops stop talking to AWS entirely. The gateway holds the only cloud credential, users sign in to it through your identity provider (Okta, Microsoft Entra ID, Google Workspace, or any OIDC-compliant IdP), and every request passes through it. That’s what makes the reception-desk features possible: model access per IdP group enforced server-side, so a modified client can’t bypass it; centrally managed settings that differ per team; daily, weekly, and monthly spend limits at the organization, group, or user level that reject requests once exceeded; and usage telemetry relayed to your observability stack, stamped with the identity of the developer who generated it. Both Claude Code and Claude Desktop can connect to it. One more trick the previous setups can’t do: the gateway routes to multiple upstreams with automatic failover (Amazon Bedrock, Claude Platform on AWS, and other providers), so you can change regions or providers without anyone reconfiguring their laptop.

It’s also AWS-friendly in practice. The reference deployment runs the gateway on ECS Fargate (or EKS) with Amazon RDS for PostgreSQL behind an internal Application Load Balancer, secrets in AWS Secrets Manager, and an IAM task role for Amazon Bedrock. No static cloud keys anywhere in the chain. Both Anthropic and AWS publish this as ready-to-adapt code, from an idempotent setup script to Terraform and CDK samples. There’s no per-seat fee for the gateway itself, and with Amazon Bedrock as the upstream your data still never leaves your AWS account.

The price of all this is in the name of our analogy: a reception desk needs staffing. You deploy the gateway, upgrade it, operate it, and keep it on a private network — it’s a real piece of infrastructure with a database behind it, not a checkbox. For a small team that’s overkill; for an organization with multiple teams, contractors, and a finance department that wants guarantees, it’s exactly the control layer the first two setups are missing. Deploying it end to end is a hands-on story of its own, and it deserves its own article — this was just the tour of the lobby.

Wrapping up

The three setups in this guide are really one path, walked as far as your organization needs. An API key gets Claude Desktop running on your own AWS account in fifteen minutes. For a solo developer or a small team, that simple setup is a good enough way to work with Chat, Cowork, and Claude Code on Amazon Bedrock every day, not just a demo. IAM Identity Center turns it into a company rollout: every user signs in as themselves, nothing long-lived sits on any laptop, and one exported file pushed by IT covers the whole company. And when governance questions get serious, the Claude Apps Gateway adds the enforcement layer: per-group policies and spend limits that actually say no.

What stays constant across all three is the part that matters: the same Claude your people already know, running on infrastructure you control, in a region you choose, billed for what’s actually used. Claude, on your terms.

Planning a Claude rollout on AWS in your organization? The contact form below this article reaches our team at Chaos Gears. If you have technical questions, reach me directly at gracjan.strzelec@chaosgears.com or on LinkedIn.

Resources

• Deploy Claude Desktop with Amazon Bedrock — the official docs this tutorial follows
• Claude Desktop configuration reference — every managed configuration key
• From developer desks to the whole organization: Running Claude Desktop on Amazon Bedrock (AWS blog)
• Introducing the Claude apps gateway for Amazon Bedrock and Google Cloud (Anthropic)
• Claude apps gateway documentation and the AWS deployment example
• Deploying Anthropic Claude apps gateway for AWS for enterprise workloads (AWS blog)
• AWS samples for the Claude apps gateway (GitHub)