The model selection conversation in most enterprise accounts doesn't start with a benchmark. It starts with a question about what's already in the contract. When a CAIO tells you they're "evaluating Bedrock," they're usually not telling you they've compared Claude on Bedrock against Claude accessed directly from Anthropic — they're telling you their AWS Enterprise Agreement is the path of least resistance and they're working backward from there.
That structural reality shapes everything that follows. AWS Bedrock, Azure OpenAI Service, and Google Vertex AI are three distinct hosting arrangements for frontier AI models, and understanding them as procurement vehicles first, technical platforms second, is what makes the difference between a discovery conversation that goes somewhere and one that doesn't. A 2025 Forrester survey of enterprise AI deployments found that 71% of organizations accessed frontier models through an existing hyperscaler contract rather than through a direct lab relationship. The technical evaluation happened after the platform was already chosen.
AWS Bedrock
What it is: A managed inference service that hosts models from multiple AI labs within AWS infrastructure, accessed through the same API surface and IAM controls that govern the rest of an enterprise's AWS footprint.
What it does: Bedrock provides API access to models from Anthropic (Claude 3 and 3.5 series), Meta (Llama 3 and 3.1), Mistral, Cohere, AI21 Labs, and Amazon's own Nova model family, all through a unified endpoint. The enterprise doesn't establish separate relationships with each lab; AWS holds those relationships, and the enterprise's existing IAM policies, VPC configurations, and service control policies extend to cover model access. Bedrock also includes Agents for Bedrock (an orchestration layer for multi-step AI workflows) and Knowledge Bases (a managed RAG implementation), though those are infrastructure features, not model catalog entries.
Who's behind it: Amazon Web Services. Bedrock launched in general availability in late 2023. Amazon's own Nova model series, positioned as cost-efficient alternatives to third-party models for common enterprise tasks, was added to the catalog in late 2024, making AWS both a platform operator and a model vendor on its own marketplace.
What makes it distinct: Catalog breadth. Bedrock carries the widest selection of third-party frontier models of the three platforms, and the selection logic appears to be: if a model has enterprise adoption and the lab is willing to accept AWS's hosting terms, it ends up in the catalog. For an enterprise whose AI strategy is "we want optionality across multiple model families," Bedrock is the structural answer. The IAM integration is also genuinely deep. Model access is governed by the same IAM roles and policies that control S3 buckets and EC2 instances, which means an enterprise with mature AWS IAM governance can extend that governance to AI model access without building a parallel access control system.
Azure OpenAI Service
What it is: Microsoft's exclusive hosting arrangement for OpenAI models within Azure infrastructure, and the only compliant path to OpenAI's frontier models for enterprises with data residency or contractual requirements.
What it does: Azure OpenAI provides API access to OpenAI's GPT-4o, GPT-4o mini, o1, o3, and DALL-E series through Azure's API management layer. The model weights run on Azure compute; the training and model development remain OpenAI's. From an enterprise perspective, the experience is nearly identical to calling the OpenAI API directly (same models, same capabilities), but the data never leaves Azure's infrastructure, the access is governed by Azure Active Directory (Entra ID), and the usage falls under the enterprise's existing Microsoft agreement rather than a separate OpenAI contract.
Who's behind it: Microsoft, through a partnership with OpenAI that began in 2019 and has since expanded to include exclusive cloud hosting rights for enterprise use. The financial relationship between Microsoft and OpenAI is complex and evolving, but the hosting exclusivity is the part that matters for this conversation: if a buyer wants GPT-4o or o3 in a production enterprise environment with data residency controls, Azure OpenAI is the only option.
Note that Microsoft has also built Azure AI Foundry as a broader platform that includes access to some open-weight models (Meta's Llama series, for instance) alongside Azure OpenAI. Foundry and Azure OpenAI Service are related but distinct offerings; in most enterprise conversations, "Azure OpenAI" refers specifically to the OpenAI model hosting arrangement.
What makes it distinct: Exclusivity. This is a single-vendor relationship, not a marketplace. Enterprises choose Azure OpenAI when the buyer's AI strategy is built around OpenAI's models, and Azure is the only compliant path to those models at enterprise scale. Catalog breadth is beside the point. The Entra ID integration is also a meaningful differentiator for Microsoft-heavy shops: model access governance plugs directly into the identity infrastructure the enterprise already operates.
Google Vertex AI
What it is: Google Cloud's AI platform, centered on the Gemini model family with third-party model access through a component called Model Garden.
What it does: Vertex provides API access to the full Gemini family, including Gemini 1.5 Pro, Gemini 1.5 Flash, and the Gemini 2.0 series, plus selected third-party models through Model Garden, including Anthropic's Claude series and Meta's Llama models. The platform also integrates with Google's broader data infrastructure: BigQuery, Dataflow, Looker, and Google's search and grounding capabilities. For an enterprise whose data estate is already in Google Cloud, Vertex offers AI model access that sits inside the same data perimeter rather than requiring cross-cloud data movement.
Who's behind it: Google Cloud, with models from Google DeepMind. Vertex has existed in various forms since 2021, but the Gemini-centered positioning solidified through 2024 as DeepMind's model work became Google's primary AI product line.
What makes it distinct: Data stack integration. Vertex's differentiating value isn't catalog breadth (Bedrock) or model exclusivity (Azure OpenAI); it's the depth of integration with Google's analytics and data infrastructure. An enterprise running its data warehouse on BigQuery can ground Gemini responses against that data without moving anything across cloud boundaries. Model Garden gives Vertex some catalog breadth, but the selection of third-party models is narrower than Bedrock's, and the primary draw remains Gemini itself. For enterprises that have standardized on Google Cloud for data and analytics, Vertex is the natural AI layer. The integration story is cleaner than anything requiring cross-cloud data movement, and that matters more than benchmark comparisons in most procurement conversations.
Comparison: Three Dimensions That Actually Drive Selection
The comparison below uses trait-led analysis across three dimensions: model catalog structure, IAM integration depth, and contract vehicle fit, rather than scenario mapping or platform clustering. AEs encounter these accounts in too many configurations for scenario mapping to be durable. The three traits are the questions worth asking in any account, regardless of the specific scenario.
Model Catalog Structure
Bedrock is a marketplace. The enterprise gets access to models from multiple competing labs through a single platform, and AWS's incentive is to keep the catalog broad because breadth is the value proposition. When a new lab achieves enterprise relevance, it typically appears in Bedrock before the other two platforms.
Azure OpenAI is an exclusive relationship. The catalog is narrow by design: OpenAI's models, accessed through Azure. The enterprise isn't choosing Azure OpenAI for optionality; it's choosing it for access to a specific set of models that aren't available anywhere else at enterprise scale.
Vertex sits between these two structures. Gemini is the center of gravity, and Model Garden adds third-party models, but the selection logic appears more curated than Bedrock's. Anthropic's Claude and Meta's Llama are present; the catalog doesn't have the same breadth as Bedrock's third-party roster.
An enterprise that wants to run Claude in production has two compliant paths (Bedrock or Vertex). An enterprise that wants GPT-4o has one (Azure OpenAI). An enterprise that wants to hedge across multiple model families has the clearest path through Bedrock.
IAM Integration Depth
All three platforms integrate with their respective cloud IAM systems, and all three support private networking configurations that keep model traffic inside the enterprise's cloud perimeter. The differences are in how that IAM integration connects to the enterprise's broader identity infrastructure.
In AWS environments, Bedrock's IAM integration is native: model access is governed by the same IAM roles, policies, and service control policies that govern everything else. Enterprises with mature AWS IAM governance can extend that governance to AI model access without a separate access control layer.
In Microsoft environments, Azure OpenAI's Entra ID integration is similarly native. Model access governance runs through conditional access policies, the same infrastructure that governs everything else in the Microsoft stack. For enterprises running Okta as their identity layer, this means the Okta-to-Entra ID integration that already governs Microsoft 365 access extends to cover model access as well, though the specifics of how that integration surfaces in model access policies is worth validating in any specific account.
Vertex's IAM integration follows Google Cloud's IAM model, which is structurally similar to AWS's but with different primitives. The integration with Google Workspace identity is present but less commonly the driver of platform selection than the data stack integration story.
Contract Vehicle Fit
This is the dimension that actually determines platform selection in most enterprise accounts, and it's the one that gets the least attention in technical comparisons.
An enterprise with an AWS Enterprise Agreement already has a procurement vehicle, a negotiated rate structure, a committed spend arrangement, and an established security review process for AWS services. Adding Bedrock to that footprint is an administrative decision. Establishing a new direct relationship with Anthropic is a procurement project: new vendor, new contract, new security review, new budget line.
The same logic applies to Azure and Google Cloud. The hyperscaler hosting layer exists, in large part, because enterprise procurement is not designed for the pace at which AI model vendors are emerging. The hyperscaler absorbs that complexity.
The cost of establishing a new vendor relationship is real, and the technical differences between hosted and direct model access are often marginal. Working from the existing contract is the sensible move. "We already have an AWS contract" is a complete explanation for platform selection in many accounts. It's not naivety about technical options; it's rational procurement behavior.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "AI cloud" | "hyperscaler hosting layer" | Buyers distinguish between cloud infrastructure and AI model access — conflating them creates confusion about what's being evaluated |
| "Bedrock is Amazon's AI" | "Bedrock is Amazon's multi-vendor model marketplace" | Amazon's own Nova models are one entry in a catalog that includes Anthropic, Meta, and others — the marketplace structure is the differentiating fact |
| "Azure OpenAI is Microsoft's model" | "Azure OpenAI is Microsoft's exclusive hosting arrangement with OpenAI" | The exclusivity is what matters; the models are OpenAI's, not Microsoft's |
| "Vertex is Google's AI platform" | "Vertex is Google's Gemini-centered platform with third-party model access through Model Garden" | Model Garden is where competitive models live; buyers need to know it exists and what's in it |
| "We can get you any model on any platform" | "Model availability is platform-specific — Claude is on Bedrock and Vertex, GPT-4o is Azure-exclusive" | Overpromising catalog availability in a discovery call creates a credibility problem when the buyer checks |
| "The models are the same everywhere" | "The model weights are the same; the data handling, IAM integration, and contract terms differ by platform" | Buyers who've done homework will push back on "same everywhere" — this framing is more precise and survives scrutiny |
| "You should switch to Bedrock for more model options" | "Bedrock has the broadest third-party catalog; the switching cost is your existing IAM and contract investment, not just the API endpoint" | Platform switching has procurement and integration costs that often exceed the value of catalog breadth |
| "What's the best platform?" | "Best for what? Model breadth, existing contract vehicle, or data stack integration — those point to different answers" | No platform is best overall; the question is which dimension the buyer is optimizing for |
| "Direct API is simpler" | "Direct lab access removes the hyperscaler layer; it also removes the IAM integration, data residency controls, and contract vehicle. That's the trade." | Buyers who ask about direct access are usually asking about cost; the full trade-off is what they need to hear |
| "They all support the same models" | "Anthropic's Claude appears on both Bedrock and Vertex; OpenAI's models are Azure-exclusive; that asymmetry matters in multi-cloud accounts" | The asymmetry is the fact that drives real platform decisions; naming it signals fluency |
Okta Concept Mapping: The Hyperscaler as Identity Broker
In SAML federation, an identity broker sits between an enterprise IdP and multiple service providers, translating trust across domain boundaries without requiring direct trust relationships between every SP and the IdP. A hyperscaler hosting layer works similarly: the enterprise's existing IAM trust relationship with AWS, Azure, or Google Cloud extends to cover AI model access, without requiring the enterprise to establish a separate identity relationship with Anthropic, OpenAI, or Google DeepMind directly. That's where the analogy holds. Where it breaks: an identity broker's job ends at authentication and authorization; a hyperscaler is simultaneously managing compute, data residency, network egress, and model access control, and the trust relationship is entangled with infrastructure in ways that a pure identity broker never is. In a buyer conversation, this means the question "how do we authenticate to the model?" is actually the easy part; the harder question is "what does the hyperscaler's IAM layer govern, and what falls outside it?" That second question is where an Okta conversation can open.
The model landscape will keep changing. New labs will emerge, existing labs will release new model families, and the catalog contents of all three platforms will look different six months from now than they do today. What won't change is the structural logic: enterprises route AI model access through hyperscalers because procurement vehicles, data residency requirements, and IAM integration are solved problems inside the hyperscaler relationship and open problems outside it. The platform choice is a procurement decision wearing a technical costume. Recognizing that is what lets you ask the right questions before the buyer has already decided.