Amazon Bedrock Foundations: APIs, Model Access, Pricing, Inference Types and Evaluations

Amazon Bedrock is the service the AIF-C01 exam names more than any other, and it is also the service that changes fastest. That combination is dangerous: memorising a model list or a per-token price is a study strategy with a shelf life of weeks, while memorising mechanisms, how on-demand, batch, provisioned throughput, service tiers and cross-region inference profiles actually behave, stays correct for years. This lesson is built around that split. Every number below is pinned to a first-party AWS source as of October 2026, and anything AWS does not confirm is flagged rather than taught.

By the end of this lesson you will be able to:

• explain what "fully managed, serverless, single API" means operationally and name the two Bedrock endpoints;
• state the 2026 model-access rules, including the Anthropic form most candidates forget;
• choose between on-demand, batch and provisioned throughput, and between the four service tiers, using price, latency, commitment and feature support;
• pick the right inference profile for cost versus data residency and predict what CloudTrail will log;
• walk a model-selection decision tree and defend a choice with verified per-token prices;
• name the four customization paths and say which one requires provisioned throughput;
• select automatic, human or LLM-as-a-judge evaluation for a given metric;
• defend the comparative verdict between Bedrock, self-hosted SageMaker, a prebuilt AI service and building it yourself.

---

1. What Amazon Bedrock is

1.1 The definition AWS uses

Amazon Bedrock is a fully managed, serverless service that gives you a single API to invoke foundation models from many providers. Three words carry the whole value proposition:

• Fully managed: AWS runs the infrastructure, the scaling and the model hosting; you never see an instance, an endpoint URL or a GPU.
• Serverless; you pay per token (on-demand and batch) or per hour (provisioned throughput); there is no idle-capacity bill unless you buy one deliberately.
• Single API: one request shape, one SDK, one set of IAM actions; switching from Anthropic Claude to Amazon Nova is a change of modelId, not a rewrite.

That last property is the single most examinable sentence in this lesson. A question that says "without rewriting application logic" is pointing at the unified API, and every other option in that question (cross-region routing, provisioned throughput, model import) is a different mechanism entirely.

1.2 The provider catalog

AWS lists 100+ foundation models without publishing an exact count. The first-party provider list verified in October 2026 is:

📚 Did you know? DeepSeek is officially supported: DeepSeek V3.2, V3.1 and R1 all appear in AWS's Models at a glance page, and V3.2 runs on both bedrock-runtime and the OpenAI-compatible bedrock-mantle endpoint. Candidates who skip the current catalog often assume DeepSeek is only available through a marketplace or a self-hosted stack; on the exam, "Amazon Bedrock does not host DeepSeek" is a distractor by construction.

1.3 The two endpoints

Bedrock exposes two service endpoints, and the exam tests which operations live where:

The distinction matters in practice: bedrock-mantle exists so that an application written for the OpenAI or Anthropic SDK can point at Bedrock with a base-URL and key change, while bedrock-runtime is the home of Converse: the API that gives you tools, Guardrails and multi-provider parity in one request shape.

1.4 Architecture: one API, many models

1.5 What AWS promises about your data

Two commitments appear in the Bedrock documentation overview and both are exam-shaped:

1. Inputs and outputs are not shared with third-party model providers.
2. Inputs and outputs are not used to train the base foundation models. Fine-tuning, by contrast, trains a private copy of the model that belongs to your account; which is why a customized model is yours and why it is billed differently.

📚 Did you know? The "not used to train base models" guarantee is precisely why fine-tuning is described as creating a private custom model: your labeled JSONL goes to S3, a training job produces a checkpoint that only your account can invoke, and the base FM that other customers use is untouched. The companion fact candidates miss is that invoking a supervised fine-tuned model requires Provisioned Throughput, on-demand will not run it, while Custom Model Import (bring your own weights) can run on-demand.

1.6 Four things Bedrock is not

Confusions that produce wrong options more often than any other Bedrock fact:

---

2. Model access: what actually unblocks an invocation

Model access used to be a click-through opt-in per model. In 2026 the flow is simpler, with one exception that still trips candidates:

After step 4, InvokeModel/Converse succeed; before it, you get an access error that looks like an IAM problem and is not one.

---

3. The API surface: Invoke, Converse and the compatibility endpoints

3.1 Operation families

3.2 Converse inference parameters: exactly four

The Converse API's base InferenceConfiguration contains four parameters and nothing else:

Model-specific knobs (for example topK or a provider's thinking budget) go into additionalModelRequestFields, which is passed through to the model. An option that claims Converse exposes five or six first-class base parameters is testing whether you know the boundary between the portable API and the provider-specific escape hatch.

3.3 Streaming

Streaming uses InvokeModelWithResponseStream (Invoke family) or ConverseStream (Converse family), with IAM action bedrock:InvokeModelWithResponseStream. Whether a given model can stream is discoverable programmatically: GetFoundationModel returns responseStreamingSupported. If a question asks "how do you confirm streaming support before promising it in the UI?", that flag is the answer.

3.4 Tool use and forced tool choice

toolChoice has exactly three values:

That third row is a classic exam micro-fact: forcing a named tool is not universal, and an option that generalises it to every model on Bedrock is wrong.

3.5 Structured output

Two routes exist for schema-conformant JSON:

1. Forced tool use (toolChoice: {any: {}} or {tool: {name:...}}): the long-standing route, because constraining the model to a tool's JSON schema is structural rather than advisory.
2. Native structured output: added to Converse/ConverseStream on 2026-02-04 via outputConfig.textFormat.type = "json_schema" together with toolSpec.strict.

The reliability gap is large and AWS-published: a community test of 102 samples on AWS Builder Center found prompt-only "return valid JSON" succeeding roughly 70 to 80% of the time versus 99%+ with forced tool use. Turn that into an operations number: 10,000 invoice documents at 75% prompt-only success means about 2,500 failed parses and retries; at 99% it means about 100.

Worked example 1, choosing the right mechanism for 10,000 structured extractions. The job needs strict JSON, no interactivity, and results by morning. Answer: on-demand or Flex-tier Converse with outputConfig.textFormat.type = "json_schema", because Batch inference does not support structured output or tool calling, and it does not support provisioned models either. Two separate traps, one question.

📚 Did you know? Prompt-only JSON instruction fails for a structural reason: the model is sampling, not validating. Asking politely in the system prompt changes the probability of braces appearing; it does not create a constraint. Forced tool use and json_schema output both work because they make invalid output impossible by construction rather than unlikely; which is also why AWS's own reliability guidance treats "just say JSON in the prompt" as a distractor answer in every structured-output question.

3.6 Request anatomy: where each knob lives

Two readings of this payload matter on the exam: the portable surface (system, messages, inferenceConfig, toolConfig, guardrailIdentifier) is the same for every provider, which is what makes a provider swap a one-line change; and additionalModelRequestFields is the deliberate escape hatch for anything provider-specific, which is why the base parameter list stays at four no matter how many knobs a given model exposes.

---

4. Pricing: four mechanisms and four service tiers

Bedrock pricing is not one model; it is an orthogonal pair of choices: how you buy capacity (on-demand / batch / provisioned) and which service tier you accept (priority / standard / flex / reserved).

4.1 The three capacity mechanisms

4.2 The four service tiers (the second axis)

serviceTier is set per request and applies to on-demand traffic:

AWS's published Reserved-tier entry conditions (secondary source: AWS Builder Center) are ≥ 100K input tokens per minute and ≥ 10K output tokens per minute, a 1- or 3-month commitment, 99.5% uptime with overflow to Standard.

4.3 Worked example 2: pure on-demand arithmetic

AWS's own example: Amazon Titan Text Lite at $0.0003 per 1K input tokens and $0.0004 per 1K output tokens.

$$\frac{2{,}000}{1{,}000}\times \$0.0003 + \frac{1{,}000}{1{,}000}\times \$0.0004 = \$0.001 \text{ per call}$$

At 1,000 calls per hour that is $1.00 per hour. The second AWS example, AI21 Jurassic-2 Mid at $0.0125 per 1K tokens both ways, for 10,000 in / 2,000 out:

$$\frac{10{,}000}{1{,}000}\times \$0.0125 + \frac{2{,}000}{1{,}000}\times \$0.0125 = \$0.15 \text{ per request}$$

4.4 Worked example 3: batch saves exactly 50%

Claude 3.5 Sonnet (Public Extended Access): $6.00 in / $30.00 out per 1M tokens on-demand, $3.00 / $15.00 on batch. A 10M input + 2M output job:

Delivery is typically within 24 hours, and the job cannot use tool calling or structured output.

4.5 Worked example 4: provisioned throughput burns whether you use it or not

AWS's documented arithmetic for one model unit at $16.20/hour:

$$1 \times \$16.20 \times 24 \text{ h} \times 31 \text{ d} = \$12{,}052.80 \text{ per month}$$

Published hourly rates for Cohere Command per model unit: $49.50 (no commitment), $39.60 (1-month, −20%), $23.77 (6-month, −52%). Llama 2 13B/70B provisioned: $21.18 (1-month) and $13.08 (6-month). The decision rule: provisioned wins only when the idle-hour cost is less than the capacity and per-token savings you actually capture: for Claude, Nova and most modern models AWS does not publish hourly rates at all and asks you to contact the account team.

4.6 Worked example 5: service-tier arithmetic

DeepSeek V3.1 in ap-southeast-2 is priced at $0.5974 in / $1.7304 out per 1M tokens on the Standard tier. Applying the documented modifiers:

Send 10% of traffic to Priority, 60% to Flex and 30% to Standard and the blend is 0.10 \times 4.07 + 0.60 \times 1.16 + 0.30 \times 2.33 \approx \1.80$: about **23$2.33. Tier discipline, not model choice, is usually the cheapest available optimisation.

4.7 Verified token prices (USD per 1M, Standard / on-demand)

Fixed and hourly prices worth knowing: custom model storage $1.95/month, Titan Text Embeddings V2 $0.00002 per 1K tokens, Cohere Embeddings $0.0001 per 1K tokens (a 5× gap on the same job).

4.8 Two more savings levers: routing and caching

Intelligent Prompt Routing operates within a model family, Claude Sonnet ↔ Claude Haiku, Nova Pro ↔ Nova Lite, and AWS's pricing page claims it can cut cost by up to 30%. The arithmetic behind the claim is simple: send easy prompts to the cheap sibling and keep hard prompts on the strong model.

Worked example 10: routing arithmetic. Use one verified anchor: Claude 3.5 Sonnet at $6.00 / $30.00 per 1M tokens. The sibling's per-token rate is not published in the sources verified for this lesson, so assume a Haiku-class model at $1.00 / $5.00 (illustrative) and a 10M-in / 2M-out daily mix:

Two readings follow. First, AWS's published claim is "up to 30%", which is the conservative figure across real traffic: never quote the illustrative 42% as an AWS number. Second, routing is a traffic-mix lever rather than a per-request discount, which is exactly what separates it from batch (−50% on every token), the Flex tier (−50% on every token) and a global profile (−10% on every token).

Prompt caching (Amazon Nova) is the other lever, and its limits are precise: a minimum of 1,000 tokens per checkpoint, at most 4 checkpoints per request, a 5-minute time to live and a 20,000-token cache cap. Cached input tokens are billed at the cache-read rate: for Claude 3.5 Sonnet that is $0.60 per 1M versus $6.00 uncached (a 10× reduction), while a cache write costs $7.50 per 1M (a 25% premium). Caching therefore pays only when a checkpoint is read repeatedly inside its TTL.

Match each pricing mechanism to its documented rule:

---

5. Cross-Region inference: profiles, price and residency

5.1 Geographic versus global profiles

Cross-Region inference is expressed through inference profiles, and there are two kinds:

5.2 What CloudTrail shows

Cross-Region requests can route to Regions that are not manually enabled in your account; the data stays on the AWS network and is encrypted in transit. AWS CloudTrail records where the work actually happened in additionalEventData.inferenceRegion; which is exactly why a CloudTrail entry can show a different Region from the request's source Region without implying a billing error. Pricing always uses the source Region, so there is no routing surcharge.

5.3 Two limits candidates miss

1. Inference profiles do not support Provisioned Throughput. Capacity reserved per model unit and cross-Region routing are separate mechanisms; you cannot combine them.
2. Application profiles exist for cost-allocation tagging: a separate concept from routing profiles, used to attribute spend rather than to place compute.

Worked example 6: cross-region economics. A geographic profile such as us.amazon.nova-lite-v1:0 keeps processing inside the United States at standard rates. A global profile is roughly 10% cheaper but may execute in any commercial Region. For an EU financial workload the choice is decided by residency, not price: choose the geographic (EU) profile and accept the higher rate.

📚 Did you know? The ~10% global-profile discount and the "price from the source Region" rule point in opposite directions and both are true: your bill is calculated with your source Region's price list, but the global pool's rates are published about 10% lower, so routing globally saves money without a surcharge line item. Meanwhile Intelligent Prompt Routing, a completely different feature, can cut cost by up to 30% by routing within a model family (Claude Sonnet ↔ Claude Haiku, Nova Pro ↔ Nova Lite). Three separate savings levers, three different mechanisms: batch (−50%), Flex tier (−50%), global profile (−10%), prompt routing (up to −30%).

---

6. Choosing a model: the decision tree AWS actually teaches

6.1 The decision tree

6.2 Verified provider × model matrix

6.3 Worked example 7: same job, 5× embedding cost

An AWS blog worked a RAG ingestion of a 5M-token document plus 0.5M query tokens = 5.5M tokens:

Same corpus, same job, 5× difference; which is why embedding model choice, not just LLM choice, belongs in a cost question.

2025 to 2026 Updates

Sections 6.1 to 6.3 teach a decision process that survives catalog churn; this subsection records what actually churned between late 2025 and October 2026, so a stale model list never becomes a wrong answer. Every row below is verified against an AWS What's New post, an AWS documentation page, the Bedrock pricing page or an AWS blog: nothing here comes from a third-party tracker.

Catalog changes (verified):

Capability changes (verified):

What did not change: every mechanism in this lesson behaves as written: the single Converse API and its four base parameters, batch at 50% with no tool calling and no structured output, provisioned throughput billed hourly per model unit, the +75% / default / −50% / 1- or 3-month tier ladder, geographic profiles for residency against global profiles at ~10%, and the three evaluation modes over a dataset in S3. The catalog is the part that moves; the mechanics are the part you are examined on.

📚 Did you know? The lifecycle policy turns this lesson's "do not memorize the model list" advice into a billing rule: because a Legacy model refuses new Provisioned Throughput orders, a team that pins capacity to a model the day before it leaves Active can be locked out of exactly the commitment section 4.5 says fine-tuned and steady-state workloads need; while its existing model units keep running. That is why an exam option naming a specific model as "available" or "unavailable" is nearly always a distractor, and why the durable answers are mechanisms: default-on access, Marketplace permissions on first enablement, the Anthropic FTU form, a valid payment method.

---

7. Customization: four paths and the provisioned-throughput rule

Worked example 8: fine-tuning cost, AWS's own image example. Amazon Titan Image Generator at $0.005 per image, 500 steps, batch size 64:

$$\$0.005 \times 500 \times 64 = \$160.00$$

plus $1.95/month custom model storage and 1 hour of custom inference at $21.00 gives $182.95 in month one.

7.1 Prompt caching (Amazon Nova)

---

8. Evaluations: three modes, one dataset location

8.1 The three modes

Automatic task types: General generation, Summarization, Q&A, Text classification. Judge models available: Nova Pro / 2 Lite / Micro / Premier, Claude 3.5 Sonnet v1/v2, Claude Opus 4.7/4.8, Claude Sonnet 4.0/4.5, Llama 3.1 70B, Mistral Large.

LLM-as-a-judge reached GA on 2025-03-20 and AWS claims up to 98% cost savings with turnaround in hours instead of weeks. It also offers bring-your-own-inference-response, so you can score outputs from models that are not even hosted on Bedrock.

8.2 Worked example 9; which evaluation, which metric

📚 Did you know? LLM-as-a-judge's bring-your-own-inference-response feature quietly makes Bedrock Evaluations usable as a cross-platform quality layer: you submit responses produced by any model, including ones running outside AWS, and a Bedrock judge scores them with an explanation and a score histogram written to S3. That is why "the evaluation must run on the same provider as the model under test" is a distractor: AWS explicitly built the opposite.

---

9. Comparative verdict

---

10. Exam traps for this lesson

---

Real-World Case Studies

Sections 1 to 10 build the mechanisms; AWS's published customer stories show which mechanism a real team actually reached for, and with what numbers. Everything below is quoted from the AWS case study or AWS Machine Learning Blog post named in the Source column, retrieved 6 October 2026. All of these figures are customer- or AWS-claimed and unaudited, and where a source says "up to", read it as a ceiling rather than an expectation.

Cases at a glance: services, numbers, sources

Case file 1: Epilot: choose the model with Bedrock Evaluations before production. Energy software from Cologne summarises long customer-email chains across 170+ utility customers. The pipeline is API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet), and the model itself was selected with Amazon Bedrock Evaluations (human ratings across prompt versions) rather than by preference; a later agent writes records with humans verifying. Outcomes: handling time −87%, 55,000 summaries per month at a negligible failure rate, 80% of users saying it simplifies their work, an MVP in 2 months, and processed data kept in an EU Region. Exam angle: this is section 8's evaluation modes used as a gate, and section 5's residency question answered up front rather than after launch. Source: aws.amazon.com/solutions/case-studies/epilot-genai-case-study (indexed July 2026).

Case file 2, Bynder: embeddings are a product feature, not just a cost line. Bynder runs 175 million assets / 18 petabytes for 4,000 companies, and text search cannot express "find me more like this one". Images and queries are vectorised with Amazon Titan Multimodal Embeddings on Bedrock for visual plus contextual similarity search. Outcomes: search time −75% and roughly +50% usable results per search. Exam angle: §6.3's embedding arithmetic is the same price table that makes Titan Text Embeddings V2 5× cheaper than Cohere embeddings, and multimodal embeddings add a visual search axis that a text-only embedding model cannot price at all. Source: aws.amazon.com/solutions/case-studies/bynder-bedrock-case-study (2025).

Case file 3, Nippon India: the gain came from retrieval engineering, not a bigger model. Naive RAG degraded as document volume grew and produced hallucinations. The fix set: FM-as-parser parsing, query reformulation, multi-query RAG, reranker models, GraphRAG and metadata filtering on Bedrock Knowledge Bases, plus Bedrock Guardrails and citations. Outcomes: accuracy +>95%, hallucination −90 to 95%, report generation 2 days → ~10 minutes. Exam angle: §8's RAG evaluation exists precisely to separate a retrieval failure from a generation failure, and AWS notes every technique above is a GA product feature, not customer-only code. Source: AWS Machine Learning Blog, 29 Jul 2025, aws.amazon.com/blogs/machine-learning/how-nippon-india-mutual-fund-improved-the-accuracy-of-ai-assistant-responses-using-advanced-rag-methods-on-amazon-bedrock.

Case file 4: Adobe: chunking and embedding choice decide RAG accuracy. Thousands of developers were getting weak doc-search results. Adobe benchmarked four chunking strategies on Bedrock Knowledge Bases: 400-token / 20%-overlap, 1,000-token, hierarchical and semantic: with Amazon Titan Text Embeddings V2 written to Amazon OpenSearch Service and read through the Retrieve API. Outcome: +20% retrieval accuracy on Adobe's own test set, with the simplest strategy (400-token / 20% overlap) the most accurate. Exam angle: a knowledge-base question that offers "pick a bigger model" is answering the wrong axis; chunking, embedding choice and retrieval are the knobs, and the benchmark runs on your dataset. Source: AWS Machine Learning Blog, 11 Jun 2025, aws.amazon.com/blogs/machine-learning/adobe-enhances-developer-productivity-using-amazon-bedrock-knowledge-bases.

Case file 5, Prime Focus Technologies: latency decided placement before price did. CLEAR holds 14 million+ assets (Disney Star, CBS, Lionsgate) and covers localization plus live cricket tagging. Amazon Bedrock + AWS Lambda agents automated the workflows; outcomes were localization cost −20 to 30%, accuracy +20 to 30% and turnaround −30 to 40%. The documented caution matters more than the percentages: the first attempt used external LLM APIs whose latency was too high for live tagging, and latency "dropped dramatically" once the workload ran on Bedrock on AWS. Exam angle: §5's routing questions and §6's decision tree both start with who is waiting, placement is settled before pricing is compared. Source: aws.amazon.com/solutions/case-studies/prime-focus-case-study (2025).

Case file 6: Alnylam: citations are the compliance feature. Complaint triage took 3 to 4 days and finding one internal answer took 15+ minutes. With Amazon Bedrock, Amazon S3 and a RAG layer, the team shipped an intake-and-triage prototype in 3 months under GxP constraints, plus the Slack assistant AskALNY serving 2,000 employees + 1,000 contractors that returns answers with source links. Outcomes: triage 3 to 4 days → hours, search 15 min → 30 s, then 250+ use cases. Exam angle: grounding plus citations is exactly exam-guide objective 5.1.5 (hallucination detection and grounding), and a regulated answer without a source link is not an answer. Source: aws.amazon.com/solutions/case-studies/alnylam-case-study (2025).

Before and after, side by side

Reconstruct the Epilot architecture and its published numbers:

📚 Did you know? The only production-readiness rate AWS publishes is 65%: of more than 1,000 Generative AI Innovation Center implementations, 65% reached production in 2025, some in as little as 45 days, using the Five V's framework (Value → Visualize → Validate → Verify → Venture). That number is why Epilot gated its model choice on Bedrock Evaluations, why Sun Finance rejected attempt 1 instead of shipping it, and why every case file above quotes a "before" alongside the "after": the other 35% is what you avoid by baselining the metric before you build.

---

Practice Questions

---