Claude Platform on AWS binds its resources to an AWS account: the Marketplace subscription, the linked Anthropic organization, and the workspaces — whose ARNs look like arn:aws:aws-external-anthropic:{region}:{account-id}:workspace/{workspace-id} — all live in the account that signed up. A common enterprise pattern puts all of that in a dedicated "AI platform" account (call it account B) while the applications that need Claude run in workload accounts (account A). The bridge between them is the same one AWS teams use everywhere: a cross-account IAM role assumed via STS.
Why centralize at all
Concentrating the subscription in one account gives you a single Marketplace line item to reconcile, one place to negotiate a private offer, one Anthropic organization whose rate limits and tiers you manage, and one set of workspace ARNs to write IAM policy against. Workspaces become your internal attribution and isolation unit — one per team or product — while workload accounts get exactly the access their role grants and nothing more. It also means the one-time platform prerequisites (the Marketplace subscription, partner signup, workspace creation) happen once instead of per team.
The two halves of the setup
In account B (where the workspaces live): create an IAM role — say claude-invoke-team-search — with two policies. The permissions policy grants the platform actions the workload needs on the specific workspace ARN, for example aws-external-anthropic:CreateInference, CountTokens, GetModel, and ListModels on arn:aws:aws-external-anthropic:us-west-2:<account-B-id>:workspace/wrkspc_01AbCdEf23GhIj. The trust policy is what makes it cross-account: it names account A's workload role (or account A itself, with conditions) as the principal allowed to call sts:AssumeRole. Standard AWS hygiene applies — trust the narrowest principal you can, and consider an external ID or conditions if your security team requires them.
In account A (where the workload runs): the application's own role needs permission to assume the account-B role, and the application assumes it before calling Claude. The assumed-role credentials are temporary — an access key, secret key, and session token from STS. The AnthropicAWS client handles temporary credentials transparently: the x-amz-security-token header that temporary credentials require is added automatically, so nothing special is needed beyond putting the credentials where the AWS default credential provider chain finds them.
import os, boto3
from anthropic import AnthropicAWS
creds = boto3.client("sts").assume_role(
RoleArn="arn:aws:iam::<account-B-id>:role/claude-invoke-team-search",
RoleSessionName="claude-cross-account",
)["Credentials"]
# Hand all three values to the default credential chain
os.environ["AWS_ACCESS_KEY_ID"] = creds["AccessKeyId"]
os.environ["AWS_SECRET_ACCESS_KEY"] = creds["SecretAccessKey"]
os.environ["AWS_SESSION_TOKEN"] = creds["SessionToken"]
client = AnthropicAWS(aws_region="us-west-2") # workspace's bound regionIn practice most teams skip the explicit STS call and let their AWS SDK profile or container configuration handle role assumption, leaving the default credential chain (slot 5 in the precedence order) to do the work. Session credentials expire, so long-running services should use a mechanism that refreshes them rather than caching a single STS response.
Platform-specific details to check
Region alignment. The workspace is bound to a single AWS region, and the client's AWS_REGION must match it — a mismatch produces a generic signature-rejection error, not a helpful diagnostic.
Outbound web identity federation. The platform has a one-time per-account prerequisite: aws iam enable-outbound-web-identity-federation. If cross-account requests fail with "Outbound web identity federation is disabled for your account," run the enable command (and verify with aws iam get-outbound-web-identity-federation-info) in the account the error is complaining about — confirm with the official documentation which account needs it in a cross-account topology if the error message leaves it ambiguous.
Auditability. Inference calls are CloudTrail Data events (explicit, paid logging), while workspace-management actions are Management events. In a centralized pattern, account B's CloudTrail is where Claude usage is visible — enable data event logging there if your security team expects per-call audit trails. Every response also carries an x-amzn-requestid for AWS support and a request-id for Anthropic support.
Where to go next
See IAM policy templates for the permissions-policy patterns, workspace isolation for the boundary design, and CloudTrail logging for the audit side.