# AWS AI Service Landscape (Business Level) The in-scope AWS AI services for AIB-C01 at the strategic level the exam tests – Amazon Bedrock, Amazon SageMaker AI and Amazon Quick – a managed-vs-custom-vs-assistant decision table, an explicit out-of-scope list, and a business-need-to-service mapping. import { Tabs, TabItem } from '@prosefly/astro-components'; This is the reference for the AWS services the [AWS Certified AI Business Strategist (AIB-C01)](/aws/aib-c01/) exam names — carried at the **strategic level the exam tests, and no deeper**. AWS states plainly that the exam **does not assess AWS services knowledge**: you will never be asked for a console flow, an API call, an IAM policy or an architecture pattern. What you *are* expected to do is recognise which category of service fits a business need, understand its commercial shape, and know the question to ask your technical team. Everything here is verified against AWS's published material as of **15 September 2026**; prices appear in full on the [Pricing & ROI page](/appendix/aws/pricing-and-roi/). Only three services are in scope: **Amazon Bedrock**, **Amazon SageMaker AI** and **Amazon Quick**. ## Amazon Bedrock — the managed foundation-model platform Bedrock is a **managed platform** for foundation models and generative-AI applications. The strategic point is that it gives you many providers' models on one platform, with governance and RAG tooling built in, and **no infrastructure to run**. You choose a model and consume it; AWS operates it. ### Multi-provider model choice One platform, many model providers — which matters strategically because it avoids single-vendor lock-in and lets you match a model to a task. The providers available include **Anthropic, Amazon (Nova, Titan), OpenAI (including GPT-6 Astra and GPT-5.6 Sol/Terra/Luna), Meta, Mistral AI, Cohere, DeepSeek, Google (Gemma), NVIDIA, Qwen, xAI (Grok), Z AI (GLM), Writer, Stability AI, TwelveLabs, Luma AI, MiniMax, Moonshot AI, AI21 Labs**, plus **Custom Model Import** for bringing your own. :::tip[Exam signal] "Avoid lock-in", "compare models from different providers", "one platform" → Bedrock's multi-provider design. The strategist value is *optionality*, not any single model. ::: ### Service tiers and inference pricing shapes Bedrock offers several ways to consume the same model, trading price against latency guarantees and commitment. The relationships between them are fair game for the exam; the exact per-token prices are model-specific and are not. | Tier / mode | Price relationship | When it fits | | --- | --- | --- | | **Standard** (on-demand) | The baseline | Variable, unpredictable traffic; no commitment | | **Flex** | **50% discount** to Standard | Latency-tolerant work that can wait a little | | **Priority** | **75% premium** over Standard | Latency-sensitive, high-value traffic | | **Reserved** | Commitment for a lower rate | Steady, predictable volume | | **Batch inference** | **50% below on-demand** (select models) | Offline, bulk jobs where latency does not matter | | **Provisioned Throughput** | Bought in **model units**; no-commitment, 1-month or 6-month prices | High, steady throughput needing guaranteed capacity | ```text cost per request high │ Priority (+75% vs Standard, latency guaranteed) │ Standard (baseline, on-demand) │ Flex (−50% vs Standard, latency-tolerant) low │ Batch (−50% vs on-demand, offline only) └────────────────────────────────────────────▶ latency tolerance rises Provisioned Throughput sits apart: buy capacity in model units, commit 1 or 6 months for a lower rate — a fixed cost that only pays off at high, steady utilisation ``` **Provisioned Throughput** is the classic *commit-for-a-discount* lever: you buy capacity in **model units** and commit for 1 or 6 months (or take a no-commitment rate). It lowers unit cost at steady high volume, but becomes a large fixed cost if utilisation is low — a strategist watches the utilisation assumption behind any commitment. ### Bedrock capabilities that show up in strategy questions | Capability | What it is, strategically | | --- | --- | | **Guardrails** | Configurable safeguards usable with any Bedrock model (or self-hosted): content filters, denied topics, sensitive-information filters (PII redaction), word filters, **contextual grounding checks** (hallucination detection against a source) and **Automated Reasoning checks**. AWS states it blocks up to **88% of harmful content**. | | **Managed Knowledge Bases** | **RAG without infrastructure** — index your data and ground answers in it, with managed parsing, embeddings and re-ranking. The strategic answer when a stem says "ground answers in our own documents" and "we don't want to build a pipeline". | | **Model Evaluation** | Compare models on your data before you commit — algorithmic scores, human evaluation, and LLM-as-a-judge / RAG evaluation. The disciplined answer to "which model should we use?" | | **Intelligent Prompt Routing** | Routes within a model family by prompt complexity; AWS states it can cut cost **up to 30%** without compromising accuracy. | | **Prompt Optimization** | Rewrites prompts for better results. | | **Bedrock Data Automation** | Turns unstructured multimodal content (documents, audio, video, images) into structured data. The answer to "extract structured data from a pile of documents". | | Filter | What it prevents | | --- | --- | | Content filters | Harmful categories (hate, violence, etc.) | | Denied topics | Subjects you define as off-limits | | Sensitive-information filters | Leaking or exposing PII (redaction) | | Word filters | Specific words and phrases | | Contextual grounding checks | Hallucinations — checks the answer against a source | | Automated Reasoning checks | Logically unsound claims, checked against a policy | Managed RAG: point it at your data, and answers are grounded in that data with citations — no vector database to run, no embedding pipeline to build. Parsing, embeddings and re-ranking are managed and included. It is the "grounded on our own content, without a build project" answer. ## Amazon SageMaker AI — custom machine learning SageMaker AI is the service for **building, training and deploying custom ML** — the opposite end of the spectrum from Bedrock's managed models. Strategically, the two facts that matter are its **economics** and its **governance tooling**. - **Instance-based economics.** You pay for compute *while it runs*, so an idle endpoint burns money. A strategist evaluating a SageMaker-based proposal asks about utilisation and whether endpoints are shut down when not in use. - **Governance tooling that matters in a review** — the tools your risk and compliance conversation will reference: | Tool | What it gives a governance conversation | | --- | --- | | **SageMaker Clarify** | Bias detection across data prep, after training and in the deployed model, plus explainability | | **Model Monitor** | Detects and alerts on inaccurate predictions from deployed models — your drift-detection story | | **Ground Truth** | Human feedback and data labelling | | **ML Governance** | Model cards, model registry and dashboards — the audit trail | :::tip[Exam signal] "Custom model on our own data and algorithms", "we need full control of the model", "detect bias in our trained model", "explainability for a model we built" → SageMaker AI. If the stem also says "we don't want to manage infrastructure" or "use a proven foundation model", it has flipped to Bedrock. ::: ## Amazon Quick — the AI-powered business assistant Amazon Quick is an **AI-powered business assistant and BI surface** over your business data: research, business insights, automation and no-code app building. Commercially it follows a **seat-based** model (per user). The strategic point is that it puts AI *in front of business users* — no build project, no data-science team — so it is the answer when a stem describes non-technical staff who need insights or a lightweight app over existing data. ```text build effort ▲ high │ SageMaker AI build a custom model (data-science team) │ Bedrock assemble on a managed platform (dev team) low │ Amazon Quick business users self-serve (no build) └──────────────────────────────────────────────▶ how technical is the user? ``` ## Managed platform vs custom ML vs business assistant | Dimension | **Amazon Bedrock** (managed platform) | **Amazon SageMaker AI** (custom ML) | **Amazon Quick** (business assistant) | | --- | --- | --- | --- | | What you get | Foundation models + GenAI tooling, managed | A toolset to build/train/deploy your own model | An AI assistant + BI over your data | | Who uses it | Developers assembling apps | Data scientists and ML engineers | Business users | | Build effort | Low — no model to train, no infra | High — you build and own the model | None — self-serve | | Pricing shape | Consumption (per token/request) + commitment options | Instance-based (pay per hour of compute) | Seat-based (per user) | | Choose it when | You want a proven model fast, no infra, provider choice, built-in guardrails/RAG | You need a bespoke model on your own data/algorithms and full control | Non-technical staff need insights or a light app over existing data | | The risk to watch | Consumption cost scaling with usage | Idle endpoints burning money | Seat cost decoupled from actual value delivered | Worked reading: "A retailer wants to answer customer questions grounded in its own product manuals, launched in weeks, with no ML team." That is **Bedrock with Managed Knowledge Bases** — managed RAG, fast, no infrastructure. Change the stem to "a fraud team needs a model trained on the bank's own transaction patterns with bias detection they control" and the answer flips to **SageMaker AI**. Change it to "the finance team wants to ask questions of last quarter's numbers without waiting on analysts" and it is **Amazon Quick**. ## What is out of scope for this exam The exam does not assess AWS services knowledge. These are the **job tasks and service depths you do NOT need** — and a stem that requires any of them is testing a distractor, not the credential: - Developing, coding, training or fine-tuning models; selecting or tuning algorithms. - Data or feature engineering; data pre-processing, cleaning, labelling or annotation. - Hyperparameter tuning or model optimisation; mathematical or statistical model analysis. - Building or deploying pipelines or infrastructure; managing production technical operations (infrastructure monitoring, pipeline debugging, model-performance troubleshooting). - Implementing security or compliance protocols; configuring or administering AWS services. - Any AWS service **other than** Bedrock, SageMaker AI and Amazon Quick (plus CAF, the shared responsibility model and the pricing/cost tools as strategy topics). - Console navigation, API calls, IAM policy syntax, or architecture patterns for any service. :::note[The tell of an out-of-scope distractor] If an option would require you to *do* the technical work — "configure the endpoint", "write the IAM policy", "tune the hyperparameters", "build the data pipeline" — it is describing the technical team's job, not the strategist's. The strategist's job is to decide *whether* and *what*, and to ask the technical team the right question. Options that pull you into implementation are usually wrong for that reason alone. ::: ## Business need → in-scope service → the question to ask your technical team | The business need | In-scope service | The question a strategist should ask | | --- | --- | --- | | Answer questions grounded in our own documents, no pipeline to build | Bedrock + **Managed Knowledge Bases** | "What accuracy do we get on our real questions, and how do we detect when it drifts?" | | Compare several models before committing | Bedrock **Model Evaluation** | "On our own data, which model wins on quality *and* cost, not just on a benchmark?" | | Extract structured data from unstructured documents | Bedrock **Data Automation** | "What is the extraction accuracy on our messiest documents, and what is the per-page cost at our volume?" | | Block harmful or off-policy outputs; redact PII | Bedrock **Guardrails** | "Which filters do we need, and what does a blocked or missed case cost us?" | | Cut inference cost on mixed-difficulty traffic | Bedrock **Intelligent Prompt Routing** | "What share of traffic can safely route to a cheaper model without hurting quality?" | | A bespoke model on our own data and algorithms | **SageMaker AI** | "What is the utilisation of the endpoints, and how do we detect bias and drift?" | | Business users need insights or a light app over our data | **Amazon Quick** | "Which users actually need seats, and how do we measure the value each seat delivers?" | | Decide whether to build, buy or partner | **AWS Marketplace** for buy/partner options; the service categories above for build | "What does *not* building cost us in optionality and control, and what does building cost us in time and skills?" | ## Key takeaways - Only **three** services are in scope: **Amazon Bedrock** (managed foundation-model platform), **Amazon SageMaker AI** (custom ML) and **Amazon Quick** (AI-powered business assistant / BI). - **Bedrock** = many providers on one platform, no infrastructure, with **Guardrails**, **Managed Knowledge Bases** (RAG without infrastructure), **Model Evaluation**, **Intelligent Prompt Routing**, **Prompt Optimization** and **Data Automation**. Tiers: Standard, Flex (−50%), Priority (+75%), Reserved; batch −50%; Provisioned Throughput in model units on 1- or 6-month commitments. - **SageMaker AI** = build your own model; instance-based cost (idle endpoints burn money); governance tooling — **Clarify** (bias/explainability), **Model Monitor** (drift), **Ground Truth** (labelling), **ML Governance** (model cards, registry). - **Amazon Quick** = seat-based assistant that puts AI in front of business users with no build project. - The exam **does not test service knowledge**: no console, API, IAM or architecture, and no service beyond these three. An option that requires implementation work is usually the distractor. - The strategist's job is to match a need to a service *category* and ask the technical team the right question — not to configure anything.