API Families

Bedrock organizes its APIs into families based on how you want to interact with models. Here’s the breakdown:

Invoke Family

• InvokeModel — synchronous, single-response calls. The basic one.
• InvokeModelWithResponseStream — returns responses as a real-time stream.
• InvokeModelWithBidirectionalStream — full-duplex streaming for interactive applications.
• AsyncInvoke — submits long-running requests asynchronously, stores output to S3.

Converse Family

• Converse — unified, model-agnostic interface for synchronous multi-turn conversations. This is the one you want for most chat use cases.
• ConverseStream — same as above but with streaming output.

OpenAI-Compatible Family

• ChatCompletions — implements the OpenAI Chat Completions interface. Existing OpenAI-based integrations can run on Bedrock with minimal changes.
• Responses API — implements the OpenAI Responses interface, supports stateful, agentic interactions with built-in tool use and conversation history management.

Messages Family

• Messages — implements the Anthropic Messages interface on the bedrock-mantle endpoint. Existing Anthropic SDK-based integrations can run on Bedrock with minimal changes.

OpenAI Compatibility

This is a big deal — you can bring your existing OpenAI SDK code to Bedrock by just changing the base URL and API key. Same goes for Anthropic SDK code via the Messages API. No rewrite needed.

Endpoint Types

Three routing options depending on your data residency and performance needs:

When to Use bedrock-mantle vs bedrock-runtime

Use bedrock-mantle when you want to:

• Use the Responses API, Chat Completions API, or Messages API with stateful, multi-turn conversations
• Bring existing OpenAI SDK code by changing only the base URL and API key
• Run asynchronous or long-running inference workloads
• Build agentic workflows with server-side tool use or pre-configured tools
• Use Projects (OpenAI-compatible) or Workspaces (Anthropic-compatible) to isolate workloads and track cost/usage at the application level

Use bedrock-runtime when you want to:

• Continue using the Bedrock-native InvokeModel or Converse APIs
• Use a model that isn’t yet available on bedrock-mantle

Inference Parameters

Temperature

Affects the probability distribution for predicted output.

• Lower value → model selects higher-probability outputs → more deterministic
• Higher value → model selects lower-probability outputs → more random/creative

In technical terms — temperature modulates the probability mass function for the next token. Lower steepens the function, higher flattens it.

Top K

The number of most-likely candidates the model considers for the next token.

• Lower value → smaller pool → more likely outputs only
• Higher value → larger pool → considers less likely outputs

Example: Top K = 50 means the model picks from 50 most probable next tokens.

Top P

The percentage of most-likely candidates considered.

• Lower value → smaller pool → more constrained
• Higher value → larger pool → more diverse

Adaptive Thinking (Claude Opus 4.6)

The recommended way to use Extended thinking with Claude. Instead of manually setting a thinking token budget, adaptive thinking lets Claude dynamically decide when and how much to think based on complexity.

"thinking": {"type": "adaptive"},
"output_config": {"effort": "high"}

Guardrails

Guardrails protect your input/output. Few key things to know:

Required Headers

• X-Amzn-Bedrock-GuardrailIdentifier (required) — The ID of the guardrail
• X-Amzn-Bedrock-GuardrailVersion (required) — The version of the guardrail
• X-Amzn-Bedrock-Trace (optional) — Enable guardrail trace

Modes

• Synchronous mode (default) — buffers and applies policies before sending response back. Adds latency but ensures compliance.
• Asynchronous mode — sends response chunks immediately while applying policies in the background. No latency impact, but content may be flagged after delivery.

Special Features

• Mask — anonymize content and replace with identifier tags ({NAME}, {EMAIL}). Available only with sensitive information filters.
• Automated Reasoning checks — operate in detect mode only. They return findings and feedback rather than blocking content.

Caching and Logging

• When store is true (the default), Bedrock retains the response (input + output) for 30 days in the source region.
• Invocation logging — collects full request data, response data, and metadata for all supported calls in your account/Region.
• Cache checkpoints — have minimum and maximum token limits depending on the model. Your prompt prefix must meet the minimum to create a checkpoint.

Service Comparison : What to Use When

Vector Store Comparison

PII Finding vs Redaction : Decision Matrix

Different services handle PII at different levels — storage, processing, inference. Here’s how to decide what goes where:

How They Work Together

• At rest (S3) — Macie scans and alerts on PII sitting in buckets. Detection only, no modification.
• In pipeline (Glue) — Redact PII during ETL before data lands in analytics or training datasets.
• In documents (Textract + Comprehend) — Textract extracts text from PDFs/images, Comprehend finds and redacts PII in that extracted text.
• At inference (Guardrails) — Last line of defense. Masks PII in prompts going to the model and in responses coming back.
• In text processing (Comprehend standalone) — Use for batch PII detection/redaction on any text corpus.

Quick Decision Guide