AWS Bedrock, Azure OpenAI Service, and Google Vertex AI are the three platforms where most enterprise AI inference actually happens. Model benchmarks, latency comparisons, and API ergonomics rarely drive the selection. Enterprise procurement already lives on these platforms, and that's the deciding factor. An AE encounters these platforms in deals as the answer to a question the buyer has usually already answered before the conversation starts: which cloud are we on? The language that buys you credibility in that conversation is not model benchmarks. It's understanding why the buyer's cloud contract is doing more work than their evaluation criteria.
AWS Bedrock
What it is: A managed inference service that hosts models from multiple providers inside the AWS environment.
What it does: Bedrock gives AWS customers API access to a catalog of foundation models — Anthropic's Claude family, Meta's Llama models, Mistral, Cohere, Amazon's own Titan and Nova models, and others — without requiring those customers to provision separate accounts with each model provider. Requests stay inside the customer's AWS VPC. Data doesn't leave the AWS environment unless the customer routes it out. Model access is controlled through standard AWS IAM: roles, policies, service control policies, the same mechanisms the customer already uses for S3 and EC2.
Who's behind it / where it comes from: Amazon Web Services, launched in 2023, built on top of AWS's existing managed ML infrastructure (SageMaker). The multi-vendor model catalog reflects Amazon's strategic decision not to bet exclusively on its own models — Titan and Nova exist, but Amazon has been explicit that Bedrock is a marketplace, not a showcase.
What makes it distinct: Bedrock is the only one of the three platforms designed from the start as a model-agnostic marketplace. The buyer isn't choosing Bedrock because they want a specific model; they're choosing Bedrock because they're AWS-first and they want model optionality inside that perimeter. A Bedrock customer can switch from Claude 3.5 Sonnet to Llama 3.1 to Mistral Large with an API parameter change and no new vendor relationship. That's the pitch. The catch is that "model optionality" at the API level doesn't mean the models are interchangeable. They're not. But the procurement and compliance overhead of accessing them is genuinely unified.
Azure OpenAI Service
What it is: A managed inference service that hosts OpenAI's model family inside Azure, under Microsoft's enterprise terms.
What it does: Azure OpenAI Service gives Azure customers access to OpenAI's production models — GPT-4o, the o-series reasoning models, DALL-E, Whisper, text embeddings — through Azure's infrastructure, with Azure's data handling commitments, Azure's SLA, and Azure's compliance certifications. The customer's data doesn't go to OpenAI's API; it goes to a Microsoft-managed endpoint that runs OpenAI's models in Azure regions. Access control runs through Microsoft Entra ID (formerly Azure AD): managed identities, RBAC, conditional access policies.
Who's behind it / where it comes from: Microsoft and OpenAI, formalized through Microsoft's multi-billion-dollar investment in OpenAI beginning in 2019. The service reflects a specific strategic bet: that enterprise buyers who want GPT-class models will want them inside the Azure perimeter, under Microsoft's enterprise agreements, rather than through OpenAI's direct API. That bet has largely paid off. Azure OpenAI has become the default path for regulated-industry customers who want OpenAI models but can't accept OpenAI's standard API data handling terms.
What makes it distinct: Azure OpenAI is the only one of the three platforms built around an exclusive relationship with a single external model provider. You cannot access Anthropic or Mistral models through Azure OpenAI Service. The platform's value proposition is not model breadth; it's the combination of OpenAI's specific model capabilities with Microsoft's enterprise compliance posture. For buyers already in the Microsoft ecosystem, M365, Azure, Copilot, Defender, Azure OpenAI is less a product decision than a procurement gravity well. The real evaluation is whether the models it offers are sufficient for the use case.
Google Vertex AI
What it is: Google Cloud's unified ML platform, which hosts Gemini models natively and provides access to selected third-party models through its Model Garden.
What it does: Vertex AI is broader than Bedrock or Azure OpenAI — it's Google's full MLOps platform, covering training, fine-tuning, evaluation, and inference. For enterprise buyers focused on inference, the relevant surface is Gemini model access (Gemini 2.0 Flash, Gemini 1.5 Pro, and the broader Gemini family) plus Model Garden, which includes Anthropic's Claude models, selected open-source models like Llama, and some Hugging Face-hosted models. Access control runs through Google Cloud IAM: service accounts, Workload Identity Federation, VPC Service Controls.
Who's behind it / where it comes from: Google DeepMind and Google Cloud, with Vertex AI serving as the commercial deployment surface for models developed by Google's research organization. The platform's architecture reflects Google's position as both a model developer and a cloud provider — unlike Amazon, Google is not neutral about which models it wants customers to use.
What makes it distinct: Vertex AI is Gemini-first in a way that Bedrock is not Titan-first. Google has built its enterprise AI narrative around Gemini's multimodal capabilities and long context window, and Vertex is the delivery mechanism for that narrative. The Model Garden exists, and Claude on Vertex is a real option, but the platform's roadmap, pricing incentives, and sales motion all point toward Gemini. Google Cloud's enterprise sales footprint is smaller than AWS's or Microsoft's, which means Vertex AI is often the technically strongest native-model option in a deal where it has the weakest procurement pull. A buyer who runs 80% of their workloads on GCP will reach for Vertex the same way an AWS buyer reaches for Bedrock. But fewer enterprise buyers are 80% GCP.
How the Three Platforms Actually Differ: A Trait-Led Analysis
This section uses trait-led analysis across three dimensions. Each platform appears in each dimension. Any claim that one platform has an advantage in a given circumstance is tied to a specific, documented trait.
Trait 1: Model selection breadth
Bedrock offers the widest third-party model catalog by design. If a buyer's use case requires evaluating Claude against Mistral against Llama against Amazon's own models, Bedrock is the only platform where that evaluation happens under a single vendor relationship. Azure OpenAI offers no third-party models — the catalog is OpenAI's catalog, full stop. Vertex AI sits in the middle: Gemini is the native model family, Claude is available through Model Garden, and a selection of open-source models are accessible, but the third-party catalog is narrower than Bedrock's and the platform's incentives favor Gemini.
If a buyer tells you they want to "evaluate multiple models," Bedrock is the structurally correct answer, but only if they're already AWS customers. If they're Azure-first and they want model variety, they're looking at a combination of Azure OpenAI for OpenAI models and direct API relationships for everything else. That friction is real and worth naming in the conversation.
Trait 2: Procurement integration
All three platforms offer committed-spend integration with their respective cloud billing systems. AWS Bedrock usage counts against AWS committed spend. Azure OpenAI usage counts against Azure committed spend. Vertex AI usage counts against Google Cloud committed spend. This is the mechanism that makes existing cloud contracts the dominant selection factor — a buyer with $20M in AWS committed spend has a financial incentive to route AI inference through Bedrock that has nothing to do with model quality.
The difference is in how those contracts are structured at the enterprise level. Microsoft's enterprise agreements tend to bundle M365, Azure, and now Copilot licensing in ways that create strong organizational momentum toward Azure services. AWS's Enterprise Discount Programs are typically compute-focused, which makes Bedrock a natural extension of existing infrastructure spend. Google Cloud's enterprise agreements are less standardized and often more negotiated, which means the committed-spend pull toward Vertex is real but less automatic.
Trait 3: IAM and identity integration
All three platforms integrate with their cloud's native IAM system, and the differences here are the most operationally significant. Bedrock uses AWS IAM roles and policies. Azure OpenAI uses Microsoft Entra ID managed identities and RBAC. Vertex uses Google Cloud service accounts and Workload Identity Federation.
For a buyer whose security team has already approved, audited, and operationalized one of these IAM systems, adding AI inference through the same system is materially easier than adding a new vendor relationship with a separate identity model. The approval cycle for a new external API — its own credential management, its own data handling terms, its own audit logging format — can take months in a regulated enterprise. Routing through the existing cloud IAM collapses that cycle. The model doesn't have to be better; it has to be approvable.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "Which AI platform is best for your use case?" | "Which cloud are you running most of your workloads on today?" | Model selection follows cloud selection in most enterprise deals; start where the decision already lives |
| "Bedrock has the most models" | "Bedrock lets you access multiple model providers under your existing AWS IAM and billing" | The value is procurement consolidation, not model count |
| "Azure OpenAI gives you access to GPT-4o" | "Azure OpenAI gives you GPT-4o under Microsoft's enterprise data handling terms, inside your Entra ID perimeter" | The enterprise differentiator is compliance posture, not model access |
| "You can use Claude on any of these platforms" | "Claude is available on Bedrock natively and on Vertex through Model Garden; it's not available on Azure OpenAI" | Buyers who want Claude need to know this before they assume platform flexibility |
| "Vertex AI has Gemini" | "Vertex AI is Google's inference platform for Gemini models, with Claude and selected open-source models available through Model Garden" | Sets accurate expectations about what's native versus what's third-party |
| "These platforms are basically the same" | "The platforms are structurally similar but differ in which models are available, how they connect to your existing IAM, and how usage counts against your cloud commitments" | Buyers need to understand the three dimensions that actually vary |
| "You should evaluate all three" | "If you're committed to AWS, Bedrock is the path of least resistance. If you're Azure-first and need OpenAI models specifically, Azure OpenAI is the answer. If you're GCP-heavy, Vertex is the default." | Saves the buyer time and positions you as someone who understands their environment |
| "The model is available on the cloud" | "The model is hosted on [platform], which means it runs inside your [AWS/Azure/GCP] environment under your existing security controls" | "On the cloud" is ambiguous; buyers care about which cloud and what that means for their compliance posture |
| "You can switch models later" | "You can change which model you're calling with an API parameter change, but the outputs will be different — this isn't like swapping one database for another" | Prevents the buyer from assuming model portability means functional equivalence |
| "Your committed spend applies" | "Usage on [Bedrock/Azure OpenAI/Vertex] counts against your existing [AWS/Azure/GCP] committed spend, which means the effective cost may be lower than the list price suggests" | Committed spend is a real procurement lever; naming it specifically is more useful than the generic claim |
| "Data stays in your environment" | "Data doesn't leave your [AWS/Azure/GCP] environment — requests go to a managed endpoint inside your VPC, not to the model provider's public API" | The security team's question is specifically about data routing, not just "environment" |
Okta Concept Mapping
Bedrock's multi-vendor model catalog is structurally similar to an identity broker: it sits between the consuming application and multiple upstream providers, abstracting the provider relationship behind a unified interface. The analogy holds for the abstraction layer and the credential management — just as Okta lets you swap or add upstream IdPs without changing the SP integration, Bedrock lets you swap model providers without changing your IAM configuration or billing relationship. The analogy runs out at the functional layer. Swapping one SAML IdP for another behind Okta doesn't change what the authenticated user can do. Swapping Claude for Titan behind Bedrock changes the output fundamentally — the "abstraction" is procurement-level, not behavioral. A security architect who's comfortable with identity brokering will intuitively grasp why Bedrock reduces vendor management overhead, but they'll need to understand that the model choice still requires evaluation on its own terms. The broker handles the plumbing; it doesn't make the models equivalent.
In practice, the market is messier than the three-platform summary suggests. Buyers have split cloud environments. They have use cases that favor Claude but contracts that favor Azure. They have security teams that approved GCP for data analytics and now need to decide whether that approval extends to Gemini inference. The hyperscaler layer solves the procurement and compliance problem. Model selection is a separate problem, and conflating the two is where these conversations go sideways.