AWS has published guidance for connecting AWS workloads, developer environments and external services to Claude Platform on AWS through a single subscription. Its architecture pairs each environment with a different authentication method: cross-account Signature Version 4 (SigV4), workspace-scoped API keys and OpenID Connect (OIDC) federation. Workspaces sit in a dedicated AI Services account, providing the common isolation boundary across those access paths. AWS’s implementation overview describes that design.
For cloud architects, the central decision is how to connect each caller’s identity to the workspace it should access. Centralizing the subscription brings administration together; the permissions attached to credentials still determine whether production and development remain separate.
Start with account ownership and workspace boundaries
Remio AI’s account of the implementation describes three account responsibilities. The management account handles organization-level billing and governance. The AI Services account holds the Claude Platform subscription, workspaces, API keys and access roles. Workload accounts host applications that consume inference by assuming roles in the AI Services account.
In this arrangement, an application account can use Claude without owning the subscription. The workspace becomes the more specific resource boundary: each workspace has an Amazon Resource Name (ARN) that AWS Identity and Access Management (IAM) policies can reference. As Remio explains, permission to invoke one workspace need not grant permission to invoke another.
Remio also reports that AWS recommends separate production and development workspaces. The architectural implication is straightforward: decide which environments need separate permissions before assigning credentials. An account layout establishes ownership, while workspace policies establish which resources callers can use.
Match authentication to the execution environment
AWS’s overview identifies three access paths:
| Caller environment | Authentication method | Workspace relationship |
|---|---|---|
| AWS workloads | Cross-account SigV4 | Access through roles in the AI Services account |
| Developers | Workspace-scoped API keys | Keys intended for a particular workspace |
| External environments | OIDC federation | Federated access to workspace resources |
AWS workloads: assume a role, then sign requests
Remio describes an Amazon EKS pod as the implementation’s AWS workload example. The pod assumes a cross-account role in the AI Services account and uses the resulting temporary credentials to sign Claude requests with SigV4.
SigV4 uses AWS credentials to cryptographically sign requests, allowing the receiving service to check the caller and request integrity without a separate static API secret. The role’s permissions determine which workspace resources the application can invoke.
The important review point is therefore the combination of role access and workspace authorization. A working cross-account connection establishes that an application can authenticate; its permissions must also reflect the intended production boundary.
Developers: check the permissions behind the key
Workspace-scoped API keys provide the developer access path, but the backing permissions deserve particular attention. Remio reports that, according to AWS’s implementation guide, the backing IAM user initially receives the AnthropicLimitedAccess managed policy and that this policy grants access across workspaces.
That reported default qualifies the workspace-scoping story. A key intended for development should be assessed alongside the permissions of its backing IAM user. Creating separate workspaces alone does not establish that a developer credential is restricted to the development workspace.
External services: account for token renewal
For external workloads, Remio describes OIDC federation as an exchange of an identity provider’s signed token for temporary AWS credentials. Those credentials are then used to generate a Claude bearer token. Its examples include Google Cloud workloads, Kubernetes clusters outside AWS, GitHub Actions and GitLab CI.
Remio reports that AWS’s example uses a one-hour bearer token and permits configurable lifetimes up to 12 hours. After expiry, the external service must obtain another token. Token renewal is consequently part of the integration’s operating requirements, alongside the initial federation setup. Those lifetimes are reported implementation details, rather than independently tested results.
Make permissions, logging and costs explicit
Remio’s reporting identifies aws-external-anthropic as the IAM namespace and CreateInference as an action associated with message requests. This mapping connects the API operation to the permission being reviewed. The supplied evidence does not contain complete policy payloads, so it does not support a deployable IAM configuration.
Logging also needs a deliberate choice. According to Remio, workspace administration appears in CloudTrail management events by default, while inference and other workspace operations require data-event logging to be enabled. For an architecture review, that means administrative visibility and inference visibility are separate checks.
For cost allocation, Remio reports that AWS supports tagging workspaces and activating those tags for use in AWS Cost Explorer. AWS’s stated activation window is 24 to 48 hours. Teams should account for that delay when checking workspace-level cost reporting.
The design gives architects a coherent way to connect three environments to centrally owned workspaces. Its practical value depends on carrying that workspace boundary through role permissions, developer credentials, token renewal and inference logging. The available evidence describes an access architecture; it does not establish measured security, performance or cost improvements.
