dataonaws
— Stack · AI

Amazon Bedrock

One API to call foundation models from several providers, open-weight models included. You pay per token, and three choices decide most of the bill and of the compliance story.

How it fits

Your app talks to one API. Bedrock routes to the model.

Your app / agentIAM role, VPC endpointConverseOpenAI · MessagesAMAZON BEDROCKGuardrailsinput and output checksKnowledge Basesretrieval from your docsModel ID or inference profiledecides which model, and in which regions it runsPrompt caching · batch · provisioned throughputAnthropic ClaudeAmazon NovaOpen-weight modelsgpt-oss, Qwen, DeepSeek, Mistral…metrics + invocation logs → CloudWatch / S3

Prompts and responses are not used to train the models.

The API your code already speaks

No rewrite to move an app onto Bedrock.

Bedrock native

Converse

client.converse(
  modelId="…",
  messages=[…])

One request shape for every model on Bedrock. Switching model is a change of ID.

OpenAI-compatible

Chat Completions, Responses

OpenAI(base_url=
  ".../openai/v1")

Point the OpenAI SDK at Bedrock and keep your code. Works with gpt-oss and the other models that support it.

Anthropic-compatible

Messages

POST .../anthropic
  /v1/messages

The native Claude request format, for apps and tools built on the Anthropic SDK.

Same IAM, logging and guardrails behind each API. Which API a model supports is listed per model in the docs.

Open-weight models

Open models, without running GPUs.

gpt-ossQwen3DeepSeek V3.2Kimi K2.5GLM 4.7Mistral Large 3GemmaMiniMax

Availability varies by region: check yours before you plan on a model.

Same models you could self-host, served and scaled by AWS, billed per token.
No lock-in on one lab. Swap between open and proprietary models behind the same API.
Fine-tune them. Reinforcement fine-tuning covers gpt-oss and Qwen, then the tuned model serves on demand.
The three choices that matter

Most of the cost and the compliance comes from here.

01

Which model, for which step

Price per token grows with model size. Small models for simple steps, the large one only where it changes the result.

02

Where it runs

The inference profile decides which regions may serve a request. Agree it with your compliance team before the first model goes live.

03

How you pay

Batch costs half for jobs that can wait. Prompt caching cuts the price of a long prompt you resend; the ratio depends on the model.

Model sizes and the cached-input bar are illustrative shapes, not prices.

What you pay

A Bedrock bill, in one line.

Input tokens
× price in
System prompt, history, retrieved documents
+
Output tokens
× price out
Priced higher than input on most models
+
Around the model
Knowledge Bases, Guardrails
Index storage, retrieval calls, text units checked
+
Logs
CloudWatch, S3
Invocation logging, if enabled
What we see in production
The same long system prompt resent on every call.Prompt caching is usually the first saving.
One large model for every step of an agent.Routing simple steps to a smaller model lowers the bill where quality allows.
No cost per team or per use case.Tag an inference profile per application before usage grows.
How we help

End-to-end agentic AI use cases

From business need to production, customer-facing included, with evaluation and ops to match.

Read the approach →
PDF · coming soon

The one-page Amazon Bedrock field guide.

Best practices, cost traps and performance checks, in the order you should run them. Printable, no fluff.

One email when the PDF is ready. Nothing else unless you tick the box.