Claude Platform on AWS is Anthropic-operated but authenticated through AWS: requests are signed with SigV4 (AWS's standard request-signing scheme) using IAM credentials, and every request carries a workspace identifier. For Java teams, Anthropic publishes an AWS-specific artifact for its Java SDK that layers the signing, the region-based endpoint construction, and the workspace header onto the standard Anthropic client — so the code your application writes against is the ordinary Messages API, and the platform specifics stay in the builder.
The dependency
Add the Maven artifact com.anthropic:anthropic-java-aws to your build (the official docs show version 2.47.1; check for the current release when you set up, since the platform-specific SDK clients for Claude Platform on AWS are in beta). The same coordinate works from Gradle. This artifact is distinct from both the base Anthropic Java SDK artifact and any Bedrock-oriented client — Amazon Bedrock is a different service with different endpoints and model ID formats, so make sure the AWS-external artifact is the one on your classpath.
Configuration before code
Two values are required and have no default fallback — the client fails fast at construction if either is missing:
export ANTHROPIC_AWS_WORKSPACE_ID='wrkspc_01AbCdEf23GhIj'
export AWS_REGION='us-west-2'The workspace ID is the tagged wrkspc_... identifier from the AWS Console (Claude Platform on AWS → Workspaces). The region must be the workspace's bound region: workspaces are tied to a single AWS region, and calling through any other region's endpoint will not reach it. AWS_DEFAULT_REGION serves as a fallback for the region variable. There is also a one-time, per-AWS-account prerequisite that has nothing to do with Java but blocks everything if skipped: aws iam enable-outbound-web-identity-federation. Until it is run, every request fails with "Outbound web identity federation is disabled for your account" — the most common setup error on this platform.
Instantiating the client
The Java client is assembled with the SDK's builder pattern, attaching an AWS backend that reads its configuration from the environment: the documented form is a client builder configured with .backend(AwsBackend.fromEnv()). "From env" means exactly what it says — region, workspace ID, and AWS credentials are all resolved from the process environment and the standard AWS credential machinery, which keeps secrets out of your source and lets the same binary run unchanged across environments.
Credential resolution follows the AWS default credential provider chain: environment variables (AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN), shared credentials and config files (including SSO profiles), web identity federation (EKS IRSA, GitHub Actions), ECS container credentials, and EC2 instance metadata — in that spirit of "wherever your AWS credentials normally come from." Temporary credentials work transparently; the session-token header they require is added automatically. Alternatively, an API key generated in the AWS Console can be supplied (for example via ANTHROPIC_AWS_API_KEY); note that first-party sk-ant-api... keys do not work on this endpoint and OAuth is not supported.
The minimal working example
Your first end-to-end test should be the smallest possible synchronous Messages call: build the client from the environment, send one user message to a bare first-party model ID such as claude-sonnet-5 (no anthropic. prefix, no ARN) with a small max-token limit, and print the text of the response. That single call verifies five things at once — dependency, environment variables, credential chain, outbound federation, and IAM permissions on your workspace.
Interpret failures by layer. An exception at client construction means a missing region or workspace ID. The federation error message means the one-time account prerequisite was skipped. A generic signature-rejection error usually means the SigV4 region and endpoint region disagree. And a 403 means the request reached the server: check that the workspace ID is right and that your IAM principal has the needed action — for inference, aws-external-anthropic:CreateInference, or the AWS managed policy AnthropicInferenceAccess as a starting point (mind its broad read permissions; see IAM policy templates).
Where to go next
See the Python and TypeScript setups for comparison, the environment variable reference for precedence rules, and the credential chain for how resolution works in depth.