AWS has published a guide for accessing the Claude Platform on AWS service from multiple environments
AWS's guide describes a shared subscription for the Claude Platform on AWS service with separation of production and development. For applications in AWS environments it uses SigV4 and cross-account roles, for developers restricted API keys, and for external environments OIDC federation.
AWS has published a guide for setting up access to the Claude Platform on AWS service from production applications, developer workstations, and external environments. The described architecture places the shared subscription in a dedicated AI Services account, which manages workspaces, API keys, and access roles. Two workspaces separate production and development traffic; additional ones can be created for individual teams or tasks.
Applications in AWS environments use SigV4 signing and assume a role in the AI Services account with permissions limited to the production workspace only. Developers can use API keys restricted to the development workspace for local work. The guide notes that the default managed AnthropicLimitedAccess policy on the IAM identity created for the key allows access to all workspaces. Isolation therefore requires removing it and replacing it with a restricted policy; keys should be stored in a secrets management tool.
For external services and CI/CD environments, the guide specifies OIDC federation. API calls must be directed to the regional endpoint corresponding to the workspace. This region does not determine where inference is performed: that is set separately in the Claude Console interface, where the article lists the options "US" and "Global routing". Short-lived keys work only against the regional endpoint where they were created, while long-lived API keys do not have this restriction. For details, see the source article.
Why it matters
Developers get a described path to local testing without setting up a chain of cross-account roles. The guide allows companies to share a single subscription while separating production and development permissions. Practically important is restricting the default API key policy, which otherwise grants access to all workspaces, as well as distinguishing the API region from the inference location setting.
Two audiences, two different impacts
What this means
For individuals
For local development, an API key for the development workspace can be used without setting up cross-account roles; access to production is not required for this.
For a business
A company can centralize its subscription and access management, but separating production and development requires explicitly restricted roles and API key policies. The default key policy grants access to all workspaces.
Risks and complianceCheck the original
Event sources
only one source so far · 1 publisher, 0 independent. We count feeds from the same owner only once.