Managed foundation models
How to use
Amazon Bedrock.
Building governed generative AI applications across multiple foundation models with managed inference, evaluation, Knowledge Bases, Guardrails, and AWS integrations.
Amazon Bedrock is a managed foundation-model, generative AI, retrieval, guardrail, and agent platform. Building governed generative AI applications across multiple foundation models with managed inference, evaluation, Knowledge Bases, Guardrails, and AWS integrations. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to Amazon Bedrock
Get into the official Amazon Bedrock experience with the right account and a setup you understand.
- 01
Start at https://aws.amazon.com/bedrock/ and confirm the domain before entering account or payment information.
- 02
Availability: Amazon Bedrock is available through the AWS Management Console, regional APIs, AWS SDKs, CLI, and supported AWS development environments.
- 03
An AWS account, an approved Region and model access, least-privilege IAM permissions, billing controls, and a secure SDK or console environment.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful Amazon Bedrock session
Learn the interaction loop using a small task with a clear outcome.
- 01
Choose a non-sensitive test task, approved AWS Region, and candidate model with explicit quality and cost limits.
- 02
Grant a development role only the required Bedrock Runtime permissions and enable the necessary model access.
- 03
Send a minimal Converse request with a pinned model, system rules, output limits, and no production data.
- 04
Inspect response metadata, latency, cost, safety behavior, throttling, and logs before expanding permissions or traffic.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of Amazon Bedrock output
Establish that an autonomous run did the right thing, not merely that it finished.
- 01
Define what the run should achieve and what it must never touch before granting it a single tool.
- 02
Read the full execution trace: which tools were called, with what arguments, and in what order.
- 03
Verify the side effects directly in the target system rather than trusting the agent's own report of success.
- 04
Confirm failures surfaced as failures — a silent retry loop or a swallowed error is more dangerous than a crash.
- 05
Re-run the same task and compare: an agent that behaves differently across identical runs is not yet production-ready.
- Verify side effects in the system of record, not in the agent's summary.
- Require human approval for any irreversible or outward-facing action.
- Log every tool call so a run can be reconstructed afterwards.
Privacy & permissions
Use Amazon Bedrock safely
Bound what an autonomous system can reach before you let it run unattended.
- 01
Enumerate every tool, credential, and system the agent can reach, and remove the ones it does not need.
- 02
Require explicit human approval for irreversible actions: sending, publishing, paying, deleting, or deploying.
- 03
Run against non-production data until behaviour is predictable across repeated runs.
- 04
Set hard limits on spend, iterations, and runtime so a failure loop cannot run unbounded.
- 05
Treat anything the agent reads from the web or a document as data, never as instructions it may follow.
- Bedrock spans regional services, many models, IAM roles, data sources, and billable resources. Use temporary least-privilege credentials, separate control and runtime access, classify data, verify model and Region support, apply and test guardrails where appropriate, evaluate every model change, preserve retrieval permissions and citations, set quotas and cost alerts, and avoid new designs centered on Agents Classic as it enters maintenance mode.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use Amazon Bedrock for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Compare foundation models through a controlled API path with IAM, guardrails, evaluation, quotas, and cost monitoring.
↓ 02 WorkflowBuild a citation-ready Amazon Bedrock Knowledge BaseIngest governed documents, tune retrieval, and evaluate generated answers while preserving permissions and source evidence.
↓Workflow 01
Run governed model inference with Amazon Bedrock
Compare foundation models through a controlled API path with IAM, guardrails, evaluation, quotas, and cost monitoring.
Outcome: Deploy a least-privilege inference integration whose model behavior and operational limits are known before production use.
- 01
Define the use case, data classification, approved AWS Region, model access, quality tests, latency, throughput, retention, and budget.
- 02
Create a least-privilege IAM role, enable only required model access, use temporary credentials, and keep application and control-plane permissions separate.
- 03
Call the Converse API with a pinned model or inference profile, explicit system rules and limits, and an associated tested guardrail where appropriate.
- 04
Evaluate factuality, safety, structured output, streaming, throttling, timeouts, and model-specific differences on a versioned benchmark.
- 05
Record request metadata without sensitive prompts, monitor CloudWatch and cost, set quotas and alerts, and use staged configuration changes with rollback.
What good use looks like
- Use temporary least-privilege credentials.
- Evaluate every candidate model.
- Set quotas and cost alerts before scale.
Workflow 02
Build a citation-ready Amazon Bedrock Knowledge Base
Ingest governed documents, tune retrieval, and evaluate generated answers while preserving permissions and source evidence.
Outcome: Create a RAG system that retrieves authorized material and returns answers whose supporting sources can be inspected.
- 01
Define source ownership, document permissions, deletion and refresh rules, expected queries, citation requirements, and an access-aware benchmark.
- 02
Choose managed or customer-managed storage deliberately, configure a least-privilege service role and encryption, and connect only approved data sources.
- 03
Test parsing and chunking on representative text, tables, scans, and conflicting documents, then ingest a small versioned corpus first.
- 04
Use Retrieve before RetrieveAndGenerate to measure recall, tune filters and reranking, and verify citations, permissions, and unanswerable behavior.
- 05
Add guardrails where appropriate, monitor ingestion and retrieval traces, test updates and deletions, and promote changes through a reviewed staging path.
What good use looks like
- Test retrieval separately from generation.
- Enforce document access at retrieval.
- Verify update and deletion behavior.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.
- Amazon Bedrock documentation ↗
- API reference overview ↗
- Amazon Bedrock Knowledge Bases ↗
- Bedrock Guardrails use cases ↗