AWS Bedrock vs. Azure AI Foundry vs. Google Vertex AI

The useful question about AWS Bedrock, Azure AI Foundry and Google Vertex AI isn't which one has the strongest model this quarter. Model quality changes fast, the three catalogues overlap heavily, and any serious application usually ends up calling more than one model anyway. The real decision is which control plane best fits the systems that already own your identity, data, networking, observability and operational responsibility — because moving a prompt between providers is trivial, and recreating everything around that prompt is not.

The platform is part of the architecture

Treat these three products as application platforms, not interchangeable model endpoints. Moving a prompt from one to another takes minutes. Recreating the IAM or Entra permission boundaries, the retrieval pipeline, tool authorization, audit trails, private connectivity, evaluation jobs and deployment workflows built around that prompt does not.

AWS Bedrock fits most naturally when an application already lives inside AWS and its operational model already runs on IAM, VPCs, CloudWatch, CloudTrail, S3 and AWS-native data services. Its Knowledge Bases feature can manage ingestion, indexing, retrieval and connectors to sources like SharePoint, Confluence, Google Drive and OneDrive, with document-level access controls for the connectors that support them.

Azure AI Foundry — now renamed to Microsoft Foundry — is strongest where Entra identity, Azure AI Search, Microsoft 365 content and Azure networking already form the enterprise substrate. Its Agent Service lets teams choose declarative prompt agents or deploy their own containerized hosted agents while keeping a managed endpoint, session state, identity, tools, scaling and tracing — which matters when an agent needs to act as an enterprise principal rather than just call a model.

Google Vertex AI is the most natural extension for an organization already running Google Cloud for data, ML and analytics, combining generative AI with the broader Vertex ML platform while Model Garden exposes Google's own models alongside selected open and third-party ones. Its strongest argument is rarely "use Gemini everywhere" so much as "keep AI applications close to the data, evaluation and ML operations already established in GCP."

Model choice is a deliberate layer, not a shopping list

All three platforms support a multi-model strategy, but their catalogues are better read as deployment contracts than shopping lists. A given model's availability can vary by region, account configuration, quota, provider terms and feature surface — AWS makes that explicit, since third-party model access on Bedrock can involve Marketplace permissions, provider-specific onboarding and license acceptance that needs review before production use.

That matters because model selection is rarely a one-time decision. Teams routinely mix a lower-cost model for extraction, a stronger one for complex reasoning, a dedicated embedding model for retrieval and a specialist multimodal model for documents or images — and the platform needs to make those choices governable without forcing every application team to rebuild authentication, quotas, logging and data handling from scratch.

Bedrock is appealing when that optionality needs to coexist with AWS account-level controls. Azure AI Foundry fits when model access needs to sit alongside Azure OpenAI and Entra-governed enterprise tools. Vertex AI works especially well when Gemini's native multimodality or long-context capability fits the workload while Model Garden preserves room for other models. Here's the line worth not crossing: building a thin, portable interface over inference, structured outputs, embeddings and tool calls is sensible engineering — it keeps the application code from being welded to one vendor. Assuming that everything underneath that interface behaves the same way across providers is not: tokenization, safety behavior, context limits, latency and regional availability all differ by platform, and a portable interface only hides those differences from the application, it doesn't make them go away.

Retrieval is an authorization problem before it's a RAG problem

Most enterprise AI applications fail in retrieval before they fail in prompting, and the hard part was never splitting files into chunks. It's ensuring a response respects the same permissions, retention rules, provenance and incident boundaries as the systems it's retrieving from.

Bedrock's managed Knowledge Bases reduce the operational work around ingestion and retrieval, but that convenience shouldn't obscure the architecture underneath: teams still need to decide how source permissions are synchronized, how chunking is governed, and whether retrieval quality is measurable against representative questions. Azure AI Foundry is often the easier fit where the authorization model already runs on Entra identities and the knowledge estate is dominated by Azure and Microsoft 365 resources — the integration work doesn't disappear, it changes shape, from building a parallel access-control plane to mapping enterprise identity into an agent workflow. Vertex AI is particularly credible where operational data already lives in BigQuery, Cloud Storage or Cloud SQL, and its agent runtime supports VPC Service Controls so a deployed agent can keep access to Google services inside a defined security perimeter.

The practical test that applies across all three: can the platform enforce source permissions at retrieval time, show why a document was retrieved, evaluate whether it improved the answer, and isolate a faulty corpus without taking the whole application down? If not, the RAG system is still a prototype, whichever cloud it's running on.

Managed agents reduce infrastructure, never accountability

Agent platforms earn their keep when an application needs state, tool execution, retrieval, policy enforcement and lifecycle management wrapped around model calls — they are not a substitute for application design. An agent that can touch production systems still needs the same threat modeling, authorization boundaries, idempotency, auditability, rollback behavior and rate limiting as any other piece of automation.

Bedrock Agents provide a managed path for combining models, knowledge bases and action groups, with AWS handling much of the orchestration while teams configure the actions, prompts, testing and versioning. Azure AI Foundry has the clearest split between prompt-defined agents and hosted code-based agents, making it a strong option when an application starts simple and eventually needs custom orchestration or a specific runtime. Vertex AI's Agent Engine is most compelling when agent execution belongs next to an existing GCP data or ML workflow, and its evaluation surface can check whether an agent actually completes defined tasks against a dataset — more useful than judging a demo conversation by how it "feels."

The sensible default across all three is usually modest: start with deterministic application code around model calls, add tools with least-privilege credentials, and reach for autonomous planning only where it demonstrably improves the workflow.

Safety, observability and the actual decision

Safety on any of these platforms has to be designed into the whole request path, not bolted onto the final answer — a policy that only screens the output leaves retrieval and tool execution exposed to a different set of failures entirely. Bedrock Guardrails can be applied across inference, agents, knowledge bases and flows so policy enforcement is reusable rather than duplicated per use case. Azure AI Foundry's advantage is how naturally its safety and agent controls connect to Entra identities, Azure RBAC and private networking, at the cost of the operational complexity that comes with private DNS, endpoint approval and role assignments. Vertex AI gives GCP organizations familiar primitives — IAM, data residency controls, Access Transparency, VPC Service Controls — with the important caveat that those constrain the platform boundary without making an unsafe prompt or an overly broad tool automatically safe; that responsibility still sits with the application.

The same logic carries into observability. A demo proves a model can answer a prompt, but a production service needs to answer which model version handled a given request, which documents it retrieved, what a failure would cost to reproduce, and whether latency regressed after the last change. CloudWatch, Application Insights and Vertex's own monitoring can each support those questions, but none of them replace the need for a retained evaluation set built and tested before the first production rollout.

Put together, the decision usually follows the cloud boundary an organization already operates. Choose Bedrock when the service lives primarily in AWS and the team wants multi-model access without standing up a separate AI platform. Choose Azure AI Foundry when Microsoft identity and enterprise workflow are the most important integration point. Choose Vertex AI when the application belongs next to an existing GCP data and ML estate. For a genuinely multi-cloud organization, the more durable answer is often a small provider-neutral application layer with one primary platform chosen for identity, retrieval, telemetry and operations — preserving an exit path without spreading responsibility across three incomplete implementations.

The platform that wins this decision is whichever one makes the production system easier to reason about when something breaks. One that improves model access while fragmenting identity, governance and incident response hasn't removed complexity — it's just moved it somewhere less visible.