Introduction
The AWS Certified AI Practitioner (AIF-C01) exam does not ask you to write code against Amazon Bedrock, but it does expect you to reason about how a foundation model is served. Domain 2 asks candidates to understand the cost tradeoffs of AWS generative-AI services — the exam guide lists responsiveness, availability, redundancy, performance, regional coverage, token-based pricing, provisioned throughput and custom models — and Domain 3 asks you to pick a model and a serving approach by cost and latency. Those bullets map onto a specific set of Bedrock features, and a scenario question will describe one of them in plain English and expect you to name it.
Our generative-AI cost optimization guide already covers the three headline pricing modes — on-demand, batch and Provisioned Throughput — as workload shapes. This article goes one level deeper into the inference features that sit around those modes: where a request is actually processed (cross-Region inference and inference profiles), how its priority and price are set (service tiers), how repeated context is made cheaper (prompt caching), how a request can be sent to a cheaper model automatically (intelligent prompt routing), how latency can be bought down (latency-optimized inference), and how a smaller model can be made (distillation and Custom Model Import). Each section ends with the exam cue that points to it.
The Mental Model: One Request, Five Decisions
Every Bedrock inference call implicitly answers five questions. The exam tests whether you can match a requirement to the feature that controls each one.
| Decision | Feature that controls it | Typical requirement in a scenario |
|---|---|---|
| Which model, and can the choice vary per request? | Model ID, intelligent prompt routing | ”best quality at lowest cost per prompt” |
| Where is the request processed? | Inference profiles (geographic, global, application) | “stay within the EU”, “handle traffic spikes”, “track cost per team” |
| How fast and how reliably must it run? | Service tiers, latency-optimized inference, Provisioned Throughput | ”mission-critical”, “can tolerate delays”, “guaranteed capacity” |
| How much repeated input does it carry? | Prompt caching | ”the same 50-page document on every turn” |
| Can it wait? | Batch inference, Flex tier | ”overnight”, “not time-sensitive” |
Keep this table in mind; the rest of the article fills in each row.
Inference Profiles and Cross-Region Inference
An inference profile is a Bedrock resource that defines a model and one or more Regions that requests may be routed to. You invoke it exactly as you would a model — by passing its ARN or ID to InvokeModel, InvokeModelWithResponseStream, Converse or ConverseStream — and it also plugs into Knowledge Bases, model evaluation, Prompt management and Flows. There are two kinds.
System-defined cross-Region inference profiles
AWS predefines profiles that pair a model with a set of Regions. Invoke one and Bedrock automatically selects a Region to process the request, spreading load and absorbing traffic bursts that would be throttled in a single Region. Two flavours exist:
| Geographic cross-Region inference | Global cross-Region inference | |
|---|---|---|
| Profile ID prefix | us., eu., apac. (for example us.amazon.nova-pro-v1:0) | global. |
| Where requests may run | Any commercial Region within that geography | Any supported commercial Region worldwide |
| Price | Standard pricing | Roughly 10% lower |
| Service control policy needed | Allow every destination Region in the profile | Allow aws:RequestedRegion = unspecified |
| Choose when | Data residency or regulatory boundaries apply | Cost and availability matter more than location |
Facts the exam can lean on, all from the Bedrock documentation:
- No extra routing charge. The price is the price of the model in the source Region — the Region you call from — regardless of where the request is processed.
- Requests can be routed to Regions you have not opted in to in your account; manual Region enablement is not required.
- Data stays on the AWS network, encrypted in transit, and never crosses the public internet.
- CloudTrail logs every cross-Region request in the source Region, with
additionalEventData.inferenceRegionrecording where it ran. - Cross-Region inference profiles do not support Provisioned Throughput; if you need reserved capacity you buy it for a model in one Region.
Exam cue. “Users in several Regions, traffic spikes cause throttling, data must remain in the EU” → a geographic (EU) cross-Region inference profile. Add “lowest possible price, no residency constraint” → global. “Customer wants to know which Region processed the call” → CloudTrail
inferenceRegion.
Application inference profiles
You create these yourself, pointing either at a model in one Region or at a system-defined cross-Region profile. Their purpose is attribution: attach cost-allocation tags (team, project, environment) and the on-demand spend made through that profile appears under those tags in AWS Cost Explorer, while CloudWatch invocation logs and metrics are broken out per profile. Nothing about the model changes — it is a labelled handle on the same inference.
Exam cue. “Three business units share one Bedrock model and finance needs to charge back usage” → application inference profiles with tags. This is a governance answer, so it also connects to the security, compliance and governance guide.
Provisioned Throughput: Model Units and Commitments
Provisioned Throughput reserves dedicated capacity for a model at a fixed hourly price. The unit of purchase is the model unit (MU), which specifies how many input tokens and output tokens the model can process per minute. Three details matter:
- Billing is hourly and continues until you delete the Provisioned Throughput. Forgetting to delete it is the classic cost mistake.
- Commitment terms are no commitment (delete any time), 1 month, or 6 months — the longer the term, the lower the hourly rate.
- Customized models historically required it. A model you fine-tuned or continued pre-training had to be served from Provisioned Throughput; its price is that of the base model it was customized from. (Bedrock now also offers on-demand inference for some custom models, so read scenario wording carefully — “guaranteed capacity” still means Provisioned Throughput.)
Batch inference is not available for provisioned models, and inference profiles cannot front them. The decision shape — commit only to steady, high, predictable volume — is covered in the cost optimization guide; here the point is to recognise the vocabulary: model units, commitment term, hourly.
Batch Inference: Asynchronous and Discounted
Batch inference lets you submit many prompts in one job. You write the requests as JSONL (in either InvokeModel or Converse format) to an S3 bucket, start a batch job, and collect the outputs from S3 when it completes — with Amazon EventBridge able to notify you on job-state changes instead of polling. On the Bedrock pricing page, batch is listed at a 50% discount to standard on-demand for supported models.
What batch cannot do is just as testable:
- No tool calling (function calling) and no structured-output
response_format. - Each record is processed independently — no multi-turn interaction.
- Not supported for provisioned models or for imported custom models.
- Prompt caching does not apply to batch requests; caching is for on-demand endpoints only.
Exam cue. “Classify two million archived support tickets by next week at minimum cost” → batch inference. If the scenario adds “and call an external API for each ticket,” batch is wrong because tool use is unsupported.
Service Tiers: Reserved, Priority, Standard and Flex
Service tiers are a request-level knob that trades price for priority on on-demand inference. You set the optional service_tier parameter on the runtime API:
{
"service_tier": "reserved | priority | default | flex"
}| Tier | What it does | Price relative to Standard | Best for |
|---|---|---|---|
| Reserved | Reserve prioritised tokens-per-minute capacity for 1 or 3 months; overflows to Standard when exceeded; targets 99.5% uptime for model response | Fixed monthly price per 1K tokens-per-minute; minimums of 100,000 input TPM and 10,000 output TPM; access via your AWS account team | Mission-critical apps that cannot tolerate downtime |
| Priority | Requests are served ahead of Standard and Flex for the fastest responses; no reservation needed | 75% premium | Customer-facing, latency-sensitive workflows that do not justify 24×7 reservation |
Standard (default) | Consistent everyday performance; used whenever service_tier is omitted | Baseline | Content generation, document processing |
| Flex | Accepts longer processing times in exchange for a discount | 50% discount | Model evaluations, summarisation, agentic workflows that can wait |
Two operational facts round it out: the on-demand quota for a model is shared across Priority, Standard and Flex, while Reserved capacity is separate; and CloudWatch exposes ServiceTier and ResolvedServiceTier metrics so you can see which tier actually served each request.
Exam cue. “Interactive assistant for paying customers, willing to pay more for the fastest responses, no capacity reservation” → Priority tier. “Nightly evaluation jobs that can run slowly for a discount” → Flex tier (or batch, if the job is a static file of prompts). “Guaranteed capacity, cannot tolerate downtime” → Reserved tier or Provisioned Throughput — the former reserves tokens-per-minute on on-demand, the latter reserves model units.
Prompt Caching: Stop Paying for the Same Prefix
Long, repeated context is the dominant cost in many generative-AI apps — a system prompt plus a 40-page policy document re-sent on every chat turn. Prompt caching lets the model reuse the processed form of a stable prompt prefix across requests, cutting both latency and input-token cost. Bedrock offers two types:
| Type | How content is selected | What you add to the request |
|---|---|---|
| Implicit prompt caching | Bedrock and the model automatically try to reuse eligible prefixes | Nothing — but keep static content first and dynamic content last |
| Explicit prompt caching | You mark cache checkpoints that define the contiguous prefix to cache | Model-specific cache controls in system, messages or tools |
The mechanics the exam could probe at the “describe” level:
- Minimum prefix size. A checkpoint only takes effect if the whole prompt prefix before it meets the model’s minimum — currently 512 to 4,096 tokens depending on the model. Below the minimum the request still succeeds; it just is not cached.
- Checkpoint limits. Models cap the number of checkpoints per request (four for current Anthropic models).
- TTL. The cache has a time-to-live that resets on every hit; many models use 5 minutes, and some support a 1-hour option. No hits within the TTL and the entry expires.
- Billing. Tokens read from cache are billed at a discounted cache-read rate; tokens that miss are billed as normal input; and on some models cache writes cost more than a standard input token. Caching therefore only pays when the prefix is reused several times.
- No guarantees. Even eligible requests may miss — check the cache-usage fields in the response.
- Scope. On-demand
Converse/InvokeModel(streaming included) and Prompt management; not batch inference. It works together with cross-Region inference, although routing across Regions can increase cache writes at times of high demand.
Exam cue. “A document Q&A assistant re-sends the same contract on every question; reduce input-token cost and latency without changing the model” → prompt caching. Contrast with “reduce cost of a one-off nightly job” → batch, and “reduce cost by using a smaller model” → right-sizing or distillation.
Intelligent Prompt Routing: One Endpoint, the Cheapest Adequate Model
Intelligent prompt routing exposes a single serverless endpoint that, for each request, predicts the response quality of each model in a chosen family and routes the prompt to the one that meets the quality bar at the lowest cost. A simple “what is our refund policy?” goes to a small model; a nuanced multi-step analysis goes to a larger one — with no orchestration logic in your application.
- Default prompt routers are preconfigured by AWS for select models in the Amazon Nova and Meta Llama families (availability varies by Region). Start here.
- Configured prompt routers let you pick the models, a fallback model that acts as the anchor, and a routing criteria expressed as a response-quality difference — for example, “switch away from the fallback only if the other model’s response is predicted to be at least 10% better.”
- Limitations to recognise: optimised for English prompts only; it cannot learn from your application’s own performance data; and highly specialised use cases may not route optimally.
Exam cue. “Mixed simple and complex customer questions; minimise cost while keeping quality; avoid building model-selection logic” → intelligent prompt routing. If the scenario instead fixes one model and asks about reuse of context, that is caching; if it asks about where to run, that is an inference profile.
Latency-Optimized Inference
For a handful of models, Bedrock offers an optimized latency mode that returns responses faster without fine-tuning or any change to the application beyond one parameter:
{
"performanceConfig": { "latency": "standard | optimized" }
}At the time of writing the feature is in preview, available for Amazon Nova Pro, Anthropic Claude 3.5 Haiku and Meta Llama 3.1 70B/405B through cross-Region inference in specific US Regions. When the optimized quota is exhausted, Bedrock falls back to standard latency and charges the standard rate; the configuration actually used is visible in the API response and in CloudTrail. The exam is unlikely to test model names; it may test the concept that latency can be purchased as a serving option, separate from choosing a smaller model.
Exam cue. “Reduce time-to-first-token for an existing Bedrock app without switching to a smaller model” → latency-optimized inference (or Priority tier, which prioritises queuing rather than speeding up the model itself).
Model Distillation: Make a Smaller Model, Then Serve It Cheaply
Every feature above changes how a model is served. Model distillation changes which model you need. A large, capable teacher generates high-quality responses to your prompts; Bedrock augments that data with its own synthesis techniques; and a smaller, faster, cheaper student model is fine-tuned on the result. The student inherits the teacher’s behaviour for your use case at a fraction of the inference cost.
How a distillation job is fed:
- Your own prompts in JSONL — Bedrock generates the teacher responses. You may add a few labelled prompt-response pairs as “golden examples.”
- Production invocation logs — if CloudWatch model-invocation logging is enabled to S3, Bedrock can reuse the teacher’s existing responses, optionally filtered by
requestMetadatayou attached at call time, so the student learns from real traffic.
Costs and constraints worth knowing: teacher inference during synthesis is billed at the teacher’s on-demand rate; data synthesis can grow the fine-tuning set to a maximum of 15,000 prompt-response pairs; the distilled model is a custom model that only your account can access and that AWS does not use to train anything else; and you then serve it like any custom model — with Provisioned Throughput, or on-demand custom-model inference where supported.
Exam cue. “A large model gives great answers but is too expensive at production volume; the task is narrow and well understood” → model distillation. Contrast with fine-tuning (teach new behaviour or format from labelled data) and RAG (inject current knowledge) — both covered in the applications of foundation models guide.
Custom Model Import: Bring Your Own Weights
The “custom models” bullet in the exam guide also covers the reverse direction. Custom Model Import lets you bring a model you customised elsewhere — for example weights trained in Amazon SageMaker AI, or a fine-tuned open-weights model — into Bedrock and invoke it through the same InvokeModel APIs, guardrails and tooling. Supported architectures include Llama 2/3.x, Mistral, Mixtral, Flan-T5, Qwen2/2.5/3 and GPTBigCode, imported from S3 in a handful of Regions.
Pricing is on-demand but measured in Custom Model Units (CMUs) — billed per minute of active inference plus a monthly storage charge per CMU — with the number of CMUs determined at import time by model architecture, parameter count and context length. Imported models cannot use batch inference or be created through CloudFormation.
Exam cue. “The data-science team fine-tuned an open-weights model in SageMaker; the application team wants to call it through Bedrock with Guardrails” → Custom Model Import. The broader Bedrock-versus-SageMaker decision is in the SageMaker guide.
Putting It Together: A Scenario Walkthrough
A retailer runs a Bedrock-powered shopping assistant. Requirements: (1) EU customer data must stay in the EU; (2) Black Friday traffic spikes must not be throttled; (3) finance wants cost by brand; (4) every turn re-sends the same 6,000-token product-catalogue prefix; (5) a nightly job rewrites 500,000 product descriptions; (6) the current large model is too expensive for the simple “where is my order?” questions.
| Requirement | Feature | Why |
|---|---|---|
| EU residency + spike absorption | Geographic (eu.) cross-Region inference profile | Routes across EU Regions only; no extra routing cost; no opt-in needed |
| Cost by brand | Application inference profiles with brand tags | Spend and metrics attributed per profile |
| Repeated 6,000-token prefix | Prompt caching (explicit checkpoint after the catalogue) | Prefix exceeds the model minimum; cache-read rate on every hit within the TTL |
| 500,000 rewrites overnight | Batch inference (or Flex tier if it must stay interactive) | 50% discount; no tool use needed |
| Simple vs complex questions | Intelligent prompt routing, or distil a student for the simple intent | Cheaper model when quality allows |
No requirement above needed Provisioned Throughput; add “guaranteed capacity for a customised model” and it would.
Quick Reference Table
| Feature | One-line definition | Price effect | Key constraint |
|---|---|---|---|
| Geographic cross-Region inference | Route within US/EU/APAC via us./eu./apac. profile | Source-Region price, no routing fee | Allow destination Regions in SCPs |
| Global cross-Region inference | Route to any commercial Region via global. profile | ~10% cheaper | Allow aws:RequestedRegion = unspecified; no residency guarantee |
| Application inference profile | User-created, tagged handle on a model or CRIS profile | Enables cost allocation | Attribution only |
| Provisioned Throughput | Reserved model units, hourly, no/1/6-month term | Fixed cost | No batch; not via inference profiles |
| Batch inference | Async JSONL job via S3 | 50% discount | No tools, no multi-turn, no caching |
| Reserved tier | Reserved TPM on on-demand, 1 or 3 months | Fixed per 1K TPM | Minimum 100K input / 10K output TPM |
| Priority tier | Request-level prioritisation | +75% | Shares on-demand quota |
| Flex tier | Slower processing | −50% | Shares on-demand quota |
| Prompt caching | Reuse processed prompt prefix | Cache-read discount; writes may cost more | 512–4,096-token minimum; TTL resets on hit; on-demand only |
| Intelligent prompt routing | Per-request model choice within a family | Lower average cost | English only; default vs configured routers |
| Latency-optimized inference | performanceConfig.latency: optimized | Separate rate; standard on fallback | Preview; limited models and Regions |
| Model distillation | Teacher → synthetic data → fine-tuned student | Cheaper student inference | Teacher calls billed on-demand; ≤15K pairs after synthesis |
| Custom Model Import | Import external weights, serve on-demand | Per-CMU per minute + storage | No batch; no CloudFormation |
Common Mistakes on These Questions
- Confusing cross-Region inference with multi-Region deployment. CRIS is a single profile that routes for you; you do not deploy anything in the destination Regions, and you pay source-Region prices.
- Choosing global when the scenario mentions residency. Global may leave the geography; geographic profiles exist precisely for compliance.
- Picking Provisioned Throughput for “guaranteed capacity” when the scenario says “customer-facing, no 24×7 reservation.” That wording points at the Priority tier.
- Applying prompt caching to batch jobs. Caching is on-demand only.
- Treating caching as a model change. It reuses the same model’s processed prefix; quality is unchanged.
- Mixing up distillation and fine-tuning. Distillation’s defining feature is the teacher model generating the training data; fine-tuning uses your labelled data.
- Assuming batch supports agents or tool calls. It does not.
Frequently Asked Questions
What is cross-Region inference in Amazon Bedrock?
A way to invoke a model through a system-defined inference profile that can route each request to any of several Regions. Geographic profiles (us., eu., apac.) keep requests within a geography for data-residency needs; global profiles route worldwide at roughly 10% lower cost. There is no routing charge — you pay the source-Region price.
Does cross-Region inference send my data over the public internet?
No. Traffic between Regions stays on the AWS network and is encrypted in transit, and CloudTrail records the processing Region in the inferenceRegion field of the source-Region event.
What is the difference between an application inference profile and a cross-Region inference profile?
Cross-Region profiles are predefined by AWS and decide where a request runs. Application inference profiles are created by you, optionally on top of a cross-Region profile, to attach tags and track cost and usage per team or application.
How does prompt caching save money?
Tokens that are read from the cache are billed at a lower cache-read rate instead of the full input rate, and the model skips reprocessing them, which also lowers latency. It applies to a stable prompt prefix of at least the model’s minimum size (512–4,096 tokens) within a TTL that resets on each hit.
What is intelligent prompt routing?
A single Bedrock endpoint that predicts which model in a family will answer a given prompt well enough and routes to the cheapest such model. Default routers cover Amazon Nova and Meta Llama; configured routers let you set a fallback model and a response-quality threshold.
What are the Bedrock service tiers?
Reserved (reserved tokens-per-minute capacity with uptime targets), Priority (fastest, 75% premium), Standard (the default) and Flex (50% discount for workloads that can wait). You select one per request with the service_tier parameter.
When would I use model distillation instead of fine-tuning?
Use distillation when a large model already performs the task well and you want a smaller, cheaper model to match it; the teacher generates the training data. Use fine-tuning when you have labelled data that teaches behaviour or format the base model lacks.
Do I need to memorise prices for AIF-C01?
No. The exam tests which feature fits a requirement, not dollar figures. Knowing the relative effects — batch and Flex cheaper, Priority dearer, global cross-Region slightly cheaper than geographic, cache reads cheaper than full input — is enough.
Conclusion & Next Steps
Bedrock’s inference features are the concrete answers to the exam guide’s abstract list of tradeoffs: regional coverage is cross-Region inference, token-based pricing is shaped by caching and tiers, provisioned throughput is model units and commitments, and custom models are distillation and import. Learn each feature as a requirement → feature pair and the scenario questions become pattern recognition.
To make that recognition automatic, practise it under timed conditions. Sailor.sh’s AWS Certified AI Practitioner (AIF-C01) Mock Exam Bundle offers eight full-length, timed mock exams with 520+ scenario-style questions across all five domains, so you can confirm you reach for the right Bedrock feature on sight. For free practice first, try the AIF-C01 practice questions, then continue with the Amazon Bedrock guide for the service overview, the model selection and inference parameters guide for temperature and top-p, and the AIF-C01 study plan and exam guide to schedule the rest of your preparation.