The Amazon Bedrock console — a complete walkthrough.

IWhat the Bedrock console is — and what it is not

The Amazon Bedrock console is the AWS Management Console surface for Amazon Bedrock, reachable at console.aws.amazon.com/bedrock or by searching "Bedrock" in the AWS console search bar. It is a web UI layered over the same Bedrock APIs your code calls — everything you do by clicking ultimately maps to an API action, which is exactly why it is so useful for learning the service.

It helps to be clear about the console's job. Amazon Bedrock itself is a fully-managed, multi-model inference service: you call a single API and get a completion from Claude, Llama, Mistral, Amazon Nova or Titan, Cohere, Stability AI, AI21, or DeepSeek, with no GPUs to run and your data kept in your account and Region (the full picture lives at Amazon Bedrock). The console is the human-facing control panel for that service: it is where you grant access to models, experiment with them interactively, configure the managed building blocks (RAG, agents, safety, orchestration), and inspect what everything costs.

What the console is good at is setup, exploration, and configuration. Turning a model on, sanity-checking whether Claude Sonnet or Nova Pro answers your prompt better, pointing a Knowledge Base at a folder of documents, drafting a Guardrail policy, sketching an Agent, and running a small evaluation are all faster by clicking than by writing code — and crucially, they are auditable, governed AWS actions, not someone's laptop script.

What the console is not is your production runtime. You would never serve a real application's user traffic by having people sit in the chat Playground; you would never manage versioned, repeatable infrastructure through ad-hoc clicks. The console produces resources (a Knowledge Base ID, an Agent alias, a Guardrail ID, a Flow) that your code then invokes at scale through the API. The honest mental model: prototype and configure in the console, serve and automate through the API. Section VIII draws that line precisely.

IIThe navigation map — every panel and what it does

The whole console is organized by the left-hand navigation pane. AWS reshuffles the exact labels and grouping over time, so treat this as a map of the jobs rather than a pixel-perfect screenshot — but as of 2026 the panels fall into five clusters: foundation-model basics, the Playgrounds, the builders, supporting tools, and configuration. Here is the full map; later sections go deep on each cluster.

A useful way to read the navigation is by the question each panel answers. "What can I use?" → Model catalog / Providers and Model access. "Does this model work for me?" → the Playgrounds and Evaluations. "How do I build a real feature?" → Knowledge Bases, Agents, Guardrails, Flows. "How do I keep it clean?" → Prompt Management and Custom/Imported models. "What does it cost and who can do it?" → the Billing link and the IAM permissions behind every action.

IIIModel access and the model catalog — turning models on

Bedrock ships off by default: a brand-new account can see the console but cannot call any model until access is explicitly granted. The Model access panel is therefore the first stop in any Bedrock walkthrough, and the model catalog is how you decide what to turn on.

Access is opt-in for governance reasons. AWS wants every model your organization can invoke to be a deliberate, auditable decision, and several models carry provider end-user license terms you must accept first. So before any Playground or builder will work, you visit Model access and enable what you need.

IVThe Playgrounds — chat, text, and image/video

The Playgrounds are the interactive try-it surfaces and usually the first place people actually feel what Bedrock does. They let you prompt a model directly in the browser, adjust generation parameters, and — importantly — compare models side by side, all without writing a line of code. Note that every Playground call still bills per token, so a Playground session is not free.

There are three to know. The Chat / Text Playground is for conversational and text-completion models. You pick a model you have access to, type a prompt (and optionally a system prompt), and tune inference parameters — temperature, top-p, max tokens, and stop sequences — watching how the output changes. Its most useful feature is compare mode: load two (or more) models at once, send the same prompt to both, and read their answers, latency, and token usage next to each other. This is the fastest honest way to decide between, say, Claude Sonnet and Nova Pro for your task before committing code.

The Image / Video Playground is the same idea for generative media: choose an image model (Amazon Nova Canvas, Stability's Stable Image/Diffusion family) or a video model (Amazon Nova Reel), enter a prompt and settings — size, number of variants, seed, style — and generate images or short clips interactively. It is how you evaluate visual quality and prompt-sensitivity before wiring generation into an app.

A practical detail many miss: most Playgrounds can show you the API request behind your interactive session (an "API request" / "View API" affordance), printing the exact JSON body or a code snippet equivalent to what you just did by clicking. That feature is the bridge between exploration and implementation — you prototype the prompt and parameters by hand, then copy the generated request straight into your codebase. It is the single best habit to form in the console.

VThe builders — Knowledge Bases, Agents, Guardrails, and Flows

This is where the console stops being a viewer and becomes a build surface. Bedrock's four managed building blocks each have a guided creation experience in the console: you configure a real, production-grade resource by clicking through forms, test it in place, and end up with an ID your application code invokes. Each would otherwise be a project of its own.

The builders compose, and the console makes that composition tangible: a typical assistant is a Knowledge Base for grounding, wrapped in a Guardrail, exposed through an Agent, and optionally orchestrated by a Flow — every piece created and tested by clicking, every piece emitting an ID your code later calls. That is the heart of what "you can do a lot without code" means on Bedrock: not that production runs in the browser, but that the entire configuration of a sophisticated, governed GenAI feature can happen before you write a serving loop.

• Knowledge Bases — managed RAG you can click together — The Knowledge Bases panel walks you through creating a retrieval-augmented-generation pipeline: point it at a data source (typically a folder of documents in S3, or a connected source), choose an embeddings model and a vector store (Bedrock can provision one for you or connect an existing OpenSearch / Aurora / vector DB), then sync. Bedrock chunks the documents, generates embeddings, and indexes them. You can then test the Knowledge Base right in the console — ask a question and see the grounded answer with citations — before any code exists. At runtime your app calls the RetrieveAndGenerate (or Retrieve) API against the Knowledge Base ID. Deep dive: Bedrock Knowledge Bases and RAG on AWS.
• Agents — define, attach tools, and test in place — The Agents builder lets you create an agent by writing its natural-language instructions, choosing a backing model, and defining action groups — the tools the agent may call, backed by AWS Lambda functions or an OpenAPI schema for your APIs. You can optionally attach a Knowledge Base for grounding and a Guardrail for safety. The console gives you a test pane to converse with the agent and watch its reasoning/trace as it decides which action to invoke. You then expose it to your app via an agent alias and the InvokeAgent API. Deep dive: Amazon Bedrock Agents.
• Guardrails — a safety policy you configure by form — The Guardrails builder is a set of toggles and fields: content filters (hate, violence, sexual, misconduct, prompt-attack) at adjustable strengths, denied topics you describe in words, word/profanity filters, sensitive-information (PII) detection set to block or redact, and contextual-grounding/relevance checks to curb hallucination. You build the policy once, version it, and then apply the Guardrail ID to any model call, Agent, or Knowledge Base — consistently across models. Deep dive: Bedrock Guardrails.
• Flows — a visual orchestration canvas — Flows is a drag-and-drop builder: a canvas where you wire nodes — prompts, foundation models, Knowledge Bases, Agents, conditions/logic, and input/output — into a single generative workflow, then deploy it as a versioned resource. It is how you chain multi-step generative logic (classify → retrieve → answer → format) without hand-writing the orchestration code. You test the Flow in the console and invoke it from your app via the Flow alias. Deep dive: Bedrock Flows.

VIEvaluations, Prompt Management, and custom models

Around the headline builders sit three supporting panels that turn a one-off prototype into something you can measure, reuse, and specialize: model Evaluations, Prompt Management, and the Custom/Imported-models area. They are easy to overlook and disproportionately useful.

VIIThe billing view, IAM, and keeping the console governed

Two things every console session quietly depends on: who is allowed to do what (IAM) and what it all costs (Billing). Neither lives entirely inside the Bedrock console — both reach into the broader AWS console — but they govern everything you just clicked through.

On cost: the Bedrock console does not have a single "your Bedrock bill" meter, because Bedrock charges flow into standard AWS billing. To see spend you use AWS Cost Explorer and the Billing console, filtering by the Amazon Bedrock service and grouping by usage type or model to see which models and features (inference, training, storage, Knowledge Base vector store) drive the bill. The critical thing to internalize is that console activity is billable: every Playground prompt, every evaluation job, every Knowledge Base sync and query consumes tokens or resources and shows up in that bill. The console is free to open; it is not free to use.

On access: every action in the Bedrock console is a Bedrock API call under the hood, governed by IAM. To use the console a principal needs permissions such as bedrock:ListFoundationModels, bedrock:InvokeModel / bedrock:Converse, the relevant bedrock:*KnowledgeBase / *Agent / *Guardrail / *Flow actions for the builders, and bedrock:GetModelInvocationLoggingConfiguration and related actions for logging. This is why a teammate sometimes sees an empty or error-laden console: their role lacks the Bedrock permissions. It is also where you enforce least privilege — scope who can grant model access, who can create builders, and who can only read.

Two governance switches worth setting from the console early: model-invocation logging (turn it on to capture full request/response payloads to S3 or CloudWatch for audit and debugging) and, at the organization level, Service Control Policies / model access controls so only sanctioned models can be enabled. With IAM scoped, logging on, and Billing watched, the console is a governed control panel rather than an ungoverned playground — which matters the moment more than one person is in the account.

VIIIConsole vs API — what you can do click-only, and when to switch

The single most useful thing to know about the Bedrock console is where its job ends and your code's job begins. The console is for setup, exploration, and one-off operations; the API (boto3, the AWS SDKs, the Converse API) is for embedding inference in an application and for anything that must be automated, versioned, or run at scale. Here is the line, drawn explicitly.

A clean rule of thumb: if a human is doing it once, use the console; if software will do it repeatedly, use the API. Enabling a model, comparing models, building and testing a Knowledge Base / Agent / Guardrail / Flow, running an evaluation, drafting prompts, kicking off a fine-tune — all of these are console-appropriate, and most are genuinely faster by clicking. Serving user traffic, embedding a chatbot in your product, automating batch jobs, deploying through CI/CD, and version-controlling your GenAI infrastructure as code — all of these belong in the API and IaC.

The companion deep-dives on the API surface itself — the Converse API, model IDs, and SDK calls — live on the main Amazon Bedrock page; for cost levers you will reach for once you are calling the API at volume, see Bedrock pricing, prompt caching, and batch inference (batch in particular is an API/job pattern, not a console click).