Cloud platforms: a practitioner's field guide.

What "cloud platform" means here

A cloud-hosted model platform is a managed multi-model inference service. You bring an account in someone's hyperscaler (AWS, Google Cloud, Azure). They give you a single API surface, a single billing relationship, and a single auth boundary that fronts a catalog of foundation models from many vendors. Anthropic's Claude. Meta's Llama. Mistral. Cohere. Amazon's Nova. OpenAI's GPT, on Azure. Google's own Gemini, on Vertex. And, increasingly, an open-weight long tail.

The pitch is simple. Instead of holding direct vendor relationships with Anthropic, OpenAI, Google, Meta, Mistral, and Cohere (each with its own API keys, contracts, billing, and audit trail), you hold one with your cloud. The cloud handles the underlying contracts, the regional availability, the data residency, and the security posture. Your application code talks to a single endpoint and you swap models behind it.

The three platforms in this guide are the ones with real production uptake as of May 2026:

• AWS Bedrock. AWS's LLM gateway. The widest model selection of the three, and the only managed home for Anthropic's Claude on AWS. Auth is plain IAM.
• Google Vertex AI. Google Cloud's LLM platform. Native Gemini, plus Claude, Llama, Mistral, and a Model Garden of open-weight options. Auth is GCP IAM with service accounts.
• Azure AI Foundry. Microsoft's umbrella for Azure-hosted models. The Azure OpenAI Service (GPT-5, the o-series, DALL-E, Whisper) plus the Foundry Model Catalog. Auth is Microsoft Entra.

Out of scope for this guide: the model vendors' own APIs (Anthropic, OpenAI, Google AI Studio), other inference services (Together, Fireworks, Groq, Replicate, Cloudflare Workers AI), and anything self-hosted. They matter, they're real options, and they don't fit the same shape as a hyperscaler-managed gateway.

The reason these platforms exist, structurally, is the same reason RDS exists. Running models is operationally expensive. Holding contracts with six vendors is administratively expensive. The cloud already has your IAM, your VPC, your audit pipeline, and your finance approvals. Putting models behind that same plane is worth real money to teams who already pay the cloud tax. For teams that don't, it's overhead they don't need.

AWS Bedrock

Bedrock is the AWS-native LLM gateway. One IAM-scoped API surface in front of a long list of model families. As of May 2026, the lineup that matters in production:

• Anthropic Claude: Sonnet, Opus, and Haiku. Bedrock is the supported managed home for Claude on AWS, and for many enterprise teams it's the only way procurement will let Claude into production.
• Meta Llama: the 3.x family and the Llama 4 generation. The open-weight workhorse choices when you want full control over fine-tuning or steady predictable cost.
• Mistral: the Mistral Large family plus the smaller mixtures.
• Cohere Command: Command R+ and the embeddings models.
• AI21 Jamba: the long-context Mamba-style models.
• Amazon Nova: Amazon's own foundation family. Nova Pro, Lite, and Micro for text; Nova Canvas for image; Nova Reel for video. Cheaper than Claude on like-for-like tasks and integrates well when you want everything in one vendor.
• Stability: Stable Diffusion family for image generation.
• DeepSeek and others: added regionally as availability shifts. The roster moves; check the console.

Surfaces you'll actually use

• Bedrock console: chat playground, model evaluation jobs, prompt management, and the place you go to enable models for an account (yes, you have to enable them; this is the part that catches first-timers).
• Bedrock Runtime API: InvokeModel for the per-vendor native shape, and Converse for a unified chat surface across model families. Use Converse unless you have a reason not to. It's the API that makes "swap the model behind the call" actually work.
• Bedrock Agents: the original hosted agent framework. AWS-managed loop with action groups, knowledge bases, and tool calling. Quick to stand up, opinionated about how the loop runs.
• Bedrock AgentCore: the newer, production-grade agent runtime. Framework-agnostic (bring LangGraph, CrewAI, Strands, or your own), with managed Runtime, Memory, Identity, Gateway, Browser, Code Interpreter, and Observability as separate building blocks.
• Bedrock Knowledge Bases: managed RAG over S3 plus a vector store of your choice (OpenSearch Serverless, Pinecone, Aurora pgvector, Redis). Handles chunking, embedding, indexing, and retrieval.
• Bedrock Guardrails: prompt-time and response-time content filters with policies for denied topics, PII redaction, and contextual grounding.
• Provisioned Throughput: reserved per-model capacity for predictable, fixed-cost inference. The right shape for steady production load.

Bedrock Agents vs AgentCore

This is the choice that confuses every team building agents on AWS. Both ship under the Bedrock umbrella, both can do tool calling, and both will technically run the same workloads. They are not the same product, and picking the wrong one costs weeks.

Pricing and billing

Per-token by model, with both on-demand and provisioned tiers. Cross-region inference profiles spread requests across regions to dodge throttling, and they bill the same per-token rate as the originating region. Knowledge Bases bills the underlying storage and embeddings separately; budget for that, not just the model calls.

Auth and region story

Auth is plain IAM. There are no separate Bedrock API keys; you sign requests with your normal AWS credentials. That's the killer feature for AWS-native shops: one access plane, one audit trail, one set of policies. Region availability is the part that bites: not every model is in every region. As of May 2026, Anthropic models are in us-east-1, us-west-2, eu-central-1, ap-northeast-1, and a growing list. Read the region matrix in the Bedrock docs before you design; assuming "the model is everywhere" will burn an afternoon.

Where it bites

The API is verbose. The model availability matrix is annoying to navigate. Latency is fine but rarely beats going direct to the source vendor. Costs add up if you don't reserve provisioned throughput for steady workloads. The AWS console is its own learning curve, and Bedrock's surface (console, runtime, agents, knowledge bases, guardrails) is enough product to need a champion on the team. None of this is disqualifying. All of it is real.

Google Vertex AI

Vertex AI is Google Cloud's LLM platform. The pitch in one sentence: it's the only place to run Gemini with full enterprise controls (IAM, VPC Service Controls, data residency, audit), and it carries enough other models that you can land most multi-model workloads here without leaving GCP.

Model lineup

• Gemini: the same Gemini 2.5 Flash and Pro that power gemini.google.com, plus the developer-only variants and the embedding models. Vertex is the supported production path for Gemini; you do not run Gemini in production from an AI Studio key, you run it from Vertex.
• Anthropic Claude: Sonnet and Opus, available in specific regions (us-east5 and europe-west1 as of May 2026). The feature parity with Anthropic's direct API is close but not perfect; some newer features land later.
• Meta Llama: the 3.x and 4 generations, available as both Vertex-managed endpoints and Model Garden deployments.
• Mistral: Mistral Large and the smaller open variants.
• Model Garden: a long list of open-weight options (Gemma, Falcon, several HuggingFace models) deployable as managed endpoints with a few clicks. Quality of "deployable" varies; some entries are reference deployments, others are production-grade.

Surfaces

• Vertex AI Studio: the GCP-side playground. Confusingly named, because Google also runs an "AI Studio" at aistudio.google.com which is the consumer-keyed cousin. Vertex AI Studio is the enterprise-keyed one; AI Studio is the rapid-prototyping one. Use AI Studio for sketches, Vertex for production.
• Vertex AI API: the REST and gRPC surfaces. The Python SDK is the most polished; the others are catching up.
• Agent Builder: Google's hosted agent framework, layered on top of the model surface.
• Vertex AI Search and Conversation: managed RAG, the Google equivalent of Knowledge Bases. Strong on the search side (it's Google), reasonable on the conversational composition side.
• Pipelines, Model Monitoring, Experiments: the MLOps tooling Google has been building for years. This is the part of Vertex that doesn't have a good equivalent on Bedrock or Foundry.

Pricing, auth, region

Per-token for managed models, with optional Provisioned Throughput for steady workloads. A free tier exists for experimentation. Auth is GCP IAM with service accounts, Application Default Credentials, or Workload Identity Federation if you're calling from outside GCP. Gemini models are broadly available; Claude on Vertex is restricted to a few regions; full data-residency controls are available with VPC Service Controls and Customer-Managed Encryption Keys.

Where it shines

• Native Gemini access with enterprise controls. If you want Gemini in production with audit, IAM, and residency, Vertex is the only supported path.
• The Workspace data integration story. With proper consent, Vertex can read your org's Workspace data through the Google security boundary. No third-party connector hops.
• MLOps tooling. Pipelines for orchestrating model workflows, Model Monitoring for drift detection, Experiments for tracking runs. If you came from a Kubeflow or MLflow background, this is the most familiar of the three platforms.

Where it bites

It's GCP-only, which is a real cost if your org isn't already there. Model breadth is narrower than Bedrock's; the Model Garden helps but the production-quality tier is smaller. The product surface is a sprawl: AI Studio, Vertex AI Studio, Gemini Code Assist, Agent Builder, Vertex AI Search, and Vertex AI Pipelines all overlap in confusing ways. And some Anthropic features lag the direct Anthropic API by days or weeks; if you need a brand-new Claude capability on day one, Vertex isn't the path.

Azure AI Foundry

Azure AI Foundry is Microsoft's umbrella product for Azure-hosted models. It absorbed the older "Azure AI Studio" branding and now covers both the Azure OpenAI Service and the broader Foundry Model Catalog. The pitch: it's the only managed home for OpenAI's frontier models with Azure's compliance, residency, and Microsoft 365 integration story.

What it hosts

• Azure OpenAI Service: GPT-5 and its variants, the o-series reasoning models, GPT-4 generations still kept around for compatibility, DALL-E 3, Whisper, and the OpenAI embeddings. This is the meaningful part for most Azure-anchored teams: GPT models with Azure's contract, audit, and residency.
• Foundry Model Catalog: hundreds of additional models (Llama, Mistral, Phi, Cohere, Stable Diffusion, plus a long HuggingFace tail) deployable as managed serverless endpoints or as dedicated capacity.

Surfaces

• Foundry portal: the playground plus a project workspace concept. Projects scope deployments, evaluations, and prompt assets together.
• Azure OpenAI REST API: the OpenAI-compatible API on Azure endpoints. If your code already speaks the OpenAI Python SDK, you can point it at Azure with a base URL and an API version and most things work.
• Foundry SDK: the new SDK that wraps both the OpenAI surface and the broader catalog. Useful if you want one client across both.
• Prompt Flow: visual orchestration for prompt pipelines, with evaluation and deployment built in.
• Content Safety: the Azure equivalent of Bedrock Guardrails. Prompt and response filtering, jailbreak detection, groundedness checks.
• Evaluations: a managed eval harness with built-in metrics and the ability to plug in custom ones.
• Agent Service: Microsoft's hosted agent framework. Newer and more enterprise-flavored than the OpenAI Assistants API it descends from.

Pricing, auth, region

Per-token for OpenAI models, varying by model and region. Both Standard (per-token, on-demand), Provisioned Throughput Units, and the newer serverless options for catalog models. Free tier through Azure trial credits. Auth is Microsoft Entra (Azure AD) with managed identities for in-Azure callers and Entra ID app registrations for external ones. Region availability is the most fragmented of the three platforms: specific OpenAI versions live in specific regions, and Sovereign Cloud (Azure Government, Azure China) options exist for regulated workloads.

Where it shines

• Enterprise integration. Entra for auth, Purview for data classification, Sentinel for security logging, Defender for threat detection. If your org runs on Microsoft, Foundry slots into a security plane that's already there.
• The OpenAI residency story. Azure OpenAI is the only managed path to GPT-5 with contractual data residency, no-training commitments, and the Azure compliance certifications (FedRAMP High, IL5, HIPAA, and the rest).
• Microsoft 365 integration. Copilot's underlying plumbing lives here. If you want to extend the M365 Copilot story or build on top of Graph data with managed AI, Foundry is the surface.

Where it bites

The OpenAI version lag. New OpenAI model releases sometimes land on Azure days or weeks after the consumer ChatGPT and OpenAI direct APIs. For most production teams that's fine; for teams chasing the bleeding edge it's a real cost. The Foundry brand is new and the docs are catching up; older Microsoft Learn articles still reference Azure AI Studio and Azure Machine Learning Studio. The quota system requires capacity requests for many model SKUs and the request flow can be slow. And the product naming is its own challenge: Foundry, Azure OpenAI, Azure ML, Copilot Studio, Power Platform AI Builder all overlap in ways that take time to map.

A three-way comparison

Side by side on the dimensions that actually move decisions. There is no overall winner. There's a winner per dimension, and the right pick is whichever lines up with the constraints you actually have.

The shorthand I use: Bedrock for breadth and IAM, Vertex for Gemini and MLOps, Foundry for OpenAI and Microsoft. Each is the obvious choice in its primary lane, and a respectable second choice in the others.

Cross-cutting concepts

Four ideas show up on all three platforms with slightly different names and largely the same shape. Knowing them once is enough.

Provisioned throughput

Paying for reserved per-model capacity instead of paying per token at on-demand rates. Bedrock calls it Provisioned Throughput. Vertex calls it Provisioned Throughput. Azure calls it Provisioned Throughput Units (PTUs). Same idea, three names. The right shape when you have steady, predictable load and you're consistently hitting the on-demand rate cap; the wrong shape for spiky, exploratory workloads where you'll pay for capacity you don't use. The cost crossover is usually somewhere around 60-70% sustained utilization. Below that, on-demand is cheaper; above that, provisioned wins.

Cross-region inference

Spreading requests across regions to dodge throttling and improve resilience. Bedrock has it as a first-class concept (cross-region inference profiles) where you call one logical endpoint and it routes to the least-loaded region. Vertex and Foundry achieve the same effect through deployment-region configuration and client-side routing. The pattern matters because a single region's per-model rate limit will bite you in production even when your aggregate volume is small; using two or three regions buys headroom without increasing cost.

Guardrails and content safety

Every platform now offers a prompt-time and response-time filtering layer. Bedrock Guardrails, Vertex safety filters, Azure Content Safety. They cover roughly the same ground: denied topics, PII redaction, jailbreak detection, and (newer) groundedness checks against retrieved context. They are not a substitute for application-level review and they will not catch a determined adversarial prompt, but they catch the obvious. Treat them as a defense-in-depth layer, not the primary defense.

Managed RAG

Every platform offers a "drop documents into a bucket, get retrieval" service: Bedrock Knowledge Bases, Vertex AI Search, Foundry Indexes. They handle the chunking, the embedding, the indexing, and the retrieval call from your model. Quality varies. Bedrock Knowledge Bases is the most flexible on backing store choice; Vertex AI Search is the strongest on retrieval quality (it's Google); Foundry Indexes is the most integrated with the rest of the Foundry stack.

One more cross-cutting note. All three platforms expose a no-training-on-your-data commitment in their enterprise terms, and all three have the certifications most enterprise procurement asks for (SOC 2, ISO 27001, the cloud-specific equivalents). The compliance differences between them are real but small; they rarely decide a platform choice on their own.

Practical workflows

Six patterns I keep coming back to. They aren't tied to a specific platform; the same shape works on all three with the names changed.

Choosing a platform (or staying direct)

Pick the cloud you already pay. Pick the model you already trust. Don't pick both at once. — TWD

The decision frame I run for clients, in order:

1. What's your existing cloud footprint? If you're 90% AWS, Bedrock is the default and you should need a real reason to pick something else. Same for GCP-Vertex and Azure-Foundry. The auth, audit, and finance benefits of staying in your existing cloud are larger than they look on paper, and they compound over time. Picking a second cloud just for a model is rarely worth the operational tax.
2. What's the compliance story? If you have a contract that says "data stays in EU" or "data does not leave the US government cloud," that often picks the platform for you. Sovereign cloud options exist on all three, but they're not equivalent. Azure Government and AWS GovCloud are the most mature for US federal; Azure has the strongest EU sovereign story; GCP's Assured Workloads is the youngest but credible.
3. Which model do you actually need? If the answer is "GPT-5 specifically," Foundry is the only managed home for it. If the answer is "Claude specifically," Bedrock is the broadest path. If the answer is "Gemini specifically," Vertex is the only path. If the answer is "Llama or Mistral," all three work and the cloud footprint question dominates.
4. How much do you care about model freshness? If you need day-zero access to new model versions, you want the direct vendor API for at least your prototype path, regardless of which platform you pick for production. Cloud platforms lag by days to weeks on new releases. That gap matters less than it used to (it was months in 2024) but it isn't zero.
5. What's your team's skill profile? AWS-fluent teams ship on Bedrock fastest. GCP-fluent teams ship on Vertex fastest. Microsoft-fluent teams ship on Foundry fastest. The platform that matches your existing operational competence is almost always the right one even when another scores marginally better on a feature checklist.

When to stay direct with the model vendor

The case for skipping cloud platforms entirely:

• You're prototyping. The friction of setting up a Bedrock account, enabling models, configuring IAM, and waiting on quota is real. For exploration, an Anthropic or OpenAI key is faster.
• You want the latest model on day one. Direct APIs get new versions first.
• You don't have enterprise compliance requirements yet. The cloud platform's main value is auth, audit, residency, and procurement; if none of those bind for you, you're paying complexity for nothing.
• You want the full feature surface. Anthropic ships features like prompt caching, computer use, and the Files API on direct first. The cloud platforms catch up, but they're behind.

The honest middle path that most teams I work with land on: direct vendor APIs for the prototype bench and for early access; one cloud platform for the production path that has to live inside compliance. The two coexist. The same prompt template, the same eval set, the same model family on both sides; the platform changes, the work doesn't.

Pitfalls and gotchas

The places these platforms are most likely to disappoint, in the order you'll hit them.

One closing observation

The three cloud platforms are converging. In 2024 they each had distinct strengths and obvious gaps. By May 2026 the gaps are smaller, the feature lists rhyme, and the choice is mostly about which cloud you already live in and which models you actually need. That convergence is a good thing for buyers; it means the wrong pick is rarely catastrophic, and switching costs are real but bounded. Build your code with the model choice behind a clean abstraction (Converse, the Vertex SDK, the Foundry SDK) and the platform-level decision becomes one you can revisit later with less pain than you'd expect.

And if any of this is out of date by the time you read it: aws.amazon.com for Bedrock, cloud.google.com for Vertex, and techcommunity.microsoft.com for Foundry. All three move fast; assume the version numbers in this guide are wrong by the time you read it, and verify before you ship.