Authentication Paths for Claude Platform on AWS
Each authentication path for Claude Platform on AWS carries different auditability, security, and operational trade-offs. This article compares SigV4, long-lived API keys, and short-term API keys, and shows how to implement each one.
Introduction
Three authentication paths are available for Claude Platform on AWS (CPonAWS), each with different implications for security, operational overhead, and auditability. This article covers that decision: how to authenticate, with implementation details for each approach. For guidance on account structure (which affects authentication choices, particularly for cross-account patterns), refer to the companion Architecture Patterns article.
CPonAWS supports three authentication approaches: SigV4 request signing, long-lived API keys, and short-term API keys. Each offers different trade-offs around security, simplicity, and auditability. This post helps you determine which path fits your workload and shows you how to implement it.
Key Concepts
Before diving into the authentication paths, make sure you are comfortable with three terms:
- Subscribed account: The single AWS account that activated CPonAWS. This is the only account that can make SigV4 calls directly to the CPonAWS endpoint. It is also where you access the AWS Management Console for API key generation. Other accounts gain access through cross-account role assumption or by using API keys generated from this account.
- CallWithBearerToken: The IAM action that must be present on the identity that generates or backs an API key (both long-lived and short-term). SigV4 authentication does not require this action.
- SDK choice: The AnthropicAWS client supports both SigV4 and API key authentication. The standard Anthropic client (also used by LangChain, LangGraph, and other frameworks) supports API keys only. Your SDK choice determines which authentication methods are available to you.
- Region: Workspaces are created in a specific AWS Region, and API calls must target the matching Regional endpoint. Note that the workspace Region determines the API endpoint, not where inference runs (inference geography is configured separately in the Claude Console).
Authentication Paths
The following table summarizes the three paths and their trade-offs:
| Path | SDK | Secrets to Manage | Workspace Scoping | Auditability | Best For |
|---|---|---|---|---|---|
| SigV4 | AnthropicAWS | None (IAM handles rotation) | CreateInference Resource on calling role | Per-caller AWS CloudTrail | New workloads on AWS |
| Long-lived API key | Any (Anthropic, AnthropicAWS, frameworks) | One key per workspace | Custom policy on backing IAM user | Per-key | Migration from 1P, multi-cloud |
| Short-term API key | Any | None (tokens expire) | CreateInference Resource on generating role | Per-key | Automatic expiration + workspace scoping |
Each path is detailed below with implementation code.
CPonAWS supports three authentication approaches. Each offers different trade-offs around security, simplicity, and auditability. The right choice depends on where your workload runs, which SDK you use, and what your security priorities are.
SigV4 (AnthropicAWS)
When to use: Workloads running on AWS that use the AnthropicAWS SDK.
How it works: The SDK signs each request using the standard AWS credential chain (environment variables, instance profile, ECS task role, Lambda execution role). No API keys to generate, store, or rotate.
Benefits
· No secrets to manage: credentials rotate automatically through IAM
· Per-caller AWS CloudTrail attribution: each IAM principal is a distinct identity in logs
· Workspace scoping via standard IAM Resource field on CreateInference
Code: Direct (same account)
1
2
3
4
5
6
7
from anthropic import AnthropicAWS
client = AnthropicAWS(aws_region='us-east-1', workspace_id='wrkspc_XXXX')
resp = client.messages.create(
model='claude-sonnet-4-6',
max_tokens=1024,
messages=[{"role": "user", "content": "Hello"}]
)
Code: Cross-account
1
2
3
4
5
6
7
8
9
10
11
12
13
14
import boto3, os
from anthropic import AnthropicAWS
sts = boto3.client("sts")
assumed = sts.assume_role(
RoleArn="arn:aws:iam::SUBSCRIBED_ACCOUNT_ID:role/CrossAccount-ClaudePlatform",
RoleSessionName="inference"
)
creds = assumed["Credentials"]
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-east-1", workspace_id="wrkspc_XXXX")When creating the cross-account role's trust policy, include an
aws:PrincipalOrgID condition to restrict access to principals within your AWS Organization.Cross-account role requirements: The assumed role needs
CreateInference, CountTokens, sts:GetWebIdentityToken, and sts:TagGetWebIdentityToken. CallWithBearerToken is not needed for SigV4 inference.Long-Lived API Key
When to use: Migrating from Anthropic 1P, multi-cloud workloads, or using the standard Anthropic client.
How it works: A bearer token generated from the AWS Management Console, backed by an
AeaApiKey-* IAM user in your subscribed account.Benefits:
• Minimal code change from 1P (swap base_url, add workspace header)
• Works from environments such as GCP, Azure, on-premises, CI/CD, and developer laptops
• No AWS SDK dependency on the calling side
Key management: Store in AWS Secrets Manager or your platform's native secret manager. Set expiration at creation time (1, 5, 30, 90, or 365 days).
Workspace scoping: By default, the backing IAM user has the
Code: Standard Anthropic client with Secrets Manager
• Minimal code change from 1P (swap base_url, add workspace header)
• Works from environments such as GCP, Azure, on-premises, CI/CD, and developer laptops
• No AWS SDK dependency on the calling side
Key management: Store in AWS Secrets Manager or your platform's native secret manager. Set expiration at creation time (1, 5, 30, 90, or 365 days).
Workspace scoping: By default, the backing IAM user has the
AnthropicLimitedAccess managed policy, which grants access to all workspaces. To restrict: detach the managed policy, then attach a custom policy scoping CreateInference to the target workspace ARN. See the Workspace Isolation section below for the full policy example.
Code: Standard Anthropic client with Secrets Manager
1
2
3
4
5
6
7
8
9
10
11
12
13
14
import boto3
from anthropic import Anthropic
secrets = boto3.client('secretsmanager')
api_key = secrets.get_secret_value(SecretId='cponaws/api-key')['SecretString']
client = Anthropic(
api_key=api_key,
base_url='https://aws-external-anthropic.us-east-1.api.aws'
)
resp = client.messages.create(
model='claude-sonnet-4-6',
max_tokens=1024,
messages=[{"role": "user", "content": "Hello"}],
extra_headers={'anthropic-workspace-id': 'wrkspc_XXXX'}
)
Short-Term API Key
When to use: You need automatic expiration combined with workspace scoping, or you have multi-cloud workloads that require a reduced credential exposure window compared to long-lived keys.
How it works: Two steps: (1) generate the token using AWS credentials (requires
CallWithBearerToken), then (2) use the token from anywhere as a bearer credential.Benefits:
· Expires automatically (max 12 hours), limiting exposure if leaked
· Workspace-scoped via the generating principal's IAM policy
· No backing IAM user created (cleaner IAM footprint)
Characteristics: Region-scoped (must call the same Region where generated). Minimum effective TTL is approximately 5 minutes.
Workspace scoping: Scope CreateInference Resource on the generating principal's IAM policy. The token inherits those permissions at generation time.
Code: Generation + usage
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
from token_generator_for_aws_external_anthropic import TokenGenerator
from anthropic import Anthropic
from datetime import timedelta
generator = TokenGenerator(region='us-east-1')
token = generator.get_token(expiry=timedelta(hours=1))
client = Anthropic(
api_key=token,
base_url='https://aws-external-anthropic.us-east-1.api.aws'
)
resp = client.messages.create(
model='claude-sonnet-4-6',
max_tokens=1024,
messages=[{"role": "user", "content": "Hello"}],
extra_headers={'anthropic-workspace-id': 'wrkspc_XXXX'}
)
Code: From external environment (cross-account generation)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import boto3
from token_generator_for_aws_external_anthropic import TokenGenerator
from anthropic import Anthropic
from datetime import timedelta
sts = boto3.client('sts')
assumed = sts.assume_role(
RoleArn='arn:aws:iam::SUBSCRIBED_ACCOUNT_ID:role/CrossAccount-ClaudePlatform',
RoleSessionName='token-gen'
)
assumed_session = boto3.Session(
aws_access_key_id=assumed['Credentials']['AccessKeyId'],
aws_secret_access_key=assumed['Credentials']['SecretAccessKey'],
aws_session_token=assumed['Credentials']['SessionToken']
)
generator = TokenGenerator(session=assumed_session, region='us-east-1')
token = generator.get_token(expiry=timedelta(hours=1))
client = Anthropic(
api_key=token,
base_url='https://aws-external-anthropic.us-east-1.api.aws'
)
Additional Considerations
The following topics apply across all three authentication paths.
Workspace Isolation
| Auth Method | Identity Evaluated | How to Scope |
|---|---|---|
| SigV4 | Calling IAM role | Scope CreateInference Resource on the role |
| Long-lived API key | Backing AeaApiKey-* user | Detach managed policy, attach workspace-scoped policy |
| Short-term API key | Generating principal | Scope CreateInference Resource on the generating role |
Workspace scoping works differently depending on your authentication method. The key distinction: with API keys, the compute role running your workload does not determine authorization. The key carries its own identity.
Important: CallWithBearerToken must remain on Resource: "*". Scoping it to a workspace ARN causes all calls to fail.
Example policy (applies to SigV4 roles and short-term key generating principals):
Important: CallWithBearerToken must remain on Resource: "*". Scoping it to a workspace ARN causes all calls to fail.
Example policy (applies to SigV4 roles and short-term key generating principals):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["aws-external-anthropic:CreateInference", "aws-external-anthropic:CountTokens"],
"Resource": "arn:aws:aws-external-anthropic:us-east-1:ACCOUNT_ID:workspace/wrkspc_XXXX"
},
{
"Effect": "Allow",
"Action": ["aws-external-anthropic:CallWithBearerToken", "aws-external-anthropic:GetAccountStatus"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["sts:GetWebIdentityToken", "sts:TagGetWebIdentityToken"],
"Resource": "*"
}
]
}
Cross-Account and External Environment Authentication
Cross-account (AWS-to-AWS): If your workload runs in an AWS account that is not the subscribed account, use cross-account role assumption. The calling account assumes a role in the subscribed account, then uses that role for SigV4 inference or short-term key generation.
External environments (GCP, Kubernetes, GitHub Actions): Workloads running outside AWS should use AWS OIDC Federation to obtain IAM credentials without storing long-lived AWS access keys. Configure an IAM OIDC identity provider for your external issuer. Then create a role with a web identity trust policy. Your workload then assumes that role without storing credentials. This is the same standard pattern used by GitHub Actions OIDC, EKS Pod Identity, and GCP Workload Identity Federation to AWS. Once you have the assumed role, use it for SigV4 inference (with AnthropicAWS) or short-term key generation. Refer to the AWS documentation on OIDC identity providers for setup instructions.
Decision Guide
Use this flowchart to identify your starting pattern. Each decision point leads to the option that best fits your constraints:
Start with SigV4 if your workload runs on AWS and you can use AnthropicAWS. If you need the standard Anthropic client or framework compatibility, choose between long-lived keys (simplest migration) and short-term keys (stronger security posture with automatic expiration).
Conclusion and Next Steps
Three paths, one principle: match your authentication method to your SDK choice and security requirements. Use SigV4 with AnthropicAWS for automatic credential rotation and per-caller attribution with no secrets to manage. Use long-lived keys for the fastest migration from Anthropic 1P. Use short-term keys when you need automatic expiration with workspace scoping.
For architecture guidance on where to deploy CPonAWS and how to organize accounts, refer to the companion article: Architecture Patterns for Claude Platform on AWS .
Official documentation:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article