Amazon Bedrock setup: from zero to your first Converse call.

IPrerequisites: what you need before the first call

Bedrock setup has a short list of prerequisites, and getting them straight up front saves the two most common stumbles: calling a Region where the model is not enabled, and using credentials that lack Bedrock permissions. None of this requires infrastructure — there are no GPUs, instances, or clusters to stand up.

At a high level you need five things, and the rest of this page walks through each in order. First, an AWS account with permission to manage IAM and Bedrock (your own account, or an admin who can grant you access). Second, the AWS CLI v2 installed locally, used to store credentials and sanity-check that they work. Third, a set of programmatic credentials (ideally a short-lived role via IAM Identity Center / SSO, or an IAM user with an access key for a pure quickstart) carrying a least-privilege Bedrock policy. Fourth, model access for the models you intend to call: on by default for many models if your role has AWS Marketplace permissions, plus a one-time use-case form for Anthropic models. Fifth, a runtime: this guide uses Python with the AWS SDK, boto3, but the same flow maps directly to the JavaScript, Java, Go, and .NET SDKs.

A few decisions are worth making deliberately before you touch a keyboard. Choose a Region first. Frontier models frequently land in US Regions (us-east-1, us-west-2) before they appear in eu-central-1 or ap-southeast-1, and your prompts and completions are processed in the Region you call — so pick a Region that has the model you want and satisfies any data-residency requirement you have. Decide which model you are starting with. A sensible default for a quickstart is one cheap, fast chat model (for example a small Claude or Amazon Nova model) so your first iterations cost pennies; you can swap the model ID later without rewriting anything. Avoid root credentials. Never use your AWS account root user for day-to-day API calls — create an IAM identity scoped to exactly what you need, which the next sections cover.

• An AWS account (with IAM + Bedrock admin reach): Your own account or one where an admin can grant you IAM and Bedrock permissions. A brand-new account works fine.
• AWS CLI v2 installed locally: Used to configure and verify credentials. Not strictly required to call Bedrock from code, but the fastest way to confirm your credentials resolve.
• Programmatic credentials with a Bedrock policy: Short-lived SSO role (preferred) or an IAM user access key (simplest for a quickstart), carrying the least-privilege policy in section III.
• Model access for your chosen model: On by default for many models in commercial Regions, if your role has the AWS Marketplace subscribe permissions for the first call. Anthropic models need a one-time use-case form.
• Python 3.9+ and boto3 (or another AWS SDK): This guide uses Python + boto3. The Converse flow is identical in the JS/Java/Go/.NET SDKs.

IIInstall the AWS CLI and boto3

Two installs get you ready: the AWS CLI v2 (to hold and verify credentials) and the boto3 SDK (to make the calls from Python). Both are a single command on every major platform.

Install the AWS CLI v2 using the method for your OS, then confirm the version. On macOS the simplest route is Homebrew; on Linux the bundled installer; on Windows the MSI from the AWS docs. The CLI is what reads and writes the shared credentials file that boto3 (and every other AWS SDK) picks up automatically, so installing it now means you do not hard-code keys in your code later.

Then create an isolated Python environment and install boto3, the AWS SDK for Python. Bedrock is exposed through two clients in boto3: bedrock (the control plane — listing models, managing custom models, configuring features) and bedrock-runtime (the data plane — actually invoking models with Converse / InvokeModel). For making completions you want bedrock-runtime; this is the single most common point of confusion in setup, so internalize it now: you call models on the bedrock-runtime client, not the bedrock client.

IIIConfigure credentials and a least-privilege IAM policy

Bedrock is a standard AWS service governed by IAM. Setup here is two parts: give boto3 a way to find credentials, and make sure those credentials carry exactly the Bedrock permissions you need and nothing more. Do this once and every SDK on the machine inherits it.

There are two good ways to provide credentials, and one you should avoid. The avoid-it option is pasting an access key into your source code — it leaks. The simplest quickstart option is an IAM user with an access key, stored via aws configure, which writes a profile into the shared credentials file at ~/.aws/credentials; boto3 reads it automatically with no code. The production-grade option is short-lived credentials from IAM Identity Center (SSO) via aws configure sso or an assumed role, so nothing long-lived sits on disk. For a first call either works; for anything beyond a sandbox, prefer SSO/roles.

However you authenticate, the principal needs a Bedrock policy. The least-privilege starting point grants only the runtime actions you will use — bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream (for streaming), and bedrock:Converse / bedrock:ConverseStream — plus, optionally, the read-only control-plane action bedrock:ListFoundationModels so you can enumerate available models. You can scope Resource down to specific model ARNs to restrict exactly which models a service may call; the example below starts permissive on resource for a quickstart and notes where to tighten it.

Every Bedrock call is recorded in CloudTrail, and you can additionally enable Bedrock model-invocation logging to capture full request and response payloads to S3 or CloudWatch — useful for debugging and audit, and worth turning on early. After you set credentials, verify they resolve before involving Bedrock at all: aws sts get-caller-identity should print your account and principal ARN. If that fails, fix credentials first; it has nothing to do with Bedrock yet.

IVCheck model access (now on by default for most models)

AWS changed this step. Per its model access page (checked 10 October 2026), access to many Bedrock models is enabled by default in every commercial Region where the model runs, as long as your IAM role has the right AWS Marketplace permissions. Two cases still need attention.

First, third-party models and AWS Marketplace. When you first call a third-party model, Bedrock starts its Marketplace subscription in the background. The calling role needs aws-marketplace:Subscribe, aws-marketplace:Unsubscribe and aws-marketplace:ViewSubscriptions, and the account needs a valid payment method for Marketplace purchases. If a prerequisite is missing, the call returns AccessDeniedException until it is fixed. After the first successful subscription, other users do not need the Marketplace permissions. Models from Amazon, DeepSeek, Google, Meta, MiniMax, Mistral AI, Moonshot AI, NVIDIA, Qwen, xAI and Z.AI, and OpenAI's gpt-oss models, are not sold through Marketplace and need no subscription.

Second, Anthropic models. Before your first Claude call, submit use-case details once per account, or once at the organization's management account: pick a Claude model in the console's model catalog, or call the PutUseCaseForModelAccess API. You can check the status with GetFoundationModelAvailability.

Availability still varies by Region: a model offered in us-east-1 may not be offered in eu-central-1 or ap-southeast-1. If a model is missing in your Region, pick a Region that has it or use a cross-Region inference profile. ListFoundationModels on the bedrock (control-plane) client shows what is offered. Because access is on by default, companies that approve each model first should block unapproved models with IAM or SCP deny policies on the Bedrock invoke actions.

Copy the exact model ID from the console model catalog. Some calls expect an inference-profile ID rather than a bare model ID. Using the precise current ID prevents the ValidationException that comes from a guessed or outdated identifier.

• Pick your Region and confirm the model is offered there (console model catalog, or ListFoundationModels).
• Make sure the role that makes the first call to a third-party model has the AWS Marketplace subscribe permissions, or have an admin make that first call.
• For Claude, submit the one-time use-case form in the console or with PutUseCaseForModelAccess.
• Copy the exact model ID or inference-profile ID and paste it into modelId.
• Optional: call GetFoundationModelAvailability to confirm the model shows as available to your account.

VYour first Converse API call

With credentials resolving and model access granted, a working completion is about ten lines of Python. Use the Converse API, not the older InvokeModel — Converse gives you one consistent request and response schema across every chat model, so the same code works for Claude, Nova, Llama, Mistral, and Cohere with only the modelId changed.

You make completions on the bedrock-runtime client. The converse call takes three things you care about at the start: a modelId (the exact string you copied from the console), a messages list (each message has a role of user or assistant and a content list of blocks — a text block is {"text": "..."}), and an inferenceConfig (generation settings such as maxTokens and temperature). You can also pass a system prompt as a top-level argument to steer behavior. That uniform shape is the whole point of Converse: there is no provider-specific request body to assemble.

The example below is a complete, runnable first call. It creates the runtime client bound to your Region, sends one user message, and prints the model's text. The only line you ever change to switch models is modelId — everything else stays identical, which is what makes model evaluation and cost-driven model routing trivial later. Region and credentials are picked up from the environment / shared config you set in section III, so there are no secrets in the code.

VIHandling responses, streaming, and errors

A robust setup reads more than just the text: it checks why the model stopped, tracks token usage for cost, switches to streaming for responsive UIs, and handles the handful of errors Bedrock actually throws. All of this is in the same Converse response shape.

The converse response is a structured object. The text lives at output.message.content[0].text. The stopReason tells you why generation ended — end_turn (the model finished), max_tokens (you hit your limit, the answer may be truncated, so raise maxTokens), or tool_use (the model wants to call a tool you defined). Crucially for cost, usage reports inputTokens, outputTokens, and totalTokens for the call — log these from day one, because they are how you reason about and forecast spend. A response that ends with max_tokens is the most common "why is my output cut off?" surprise in early setup.

For anything user-facing, switch to streaming so tokens render as they are generated instead of after a multi-second wait. Streaming is the same request via converse_stream; the response carries a stream of events, and you iterate it, pulling text from the contentBlockDelta events as they arrive. The request body is byte-for-byte the same as the non-streaming call — only the method name and the way you read the response change — so adding streaming to a working first call is a tiny diff. (The matching IAM action is bedrock:ConverseStream, already in the section III policy.)

Finally, handle the small set of errors Bedrock surfaces so failures are legible rather than cryptic. The four you will meet most are AccessDeniedException (missing IAM permission, missing Marketplace permissions on a first third-party call, or a missing Claude use-case form; see sections III and IV), ValidationException (a bad request, most often a wrong or stale modelId), ThrottlingException (you exceeded the model's request/token rate: back off and retry, or move steady high volume to Provisioned Throughput), and ModelTimeoutException / ModelErrorException (a transient model-side issue: retry with backoff). Wrapping calls in a try/except and retrying throttles and timeouts with exponential backoff is the difference between a demo and something that survives real traffic.

VIINext steps: from a first call to a real workload, and who can fund it

A working Converse call is the foundation, not the finish line. The path from here splits into capability (what you build on top) and economics (what it costs and how to fund it). Both matter from the first week.

On capability, Bedrock turns raw inference into applications through managed features you configure rather than build. The most common next moves: add tool use (function calling) so the model can call your code, then graduate to Agents for multi-step task orchestration; point a Knowledge Base at documents in S3 for managed retrieval-augmented generation with citations; wrap the model in Guardrails to filter harmful content and redact PII; and use model evaluation to choose the right model on your own data instead of vendor benchmarks. Deep dives live at Bedrock Agents, Knowledge Bases, RAG on AWS, and Guardrails. For the full platform map, the flagship reference is Amazon Bedrock — the complete guide, with model-specific setup at Claude on Bedrock and access mechanics at how to access Amazon Bedrock.

On economics, Bedrock is cheap per call and expensive in aggregate. A quickstart costs pennies; a retrieval-augmented assistant that resends a large system prompt and retrieved context on every turn, serving thousands of users, can move into five or six figures a month faster than teams expect — especially if every call hits a frontier model. The levers are concrete: route cheap, high-volume calls to small models and escalate only hard steps to frontier models; run latency-tolerant work as batch (~50% cheaper); enable prompt caching so repeated context is not re-billed at full price every turn; and reserve Provisioned Throughput only once volume is high and steady. The API mechanics live at the Bedrock API reference and the numbers at the pricing breakdown in the main guide.

Funding is the lever most teams miss. An AWS consulting partner can file POC (proof of concept) funding to test a Bedrock workload, or incremental workload (IW) funding if you already run on AWS and are launching new AI work. For startups this is often $50K to $150K. Depends on the workload; AWS approves. Separately, you apply for AWS Activate yourself: Founders gives $1,000 to start, up to $5,000, and Portfolio gives up to $200,000 with the Org ID from your Activate Provider; a consulting partner cannot file Activate. CloudRoute matches you with one vetted AWS partner for free; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. See POC funding explained.