Architecture Patterns for Claude Platform on AWS
Choosing where to subscribe to Claude Platform on AWS is an architecture decision that's hard to reverse. This post compares four multi-account patterns, explains the trade-offs of each, and recommends the right fit based on your organization's isolation requirements and account structure.
Introduction
When adopting Claude Platform on AWS (CPonAWS), one of the first architecture decisions you face is how to organize your AWS accounts and workspaces. CPonAWS brings the full Anthropic service into your AWS account. You get the Messages API, Managed Agents, Agent Skills, code execution, prompt caching, and Claude models, all authenticated through AWS Identity and Access Management (IAM) and billed through AWS Marketplace on your existing AWS invoice.
But before you make your first API call, you need to answer two questions: where do you subscribe, and how do you organize workspaces across your environments?
These choices are hard to reverse later. The account that subscribes to CPonAWS becomes the anchor for your Anthropic organization. Getting the architecture right from the start saves you from a costly migration later.
In this post, we walk through four architecture patterns, ranging from a single standalone account to enterprise multi-account setups with dedicated AI services accounts. For each pattern, you will see the architecture diagram, the trade-offs, and the audience it serves best. By the end, you will have a clear decision framework to pick the pattern that fits your organization.
A note on migration: When you subscribe to CPonAWS, the service creates a new Anthropic organization tied to your AWS account. If you already have an Anthropic organization from platform.claude.com, note that CPonAWS does not migrate those assets. Prompts, projects, API keys, and configurations from your existing 1P org remain separate. Plan accordingly if you are transitioning from a direct Anthropic relationship.
Key Concepts
Before diving into the patterns, make sure you are comfortable with three terms:
Subscribed account: The specific AWS account from which you activated CPonAWS in the AWS Management Console. This is the only account that can make SigV4-authenticated API calls to the CPonAWS endpoint without cross-account configuration. Other accounts can use cross-account role assumption or API keys to gain access.
Note: Only the subscribed account has access to the Anthropic Organization console (accessed through the AWS Management Console) for managing workspaces, and managing the keys and IAM users that back those keys. However, API keys generated from this account can be used from anywhere. This includes workloads running on GCP, Azure, on-premises, or CI/CD pipelines. The calling side needs no AWS credentials, only the key itself.
Workspace: A logical boundary within your CPonAWS organization that provides three forms of isolation: independent rate limits (TPM/RPM per workspace), and access control (API keys can be scoped to specific workspaces through IAM policy customization). Think of workspaces as tenants within your org. Workspace IDs follow the format
wrkspc_XXXX. You might create one workspace per team, per environment, or per application.Anthropic Organization: Created automatically at subscription time. One Anthropic organization maps to one subscribed AWS account. The organization contains your workspaces and configuration. CPonAWS models access control through AWS Identity and Access Management (IAM) rather than org-level membership lists. You manage workspaces through the Anthropic Console (accessed via the AWS Management Console) and the workspace management API.
Architecture Patterns
The following four patterns cover the most common ways to organize CPonAWS within your AWS account structure. Each pattern builds on the previous one in terms of isolation and operational complexity. Start with the one that matches your current needs, you can evolve toward a more structured pattern later.
Each of these patterns supports multiple authentication approaches — from API keys (usable from any environment) to cross-account SigV4 (for AWS CloudTrail-level auditability). The Authentication Paths article in this series covers these options in detail, including workspace-scoped access, short-term keys, and auto-renewal patterns.
Option A: Standalone AWS Account
This pattern has the fewest moving parts. A single AWS account subscribes to CPonAWS, runs workloads, and manages the platform from a single location.
You subscribe from this account, create multiple workspaces (dev, staging, prod) to separate concerns, and generate API keys. By default, each key has access to workspaces across the organization. To scope a key to a specific workspace, you customize the IAM policy on the backing user. Your application code authenticates using IAM roles (SigV4) or API keys.
You achieve environment separation at the workspace level, not the account level. Each workspace has independent rate limits and usage tracking, so a runaway dev workload does not consume your production quota.
Ideal for: Startups, proofs of concept, single-team organizations, early evaluation phases.
Pros:
- Most straightforward setup with no cross-account configuration
- Short time to first inference (subscribe and call within minutes)
- Unified view for everything: workloads, billing, and CPonAWS management
Cons:
- No AWS account-level isolation between environments
- Mixes workload infrastructure concerns with platform management
- IAM policies must carefully separate who can manage CPonAWS vs. who can invoke it
- Harder to scale as teams and compliance requirements grow
This pattern works well for getting started. Many organizations begin here and evolve toward more structured options as they move to production.
Option B: AWS Organization, Payer Account Subscribes
If you already have an AWS Organization, a natural choice is to subscribe from the payer (management) account. This keeps CPonAWS management centralized alongside your existing billing and organizational controls.
The payer account subscribes, creates workspaces, and generates API keys.
Works well for: Organizations with existing AWS Organizations wanting centralized control, teams already comfortable managing services from the payer account.
Pros:
- Uses your existing Org structure without adding accounts
- Account-level isolation for workloads (dev mistakes stay in dev)
- Centralized management of CPonAWS alongside other org-wide controls
- API key distribution avoids cross-account IAM complexity
Cons:
- Payer account now mixes billing/governance AND CPonAWS subscription
- Some organizations have SCPs or policies that prohibit running services from the payer
- Security teams may flag the payer account as too privileged for service subscriptions
- If the payer account has a security issue, both org governance and AI services are at risk
Option C: AWS Organization, Dedicated AI Services Account (Recommended)
This is the recommended pattern for organizations with multiple teams and strict separation requirements.
You add a dedicated linked account, often called "AI Services" or "AI Platform." Its purpose is to provide access to AI services like CPonAWS. It cleanly separates billing, platform management, and workloads across three layers.
Here is how the layers break down:
- Payer account handles billing, SCPs, and organizational governance. It has no CPonAWS subscription and no workloads.
- AI Services account subscribes to CPonAWS, creates and manages workspaces, generates API keys, and hosts the cross-account IAM role that workload accounts assume.
- Workload accounts (Dev, Stage, Prod) run your application code. They call CPonAWS by assuming the invoke role in the AI Services account or by using distributed API keys.
This gives you clear separation between layers. A workload account with inadvertent access cannot modify CPonAWS configuration. A billing policy change in the payer does not disrupt inference. And the AI Services team can manage workspaces, rate limits, and keys without touching production infrastructure.
Designed for: Organizations with multiple teams, those using AWS Control Tower, and teams with strict separation-of-concerns policies.
Pros:
- Clean separation across billing, platform management, and workloads
- Account-level isolation at every layer
- Compatible with AWS Control Tower guardrails and landing zone patterns
- Payer account stays pristine (no services, no workloads)
- Scales naturally: add new workload accounts without modifying CPonAWS setup
- Centralized audit trail for CPonAWS management actions
Cons:
- One additional account to create and manage
- Cross-account IAM configuration required (role trust policies, assume-role permissions)
- Higher initial setup time compared to Options A or B
The cross-account IAM setup requires careful configuration but follows standard AWS patterns. For step-by-step role configuration details, including trust policies and condition keys for workspace-scoped access, see the Authentication Paths article in this series.
Option D: Multiple Independent Subscriptions
In this pattern, each environment account independently subscribes to CPonAWS, creating a separate Anthropic organization per account.
The critical distinction: each subscription creates a separate Anthropic organization. There is no shared view across these orgs. Workspaces, API keys, rate limits, and usage data are completely independent.
Best for: Maximum isolation requirements, organizations where regulatory mandates require complete separation between environments.
Pros:
- Full isolation between environments at both the AWS and Anthropic levels
- No cross-account dependencies whatsoever
- Independent rate limits and quotas per environment
- An issue in one environment has zero impact on others
Cons:
- Multiple Anthropic organizations with no cross-org visibility or management
- Linked account costs still appear in the payer bill (use AWS Invoice Units or Cost Allocation Tags for separated cost reporting)
- Highest operational overhead (manage N subscriptions, N sets of workspaces)
- Workspace configuration cannot be shared or templated across orgs
- No unified usage dashboard or cost view at the Anthropic level
- Prompt caches are not shared across orgs
Most organizations find sufficient isolation with Option C while maintaining unified management. Reserve Option D for cases where compliance explicitly requires that environments share no platform-level state.
Decision Tree
Use this flowchart to identify your starting pattern. Each decision point leads to the option that best fits your constraints:
When in doubt, start with Option C. The additional account is a small price for the architectural flexibility it provides as your AI workloads grow.
Conclusion and Next Steps
In this post, you explored four multi-account architecture patterns for Claude Platform on AWS. Option A works for getting started quickly. Options B and C introduce account-level isolation, with Option C providing the cleanest separation for teams with strict governance requirements. Option D offers maximum isolation at the cost of operational overhead. For most organizations, Option C provides the right balance of separation, scalability, and manageability.
You've now explored the "where" of CPonAWS deployment. The next critical decision is "how" your workloads authenticate. The next article in this series dives deep into Authentication Paths for Claude Platform on AWS - Covers API key vs. SigV4, short-term vs. long-lived tokens, workspace-level isolation patterns, and automatic key renewal strategies.
For official documentation and getting-started guides:
To get started: audit your current AWS account structure, decide which pattern fits (when in doubt, choose Option C), and create your subscribed account. Once subscribed, you can make your first Claude API call within minutes.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article