Learning objectives

Internalize the thesis: AI concepts are portable across clouds; only the service names differ.
Map Azure AI services onto their AWS (Bedrock) and GCP (Vertex AI) equivalents.
Recognize the same RAG / agent / guardrail / eval building blocks on each cloud.
Choose a cloud by where the client already is — meet them there, not where you're most comfortable.

Note

For consultants: you won't pick your clients' clouds — they're already on one. A French bank runs Azure; an AWS-native startup runs Bedrock; a data-heavy GCP shop runs Vertex. Your value is that your vendor-neutral skills (Tracks 1–6) map onto all three, so you can serve any of them. This topic is that map, not deep expertise in each console. Product names shift — verify current docs.

The thesis: concepts are portable

Every major cloud offers the same shape of AI platform, because they're all wrapping the same underlying concepts you learned vendor-neutrally: a way to call models, a managed RAG/search store, an agent framework, content safety, and container deployment. Learn the concept once (as you have) and each cloud is a renaming exercise, not a new skillset. The one master table:

Concept (this course)	Azure	AWS	GCP
Managed model API	Azure OpenAI	Amazon Bedrock	Vertex AI (Gemini + Model Garden)
Model catalog (open + closed)	Foundry model catalog	Bedrock model access	Vertex Model Garden
Managed RAG / vector search	Azure AI Search	Bedrock Knowledge Bases / OpenSearch	Vertex AI Search / Vector Search
Managed agents	Foundry Agent Service	Bedrock Agents	Vertex Agent Builder
Content safety / guardrails	Azure AI Content Safety	Bedrock Guardrails	Vertex safety filters / Model Armor
Eval tooling	Foundry Evaluations	Bedrock model evaluation	Vertex Gen AI evaluation
Container deployment	Container Apps / AKS	App Runner / ECS / EKS	Cloud Run / GKE
Secrets	Key Vault	Secrets Manager	Secret Manager
Identity	Entra ID	IAM	Cloud IAM

Read across any row: the job each service does is identical — only the brand changes. Your RAG pipeline, agent loop, guardrail stack, and eval suite land on any column.

Tip

↳ Exercise 1 has you fill in this cross-cloud map from memory for the core services — the fluency that lets you talk credibly to any client about their stack.

AWS Bedrock

Amazon Bedrock is AWS's managed model service — a single API to many providers' models (Anthropic Claude, Meta Llama, Amazon Titan, Mistral, etc.), which is a notable difference from Azure OpenAI's OpenAI focus. Around it, AWS offers the same building blocks under its own names:

Bedrock Knowledge Bases — managed RAG (ingest → chunk → embed → retrieve), the Azure AI Search equivalent.
Bedrock Agents — managed tool-using agents (the Track 4 agent, hosted).
Bedrock Guardrails — content filtering + denied topics + PII redaction (Track 6, managed).
Deploy on App Runner (managed containers), ECS, or EKS (Kubernetes).

Everything you built maps over: your chunking + prompt still yours; retrieval/agents/guardrails become Bedrock configuration. Bedrock's multi-provider model access is its distinctive strength — one API, many model families.

Tip

↳ Exercise 2 has you describe how your hand-rolled RAG maps onto Bedrock Knowledge Bases — the same managed/DIY boundary as the Azure exercise, different brand.

GCP Vertex AI

Vertex AI is Google Cloud's unified ML/AI platform, home to the Gemini models plus a Model Garden of open and third-party models. Its building blocks:

Vertex AI Search / Vector Search — managed RAG and vector retrieval (the AI Search / Knowledge Bases peer).
Vertex Agent Builder — managed agents and conversational apps.
Gen AI evaluation — Vertex's eval tooling (the Track 5 eval suite, managed).
Deploy on Cloud Run (managed containers) or GKE (Kubernetes, which Google originated).

Vertex tends to appeal to data-heavy, GCP-native, and Gemini-first shops. Same concepts, Google's brand and its particularly strong container/Kubernetes lineage.

Tip

↳ Exercise 3 has you place three of your course building blocks (RAG store, agent host, eval) onto Vertex's services — proving the map works in the third column too.

Choosing a cloud

You rarely choose from scratch; you meet the client on their existing cloud — the dominant factor. The decision, layered on the code-vs-no-code / Azure-vs-alternative judgment from earlier:

Client already on a cloud → use its AI stack. Cross-cloud (running AI on a cloud the client doesn't use) adds data-egress cost, latency, and operational friction for little gain. This decides most cases.
Model availability → need Claude? Bedrock and Azure both offer it; need Gemini? Vertex. Need a specific OpenAI model? Azure OpenAI. Let a hard model requirement break ties.
EU residency / compliance → all three offer EU regions; check the specific service and model availability per region.
Greenfield / no cloud yet → then weigh ecosystem, model access, pricing, and the client's team skills — but this is the rarer case.

Because your skills are portable, "which cloud" is a client-context question, not a limit on what you can build. That portability is itself a selling point: you're not locked to one vendor's ecosystem.

Tip

↳ Exercise 4 has you recommend a cloud for three clients (an AWS-native SaaS, a Gemini-committed data team, a greenfield EU startup) and justify each — meeting the client where they are.

Pitfalls

Believing each cloud is a separate skillset. It's the same concepts renamed — learn the map, not three platforms from scratch.
Forcing your preferred cloud. Running AI off the client's existing cloud adds egress cost, latency, and friction — meet them where they are.
Ignoring model availability. A hard requirement (Claude/Gemini/a specific OpenAI model) can decide the cloud regardless of other factors.
Assuming feature parity is exact. The shape matches, but specifics (region availability, limits, pricing) differ — verify per service.
Chasing renamed products. Cloud AI services get renamed constantly; anchor on the concept, confirm the current name.

Recap

AI concepts are portable; each cloud wraps them under different names — learn the concept once, map it to any provider.
Azure OpenAI ↔ AWS Bedrock ↔ Vertex AI (models); AI Search ↔ Knowledge Bases ↔ Vertex Search (RAG); agents, guardrails, eval, and container deploy all have a per-cloud equivalent.
Bedrock stands out for multi-provider model access; Vertex for Gemini and GCP/Kubernetes-native shops; Azure for the OpenAI + Microsoft-enterprise default.
Choose a cloud by where the client already is, then model availability and residency — portability means "which cloud" is client context, not a skills limit.
Worked examples map to the exercises: the cross-cloud map (Ex 1), RAG on Bedrock (Ex 2), building blocks on Vertex (Ex 3), a cloud-choice decision (Ex 4).

Cloud Equivalents — Exercises

Mapping/judgment exercises — no cloud account needed. The goal is fluency across clouds, not deep expertise in each console.

Exercise 1 — Fill in the cross-cloud map

From memory, give the AWS and GCP equivalent for each Azure service: (a) Azure OpenAI, (b) Azure AI Search, (c) Foundry Agent Service, (d) Azure AI Content Safety, (e) Container Apps.

Reference solution

Concept	Azure	AWS	GCP
Managed model API	Azure OpenAI	Amazon Bedrock	Vertex AI (Gemini)
Managed RAG / vector search	Azure AI Search	Bedrock Knowledge Bases	Vertex AI Search / Vector Search
Managed agents	Foundry Agent Service	Bedrock Agents	Vertex Agent Builder
Content safety	Azure AI Content Safety	Bedrock Guardrails	Vertex safety / Model Armor
Managed containers	Container Apps	App Runner (or ECS/EKS)	Cloud Run (or GKE)

Reading across each row: the job is identical, only the brand changes. Being able to produce this map on the spot is what lets you talk credibly to a client about their existing stack.

Exercise 2 — Your RAG on AWS Bedrock

Describe how your hand-rolled RAG (chunk → embed → index → hybrid retrieve → generate) maps onto AWS Bedrock, and what you still own.

Reference solution

Model calls → Bedrock (choose Claude / Llama / Titan / Mistral via one API — its multi-provider access is the distinctive strength).
Indexing + retrieval → Bedrock Knowledge Bases (managed ingest → chunk → embed → retrieve), the AI Search equivalent.
Agents → Bedrock Agents; guardrails → Bedrock Guardrails; deploy → App Runner / ECS / EKS.
You still own: chunking strategy choices and the generation prompt — the same managed/DIY boundary as on Azure.

Same building blocks, AWS brand. Your vendor-neutral RAG knowledge lands directly; the work is locating each stage in Bedrock's services.

Exercise 3 — Building blocks on GCP Vertex

Place three course building blocks on Vertex AI services: (a) a managed vector/RAG store, (b) an agent host, (c) eval tooling.

Reference solution

(a) Managed RAG / vector store → Vertex AI Search / Vector Search.
(b) Agent host → Vertex Agent Builder.
(c) Eval tooling → Vertex Gen AI evaluation.

Plus: models via Gemini + Model Garden, deploy on Cloud Run / GKE. The third column of the map holds up — Vertex offers the same concepts under Google's brand, with a Gemini-first and strong-Kubernetes flavor.

Exercise 4 — Recommend a cloud

For each client, recommend a cloud and justify: (a) an AWS-native SaaS company wanting to add a RAG assistant; (b) a data team already committed to Google Gemini; (c) a greenfield EU startup with no cloud yet needing Claude and EU residency.

Reference solution

(a) AWS-native SaaS → AWS Bedrock. Stay on their existing cloud — running AI elsewhere adds egress cost, latency, and friction. Bedrock Knowledge Bases gives managed RAG in-place.
(b) Gemini-committed data team → GCP Vertex AI. Gemini is native to Vertex, and they're likely already GCP; model requirement + existing cloud both point there.
(c) Greenfield EU startup needing Claude + EU residency → Azure or AWS (both offer Claude in EU regions). Greenfield means you weigh ecosystem/pricing/team skills; the hard requirements (Claude + EU) narrow it, and either Azure OpenAI-adjacent or Bedrock in an EU region works.

The dominant factor is almost always where the client already is, then a hard model/residency requirement. Your portable skills mean 'which cloud' is client context — and that portability is itself a selling point.