A great deal of enterprise backend software is Java, and Bedrock fits into that world without ceremony. AWS SDK for Java v2 provides a Bedrock runtime client — the BedrockRuntimeClient — that handles Signature Version 4 signing, credential discovery, and retries exactly as it does for S3 or DynamoDB. This article covers the setup and the synchronous/asynchronous split conceptually; pair it with the AWS SDK for Java API reference for exact class and builder names. (Per this site's conventions, inline code samples are Python-only, so treat the identifiers here as signposts into the Java reference docs.)
Dependencies and client construction
Add the Bedrock runtime module of AWS SDK for Java v2 to your Maven or Gradle build (the SDK is modular, so you pull in only the services you use, typically alongside a BOM that pins consistent versions). You then construct the client through the standard v2 builder pattern: specify a region, optionally a credentials provider, and build. Treat the client as a long-lived, thread-safe object — create it once at application startup, share it across requests, and close it at shutdown, as with other v2 service clients.
Credentials come from the standard AWS chain: explicit provider first, then environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), then config files and ambient providers — SSO, assumed roles, ECS task roles, EC2 instance metadata. In production, attach an IAM role to the compute and configure nothing in code. The role needs bedrock:InvokeModel (plus bedrock:InvokeModelWithResponseStream for streaming, or the Converse actions) on the model ARNs you permit.
The request body is the same JSON as everywhere else
InvokeModel is a pass-through API: whatever JSON body you provide goes to the model. For Claude, that body is Anthropic's Messages format with Bedrock's required version marker — "anthropic_version": "bedrock-2023-05-31" — plus max_tokens and a messages array of alternating user/assistant turns; system prompts go in the top-level system field. In Java you typically build this JSON with your preferred library (Jackson is common), hand it to the request as the body payload along with the model ID, and parse the JSON response the same way. The full body specification is in InvokeModel in depth, and it is identical across boto3, Node.js, and Java — a useful property when several teams in different languages share one prompt library.
Synchronous vs asynchronous calls
Synchronous: the standard BedrockRuntimeClient blocks the calling thread until the full response arrives. This is the simplest model and fits batch jobs, request-scoped work behind a thread pool, and anywhere your framework already isolates blocking I/O.
Asynchronous: SDK v2 also offers an async variant of the runtime client that returns futures instead of blocking, built for non-blocking stacks and for high-concurrency services where you don't want a thread parked for the duration of a long generation. The async client is also the natural home for InvokeModelWithResponseStream, where response events arrive incrementally over time — you register handlers for stream events rather than waiting on a single response object. The event flow itself is described in the response-streaming article.
Which models you can reach from this client
The bedrock-runtime surface uses ARN-versioned model IDs with routing prefixes (for example global.anthropic.claude-opus-4-6-v1, or us.-prefixed geographic variants). The newest generation — Claude Fable 5, Opus 4.8, Sonnet 5 — is not served on this surface; those models live on the current "Claude in Amazon Bedrock" endpoint (bedrock-mantle), which speaks the standard Anthropic Messages API over HTTPS with SigV4. A Java service can reach that surface as an HTTP API; check Anthropic's Claude in Amazon Bedrock documentation for current client options in your language.
Operational notes
Request payloads are capped at 20 MB. Every invocation is a CloudTrail management event by default, and model invocation logging (if enabled) captures full request and response bodies for runtime-surface calls. Handle throttling with the SDK's retry configuration plus your own backoff at the application layer — and see the throttling guide before your first load test, not after.
Where to go next
Read InvokeModel vs Converse to choose your request style, or compare language stacks via the Node.js guide and the boto3 setup.