Amazon Bedrock: one API for foundation models, knowledge bases, agents and guardrails

Almost every generative AI question on the AIF-C01 exam has Amazon Bedrock somewhere in the answer. It is the service that turns "we want to use a foundation model" into an API call: pick a model from a catalogue of providers, send a prompt, get a completion, and pay for the tokens. Around that call AWS has built the pieces a real application needs, and each piece has a name the exam expects you to know: Knowledge Bases for your documents, Agents for tasks that take several steps, Guardrails for what must never be said, customisation jobs for teaching a model your data, evaluation jobs for choosing between models, and the logging, pricing and network controls that let a regulated company sign off on all of it. This article is the reference for the whole service. The previous article placed Bedrock in the AWS stack, and the next one explains the theory of RAG, vector search and agent loops; here the subject is Bedrock itself, feature by feature.

The map

Read this first when short on time. Every branch is a section below.

One API: what Amazon Bedrock is and the promise it makes about your data

Amazon Bedrock is a fully managed, serverless service that puts foundation models from Amazon and several other providers behind a single API, so an application can call any of them with one set of credentials, one SDK and one bill, without provisioning or running any model infrastructure.

"Fully managed" and "serverless" carry specific meaning here. There is no instance to choose, no container to patch and no endpoint sitting idle at night: AWS runs the models on shared capacity in its own accounts, and you are billed for what you use, by the token for text models, by the image for image models, or by the hour for reserved capacity. "Single API" means that the same InvokeModel or Converse call reaches an Amazon Nova model, an Anthropic Claude model or a Meta Llama model, and switching between them is a change to a model identifier, not a rewrite. That is what makes the model choice reversible: you can evaluate three models against your own prompts and change your mind after launch.

The catalogue at the time of writing has models from Amazon (the Titan and Nova families), Anthropic, Meta, Mistral AI, Cohere, AI21 Labs and Stability AI, with a longer tail of specialised and open-weights models offered through Amazon Bedrock Marketplace. The next section lists them. Around the models, Bedrock adds managed building blocks that would otherwise be weeks of work each: Knowledge Bases for retrieval over your documents, Agents for multi-step tasks that call your APIs, Guardrails for filtering input and output, model customisation for fine-tuning or continued pre-training, model evaluation for comparing candidates, Prompt Management and Flows for versioned prompts and visual pipelines, and invocation logging for the audit trail.

flowchart TD
  APP["Your application<br/>AWS SDK call with IAM credentials"]
  GI["Guardrail, input side<br/>denied topics, PII, prompt attacks"]
  CV["Converse or InvokeModel<br/>one prompt, one answer"]
  RG["RetrieveAndGenerate<br/>a Knowledge Base"]
  IA["InvokeAgent<br/>an Agent"]
  FM["Foundation model<br/>Nova, Claude, Llama, Mistral, Cohere"]
  VS["Vector store<br/>OpenSearch Serverless by default"]
  LF["AWS Lambda<br/>action group"]
  GO["Guardrail, output side<br/>grounding check, PII redaction"]
  APP --> GI
  GI --> CV
  GI --> RG
  GI --> IA
  CV --> FM
  RG --> VS
  RG --> FM
  IA --> LF
  IA --> RG
  IA --> FM
  FM --> GO
  GO --> APP

The data promise

The sentence AWS repeats in every Bedrock page is the one the exam tests most: your prompts and completions are not used to train or improve the base models, and they are never shared with the model providers. The provider does not see your traffic; the model runs inside AWS. Data is encrypted in transit with TLS and at rest with AWS-managed keys, or with your own AWS KMS keys where Bedrock stores something on your behalf (custom models, Knowledge Base configuration, agents, logs). Inputs and outputs are processed in the region you called and are not stored by the service unless you turn on model invocation logging yourself. Custom models that you create by fine-tuning are private copies that only your account can invoke. AWS does run automated abuse detection on traffic, which looks for patterns that break the acceptable use policy, but that is a classifier over content, not a training pipeline.

The stack article compared Bedrock with SageMaker JumpStart, where you host a model yourself. The one-line version: JumpStart gives you an endpoint you run on instances you pay for by the hour; Bedrock gives you an API you pay for by use, and everything below it is AWS's problem.

foundation model (FM)

A large model trained on broad data that can be adapted to many tasks by prompting or customisation; Bedrock's catalogue is a list of these.

serverless

The service scales and runs the infrastructure; you never see or pay for an instance, only for use.

model provider

The company that trained the model: Amazon, Anthropic, Meta, Mistral AI, Cohere, AI21 Labs, Stability AI and others. Bedrock hosts their models without them seeing your data.

The model catalogue: providers, families and what each modality does

The Bedrock catalogue is organised by provider, then by model family, and the first thing to know about any family is its modality: what goes in, what comes out, and whether it is meant for generation, embeddings or images.

The exam does not ask for version numbers, which change every few months, but it does expect you to know which family does what and which provider it belongs to. The table lists the families that appear in the exam guide and the ones the console shows first.

Beyond that table the catalogue keeps growing: DeepSeek reasoning models, Luma AI and TwelveLabs for video, Writer for enterprise text, and open-weights models from OpenAI and Qwen have appeared as fully managed serverless models, and Amazon Bedrock Marketplace adds more than a hundred specialised models that deploy onto managed endpoints rather than shared serverless capacity. The exam guide names only the families in the table.

Model access

A model must be enabled in your account and region before it can be called. In the console the Model access page lists every model with its status; historically every model had to be requested, and Anthropic models asked for a short use-case form, filled in once per account. Newer accounts have most serverless models enabled on first use, but the IAM side never went away: a principal needs bedrock:InvokeModel on the model's ARN, so access is really two gates, the account-level switch and the IAM policy. When a question describes a developer who "cannot see the model in the console" or gets an access denied error on a new model, one of those two gates is the answer.

The playgrounds

The console has a chat and text playground, an image playground and a video playground. Each lets you pick a model, type a prompt, drag the inference parameters (temperature, top-p, response length, stop sequences) and see the output, with a compare mode that puts up to three models side by side on the same prompt, and a "view API request" button that shows the exact JSON so the experiment can be pasted into code. The playgrounds are where a model is evaluated by hand before an evaluation job or an application is written; they use the same on-demand pricing as the API.

modality

The kind of data a model consumes and produces: text, image, video, audio, or an embedding vector.

open weights

A model whose trained parameters are published under a licence, so it can run on Bedrock or on your own hardware; Llama and Mistral are examples, Claude and Nova are not.

mixture of experts

An architecture where only some of the model's sub-networks activate for each token, giving a large model's quality at a smaller model's cost per token; Mixtral is the well-known example.

Amazon Bedrock Marketplace

A catalogue of additional models from many providers that deploy onto managed endpoints you pay for by the hour, reached through the same Bedrock APIs.

Calling a model: the endpoints, InvokeModel, Converse and the inference parameters

Bedrock is four API endpoints, and inference itself is two request shapes: InvokeModel, which sends the provider's own JSON, and Converse, which sends one uniform message format to every model, each with a streaming twin.

The SDKs split Bedrock into four clients, and knowing which does what saves confusion when reading an IAM policy or an error message. bedrock is the control plane: list the foundation models, start a customisation or evaluation job, configure logging, buy provisioned throughput. bedrock-runtime is inference: InvokeModel, Converse, their streaming variants and ApplyGuardrail. bedrock-agent builds Knowledge Bases, Agents, Flows, Prompts and Guardrail configuration, and bedrock-agent-runtime runs them: Retrieve, RetrieveAndGenerate, InvokeAgent, InvokeFlow and Rerank.

flowchart TD
  APP["Your application or the console"]
  B["bedrock<br/>control plane: list models, customisation and evaluation jobs,<br/>logging settings, provisioned throughput"]
  BA["bedrock-agent<br/>build time: create Knowledge Bases, Agents,<br/>Flows, Prompts, Guardrails"]
  BR["bedrock-runtime<br/>InvokeModel, Converse, the streaming variants,<br/>ApplyGuardrail"]
  BAR["bedrock-agent-runtime<br/>Retrieve, RetrieveAndGenerate, InvokeAgent,<br/>InvokeFlow, Rerank"]
  APP --> B
  APP --> BA
  B --> BR
  BA --> BAR

InvokeModel

InvokeModel takes a modelId and a body, and the body is whatever JSON that provider's model expects: Titan Text wants inputText and a textGenerationConfig block, Anthropic wants a messages array with max_tokens, Llama wants a prompt string with max_gen_len. The response body is equally provider-specific. It works for every model, including image and embedding models, which have no chat shape to unify, but switching text models means rewriting the request and the response parsing. InvokeModelWithResponseStream is the same request with the answer delivered as a stream of chunk events as the tokens are produced, which is what a chat interface needs to show text appearing rather than a spinner.

Converse

Converse was added to remove that per-provider rewrite for conversational models. Every request has the same shape: an optional system prompt, a messages array of user and assistant turns whose content blocks can be text, images or documents, an inferenceConfig with the common parameters, and optional toolConfig for tool use and guardrailConfig to attach a guardrail. Anything provider-specific goes in additionalModelRequestFields (top-k is the usual case). Every response has the same shape too: the assistant's message, a stopReason (end_turn, max_tokens, stop_sequence, tool_use, guardrail_intervened or content_filtered) and a usage block with input and output token counts, which is what a cost dashboard reads. ConverseStream streams the same thing. Because the format is uniform, changing the model is changing one string.

import boto3

rt = boto3.client("bedrock-runtime", region_name="eu-west-1")

resp = rt.converse(
    modelId="amazon.nova-lite-v1:0",          # swap for anthropic.claude-... and nothing else changes
    system=[{"text": "You answer in one short paragraph."}],
    messages=[{"role": "user", "content": [{"text": "What does a Bedrock Knowledge Base do?"}]}],
    inferenceConfig={"maxTokens": 300, "temperature": 0.2, "topP": 0.9, "stopSequences": ["###"]},
)

print(resp["output"]["message"]["content"][0]["text"])
print(resp["stopReason"], resp["usage"])   # end_turn {'inputTokens': 31, 'outputTokens': 84, ...}

The modelId does not have to be a base model. It can be the ARN of a custom model you fine-tuned, of the provisioned throughput that hosts it, of an imported model, of a prompt from Prompt Management, or a cross-region inference profile such as eu.amazon.nova-lite-v1:0, which lets Bedrock route the request to any region in the geography with spare capacity. The same call handles all of them.

The inference parameters

The applications article explains what each sampling parameter does to the probability curve; here is where they live in Bedrock and what to reach for in a scenario.

Two rules of thumb. Change temperature or top-p, not both, or the effects become hard to reason about. And remember that these parameters change the output, not the model: a question that proposes retraining to make answers "more consistent" or "less random" is describing a temperature setting.

InvokeModel

The original inference API: a model identifier plus the provider's native JSON body; works for text, image and embedding models.

Converse

The uniform chat API: system, messages, inferenceConfig, toolConfig and guardrailConfig in one shape for every conversational model.

stopReason

Why generation ended: the model finished, hit the token cap, hit a stop sequence, asked to use a tool, or a guardrail intervened.

inference profile

A model identifier that stands for a model in one or more regions; cross-region profiles let Bedrock route a request across a geography.

Knowledge Bases: managed retrieval over your own documents

Amazon Bedrock Knowledge Bases (launched as Knowledge Bases for Amazon Bedrock) is the managed implementation of Retrieval Augmented Generation: you point it at your documents, choose an embedding model and a vector store, and it ingests, chunks, embeds and indexes them, then answers questions from them with citations through two APIs.

The applications article explains why RAG works and where it fails; this section is about the Bedrock product. The reason it exists is the exam's favourite scenario: a company wants a model to answer from its own current documents, does not want to train anything, and must show where each answer came from. A Knowledge Base does that in a console wizard.

Building one

1. Choose a data source. Amazon S3 is the usual one: a bucket or prefix of PDFs, Word files, HTML, Markdown, CSV and text, optionally with a sidecar metadata JSON per file for filtering. Other connectors are a web crawler for public pages, Confluence, Microsoft SharePoint and Salesforce, and a custom data source that lets your own code push documents through the API. A Knowledge Base can also sit on structured data (Amazon Redshift, tables in the AWS Glue Data Catalog), where it turns a question into SQL instead of a vector search, or use an Amazon Kendra GenAI index as its retriever.
2. Choose how documents are parsed and chunked. The default parser extracts text; a foundation-model parser or Amazon Bedrock Data Automation can be used instead to read tables, figures and scanned pages. Chunking decides how big each retrievable piece is; the table below lists the strategies.
3. Choose the embedding model. Amazon Titan Text Embeddings V2 (with a choice of vector dimensions) or Cohere Embed, English or Multilingual. The same model embeds the question later, so it cannot be changed without re-indexing.
4. Choose the vector store. "Quick create" makes an Amazon OpenSearch Serverless vector collection for you; otherwise you connect a store you already run. The table below lists them.
5. Sync. An ingestion job reads the source, chunks, embeds and writes to the store. It is incremental: re-running it picks up new, changed and deleted documents. Nothing is retrievable until the first sync finishes.

Two ways to query

Retrieve does the search only: it embeds the question, queries the store and returns the top chunks with their text, relevance score, source location (an S3 URI, a URL) and metadata. Your code decides what to do with them, which is right when you want your own prompt, your own model or no generation at all. RetrieveAndGenerate does the whole thing: it retrieves, builds a prompt from the chunks and the question, calls the foundation model you choose, and returns the answer with citations that tie each span of the answer to the chunks and documents it came from. A sessionId keeps a conversation going across calls so follow-up questions can lean on earlier turns, and RetrieveAndGenerateStream streams the answer. Query-time options cover the number of results, semantic versus hybrid search, metadata filters (only documents where department equals finance), a re-ranking model over the candidates, query decomposition for multi-part questions, and a custom generation prompt template.

sequenceDiagram
  autonumber
  participant A as Application
  participant K as Knowledge Base
  participant V as Vector store
  participant M as Foundation model
  A->>K: RetrieveAndGenerate, the question
  K->>K: embed the question
  K->>V: nearest chunks, top k, filters
  V-->>K: chunks, scores, source URIs
  K->>K: prompt from chunks and question
  K->>M: generate an answer
  M-->>K: answer grounded in the chunks
  K-->>A: answer plus citations, sessionId

A Knowledge Base is also a component: an Agent can have one or more attached as tools, a Flow can have a Knowledge Base node, and a Guardrail's contextual grounding check can use the retrieved chunks as the source of truth to test the answer against. That last combination, retrieval plus a grounding check, is the exam's complete answer to "reduce hallucinations about company information".

data source

Where a Knowledge Base reads documents: S3, a web crawler, Confluence, SharePoint, Salesforce or a custom feed through the API.

ingestion job (sync)

The run that parses, chunks, embeds and indexes new and changed documents from a data source.

citation

In a RetrieveAndGenerate response, the mapping from a span of the answer to the retrieved chunks and their source locations.

GraphRAG

Retrieval that also follows relationships between entities in a graph, so related chunks are found even when they share no words; Neptune Analytics is Bedrock's graph store for it.

Agents: a model that plans, calls your APIs and remembers the session

Amazon Bedrock Agents (launched as Agents for Amazon Bedrock) is the managed way to build an assistant that completes a task in several steps: you give it instructions, a foundation model and a set of tools, and Bedrock runs the loop in which the model decides what to do next, calls a tool, reads the result and continues until it can answer.

The applications article explains the agent loop as a pattern; the pieces of the Bedrock product are what the exam asks about, and each has a fixed name.

• Instructions. Plain English describing the agent's job and rules ("You help customers track and change orders. Never cancel an order without confirming the order number."). Bedrock combines them with the tool definitions into the orchestration prompt.
• Foundation model. The model that reasons; a Claude or Nova model is typical. Its quality decides how well the agent plans.
• Action groups. The tools. Each action group is a set of operations defined either by an OpenAPI schema (paths, parameters and descriptions, in JSON or YAML, inline or in S3) or by function details (name, description and parameters typed straight into the console). The descriptions are read by the model to decide which operation fits, so they are prompt engineering, not documentation. Each group is executed by an AWS Lambda function that receives the chosen operation and its parameters and does the real work, or is set to return of control, in which case Bedrock hands the chosen operation back to your application in the response and your code executes it and sends the result in the next call. Operations can require user confirmation before they run. A built-in code interpreter action group lets the agent write and run Python in a sandbox for calculations and file handling.
• Knowledge Bases. Attaching one gives the agent a retrieval tool; the agent decides when to search and cites what it used.
• Guardrails. A guardrail attached to the agent filters the user's input and the agent's final output.
• Memory. Session memory is the conversation within one sessionId: every turn, tool call and result is kept until the session ends or times out. Optional long-term memory keeps a summary of past sessions for the same user (a memoryId) for a configurable number of days, so the agent remembers preferences across conversations.
• Prompt templates and trace. The four prompts the agent uses internally (pre-processing, orchestration, Knowledge Base response generation, post-processing) can be edited, and enableTrace returns every reasoning step, tool call and observation, which is how an agent is debugged.
• Versions and aliases. An agent is edited as a draft, prepared, and invoked through an alias that points at a version, so production keeps running the tested version while you change the draft.

The reasoning loop

An InvokeAgent call carries the user's text and a sessionId. The agent optionally pre-processes the input (is this request valid and in scope?), then enters orchestration: the model is shown the instructions, the tools, the conversation so far and the new request, and it produces either a tool call or a final answer. A tool call is executed (Lambda, return of control or a Knowledge Base search), the result is appended as an observation, and the model is asked again. When it produces a final answer, optional post-processing can rewrite it, the Guardrail checks it, and the response streams back with the trace if requested. This is the ReAct pattern, reason then act then observe, run by Bedrock.

sequenceDiagram
  autonumber
  participant A as Application
  participant G as Bedrock Agent
  participant M as Foundation model
  participant L as Lambda action
  A->>G: InvokeAgent(sessionId, text)
  G->>M: orchestration prompt plus tools
  M-->>G: call getOrder(orderId 4471)
  G->>L: event with operation and params
  L-->>G: order status as JSON
  G->>M: observation appended, continue
  M-->>G: final answer text
  G-->>A: completion stream plus trace

Beyond one agent

Multi-agent collaboration lets a supervisor agent delegate to specialist collaborator agents, each with its own instructions and tools, when one agent's instruction set would grow too long to follow reliably. Inline agents are defined at invocation time in the request rather than created in advance, useful when tools differ per user. And for teams that bring their own agent framework rather than Bedrock's loop, Amazon Bedrock AgentCore offers the runtime, memory, gateway and identity services to host it; for the exam, Bedrock Agents is the managed loop and that is enough.

action group

A named set of operations an agent may call, described by an OpenAPI schema or function details, executed by a Lambda function or returned to the application.

return of control

An action group setting under which Bedrock returns the chosen operation and parameters to the caller instead of invoking Lambda.

orchestration

The loop in which the model reads the state, chooses a tool or an answer, and continues after each observation.

alias

A named pointer to a prepared version of an agent (or a Flow or Prompt), so callers are insulated from edits to the draft.

Guardrails: the policies that filter what goes in and what comes out

Amazon Bedrock Guardrails (launched as Guardrails for Amazon Bedrock) is a set of configurable safety policies that is applied to the prompt before it reaches the model and to the response before it reaches the user, independent of which model is used, so an organisation defines its rules once and applies them everywhere.

A guardrail is a resource you create, version and attach. It can be attached to a model call (the guardrailConfig block in Converse or the guardrail fields of InvokeModel), to an Agent, to a Knowledge Base's RetrieveAndGenerate, and to a Flow. It can also be called on its own through the ApplyGuardrail API with any text you like, which is how the same policies are applied to a model hosted on SageMaker, a third-party API or a legacy chatbot. Each guardrail is built from up to six policy types.

flowchart TD
  U["User prompt"]
  I["Input policies<br/>content filters and prompt attack, denied topics,<br/>word filters, sensitive information"]
  FM["Foundation model, Agent or Knowledge Base<br/>produces a response"]
  O["Output policies<br/>content filters, denied topics, word filters,<br/>sensitive information masked or blocked"]
  G["Contextual grounding check<br/>is the answer supported by the source and relevant"]
  R["Response to the user<br/>or the configured blocked message"]
  U --> I
  I --> FM
  FM --> O
  O --> G
  G --> R

When a policy fires, the caller sees a stopReason of guardrail_intervened and the response text is replaced by the blocked message you configured ("Sorry, I can only help with questions about your account."). The assessment in the response says which policy matched, which is what a compliance report reads. Guardrails are versioned like code: you edit a working draft, create a numbered version and point production at it. Selective evaluation lets you tag only part of a prompt (the user's text, not your system instructions) so the filters do not fire on your own template. Streaming responses are checked in chunks as they arrive, or, if you prefer certainty over latency, after the whole response is complete.

denied topic

A subject defined in plain language that the guardrail refuses to discuss, on input or output.

prompt attack

An input that tries to override the system prompt or trick the model out of its rules (jailbreak, prompt injection); one of the content filter categories.

masking

Replacing detected sensitive information with a type tag, leaving the rest of the text intact; the alternative to blocking the whole message.

ApplyGuardrail

The API that runs a guardrail over arbitrary text without a model call, so the policies work outside Bedrock's own inference.

Customisation: fine-tuning and continued pre-training, and the private model they produce

Model customisation in Bedrock is a managed training job that takes a supported base model and your data in S3 and produces a private custom model in your account, either by fine-tuning on labelled examples of the task you want or by continued pre-training on unlabelled text from your domain.

Customisation is the expensive rung of the ladder that the applications article describes and the training article explains in depth; here is how the Bedrock product works and, more important for the exam, when to reach for it and when not to.

Fine-tuning

Fine-tuning teaches a model a task or a style: answer in our support tone, classify tickets into our twelve categories, extract fields into our JSON schema. The training data is labelled: a JSONL file in S3 where each line is an example of an input and the output you want. For older text models each line is a prompt and a completion; for conversational models it is a system prompt plus a messages array in the Converse shape. A validation file lets the job report how well the model generalises. You choose the base model (Amazon Titan Text, Amazon Nova, Meta Llama, Cohere Command and Anthropic Claude Haiku are among those that support fine-tuning) and a few hyperparameters, chiefly the number of epochs, the batch size, the learning rate and warm-up steps; the job writes training and validation loss to S3 as it goes.

{"prompt": "Classify the ticket: My invoice shows two charges for March.", "completion": "billing_duplicate_charge"}
{"prompt": "Classify the ticket: The app crashes when I open settings.", "completion": "app_crash"}
{"prompt": "Classify the ticket: How do I add a second user to my plan?", "completion": "account_management"}

Continued pre-training

Continued pre-training teaches a model vocabulary rather than a task: it keeps training the base model on raw, unlabelled text from your domain (regulatory filings, clinical notes, your own product documentation) so it becomes fluent in that language before you prompt or fine-tune it. The data is a JSONL file where each line carries just an input field of text. It needs far more data than fine-tuning and is supported on a smaller set of models, the Amazon Titan Text family in particular. It does not make the model know today's facts, and it does not give citations; that is what a Knowledge Base is for.

What you get, and what it costs to run

Both jobs produce a custom model: a private copy visible only in your account, encrypted with an AWS key or your own KMS key, listed under custom models in the console. The base model is unchanged for everyone else. The rule the exam repeats is that a custom model cannot be invoked on demand; it must be hosted on provisioned throughput, bought in model units by the hour, either with no commitment or with a one- or six-month commitment at a lower hourly rate. So the bill for customisation has three parts: the training job, charged by tokens processed times epochs; storage of the custom model per month; and provisioned throughput for as long as it is invocable. That third line is why a fine-tuned model that serves a few requests a day is usually the wrong design.

flowchart TD
  D["Training data in Amazon S3<br/>a JSONL file: labelled pairs,<br/>or raw domain text"]
  J["Model customisation job<br/>base model, epochs, batch size<br/>learning rate, VPC and KMS options"]
  V["Metrics to S3<br/>training and validation loss"]
  M["Custom model<br/>private, encrypted, in your account"]
  P["Provisioned throughput<br/>model units, hourly or committed"]
  I["Invoke with the same API<br/>modelId is the provisioned model ARN"]
  D --> J
  J --> V
  J --> M
  M --> P
  P --> I

Two neighbours of customisation are worth a sentence. Custom Model Import brings weights you trained elsewhere (Llama, Mistral and a few other architectures, from S3 or a SageMaker training job) into Bedrock, where they run on demand and are billed in custom model units while active. Model Distillation uses a large teacher model to generate training responses for a small student model of the same family (Nova Premier teaching Nova Pro, a large Claude teaching a smaller one), from your prompts or from your invocation logs, so you get much of the large model's quality at the small model's price and latency.

Which rung of the ladder

fine-tuning

Further training of a base model on labelled input and output pairs so it performs a specific task or adopts a style; in Bedrock a managed job over JSONL in S3.

continued pre-training

Further training on unlabelled domain text so the model learns the field's language; needs more data and produces a custom model in the same way.

epoch

One full pass over the training data; more epochs fit the data more closely, at the risk of over-fitting.

custom model

The private output of a customisation job, stored in your account and callable only through provisioned throughput.

distillation

Training a small student model on responses generated by a large teacher, to keep most of the quality at a fraction of the cost.

Model evaluation: automatic metrics, a model as judge, or people

Amazon Bedrock model evaluation is a managed job that measures how a model performs on a task against a dataset, in three styles: automatic scoring with built-in metrics, an evaluator model that judges responses, and human evaluation by your own team or one AWS manages.

The playground tells you what one model does on one prompt; an evaluation job tells you what it does on a thousand, with a number attached, so the model choice can be defended and repeated when a new version appears. The training article covers the metrics themselves (ROUGE, BLEU, BERTScore, F1) and the public benchmarks; this section is about the job.

A Knowledge Base has its own evaluation job, RAG evaluation, with two modes: retrieval only, scored on context relevance and context coverage (did the right chunks come back), and retrieve-and-generate, scored on correctness, completeness, faithfulness (the hallucination metric), helpfulness, citation precision and coverage, and harmfulness. Results of every evaluation land in the console as a report and in S3 as JSON, so they can be compared across runs and pinned to a release.

robustness

How much a model's output changes when the input is perturbed slightly (typos, rewording); a metric in Bedrock's automatic evaluation.

faithfulness

Whether a generated answer is supported by the context it was given; the RAG evaluation metric for hallucination.

work team

The group of people who rate responses in a human evaluation job; your own employees, or a team AWS provides.

Builder tools: Prompt Management, Flows, Bedrock Studio and the smaller pieces

Around the core features Bedrock adds tools for the people building on it: Prompt Management to version prompts as resources, Flows to wire prompts, Knowledge Bases, Agents and code into a visual pipeline, and a team workspace so builders need not touch the AWS console.

Prompt Management

A prompt in Amazon Bedrock Prompt Management is a stored resource: the template text with {{variables}}, the model it targets, its inference parameters, and numbered versions. You test it in the console with sample variable values, publish a version, and reference the prompt's ARN as the modelId in Converse or InvokeModel, passing the variable values in the request, or drop it into a Flow. The point is that prompt text stops living in application code: it can be edited, reviewed and rolled back by the people who own the wording, and production pins a version.

Flows

Amazon Bedrock Flows (launched as Prompt Flows for Amazon Bedrock) is a visual builder for multi-step generative AI pipelines. A flow is a graph of nodes: input and output, prompt nodes (inline or from Prompt Management), Knowledge Base nodes, Agent nodes, Lambda nodes for custom code, an Amazon Lex node for a conversational front end, condition nodes for branching, iterator and collector nodes for loops, and S3 storage and retrieval nodes. You draw it, test it in the console, and invoke it with InvokeFlow through an alias, exactly as with an Agent. Where an Agent decides its own steps at run time, a Flow runs the steps you drew, which makes it the right tool for a fixed pipeline such as classify, then route, then answer.

flowchart TD
  IN["Flow input<br/>the customer's message"]
  PR["Prompt node<br/>classify the message, template from Prompt Management"]
  CD{"Which kind?"}
  KB["Knowledge Base node<br/>policy and product questions"]
  AG["Agent node<br/>changes to an account or an order"]
  LF["Lambda node<br/>anything else goes to a ticket"]
  OUT["Flow output<br/>reply to the customer"]
  IN --> PR
  PR --> CD
  CD -- "question" --> KB
  CD -- "action" --> AG
  CD -- "other" --> LF
  KB --> OUT
  AG --> OUT
  LF --> OUT

Bedrock Studio

Amazon Bedrock Studio was launched as a web workspace where a team signs in through AWS IAM Identity Center and builds prototype applications with models, Knowledge Bases, Agents and Guardrails, in shared projects, without anyone needing IAM users or console access; its successor is Amazon Bedrock IDE inside Amazon SageMaker Unified Studio, which keeps the same purpose. When a question wants "a team of builders to experiment and share generative AI apps with single sign-on and without the AWS console", this is what it means; PartyRock is the public, no-account version for individuals.

The smaller pieces

• Amazon Bedrock Data Automation turns unstructured documents, images, audio and video into structured output (extracted fields, summaries, transcripts, scene descriptions) with one API, and doubles as an advanced parser for Knowledge Bases.
• Intelligent Prompt Routing sends each request to the cheaper or the stronger model within a family depending on how hard the prompt looks, to cut cost without a visible quality drop.
• Prompt caching reuses the processed prefix of a long repeated prompt (a big system prompt, a long document) at a discount and with lower latency on supported models.
• Latency-optimised inference is a per-request option on some models that returns tokens faster at a higher price, for the cases where a person is waiting.
• Amazon Bedrock Marketplace extends the catalogue with specialised models deployed onto endpoints you pay for by the hour but call through the Bedrock APIs.

prompt variable

A placeholder such as {{customer_name}} in a managed prompt, filled in at invocation time.

node

One step in a Flow: a prompt, a Knowledge Base query, an Agent call, a Lambda function, a condition or an input or output.

prompt caching

Reusing the model's processed state for a repeated prompt prefix so the repeated part is charged less and answered faster.

Logging and audit: invocation logs, CloudWatch metrics and CloudTrail

Bedrock records what happened in three places for three purposes: model invocation logging captures the prompts and responses themselves, CloudWatch metrics count and time the calls, and AWS CloudTrail records who made which API call, so an audit can answer what was asked, how much and by whom.

Model invocation logging

Model invocation logging is off by default, because prompts can carry personal data and AWS does not keep them unless you ask. You turn it on per account and region in the Bedrock settings, choosing Amazon CloudWatch Logs, Amazon S3 or both as the destination, and which data types to include (text, images, embeddings). Each record has the timestamp, the caller's account and identity, the region, the model identifier, the full request and response bodies, the inference parameters and the input and output token counts; payloads too large for a log event are written to S3 with a pointer in the log. This is the data behind a cost dashboard by team, a review of what users actually ask, a training set for distillation, and the evidence a compliance officer wants when a user reports an odd answer.

CloudWatch metrics

Bedrock publishes metrics to the AWS/Bedrock namespace without any setup: Invocations, InvocationLatency, InvocationClientErrors, InvocationServerErrors, InvocationThrottles, InputTokenCount, OutputTokenCount and OutputImageCount, by model identifier. Alarms on throttles tell you that on-demand quotas are being hit and provisioned throughput or cross-region inference should be considered; alarms on latency catch a slow model before users do.

CloudTrail and EventBridge

CloudTrail records Bedrock API calls as events: who created a guardrail, changed the logging configuration, started a customisation job or invoked a model, with the identity, time and source IP, but not the prompt or response content. Runtime calls to Agents and Knowledge Bases are data events that must be enabled on the trail. Amazon EventBridge receives state changes from long-running jobs (a customisation job finished, a batch inference job failed) so a pipeline can react without polling.

flowchart TD
  I["Every model invocation<br/>InvokeModel, Converse, the streaming variants"]
  L["Model invocation logging<br/>off by default, enabled per account and region"]
  CW["Amazon CloudWatch Logs<br/>prompt, response, model id, token counts"]
  S3["Amazon S3<br/>full bodies, large payloads, long retention"]
  CT["AWS CloudTrail<br/>who called which API, when, from where"]
  CM["CloudWatch metrics<br/>Invocations, InvocationLatency, token counts, throttles"]
  I --> L
  L --> CW
  L --> S3
  I --> CT
  I --> CM

model invocation logging

The opt-in Bedrock setting that writes each request and response, with metadata and token counts, to CloudWatch Logs or S3.

data event

A CloudTrail event for a high-volume runtime operation (here, Agent and Knowledge Base invocations) that must be switched on explicitly.

throttle

A rejected request because the account exceeded a per-model rate quota; counted in InvocationThrottles.

Pricing: on-demand tokens, batch, provisioned throughput and the other line items

Bedrock is paid for in three modes, on-demand by the token, batch by the token at a discount, and provisioned throughput by the model unit per hour, plus a handful of separate charges for customisation, storage, Guardrails and the stores that Knowledge Bases use.

The stack article covered the cost trade-offs in general; this is the Bedrock price list in shape, without numbers, because the numbers change per model and the exam never asks for them.

The other line items

• Customisation: a training charge per token processed (tokens in the training data times epochs), then custom model storage per model per month, then provisioned throughput to serve it. Custom Model Import instead bills custom model units in five-minute windows while the model is active.
• Knowledge Bases: no charge for the feature itself, but the embedding model's tokens at ingestion and query time, the generation model's tokens, and the vector store (OpenSearch Serverless compute units, Aurora instances, a partner's subscription).
• Agents and Flows: no separate charge; you pay for the model tokens each step uses and for the Lambda functions they call.
• Guardrails: per text unit (a block of characters) per policy type applied; word filters are free, the content, denied-topic, sensitive-information and grounding policies are metered.
• Model evaluation: the inference the job performs, plus the human work team's time if it is AWS's.
• Levers that cut the bill: a smaller model, shorter prompts, a lower maximum output, prompt caching, Intelligent Prompt Routing and batch for anything offline.

Cross-region inference

A cross-region inference profile lets Bedrock route a request to any region within a geography (the US regions, the EU regions, the Asia Pacific regions) that has capacity, which raises the throughput you can get on demand and absorbs bursts without provisioned units. It is priced at the source region's rate with no extra charge, the request and response are processed in whichever region served them, logs stay in the source region, and the data never leaves the geography, which is the fact a data protection review needs. Some models also offer a global profile that routes worldwide. When a scenario says "on-demand throttling during peaks" and "no reserved capacity", a cross-region profile is the answer.

model unit

The unit of provisioned throughput: a fixed rate of input and output tokens per minute for one model, billed per hour.

batch inference

A job that processes a JSONL file of prompts from S3 and writes the results to S3, at a discount, in hours.

text unit

The metering unit for Guardrails: a block of characters of input or output that each policy is charged against.

cross-region inference profile

A model identifier that lets Bedrock serve the request from any region in a geography, for more throughput at the source region's price.

Security and compliance: IAM, KMS, PrivateLink and the certifications

Bedrock's security model is the standard AWS one applied to a model API: IAM decides who may call which model and feature, KMS encrypts what Bedrock stores, PrivateLink keeps the traffic off the internet, and the service sits inside the compliance programmes a regulated customer needs.

Identity and access

Every Bedrock call is authorised by IAM. Identity-based policies grant actions such as bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:Retrieve or bedrock:InvokeAgent on resources: foundation models have ARNs, so a policy can allow one team only the small models, and custom models, Knowledge Bases, Agents, Guardrails and provisioned throughput each have their own. Condition keys can require that a guardrail is attached to every invocation. The features that act on your behalf (a Knowledge Base reading S3 and writing to OpenSearch, an Agent calling Lambda, a customisation job reading training data) each use a service role you create with only those permissions. The security article covers the wider governance picture; the shape here is least privilege per feature.

Encryption

Traffic is encrypted in transit with TLS. At rest, anything Bedrock keeps for you (custom models, imported models, Knowledge Base configuration, Agent definitions, evaluation job output) is encrypted with AWS-owned keys by default and with a customer managed AWS KMS key where you specify one, which gives you the key policy, rotation and the CloudTrail record of every use of it. Training data, batch input and invocation logs stay in your own S3 buckets and log groups under the encryption you set there, with a KMS key of your choice for the logs.

Network

By default an application reaches Bedrock over the public AWS endpoints, still authenticated and encrypted. For a private path you create VPC interface endpoints powered by AWS PrivateLink for the services you use: bedrock, bedrock-runtime, bedrock-agent and bedrock-agent-runtime each have one. Traffic then flows from a private subnet to Bedrock over the AWS network with no internet gateway, no NAT gateway and no public IP in the path, and an endpoint policy can restrict which principals and models may be reached through it. Customisation jobs can be given a VPC configuration so the training job reads S3 through your subnets, and a Knowledge Base on Aurora connects to the database inside your VPC.

flowchart TD
  A["Application, private subnet<br/>no internet or NAT gateway"]
  E["VPC interface endpoint<br/>AWS PrivateLink, one per Bedrock endpoint"]
  P["Endpoint policy and IAM role<br/>which principals, which models, which actions"]
  B["Amazon Bedrock, your region<br/>TLS in transit, KMS at rest"]
  A --> E
  E --> P
  P --> B

Data handling and compliance

The data promise from the first section is the core of the compliance story: prompts and completions are not stored (unless you log them), are not shared with model providers, are not used to train base models, and are processed in the region you called, or within the geography for a cross-region profile. On top of that, Bedrock is in scope for the major AWS compliance programmes: it is HIPAA eligible, covered by the SOC reports, certified under ISO standards, in scope for PCI DSS, usable under the GDPR with AWS's data processing terms, and authorised at FedRAMP High in the GovCloud regions. The exact lists live in AWS Artifact, which is where an auditor is sent for the reports. What that scope means in practice is that a hospital can run patient-facing summarisation through Bedrock under a Business Associate Addendum, a bank can process card-holder conversations, and an EU company can keep processing inside EU regions.

AWS PrivateLink

The technology behind VPC interface endpoints: a private network interface in your subnet that fronts an AWS service, so traffic never leaves the AWS network.

endpoint policy

An IAM resource policy on a VPC endpoint that limits which principals, actions and resources may pass through it.

service role

An IAM role that Bedrock assumes to act for you: read training data, write to a vector store, invoke a Lambda function.

HIPAA eligible

An AWS service that may process protected health information under a Business Associate Addendum; the customer remains responsible for compliant use.

Recap