« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 25 — Managed Cloud AI Platforms: SageMaker, Vertex AI & Azure ML

Answers these JD lines: "Cloud AI platforms: GCP Vertex AI or Azure Machine Learning or AWS SageMaker," "production ML pipelines (ingestion → training → evaluation → deployment)," "MLOps/deploy: production deployment, model versioning + monitoring + CI/CD," "distributed training," "cloud-native AI architectures." This is the general ML lifecycle platform layer of the enterprise AI/ML Engineer role — the layer that trains, registers, deploys, and orchestrates any model (a fraud classifier, a forecaster, and an LLM), where Phase 24 (Bedrock) and Phase 20 (AgentCore) cover the GenAI/agent layer specifically.

Why this phase exists

Phases 24 and 20 answered "how do I serve a foundation model and run an agent on AWS." This phase answers the older, broader question every enterprise ML JD still leads with: how does a team run the full ML lifecycle — train, tune, register, deploy, orchestrate — without building its own platform? All three hyperscalers sell the same answer under different names, and the JD says "or" between them because the shape is what matters. Three ideas do most of the work:

1. The training job is the atomic unit. You bring a script/container + hyperparameters + a compute request; the platform schedules it on managed (often spot/preemptible) capacity, checkpoints it, and emits a versioned artifact. Tuning jobs, pipelines, and registries are all built out of this one primitive.
2. The registry is the source of truth; the endpoint is just a consumer of it. Model versions with stages/approvals and lineage decide what is in production; real-time endpoints, multi-model endpoints, batch transform, and serverless/async inference are just different cost/latency shapes for serving whatever the registry blesses.
3. The pipeline is a DAG with artifacts, caching, and conditions. SageMaker Pipelines, Vertex AI Pipelines (KFP), and Azure ML pipelines are the same engine: steps declare inputs/outputs, the DAG is derived, unchanged steps are cache-skipped, and "register only if accuracy clears the bar" is a first-class branch node.

SageMaker vs Vertex AI vs Azure ML

The three-way comparison the interview will ask for. Same shape, different accents:

The one-liner: same lifecycle, three dialects — pick by where your data, identity, and existing cloud commitment already live, not by feature checklists. And keep the GenAI split straight: for foundation-model serving, AWS answers with Bedrock (Phase 24) and Azure with Azure OpenAI, both beside their ML platforms — only Vertex AI folds GenAI into the ML platform itself.

Concept map

• Control plane vs data plane — job/endpoint/pipeline CRUD vs the invocation hot path; the same split Bedrock made literal in Phase 24 (Warmup §1).
• Training — managed training jobs, spot + checkpoint/resume, distributed training (data vs model parallel), HPO strategies (Lab 01).
• Registry — versions, stages vs approval statuses, lineage, "latest production" (Lab 01).
• Serving — real-time endpoints + autoscaling, multi-model endpoints, batch transform, serverless/async; deployment safety: shadow → canary → blue/green (Lab 02).
• Pipelines — DAG from declared inputs/outputs, artifact passing, step caching, conditional registration, fan-out/fan-in (Lab 03).
• Also: feature stores, notebooks, AutoML, cost model, and the IAM/VPC/CMK security substrate — covered in the Warmup, not built as labs.

The labs

Integrated scenario (how this shows up at work)

Your team ships a churn model that must retrain weekly on fresh data, never regress in production, and cost as little as possible. The weekly run is a pipeline (Lab 03): preprocess → train → evaluate → condition: AUC beats the incumbent → register; unchanged preprocessing steps are cache hits, so a code tweak to the evaluator doesn't re-spend six GPU hours. Training runs as a managed spot job with checkpointing (Lab 01) at a fraction of on-demand cost, and an HPO job fans out the learning-rate sweep. The winning version lands in the registry with lineage back to the exact job and data. Deployment is a shadow first (compare against the incumbent on live traffic, zero user impact), then a canary at 10% wired to an error-rate alarm that auto-rolls-back (Lab 02); the endpoint autoscales on invocations per instance with cooldowns so it doesn't flap. When the same team later adds an LLM feature, they don't rebuild any of this — they point the same registry/endpoint/pipeline discipline at Bedrock or Azure OpenAI (Phase 24) and keep the lifecycle.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py (30 tests).
• Lab 02 green (31 tests); you can contrast canary, blue/green, and shadow without notes.
• Lab 03 green (24 tests); you can explain what invalidates a step-cache key and the stale-cache foot-gun.
• You can reproduce the SageMaker/Vertex/Azure-ML table's spine (training / registry / endpoints / pipelines / GenAI story) from memory.
• You can state when to pick each cloud — and where Bedrock and Azure OpenAI sit relative to SageMaker and Azure ML.
• You can explain why a resumed spot job must produce the same artifact as an uninterrupted one, and what breaks if it doesn't.

Key takeaways

• One lifecycle, three dialects. Train → tune → register → deploy → orchestrate is identical across SageMaker, Vertex AI, and Azure ML; learn the shape once and the vendor docs become a vocabulary lookup.
• The registry — not the endpoint — is the source of truth. Endpoints, batch, and serverless are interchangeable serving shapes for whatever version the registry says is production.
• Deployment safety is a progression: shadow (zero risk, learn) → canary (bounded risk, verify) → promote; blue/green when you need instant total rollback and will pay double capacity for it.
• Pipelines are DAGs with artifacts, caching, and conditions — the caching key is the whole game, and a key that misses a real input serves you a stale model.
• The senior framing: "I pick the platform by gravity — data, identity, existing commitment — because the lifecycle is the same; then I keep the GenAI layer (Bedrock / Azure OpenAI / Gemini in Vertex) behind the same registry-and-rollout discipline as every other model."