Share one Claude subscription to cut environment sprawl and centralise access

Implementing AWS's multi‑environment pattern for Claude Platform means you can run production inference, developer laptops and external CI from one subscription while isolating traffic by workspace — an upfront configuration task that reduces per‑environment drift and centralises access control.

What actually changed

AWS published a step‑by‑step implementation for Multi‑Environment Access for Claude Platform on AWS (CPonAWS). The guidance ties three common environments — production on AWS, developer laptops for local iteration, and external services (other clouds or on‑prem CI/CD) — to a single Claude subscription while enforcing workspace‑level isolation between production and development traffic. The post walks through deploying a dedicated AI Services account, configuring cross‑account SigV4 for AWS workloads, generating workspace‑scoped API keys for developers, and wiring up OIDC federation for external environments. Every step in the post includes a CLI command, console instruction or code snippet to follow.

Who it affects

• Small teams running Claude Platform inference across mixed environments: production workloads on AWS, developers working locally, and CI/CD or external services.
• Organisations that previously used separate subscriptions or ad‑hoc authentication per environment; the pattern expects a single subscription and workspace separation.
• Teams that need predictable authentication paths for cross‑account AWS workloads and for external service integration via OIDC.

What it costs or what it replaces

• The announcement does not state pricing.
• It replaces the ad‑hoc approach of separate subscriptions or inconsistent auth setups per environment with a single‑subscription model plus workspace‑level isolation and a repeatable cross‑account role pattern.

How to implement this week (step‑by‑step)

1. Read the AWS Machine Learning Blog post (published 1 Oct 2026) and gather the included CLI commands and console steps. The blog contains the concrete commands and snippets you will run.
2. Create a dedicated AI Services account inside your organisation and follow the post's instructions to provision it. Treat this account as the central point for Claude Platform access.
3. Configure cross‑account SigV4 for your AWS production workloads following the provided role pattern; this establishes trusted, SigV4‑signed calls from your AWS workloads into the AI Services account.
4. In the AI Services workspace, generate workspace‑scoped API keys for developer laptops; distribute these keys to developers for local iteration and restrict them to non‑production workspaces.
5. Wire up OIDC federation for external environments (other clouds or on‑prem CI/CD) as shown in the post, using the supplied console and CLI steps to create the trust relationship.
6. If you have more environments or teams, create a workspace per team or workload and repeat the cross‑account role pattern for each workspace.

What we don't know

• Whether centralising to a single subscription changes your billing visibility or billing accounts.
• Any limits or quotas on workspace creation, API keys or federation tokens; the post summary does not list limits.
• Exact IAM role names, policy JSON or CLI flags — the summary says the post includes commands and snippets, but those specifics are in the full blog text.
• Operational recommendations for rotating workspace API keys or automating key distribution beyond the examples in the post.

What to do next

1. Open the AWS Machine Learning Blog post (Implementing Multi‑Environment Access for Claude Platform on AWS, 1 Oct 2026) and copy the CLI commands and console steps into a sandbox account.
2. Deploy the dedicated AI Services account and implement cross‑account SigV4, workspace API keys and OIDC federation in a development workspace; run an end‑to‑end test from a developer laptop and from an external CI job.
3. If tests succeed, replicate the workspace + cross‑account role pattern for production and any additional team workspaces, then formalise key rotation and monitoring as part of your deployment checklist.