« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes
Phase 24 — Amazon Bedrock: The Managed Foundation-Model Platform
Answers these JD lines: "experience with Amazon Bedrock," "building GenAI applications on AWS," "managed RAG / Knowledge Bases," "model evaluation and fine-tuning on Bedrock," "AWS AI security and compliance (Guardrails, VPC, KMS)." This is the layer every other AWS-agent phase in this track quietly assumes: Phase 20's AgentCore hosts agents; Bedrock is what actually serves the model underneath them (or doesn't — AgentCore is model-agnostic). A principal engineer needs both, and needs to draw the line between them without hesitating.
Why this phase exists
Phase 20 built Bedrock AgentCore — the agent orchestration/runtime layer: session isolation, a Gateway that turns APIs into MCP tools, Cedar policy, memory strategies. This phase is about Bedrock itself — the managed foundation-model platform underneath it. They are different services, they solve different problems, and conflating them is a fast way to sound junior in an AWS-platform interview. Three ideas do most of the work:
- One API surface over many model vendors. Bedrock federates Anthropic Claude, Amazon
Titan/Nova, Meta Llama, Mistral, Cohere, AI21, Stability AI, and imported custom models behind
a single control plane and a normalized invocation API (
Converse). You pick a model by string ID, not by vendor SDK. - Capacity, safety, and retrieval as managed primitives, not glue you write: On-Demand / Provisioned Throughput / Batch inference for capacity, Guardrails for content safety, Knowledge Bases for RAG, plus model customization and evaluation jobs — each independently adoptable, the same "composable primitives" philosophy AgentCore uses one layer up.
- The trust boundary is architectural, not a prompt: VPC endpoints/PrivateLink keep traffic off the public internet, IAM policies gate who can invoke what, KMS encrypts at rest, and CloudTrail logs every data-plane request — the same Phase 00 trust-boundary discipline, applied to the model-serving layer.
Bedrock vs AgentCore vs Agents for Bedrock
Three AWS products, three different jobs. Interviewers listen for whether you keep them straight.
| Bedrock (this phase) | Bedrock AgentCore (Phase 20) | Agents for Bedrock (legacy) | |
|---|---|---|---|
| What it is | the model-serving platform: catalog, invocation, capacity, safety, RAG | the agent runtime/ops layer | a console-native, single-agent RAG+action-group builder |
| The unit you get | a model you can Converse with | an isolated, observable place to run an agent loop | one fully-managed agent AWS orchestrates for you |
| Who owns the agent loop | n/a — there is no loop here | you — any framework, any model | AWS |
| Ties to a specific model | no — front any model with Guardrails/KB | no — framework- and model-agnostic | Bedrock models only |
| Adopt independently? | yes (Guardrails/KB/capacity are separable) | yes (Runtime/Gateway/Memory are separable) | no — one bundled product |
The one-liner: Bedrock serves the model; AgentCore runs the agent; Agents for Bedrock was AWS's
first, now largely superseded, attempt to bundle both into one low-code product. AgentCore does
not require Bedrock models — it is framework- and model-agnostic — but in practice most AWS-native
agents call Bedrock underneath AgentCore's Runtime, which is exactly why this phase and Phase 20
compose: Lab 01 here builds the Converse/capacity layer AgentCore's Runtime would call into.
Concept map
- Model catalog & invocation — first-party (Titan, Nova) vs third-party (Anthropic, Llama,
Mistral, Cohere, AI21, Stability) vs Custom Model Import; raw
InvokeModel(provider-native) vs the unifiedConverse/ConverseStreamAPI (Lab 01). - Capacity — On-Demand (token-bucket throttling), Provisioned Throughput (reserved Model Units), Batch inference (async, discounted, no real-time SLA), cross-region inference profiles (Lab 01).
- Guardrails — denied topics, content filters (six categories, per-category severity thresholds), word filters, PII detection (block/mask), contextual grounding — a content-safety policy layer, distinct from Cedar/IAM access-control (Lab 02).
- Knowledge Bases — managed RAG: chunking → embedding → a BYO vector store,
RetrievevsRetrieveAndGeneratewith citations, metadata filtering, async data-source sync (Lab 03). - Also: model customization (continued pre-training / fine-tuning / Custom Model Import / distillation), model evaluation jobs, and the security/observability substrate (VPC endpoints, IAM, KMS, CloudTrail, invocation logging) — covered in the Warmup, not built as labs.
The labs
| Lab | You build | Proves you understand |
|---|---|---|
| 01 — Unified Invocation & Capacity | four provider adapters (Anthropic/Titan/Llama/Cohere), raw invoke_model vs normalized converse/converse_stream, On-Demand token bucket, Provisioned Throughput pool, Batch job lifecycle, cross-region routing | why Converse exists and what "least common denominator" costs you; the three capacity models and their real failure modes |
| 02 — Guardrails | denied topics, content filters with severity thresholds, word filters, PII block/mask, contextual grounding, input vs output guardrail pipeline | content-safety policy vs access-control authorization; why the model must never see a blocked prompt |
| 03 — Knowledge Bases | fixed and hierarchical chunking, deterministic embedding + vector index, Retrieve/RetrieveAndGenerate, sync job lifecycle | managed RAG as chunking + a BYO vector store + citations, not magic |
Integrated scenario (how this shows up at work)
Your team is shipping a customer-support assistant. Product wants it to answer from your docs, never leak a customer's SSN into a log, and not fall over during a traffic spike. You put Guardrails in front of every prompt and generation (Lab 02) so a jailbreak attempt or a PII-bearing answer never reaches the customer — and you can point to the exact rule that fired when someone asks why. You back answers with a Knowledge Base over your support docs (Lab 03) so responses cite the article they came from, not a hallucination. You call models through Converse (Lab 01) so swapping Claude for Nova next quarter is a config change, not a rewrite; you run steady traffic on Provisioned Throughput and a nightly reprocessing job through Batch at a fraction of the cost, with On-Demand as the burst overflow, all sitting behind a cross-region inference profile so a regional capacity crunch doesn't take you down. If this assistant is itself an agent — reasoning over multiple tools, running for minutes — you hand it to AgentCore (Phase 20) for session isolation and Cedar-gated tool access; Bedrock is what it calls to think.
Deliverables checklist
-
Lab 01 green under
LAB_MODULE=solution pytestand your ownlab.py(40 tests). - Lab 02 green (26 tests); you can state the difference between a masked and a blocked Guardrails intervention.
- Lab 03 green (29 tests); you can explain why hierarchical chunking returns parent text on a child match.
- You can draw the Bedrock / AgentCore / Agents-for-Bedrock triangle from memory.
- You can do the On-Demand-vs-Provisioned-Throughput cost crossover on a whiteboard.
- You can name at least three Bedrock competitors and when you'd pick each over Bedrock.
Key takeaways
- Bedrock is the model-serving platform; AgentCore is the agent-runtime platform. Different layers, both AWS, not competitors with each other.
Converseis a translation layer overInvokeModel, not a separate capability — and its feature set is only as rich as the least-capable provider you route to.- Guardrails is content safety; Cedar/IAM is access control. A production agent needs both, and they fail independently.
- Knowledge Bases is chunking + embedding + a BYO vector store + citations, offered as a managed pipeline — the mechanism is exactly Phase 05's hybrid retriever, run as a service.
- The senior framing: "Bedrock's value isn't any one model — it's not re-solving capacity, safety, and retrieval for every model I adopt, with an exit ramp if I need to leave."