On Claude Platform on AWS, a workspace is where three concerns converge. Usage, quotas, cost, files, batches, and Skills all roll up per workspace, so it's your cost-attribution unit. The workspace ARN is the primary IAM resource, so it's your permission boundary. And prompt caches are isolated per workspace, so it's a data boundary too. That triple role dictates the strategy: one workspace per application per environment.
Why one workspace per production application
Anthropic's workspace documentation describes workspaces as the mechanism to "separate different projects, environments, or teams while maintaining centralized billing and administration." On Claude Platform on AWS specifically, three properties make the per-app, per-environment split pay off:
Cost attribution comes free. Because usage and cost roll up per workspace, a workspace named invoicing-prod gives finance an unambiguous line without any tagging discipline. This matters more here than elsewhere: spend limits are not available on Claude Platform on AWS (billing runs through AWS Marketplace, metered in Claude Consumption Units), so per-workspace visibility plus AWS billing controls is your cost-governance toolkit.
IAM scoping becomes mechanical. Each environment's role gets an Allow on exactly one workspace ARN. A staging credential physically cannot call the production workspace — the request 403s at the gateway. There is no workspace member management on this platform; AWS IAM policies on workspace ARNs are the access-control system, so the workspace layout is your permission model.
Blast radius stays small. A leaked dev credential scoped to wrkspc_...dev exposes dev files, dev batches, and dev sessions — not production data. Prompt-cache isolation per workspace also means environments never share cached content.
Mind the region binding
Each workspace is bound to a single AWS region at creation — a workspace created in us-west-2 is only reachable through the us-west-2 endpoint. If dev runs in one region and prod in another, that's naturally one workspace each. If all environments share a region, the workspaces simply live side by side there. Note that the workspace's region governs the gateway endpoint and where AWS-side resources like IAM and CloudTrail are scoped; it does not pin where model inference runs — that's controlled separately with the inference_geo parameter.
Propagating the right workspace ID per environment
The SDK client resolves two required values with no default fallback: the AWS region (env var AWS_REGION, falling back to AWS_DEFAULT_REGION) and the workspace ID (env var ANTHROPIC_AWS_WORKSPACE_ID). Both can also be passed as constructor arguments. The clean pattern is to keep application code identical across environments and inject the values through each environment's configuration — task definitions, deployment manifests, or your parameter store:
# Same code in every environment
from anthropic import AnthropicAWS
client = AnthropicAWS() # reads AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID
resp = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello"}],
)
Then per environment:
# staging
export AWS_REGION='us-west-2'
export ANTHROPIC_AWS_WORKSPACE_ID='wrkspc_01StAgInGxxxx'
# production
export AWS_REGION='us-west-2'
export ANTHROPIC_AWS_WORKSPACE_ID='wrkspc_01PrOdUcTiOnx'
A useful safety property: the client raises an error at construction if either value is missing, so a misconfigured deployment fails at startup rather than sending traffic nowhere. And because the environment's IAM role is scoped to its own workspace ARN, even a copy-paste mistake — prod's workspace ID landing in staging's config — fails with a 403 instead of silently billing the wrong bucket.
Quotas and limits are per organization, managed by Anthropic
One caveat to the isolation story: rate limits and quotas on Claude Platform on AWS are managed by Anthropic, not by AWS quota systems, and new organizations start on the Start tier without automatic tier movement. Contact Anthropic to raise limits. Plan for this before a launch — a production workspace doesn't get more headroom just because it's labeled production.
Where to go next
For the create/rename/archive mechanics, see the workspace lifecycle guide. To wire per-environment IAM policies, use the copy-paste IAM policies, and for hard multi-tenant separation, read workspace isolation.