A dedicated AI Services account now serves as the single subscription holder for Claude Platform on AWS, while production workloads, developer laptops, and external CI/CD pipelines each use a separate authentication mechanism. By isolating the subscription and workspaces at the account level, engineers can keep production traffic separate from development traffic, avoid long‑lived secrets in workloads, and leverage native AWS identity services for each environment.
Architecture Overview
The pattern introduces a three‑account topology:
- Payer (management) account – handles billing and organization governance.
- AI Services account – owns the Claude Platform subscription, creates workspaces, and defines cross‑account IAM roles.
- Workload accounts – host production or other workloads and assume roles in the AI Services account to invoke inference.
All traffic is routed through the AI Services account, which enforces workspace‑level isolation between production and development workloads. For organizations with additional environments, the same model can be repeated by creating a workspace per team or workload and applying the cross‑account role pattern again.
Authentication Paths
Three distinct access methods are configured:
- Cross‑account SigV4 – An Amazon EKS pod in a workload account assumes an IAM role in the AI Services account and makes SigV4‑signed inference calls. No API keys are stored, eliminating secret rotation concerns.
- Workspace‑scoped API key – Developers generate a long‑lived API key that is locked to a development workspace. The key is used locally with the standard Anthropic SDK, providing a simple, isolated credential for iterative work.
- OIDC federation – External services outside AWS authenticate via an OpenID Connect provider, receive short‑lived AWS credentials, and then generate a temporary token for inference calls. This path avoids any persistent credentials in the external environment.
Each path is independent; the guide supplies the necessary CLI commands, console steps, and code snippets for implementation. Placeholders such as YOUR_ORG_ID must be replaced with actual values (e.g.,
YOUR_ORG_ID = o-abc123de).
Operational Considerations
Adopting this model requires coordination across several operational domains:
- IAM role design – Roles in the AI Services account must grant only the permissions needed for inference, and trust policies must allow assumption from designated workload accounts.
- Workspace management – Separate workspaces should be created for production and development traffic to enforce isolation at the service level.
- Credential lifecycle – API keys for developers are long‑lived but scoped to a workspace, while OIDC‑based tokens are short‑lived, reducing exposure risk.
- Monitoring and audit – All inference calls flow through the AI Services account, simplifying logging and audit of who accessed which workspace and from which environment.
Prerequisites include an AWS Organization with the three accounts, AWS CLI v2 with named profiles for each account, and a Python 3.12+ environment with the anthropic[aws] and boto3 packages installed.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Implementing the dedicated AI Services account pattern gives engineers a clear separation of concerns: production workloads use short‑lived, role‑based credentials; developers work with isolated API keys; and external pipelines rely on OIDC federation. The result is reduced secret management overhead, tighter workspace isolation, and a unified audit surface that aligns with existing AWS account governance. Teams should evaluate their current account structure, map required IAM roles, and plan workspace creation before rolling out the pattern to ensure a smooth transition.
