Amazon Bedrock vs Vertex AI vs Microsoft Foundry in 2026: Which Cloud AI Platform for Your SaaS?

Summary

If you are adding generative AI to a SaaS product in 2026, there is a good chance your first serious architecture decision is not "which model?" but "which cloud AI platform?". Amazon Bedrock, Google's Vertex AI (now sold as part of the Gemini Enterprise Agent Platform) and Microsoft Foundry (formerly Azure AI Foundry) all give you managed access to frontier models, retrieval, guardrails and agent runtimes behind your cloud account's identity, billing and compliance controls.

The short answer: build where your data, identity and cloud commitments already live, and keep a thin abstraction layer so you can switch models later. The model catalogues now overlap heavily (all three offer Anthropic's Claude models, for example), so the real differences are the agent runtime, governance, data-residency options, pricing levers and how much of your code ends up tied to one vendor. This guide walks through those differences from the point of view of a team actually shipping a product, with code you can adapt.

Why use a cloud AI platform at all?

You can always call a model provider's own API directly, and for an early prototype that is often the fastest route. Teams move to a hyperscaler platform once one or more of these become true:

• Procurement and billing: AI spend can go on the existing AWS, Google Cloud or Azure bill and count towards committed-spend agreements, instead of onboarding a new vendor.
• Security review: customer data stays inside a cloud account your security team already audits, with IAM roles, private networking, encryption keys and audit logs they understand.
• Data residency: enterprise customers in the EU, UK or Australia ask where prompts are processed. The platforms offer regional or geography-scoped deployment options that a direct API may not.
• Model choice: one API and one contract give you access to several model families, so you can route cheap tasks to small models and hard tasks to frontier ones.
• Managed building blocks: knowledge bases for RAG, content guardrails, agent hosting, evaluation and observability are available as services rather than things you build and run yourself.

If none of those apply yet, starting with a direct provider API is perfectly reasonable. A cloud platform can come later, especially if you design for it from day one (see the abstraction layer section below).

Bedrock vs Vertex AI vs Microsoft Foundry at a glance

Product names in this space change often (two of the three platforms were rebranded within the last year), so always confirm current feature and region availability in the official docs before committing.

Amazon Bedrock: the multi-model choice for AWS products

Where it shines

Bedrock's biggest strength is breadth. If your application already runs on AWS (ECS, Lambda, EKS, RDS, S3), Bedrock lets you call many model families through a single, consistent API, the Converse API, using the same IAM roles your services already have. You can swap a model by changing an ID rather than rewriting an integration.

AgentCore is the other big draw for 2026. It hosts agents written in whatever framework you prefer and adds managed memory, identity, a tool gateway (including MCP support) and observability. If your team has already built an agent with LangGraph or CrewAI, AgentCore lets you run it in production without a rewrite.

Things to watch

• Not every model is available in every region, and some of the newest third-party models are only offered through cross-region inference. Check this early if you promise EU-only processing.
• A wide catalogue makes it tempting to use five models where two would do. Each extra model adds evaluation, prompt maintenance and monitoring work.
• Default service quotas (tokens per minute) can be low for new accounts. Request increases well before launch.

A minimal Bedrock call in Python

import boto3, os

client = boto3.client("bedrock-runtime", region_name="eu-west-1")

response = client.converse(
    modelId=os.environ["BEDROCK_MODEL_ID"],  # e.g. a Claude or Nova model/inference profile ID
    messages=[{"role": "user", "content": [{"text": "Summarise this support ticket: ..."}]}],
    inferenceConfig={"maxTokens": 512, "temperature": 0.2},
)

print(response["output"]["message"]["content"][0]["text"])
print(response["usage"])  # input/output token counts for cost tracking

Google Vertex AI and the Gemini Enterprise Agent Platform

Where it shines

Google is the only one of the three with its own frontier model family, Gemini, offered as a managed first-party service. If your use case is multimodal (documents, images, audio, video), relies on very long context, or needs grounding in Google Search or your own BigQuery data, Vertex AI is usually the most natural fit. Data teams already using BigQuery get a short path from warehouse to AI feature.

On the agent side, Google's open-source Agent Development Kit (ADK) and its support for the Agent2Agent (A2A) protocol give you a code-first, fairly open way to build multi-agent systems, deployed onto Google's managed agent runtime.

Things to watch

• Google's documentation is explicit that the global endpoint does not guarantee in-region processing. If you have residency requirements, use regional or US/EU multi-region endpoints.
• Claude and other partner models are available, but the platform is clearly optimised around Gemini. Avoid a strategy that silently assumes one model for everything.
• Branding is in flux (Vertex AI features are being folded into the Gemini Enterprise Agent Platform), so internal docs and Terraform modules may reference older names.

A minimal Vertex AI call in Python

import os
from google import genai

client = genai.Client(
    vertexai=True,
    project=os.environ["GCP_PROJECT"],
    location="europe-west1",  # pick a region, not "global", if residency matters
)

resp = client.models.generate_content(
    model=os.environ["VERTEX_MODEL_ID"],  # e.g. a Gemini model ID
    contents="Extract the invoice number and total from this text: ...",
)

print(resp.text)
print(resp.usage_metadata)

Microsoft Foundry: the Microsoft 365 and OpenAI-first choice

Where it shines

If your customers live in Microsoft 365, your staff sign in with Entra ID, and your security team audits everything through Azure policies, Foundry is hard to beat. You get the deepest integration with OpenAI's models, enterprise identity for agents, and a direct path to publishing agents into Teams and Microsoft Copilot experiences. For B2B products sold into large UK and EU enterprises that are already Microsoft-centric, this alignment can shorten security reviews considerably.

Foundry's deployment types also make processing location explicit: Global deployments can run in any Azure region, Data Zone deployments keep processing within a zone such as the EU or US, and regional deployments keep it within a single Azure geography.

Things to watch

• Some partner models are purchased through Azure Marketplace on the provider's own terms, which can complicate contracts and billing.
• Capacity for the most popular models can be tight in some regions. Plan quota and, for steady high-volume workloads, consider provisioned throughput.
• There is a lot of overlapping tooling (Foundry, Azure OpenAI, Copilot Studio, Azure AI Search). Decide early which pieces you will actually use.

A minimal Foundry / Azure OpenAI call in Python

import os
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import AzureOpenAI

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://cognitiveservices.azure.com/.default"
)

client = AzureOpenAI(
    azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
    azure_ad_token_provider=token_provider,  # keyless auth via Entra ID
    api_version=os.environ["AZURE_OPENAI_API_VERSION"],
)

resp = client.chat.completions.create(
    model=os.environ["AZURE_DEPLOYMENT_NAME"],  # your deployment name, not the raw model name
    messages=[{"role": "user", "content": "Draft a polite reply to this customer email: ..."}],
)

print(resp.choices[0].message.content)

How pricing really compares

List prices per million tokens change frequently and vary by model and region, so we will not quote numbers here. What matters more for a SaaS budget is the set of pricing levers each platform gives you:

• On-demand per-token pricing on all three, which is right for most early-stage products.
• Batch processing at a significant discount (commonly around half price) for work that can wait hours, such as nightly document classification or bulk embedding.
• Cheaper "flex" and faster "priority" tiers on some platforms, letting you trade latency for cost.
• Provisioned or reserved throughput for predictable, high-volume traffic where guaranteed capacity matters more than per-token price.
• Prompt caching for long, repeated system prompts or documents, which can cut input-token costs sharply on supported models.

In practice, the biggest savings rarely come from choosing one cloud over another. They come from routing simple tasks to small models, caching, trimming context, and batching background work. We covered this in detail in our guide to reducing LLM API costs for SaaS products. Remember to budget for the surrounding services too: vector search, agent runtime compute, logging and data egress.

Design for portability: a thin model gateway

Whichever platform you choose, do not scatter vendor SDK calls across your codebase. Put a small interface between your business logic and the model provider. It makes testing easier, lets you run evaluations across platforms, and keeps a future migration measured in days rather than months.

Here is a simple version in Laravel:

<?php

namespace App\AI;

interface LlmClient
{
    /** @param array<int, array{role: string, content: string}> $messages */
    public function chat(array $messages, array $options = []): LlmResponse;
}

final class LlmResponse
{
    public function __construct(
        public readonly string $text,
        public readonly int $inputTokens,
        public readonly int $outputTokens,
        public readonly string $provider,
        public readonly string $model,
    ) {}
}

// app/Providers/AppServiceProvider.php
public function register(): void
{
    $this->app->bind(LlmClient::class, fn () => match (config('ai.provider')) {
        'bedrock' => new BedrockClient(config('ai.bedrock')),
        'vertex'  => new VertexClient(config('ai.vertex')),
        'foundry' => new FoundryClient(config('ai.foundry')),
    });
}

Each adapter translates to its platform's API and returns the same LlmResponse, including token usage so you can track cost per tenant and per feature. The same pattern works in Node.js with a TypeScript interface. For more on structuring AI features inside an existing product, see how to integrate AI into a Laravel or Node.js app.

Two other portability habits pay off:

• Keep prompts and evaluation sets in version control, independent of any vendor console, so you can rerun the same tests on another platform.
• Prefer open protocols for tools and agents, such as MCP for tool access. All three platforms now support MCP in some form, so tools you expose once can be reused. Our guide to building an MCP server for your SaaS shows how.

A practical decision framework

When we help clients choose, we work through these questions in order:

1. Where does your product and its data already run? Moving terabytes of customer data across clouds for an AI feature adds cost, latency and compliance work. This answer usually decides the platform on its own.
2. What do your customers' security teams expect? Microsoft-centric enterprises often prefer Azure; data-heavy analytics customers may already be on Google Cloud; many SaaS buyers simply want to know data stays in AWS in their region.
3. Which models perform best on your actual tasks? Build a small evaluation set (50 to 200 real examples) and test two or three candidate models. Do not rely on public benchmarks alone.
4. Do you need managed agents, or just model calls? If you are building multi-step agents, compare AgentCore, Google's ADK and runtime, and Foundry Agent Service against simply running your own framework in containers.
5. What residency guarantees can you offer? Confirm the specific model is available in the specific region or data zone you need, not just that the platform operates there.

Rules of thumb that hold up well:

• AWS-native product, want wide model choice and a framework-agnostic agent host: start with Bedrock.
• Google Cloud or BigQuery data, multimodal or Gemini-centred use case: start with Vertex AI.
• Microsoft 365 / Entra customers, OpenAI-first, agents inside Teams: start with Microsoft Foundry.
• Early prototype with no cloud constraints: a direct provider API is fine, as long as it sits behind your own interface.

Common mistakes we see

• Choosing a platform by model hype. Model leadership changes every few months; your cloud estate does not.
• Ignoring quotas until launch day. Throttling errors under real traffic are a common cause of failed AI launches.
• No per-tenant cost tracking. Without token accounting per customer, one heavy user can quietly erase your margin.
• Skipping guardrails and prompt-injection testing. Managed guardrails help, but you still need input validation, output checks and least-privilege tool access.
• Hard-coding one SDK everywhere. It turns a future model or platform change into a large refactor.

FAQ

Is Amazon Bedrock better than Vertex AI?

Neither is better in general. Bedrock usually wins for AWS-hosted products that want many model vendors behind one API; Vertex AI usually wins for Google Cloud teams and Gemini-centred, multimodal or BigQuery-heavy use cases.

Can I use Claude on all three platforms?

Yes. Anthropic's Claude models are offered on Amazon Bedrock, Google's Vertex AI and Microsoft Foundry, although model versions and regions differ, so check availability for your region.

Is it cheaper to use a cloud platform than the model provider's own API?

Per-token list prices are often similar. Savings come from batch and flex tiers, provisioned throughput, prompt caching and existing cloud commitments, while extra services like vector search add cost.

Which platform is best for GDPR and EU data residency?

All three can keep processing in the EU when configured with EU regions, data zones or multi-region endpoints, but not every model is available everywhere, so verify per model.

Do I need a cloud AI platform to add AI to my SaaS?

No. Many products start with a direct provider API. A cloud platform becomes valuable when security reviews, residency, consolidated billing or managed RAG and agents matter.

How hard is it to switch platforms later?

If model calls sit behind your own interface and prompts and evaluations live in your repository, switching is mostly adapter work plus re-testing.