When a CAIO says "we're evaluating foundation models," they usually mean they're evaluating which hyperscaler's AI hosting platform to standardize on. Those are different conversations, and conflating them costs you the room. The three platforms in play are AWS Bedrock, Azure OpenAI Service, and Google Vertex AI. You'll encounter them in discovery calls, in RFIs, and in the phrase "we're already on [cloud]," which more often than not ends the model selection conversation before it starts.
The frame that matters: for most enterprise and public sector accounts, the cloud contract came first. The AI platform follows the contract. Technical merit is a distant second, and in federal accounts where cloud infrastructure is locked to an existing IDIQ or BPA, it may not be a factor at all.
The Profiles
AWS Bedrock
What it is: A managed API service that hosts foundation models from multiple vendors inside the AWS environment.
What it does: Bedrock gives AWS customers access to a catalog of models (Anthropic's Claude family, Meta's Llama series, Mistral, Cohere, AI21 Labs, and Amazon's own Titan models, among others) through a unified API surface. The customer doesn't manage model infrastructure. They call an endpoint, pay for usage, and the model runs inside AWS's network boundary. Bedrock also includes tooling for fine-tuning, retrieval-augmented generation, and agent orchestration through a feature set called Bedrock Agents.
Who's behind it: Amazon Web Services. The model vendors are third parties with commercial agreements with AWS; they don't operate the infrastructure. Amazon holds the data residency and security posture.
What makes it distinct: Breadth. Bedrock is the closest thing to a model marketplace among the three platforms. An organization that wants optionality, the ability to run Claude for one workload and Llama for another under a single cloud billing relationship, gets that here. Whether that optionality is operationally useful or just theoretically appealing is a question worth asking in discovery.
Azure OpenAI Service
What it is: A managed API service that hosts OpenAI models inside the Azure environment, under Microsoft's enterprise terms.
What it does: Azure OpenAI gives Azure customers access to OpenAI's model family — GPT-4o, the o1 and o3 reasoning series, DALL-E, Whisper, and embedding models — through Azure's infrastructure, with Azure's data handling commitments and Azure's IAM surface. The models are the same models available through OpenAI's API directly, but the hosting relationship is different: data doesn't leave Azure, the contract is with Microsoft, and access is governed through Azure Active Directory (now Entra ID) rather than OpenAI's own credential system.
Microsoft has expanded the platform through Azure AI Foundry, which adds access to some third-party models including Meta's Llama series. The core identity of the platform, however, remains OpenAI-first. When buyers say "Azure OpenAI," they mean GPT-4-class models under Microsoft's enterprise wrapper.
Who's behind it: Microsoft, with OpenAI as the exclusive primary model vendor. The partnership gives Microsoft first-party distribution rights for OpenAI's commercial models.
What makes it distinct: Enterprise trust transfer. Organizations that have spent years building compliance posture on Azure — FedRAMP authorizations, data classification frameworks, Entra ID integrations — get to extend that posture to AI without re-litigating the security review. The model is new; the trust relationship isn't. That's a meaningful procurement advantage in accounts where the security review cycle is measured in quarters.
Google Vertex AI
What it is: Google Cloud's managed AI platform, centered on the Gemini model family with access to selected third-party models through a feature called Model Garden.
What it does: Vertex AI is Google's unified platform for building and deploying AI applications. At the foundation model layer, it provides access to the Gemini family (Gemini 2.0 Flash, Gemini 1.5 Pro, and the broader Gemini lineup) plus third-party models including Anthropic's Claude and Meta's Llama through Model Garden. Vertex also includes MLOps tooling, vector search, and agent-building infrastructure that Google has positioned as a full AI development environment rather than just a model API.
Who's behind it: Google Cloud. Gemini models are first-party; third-party model availability through Model Garden is governed by individual partnership agreements and may not match the breadth of Bedrock's catalog.
What makes it distinct: Gemini integration depth. Organizations already running Google Workspace, BigQuery, or Google Cloud infrastructure get native integration between Vertex AI and their existing data and productivity layers. Gemini's multimodal capabilities, handling text, images, audio, and video in a single model, are accessible through Vertex in ways that don't require stitching together separate model calls. For accounts where Google Cloud is the primary cloud, Vertex is the natural landing spot.
Comparison: What Actually Drives Selection
The comparison structure here is trait-led: five dimensions that surface in real enterprise selection decisions, with all three platforms on each. No ranking follows. Better requires a circumstance.
Cloud Contract Alignment
This is the dominant driver. In enterprise accounts, AI platform selection follows the existing cloud relationship roughly 70-80% of the time. In federal accounts with active cloud contracts, the number is higher, because the alternative is a new procurement action.
Bedrock wins when AWS is the primary cloud. AWS's market share in enterprise and federal infrastructure means a plurality of accounts arrive at Bedrock by default.
Azure OpenAI wins when Microsoft is the primary cloud relationship. This is particularly common in organizations that standardized on Microsoft 365 and Azure before the AI conversation started, which describes a large fraction of mid-market and public sector accounts.
Vertex AI wins when Google Cloud is the primary cloud. Google's enterprise cloud share is smaller than AWS or Azure, but in accounts where it's the primary platform, particularly organizations that went deep on Google Workspace or BigQuery, Vertex is the natural landing spot.
Before you get into model capabilities, find out which cloud the account is on. That conversation takes thirty seconds and tells you which platform you're actually selling into.
Model Catalog Breadth
Bedrock has the broadest third-party catalog by design. The marketplace model means AWS has commercial relationships with multiple model vendors simultaneously, and customers can switch between them under a single billing relationship.
Azure OpenAI is OpenAI-first, with expanding third-party access through Azure AI Foundry. If the buyer's requirement is specifically GPT-4-class models under enterprise terms, Azure OpenAI is the only place to get that. If the buyer wants model optionality, the catalog is narrower than Bedrock.
Vertex AI sits between the two. Model Garden provides access to third-party models including Claude and Llama, but the platform's center of gravity is Gemini. Organizations that want Gemini's multimodal capabilities or Google's first-party models have no equivalent option on the other platforms.
Catalog breadth matters most when the buyer hasn't committed to a specific model family. Once they say "we're evaluating Claude" or "we need GPT-4o," the catalog question collapses into a hosting question.
IAM Integration Surface
All three platforms integrate with their respective cloud IAM systems. IAM integration is a cloud differentiator, not a platform differentiator.
Bedrock uses AWS IAM roles and resource-based policies. Access to model endpoints is governed by IAM policies attached to roles, with VPC endpoint support for network-level isolation.
Azure OpenAI uses Azure Entra ID managed identities and role-based access control. For organizations with mature Entra ID deployments, this means AI model access can be governed through the same identity infrastructure that governs everything else in Azure.
Vertex AI uses Google Cloud IAM with service accounts and Workload Identity Federation for cross-environment access.
An organization's existing cloud IAM maturity transfers directly to the AI platform. An account with a sophisticated Entra ID deployment gets more immediate governance capability on Azure OpenAI than it would starting fresh on Bedrock, and vice versa.
Data Residency Controls
All three platforms offer regional deployment options that allow organizations to specify where model inference occurs and where data is processed. The specifics vary by region availability and by whether the organization needs government-specific cloud regions.
Bedrock in AWS GovCloud (US) is available for federal workloads requiring FedRAMP High authorization. [Flag for accuracy review: specific FedRAMP authorization status for individual Bedrock model endpoints changes as new models are added; verify current status before citing in a buyer conversation.]
Azure OpenAI in Azure Government is similarly positioned for federal requirements, with the added consideration that Microsoft's enterprise compliance commitments, including data processing agreements and audit rights, extend to the AI layer.
Vertex AI through Google Cloud's public sector offerings (AWS GovCloud, Azure Government, Google Cloud's public sector offerings) provides comparable regional controls, with Google's compliance posture extending to Vertex workloads.
Data residency is a requirement, not a differentiator. All three platforms can satisfy it for most enterprise use cases. The question is whether the organization's existing cloud compliance posture already covers the AI platform, or whether a new compliance review is required.
Operational Familiarity
This is underweighted in technical evaluations and overweighted in actual decisions.
The team that manages the organization's cloud infrastructure already knows one of these platforms. They know its IAM model, its networking constructs, its monitoring and logging patterns. Introducing AI workloads on the same platform means the operational model is familiar. Introducing them on a different platform means a new operational learning curve, new tooling, and new support relationships.
Bedrock benefits when the operations team is AWS-native. The same CloudWatch, CloudTrail, and IAM patterns they use for everything else apply to AI workloads.
Azure OpenAI benefits when the operations team is Azure-native. Azure Monitor, Entra ID, and Azure Policy extend naturally to AI workloads.
Vertex AI benefits when the operations team is Google Cloud-native. Cloud Logging, Cloud IAM, and Google's operations suite apply without modification.
When a buyer says "we want to evaluate all three," operational familiarity will likely determine the outcome. The platform that fits the existing operational model will win the internal evaluation, because the team running it will be more confident in their assessment of it.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "ChatGPT" when referring to Azure OpenAI | "Azure OpenAI Service" or "GPT-4 hosted on Azure" | ChatGPT is a consumer product; Azure OpenAI is an enterprise API — buyers hear the distinction immediately |
| "The best model for your use case" | "Which cloud are you primarily on?" | Model selection follows cloud contract; leading with model capability skips the actual decision |
| "Bedrock is Amazon's AI" | "Bedrock is AWS's platform for hosting multiple vendors' models" | Bedrock doesn't make models; conflating the platform with the models signals unfamiliarity |
| "Vertex is Google's ChatGPT" | "Vertex AI is Google Cloud's platform for Gemini and other foundation models" | The ChatGPT comparison is a consumer frame; it doesn't land with enterprise buyers |
| "You can use any model on any platform" | "Model availability varies by platform; Claude is on Bedrock and Vertex, GPT-4 is Azure-only" | Overstating portability creates credibility problems when the buyer checks |
| "Azure OpenAI is the same as OpenAI" | "Azure OpenAI hosts OpenAI's models under Microsoft's enterprise terms — different contract, different data handling" | The distinction matters for compliance-sensitive buyers; missing it signals you don't understand the procurement layer |
| "It depends on the model" | "It usually depends on which cloud you're already contracted with" | Reframes the conversation to the actual driver; buyers with existing cloud contracts respond to this immediately |
| "We support all three platforms" | "We integrate with whichever platform your cloud contract is on — which one is that?" | Turns a generic claim into a discovery question; positions you as someone who understands their environment |
| "Gemini is Google's answer to GPT-4" | "Gemini is Google's foundation model family, available through Vertex AI" | The competitive framing is reductive and sounds like marketing; buyers want architecture, not positioning |
| "You should evaluate all three" | "Most organizations land on the platform that matches their existing cloud contract; is that already decided?" | Saves everyone time; if the cloud contract is decided, the platform evaluation is largely done |
| "The model runs in the cloud" | "The model runs inside [AWS/Azure/Google Cloud]'s network boundary, under your existing cloud data handling terms" | Data residency and network boundary are the actual enterprise concerns; "the cloud" is too vague to be useful |
Okta Concept Mapping
The analog: Managed identities and service accounts.
Each hyperscaler platform uses its cloud-native non-human credential system to govern access to model endpoints: IAM roles on Bedrock, Entra ID managed identities on Azure OpenAI, service accounts on Vertex AI. This maps cleanly to the machine-to-machine credential pattern Okta handles — non-human identity lifecycle, scoped access, credential rotation. Where the analogy holds: the trust delegation model is structurally similar. A service calls a model endpoint using a credential scoped to that purpose, with a defined lifetime and revocation path. Where it breaks: cloud managed identities are scoped to the cloud control plane. They don't carry enterprise identity context into the model call itself — the model has no visibility into which human user, with which enterprise attributes, is driving the request. The cloud IAM layer authenticates the service; it doesn't authorize the person behind the service. That gap is where enterprise identity governance of AI workloads actually lives, and it's not solved by any of the three platforms natively.