When your public sector buyer mentions they're "evaluating AI platforms," the evaluation is usually over. They're figuring out how to run AI workloads inside a cloud contract their procurement office signed two years ago. The three platforms you'll encounter are Amazon Bedrock (AWS), Azure AI Foundry (Microsoft), and Vertex AI (Google Cloud). This piece profiles each one, maps them to the buyer contexts where they actually appear, and gives you field-ready language for Tuesday.
Why the Hyperscaler Layer Exists
Anthropic, OpenAI, and Google all sell model access directly. A developer can get an API key in minutes. So why would an agency route through AWS, Azure, or Google Cloud?
Procurement compliance, data residency, and integration with existing infrastructure. A federal buyer can't swipe a credit card for Claude API access. They need the model available inside a FedRAMP-authorized boundary, billed through an existing contract vehicle, governed by the IAM policies their security team already manages. The hyperscaler hosting layer solves all three at once.
The tradeoff is cost. Hyperscalers mark up model access over what you'd pay the lab directly. How much depends on the model, deployment type, and volume. Pricing mechanics are the next lesson. For now, know the markup exists and your buyer is paying it deliberately, because the compliance and procurement wrapper is worth more to them than the savings.
Amazon Bedrock
What it is: AWS's managed service for accessing foundation models (large AI models trained on broad data, used as a starting point for specific tasks) via API.
What it does: Gives developers a single API layer to invoke models from multiple providers: Anthropic's Claude, Meta's Llama, Mistral, Cohere, Amazon's own Nova, and as of April 2026, OpenAI's open-weight GPT models (per AWS's own service announcements). Pick a model, call the API, get a response. Bedrock also offers managed features on top of the model layer: Agents (autonomous task execution), Guardrails (output filtering), Knowledge Bases (connecting models to your data), and fine-tuning.
Who's behind it: Amazon Web Services. The models come from third-party providers, but AWS hosts them on its own infrastructure. Model providers have no access to customer data or deployment accounts (per AWS's data protection documentation). AWS deep-copies each model into isolated accounts after delivery.
What makes it distinct: The model-agnostic option. Bedrock is the only hyperscaler platform where you can access Claude, Llama, and Mistral through one API without leaving your AWS environment. If the buyer wants to test three models against the same use case without three different procurement vehicles, Bedrock is the natural fit.
Azure AI Foundry
What it is: Microsoft's platform for deploying and managing AI models within Azure, built around a deep OpenAI integration.
What it does: Provides access to OpenAI models (GPT-4.1, GPT-5, o-series reasoning models) as a first-party Azure service, plus a growing catalog of third-party and open-source models. Foundry handles deployment, scaling, content filtering, and fine-tuning. The OpenAI models run entirely within Azure's infrastructure. They do not interact with OpenAI's services (per Microsoft's data privacy documentation — this is the answer to "does my data go to OpenAI?").
Who's behind it: Microsoft, operating under an exclusive partnership with OpenAI. Azure is the only hyperscaler where you get OpenAI's proprietary models (GPT-5, o3) as a managed cloud service. Anthropic's Claude is also available in the Foundry catalog, but the OpenAI relationship is the headline.
What makes it distinct: The OpenAI exclusive. If the buyer's use case requires GPT-5 or o3 specifically, and they need it inside a FedRAMP-authorized boundary, Azure is the only path. Foundry also has the deepest classification-level coverage of any hyperscaler AI service: Azure Government holds FedRAMP High, DoD IL4/IL5 (Impact Levels governing increasingly sensitive unclassified data), and ICD 503 (Top Secret) authorization for AI model access (per Microsoft's Azure Government dev blog; the FedRAMP Marketplace entry for Azure Government is the primary verification source). No other hyperscaler has publicly documented Top Secret authorization for AI services.
Google Vertex AI
What it is: Google Cloud's AI platform for accessing Gemini and a broad catalog of open and third-party models.
What it does: Provides access to Google's Gemini model family, Anthropic's Claude, Meta's Llama, and over 200 models in its Model Garden (a browsable catalog of deployable models). Vertex AI handles inference (running a model against input to get output), fine-tuning, grounding (connecting model responses to external data sources), and evaluation. Google's approach to government compliance uses Assured Workloads — a software-defined compliance layer on top of standard Google Cloud infrastructure — rather than a physically separate government cloud.
Who's behind it: Google Cloud. Gemini models are Google's own. Third-party models are hosted on Google's infrastructure under Google's FedRAMP authorization (per Google Cloud's FedRAMP documentation).
What makes it distinct: Gemini-native with the broadest open-model catalog. Model Garden gives buyers access to more models than either competitor. If the buyer's workload benefits from model variety and the compliance coverage fits, Vertex AI offers the widest selection in one place.
All three platforms govern model access through their native cloud IAM layer: AWS IAM for Bedrock, Entra ID with RBAC for Azure AI Foundry, Google Cloud IAM for Vertex AI. None of them invented a separate identity plane for AI. An organization that has already federated Okta into their cloud provider's IAM has the mechanics in place to govern who can invoke which models. The AI access policy is an IAM policy — your instinct here is correct.
Which Platform for Which Buyer
I'm organizing this section by buyer context rather than feature comparison, because that matches how platform decisions actually get made in government. Nobody picks a hyperscaler AI platform on technical merit and then renegotiates their cloud contract to match. They pick the AI platform that runs inside the contract they already hold.
Three buyer contexts. Three conversations.
The AWS-First Agency
This buyer has GovCloud workloads, an existing JWCC task order or agency-level AWS contract, and an ops team that thinks in IAM roles and VPCs (Virtual Private Clouds — isolated network segments within AWS). They're going to use Bedrock. That part is settled. The part that's still open is which models, and whether the ones they want are available in GovCloud yet.
GovCloud model availability lags commercial regions (per AWS's own regional availability documentation). Claude 3.5 Sonnet, Llama 3, and the new OpenAI open-weight models are authorized. The latest frontier models are not. This lag is true across all three hyperscalers. If the buyer sounds frustrated about model availability, the right response is empathy. They're not switching clouds over it. They know this. They're planning around it.
Bedrock's strength here: model optionality within a single procurement vehicle. The buyer can test Claude and Llama side by side without a new contract.
The Microsoft-First Agency
This buyer has E5 licenses, Entra ID running their directory, Azure Government for their workloads, and probably a CISO who sleeps slightly better knowing Microsoft handles the compliance paperwork. They're going to use Azure AI Foundry.
In the field: this is the only path to OpenAI's proprietary models inside a government boundary. If the buyer's pilot was built on GPT-4 and they want to upgrade to GPT-5, Azure is it. The Top Secret (ICD 503) authorization also gives Azure a unique position for intelligence community and classified defense workloads. That claim comes from Microsoft's own Azure Government dev blog. For classified-environment conversations, the buyer's security team will want to verify against the actual authorization documentation.
Azure AI Foundry's identity story is the most enterprise-familiar of the three. Entra ID groups, RBAC roles with a clean control-plane/data-plane split (who can manage deployments vs. who can invoke models), and Conditional Access policies the buyer's security team already knows how to write. If the buyer says they're worried about "who can access the AI," they're describing a problem their existing Azure RBAC already solves.
The Google-First or Multi-Cloud Agency
Less common historically, but growing. The Navy awarded Google Cloud JWCC task orders in December 2025 (reported by ExecutiveGov, a federal contracting trade publication). Google holds positions on both JWCC and the CIA's C2E contract. A buyer here is either Google-native (rarer in federal, more common in SLED) or running a multi-cloud strategy where Vertex AI handles specific workloads.
Vertex AI's FedRAMP High authorization is solid, and Model Garden's catalog is the broadest of the three. Claude on Vertex AI was authorized for FedRAMP High and IL2 in October 2025 (per Anthropic's own announcement). The constraint is classification depth and export control. IL4/IL5 and ITAR (International Traffic in Arms Regulations, controlling defense-related technical data) coverage for Vertex AI generative models isn't there as of early 2026. If the buyer's workload touches ITAR-controlled data, Vertex AI can't serve the AI inference piece today, even if Google Cloud handles their other workloads fine.
The multi-cloud buyer is the most interesting conversation. They have workloads on two or three clouds and need to figure out where AI lives. Honestly, it usually lives wherever the data already lives, because moving data across cloud boundaries for inference creates latency, cost, and compliance headaches that nobody wants to own.
The multi-cloud buyer has the hardest identity problem: governing AI access consistently across platforms that each have their own IAM. This is structurally identical to the federation challenge Okta already solves for cloud applications. One identity provider, federated into AWS IAM, Entra ID, and Google Cloud IAM, enforcing consistent access policies regardless of which platform's models the user invokes. When the buyer says "we need governance across our AI platforms," they're describing a cross-cloud identity layer.
Data Residency in 30 Seconds
Every public sector AI conversation eventually hits "where does my data go?" The answers, drawn from official documentation:
Bedrock: Customer data stays in the AWS Region where the API call is processed. Not shared with model providers. Not used for training. AWS uses automated abuse detection with no human access to input or output data.
Azure AI Foundry: Customer data is not shared with OpenAI or other model providers. Not used for training without explicit permission. Abuse monitoring retains data up to 30 days by default, but Microsoft offers a "modified abuse monitoring" approval process that eliminates this retention for qualifying government workloads.
Vertex AI: Customer data is not used for training without permission. Data residency is configurable by region. A nuance worth flagging: Gemini models cache data in-memory (not at rest) with a 24-hour TTL for latency optimization. This is project-isolated and ephemeral, but it's a different posture than Bedrock's "no storage" claim. Also: if the buyer uses Grounding with Google Search (connecting model responses to public web results), Google retains prompts and outputs for 30 days with no opt-out. The workaround is Web Grounding for Enterprise, which doesn't carry that retention.
All three platforms offer private network connectivity (PrivateLink, Private Endpoint, VPC Service Controls) to keep inference traffic off the public internet. In a field conversation: all three keep your data in-region, none use it for training, and the differences are in abuse monitoring retention and caching behavior. Precise enough to survive a CISO's follow-up question.
OMB M-25-21 requires agencies to maintain AI governance structures, including use case inventories and oversight boards. The buyer's CAIO needs to answer "who accessed which model, when, and what did they do with it?" That's an audit question, and it maps to identity-layer logging that flows through each platform's IAM. When Okta is the federated identity source, the audit trail starts at the identity provider, not at the cloud platform. In a multi-cloud environment, that's a real governance advantage worth stating plainly when the CAIO is in the room.
How to Say This in the Field
| Don't say | Do say | Why it matters |
|---|---|---|
| "Bedrock is the best platform because it has the most models" | "Bedrock gives you model optionality inside your existing AWS contract. Claude, Llama, Mistral, all through one API." | Avoids a "best" claim; anchors to procurement reality |
| "Azure has GPT-5" | "Azure is the only FedRAMP-authorized path to OpenAI's proprietary models. GPT-5, o3, the reasoning models — all inside Azure Government." | Specificity signals you understand the exclusivity |
| "Vertex AI is behind" | "Vertex AI has FedRAMP High and the broadest model catalog, but doesn't cover ITAR workloads for AI inference yet." | Honest constraint without editorializing |
| "You should switch to Azure for AI" | "Which cloud is your primary contract vehicle? That's probably where your AI workloads will land." | Matches how the buyer actually makes the decision |
| "The data stays private" | "All three platforms contractually commit to not training on your data. Inference stays in-region. The differences are in abuse monitoring retention and caching." | Precise enough to survive a CISO's follow-up |
| "AI needs new identity infrastructure" | "Model access runs through the same IAM layer you already use. IAM roles on AWS, Entra ID RBAC on Azure, Cloud IAM on Google." | Demystifies AI governance; connects to what they know |
| "We're evaluating all three platforms" | "Which JWCC task orders does your agency hold? That usually narrows the field fast." | Shows you understand DOD procurement mechanics |
| "Google isn't a real player in government cloud" | "Google holds positions on JWCC and C2E. The Navy awarded them cloud task orders in December." | Factually current; avoids looking uninformed |
| "The frontier models are all available in GovCloud" | "GovCloud regions lag commercial on model availability. That's true across all three hyperscalers. Your buyer knows this and is planning around it." | Prevents overpromising; builds credibility |
| "AI governance is a new problem" | "M-25-21 requires your agency to have AI governance structures. The identity layer you already operate is how you enforce them." | Connects OMB policy to existing infrastructure |
The pattern across all ten rows: specificity over generality, procurement awareness over technical enthusiasm, honest constraints stated without apology. Your buyer lives inside contract vehicles and compliance boundaries. Meeting them there is the whole game. Next lesson: what the hyperscaler markup actually looks like, and how pricing works across these three platforms.
Things to follow up on...
-
JWCC Next reshapes the field: The Pentagon is preparing a successor to the current JWCC contract that would expand eligibility beyond the four current hyperscalers and potentially include third-party AI marketplaces, with a solicitation expected in 2026 and awards by early 2027.
-
Claude runs everywhere now: Anthropic's Claude is the only frontier model available on all three hyperscaler platforms (Bedrock, Azure AI Foundry, and Vertex AI), which makes it the default multi-cloud model option for agencies running hybrid architectures.
-
GovCloud model access has friction: Accessing Bedrock foundation models in AWS GovCloud requires initiating the request through a linked standard AWS account first, a cross-partition workflow that your AWS-heavy buyers will already be navigating.
-
Azure agents get their own identities: Every hosted agent deployed in Azure AI Foundry automatically receives its own dedicated Entra ID identity and endpoint, which gives administrators a way to inventory, audit, and apply policies to AI agents the same way they manage human users.

