AWS AI Stack & Amazon Bedrock — Conceptual Crash Course | Carrier Round 1 | 2026-05-18

Carrier is fully AWS. Understanding Bedrock architecture and the AWS AI service landscape is a first-class signal for this interview.

1. Mental Model

Amazon Bedrock is AWS's managed foundational model platform. It provides API access to multiple foundation models (Anthropic Claude, Meta Llama, Amazon Titan, Mistral, Cohere) without requiring infrastructure management. Think of it as the managed GenAI layer in the AWS stack — equivalent to John's self-hosted vLLM setup at NewsRx, but abstracted to a managed service.

The key insight: Bedrock is not just model inference. It includes Knowledge Bases (managed RAG with S3), Agents (agentic workflows with tool use), Guardrails (content filtering, PII redaction), and Model Evaluation (automated benchmarking). It's a full production GenAI platform.

Carrier uses Bedrock for: The "Tell Me More" generative AI agent in Abound (launched Feb 2026) — conversational troubleshooting for HVAC technicians trained on technical manuals. This is a RAG+Agents pattern: technician asks a question → Bedrock Agent retrieves relevant manual sections → generates contextual guidance.

4. Bedrock vs. Self-Hosted (John's Context)

NewsRx (John's approach)

Self-hosted Qwen3-32B on RunPod H100
vLLM inference server
Langfuse self-hosted tracing
DeepEval CI/CD gates
$21/mo operational
Zero data egress to vendors

Carrier Bedrock approach

Managed model APIs (no infra)
Built-in Guardrails
Native Knowledge Bases (RAG)
Built-in Agents workflow
AWS CloudWatch tracing
Pay-per-token pricing

Bridge language: "I've built the self-hosted equivalent of Bedrock's architecture at NewsRx — inference server, evaluation gates, tracing, guardrails. Bedrock makes that managed. The architectural decisions are the same: model selection, RAG indexing strategy, guardrail policies, evaluation metrics. I'm fluent in both the managed and self-hosted patterns."

2. Key Concepts

Concept	What it is	Carrier use case
Bedrock Knowledge Bases	Managed RAG: connect S3 docs, auto-index, semantic search at query time	Abound "Tell Me More" — technical manuals for HVAC troubleshooting
Bedrock Agents	Agentic workflows with tool use, multi-step reasoning, action groups connected to APIs	Orchestrate multi-step diagnostic flows: query KB → call equipment API → generate guidance
Bedrock Guardrails	Content filtering, PII redaction, topic blocking, grounding checks at inference time	Prevent hallucinated maintenance instructions that could damage equipment or injure techs
SageMaker Feature Store	Centralized storage for ML features — online (low-latency) and offline (batch training)	HVAC sensor features shared across all models in the fleet
SageMaker Pipelines	MLOps orchestration: data prep → training → evaluation → deployment in a DAG	Retraining pipeline triggered by model drift detection
SageMaker Model Monitor	Automated drift detection for data quality and model quality in production	Alert when HVAC sensor distribution shifts (new equipment generation deployed)
AWS Glue	Serverless ETL: data catalog, transformation jobs, Spark-based at scale	Carrier's HVAC fault prediction ETL from raw IoT data to ML-ready features
Amazon Kinesis	Real-time data streaming — sub-second latency IoT ingest	Continuous HVAC sensor readings from Lynx/Abound equipment fleet

3. AWS AI Architecture Pattern (Carrier's Stack)

Data pipeline: IoT Core → Kinesis Data Streams → S3 (raw) → Glue ETL → S3 (features) → SageMaker Feature Store

Traditional ML: Feature Store → SageMaker Training → Model Registry → SageMaker Endpoints → CloudWatch monitoring

GenAI: Technical docs → S3 → Bedrock Knowledge Base (vector index) → Bedrock Agent → Abound API → technician chat

Governance: Bedrock Guardrails (content) + SageMaker Model Monitor (drift) + CloudTrail (audit) + IAM (access)

5. MLOps / LLMOps on AWS

MLOps Capability	AWS Native	John's Equivalent
Pipeline orchestration	SageMaker Pipelines	DeepEval CI/CD at NewsRx, SAFe release train at Amgen
Model registry & versioning	SageMaker Model Registry	MLflow at NewsRx
Production tracing	CloudWatch, X-Ray	Langfuse self-hosted at NewsRx
Drift detection	SageMaker Model Monitor	HHEM score tracking, BERTScore trending at NewsRx
Canary/A-B deployment	SageMaker Deployment	Staged rollouts (Invistics facility-by-facility deployment)
Evaluation gates	Bedrock Model Evaluation	DeepEval + HHEM + BERTScore CI/CD gates at NewsRx
Guardrails	Bedrock Guardrails	Zero-fabrication guardrails, ALCOA+ audit at NewsRx / Amgen GxP AI guardrails

6. Interview Language

"Bedrock is the managed version of what I built at NewsRx — RAG with Knowledge Bases, agentic orchestration with Agents, guardrails at inference time. I'm familiar with both the self-hosted architecture and the managed platform trade-offs."

"For Carrier's use cases, I'd use SageMaker Pipelines as the MLOps backbone — training, evaluation, registry, deployment as a DAG. Model Monitor covers drift detection. The architectural pattern I'd add is a tiered evaluation gate before promoting to production, which is the DeepEval pattern I use at NewsRx but implemented as a SageMaker Pipeline step."

"The Bedrock Agent architecture for Abound's 'Tell Me More' is a textbook RAG-plus-tools pattern — Knowledge Base for manual retrieval, action groups for equipment API calls, Guardrails to prevent hallucinated maintenance instructions. I would add an evaluation layer: BERTScore against manual ground truth to catch semantic drift when the knowledge base is updated."

"One architectural consideration I'd flag for Carrier: Kinesis streaming to S3 is the right ingest pattern, but the Glue ETL layer needs version-controlled job definitions and automated data quality checks before features land in SageMaker — otherwise model retraining ingests corrupted features. I've built that governance layer at J&J and NewsRx."

Key Watch-out: PyTorch/TensorFlow

Carrier's SageMaker stack is PyTorch-native. If asked: "SageMaker's native framework is PyTorch. vLLM — which I use daily for LLM inference at NewsRx — runs on PyTorch. My model development has been framework-agnostic by architectural choice, but I'm operating in a PyTorch ecosystem."