SigV4 Under the Hood: What the SDK Signs for You

SigV4 (AWS Signature Version 4) is the request-signing scheme used across AWS. Instead of sending a secret with each call, the client computes a cryptographic signature over the request — method, path, headers, body, timestamp — using your AWS credentials, and sends the signature. The server recomputes it; if the two match, the request is authentic and untampered. Claude Platform on AWS uses SigV4 as its primary authentication method, which is exactly why it plugs into IAM roles, STS, and CloudTrail like any native AWS service.

What a signed request looks like

Requests go to a base URL of the form https://aws-external-anthropic.{region}.api.aws/v1/... — the plain Claude API surface (/v1/messages and friends), not a Bedrock-style path. On top of the usual Claude API headers, the SDK handles:

The signature is scoped to a service name — here aws-external-anthropic — and a region, and it embeds a timestamp, so signatures expire quickly and can't be replayed later. Because the signature covers the request contents, any mutation in transit invalidates it. This is also why you never hand-roll these headers: getting canonicalization, scope, and timestamps right is fiddly, and every SDK client (Python's AnthropicAWS included) does it for you, along with building the region-based base URL and setting the workspace header.

from anthropic import AnthropicAWS

# All SigV4 work happens inside the client.
client = AnthropicAWS()  # AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID
resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=256,
    messages=[{"role": "user", "content": "ping"}],
)

If you must test outside an SDK, cURL can sign for you: --aws-sigv4 "aws:amz:<region>:aws-external-anthropic". Streaming responses, incidentally, are standard server-sent events (SSE), the same as the first-party Claude API — not AWS EventStream framing.

Diagnosing signature errors in development

Signature failures (the family Bedrock veterans know as SignatureDoesNotMatch) are deliberately unhelpful: per Anthropic's docs, a mismatch produces a generic signature-rejection error, not a specific diagnostic, because telling an attacker which part of a forged signature was wrong would help them. Work through the usual suspects in order:

Region mismatch. The single most common cause. The SigV4 signing region must match the region in the endpoint URL. If AWS_REGION says us-east-1 but you're hitting the us-west-2 endpoint (or vice versa), the signature is computed for the wrong scope and is rejected. Remember workspaces are region-bound, so the correct region is your workspace's region.

Wrong service name. Only relevant with hand-built requests or cURL: the service string must be aws-external-anthropic, not bedrock or anything else.

Stale or mismatched credentials. Temporary credentials missing their session token, or an old key pair in the environment shadowing the role you meant to use — see the credential chain guide for which source wins.

Clock skew. Signatures embed a timestamp; a machine clock far off from real time produces signatures the server treats as expired.

Also distinguish a signature rejection from a 403: a 403 means your signature was fine and the request authenticated, but the IAM principal lacks the required aws-external-anthropic:* action or the workspace ID is wrong. When you escalate, every response carries two request IDs — x-amzn-requestid for AWS support (and CloudTrail correlation) and request-id for Anthropic support.

Where to go next

See the credential chain for where the signing credentials come from, the IAM actions reference for what a signed request is authorized to do, and the error codes guide for the broader error taxonomy.

Sources

• Claude Platform on AWS documentation
• Claude Platform on AWS IAM actions reference