Cloud AI platforms: Amazon Bedrock, Microsoft Foundry and Gemini Enterprise Agent Platform

0:00 Cloud AI platforms

If you work in a bank, a hospital, a government agency or a large enterprise, there's a good chance you won't call AI models directly from their makers. You'll go through your company's cloud: Amazon, Microsoft or Google. In this lesson you'll learn why, what each major cloud AI platform offers, what changed with their recent renaming, and how to decide which route fits each workload.

0:29 Why cloud platforms

Why do enterprises prefer cloud platforms? Contracts and billing through existing agreements. Identity and access through the cloud's own roles and managed identities, instead of static keys. Private networking, so traffic never crosses the public internet. Regional deployment for data residency. Centralized logging and governance. And a catalog of many vendors' models in one place. Think of buying through your company's approved supplier portal instead of a personal credit card. Slower sometimes, but procurement, security and finance are already happy.

1:04 The trade-offs

The trade offs are real, though. New models and features may arrive later than on first party APIs, some features may be missing, request shapes can differ, and prices and quotas are set by the platform. So the question is never just which model. It's which model, on which platform, with which features, in which region.

1:28 Amazon Bedrock

First, Amazon Bedrock. It hosts models from Anthropic, Meta, Mistral, Amazon, OpenAI and others. You can use its model agnostic Converse API, or newer Mantle endpoints that keep each provider's native request shape. The Anthropic SDK has a Bedrock Mantle client for Claude, and the OpenAI SDK has a Bedrock provider for OpenAI models hosted there. Separately, Anthropic offers Claude Platform on AWS, which is operated by Anthropic, uses AWS identity and billing, and matches the Claude API's features on the same day.

2:04 Microsoft Foundry

Second, Microsoft Foundry. It used to be called Azure AI Foundry and was renamed at Microsoft Ignite in November twenty twenty five. It offers Azure OpenAI models, plus Claude, Llama, Mistral and many others through its catalog. You authenticate with keys or Microsoft Entra ID, and it integrates with Azure networking, Key Vault, monitoring and content safety. Both the OpenAI and Anthropic SDKs have dedicated clients for it.

2:34 Gemini Enterprise Agent Platform

Third, Google's Gemini Enterprise Agent Platform, which was called Vertex AI until its renaming in twenty twenty six. Existing API endpoints keep working. It offers Gemini models plus partner and open models, including Claude, through its Model Garden. You authenticate with Google Cloud identity. The Google Gen AI SDK switches to it with an enterprise flag and your project and location, and the Anthropic SDK has a client for Claude on Google Cloud. It adds batch prediction from BigQuery or Cloud Storage, context caching and agent services.

3:12 Check quotas early

Here's a practical tip that saves real frustration: check quotas early. On cloud platforms, default quotas for a newly enabled model are often modest, and raising them can take a request and some waiting. Teams build a feature, test it happily with a few users, then launch and hit throttling on day one. Before launch, estimate your peak requests and tokens per minute, compare with your current quota in the platform console, and file increase requests well ahead of time, per model and per region.

3:49 Simple example: prototype → production

A simple example. A developer at a mid sized company already uses Claude through the first party API for prototypes. Their production team runs on Google Cloud. Moving the same feature into production is mostly a client swap: construct the Claude client for Google Cloud with the project and region, keep the same messages call, and confirm the model is available in that region. The lesson's code shows the same call on the first party API, on Bedrock and on Google Cloud side by side.

4:26 Choosing a route

How do you choose? Startups wanting the newest features fastest usually lean to first party APIs. Organizations with existing cloud agreements and identity standards lean to that cloud's platform. Strict data residency or private networking points to a platform with regional deployment and private endpoints. Multi vendor experimentation with one bill suits platform catalogs. And if you need a feature only the first party API has, use it, alongside the platform where appropriate. Many companies run both.

4:59 Business example: UAE bank

Now a realistic business example. A bank in the UAE wants a customer service assistant. Requirements: in region processing where available, private networking, bank wide identity, audit logs, and only approved vendors. It deploys through its existing cloud platform contract, with private endpoints and managed identities, so there are no API keys at all. It enables the platform's guardrail and logging services. And it keeps a small first party sandbox, using only synthetic data, to evaluate new models before they reach the platform. Compliance signs off faster because the platform is already approved.

5:39 Common mistakes

Common mistakes. Assuming every first party feature exists on the platform. Hard coding platform specific model ids throughout your code. Forgetting quotas, which are often lower by default on platforms and need requests to raise. And mixing platforms without clear rules about which data class may go where.

6:00 Keep a feature matrix

One more habit for platform users: keep a living feature matrix. For each model you use, list which platforms and regions it's on, and whether the features you rely on, like structured outputs, prompt caching, batch, citations or server side tools, are available there. Update it when providers announce changes. It sounds like paperwork, but it prevents the classic surprise where a feature works perfectly in the prototype on the first party API, then turns out to be missing in the production region.

6:36 Deeper: the bank's second assistant

Let's deepen the UAE bank example. The bank's first AI assistant took months to approve, mainly because the security team had to assess a new vendor from scratch. For the second, they used their existing cloud platform, where the model provider was already on the approved list, identity came from managed identities, and traffic used private endpoints. The assessment focused only on the new use case: what data, which model, what guardrails. Approval took weeks rather than months, illustrative again. They still keep a first party sandbox with synthetic data for trying new models early, and move a model into production only once it appears in their platform region.

7:23 Watch me do it: one call, three routes

Watch me do it. Let's walk through the same Claude call on three routes. The prompt is one user message asking for a two sentence policy summary. Route one, the first party API: the default client reads a key or workload identity, and I pass the bare model id. Route two, Amazon Bedrock through the Mantle client: I pass the AWS region, and the model id carries the anthropic dot prefix; credentials come from the AWS chain, so there's no Anthropic key. Route three, Google Cloud: the Vertex client takes my project id and a region such as global, uses application default credentials, and takes the bare model id. In every case, the messages create call is identical. That's the point: moving a workload between routes is mostly constructor and model id changes. Before switching, I check the platform's model list for my region and whether features I use, like batch or caching options, are available there.

8:31 Recap + try this now

Quick recap. Cloud platforms wrap models in enterprise contracts, identity, networking, residency and governance. Bedrock, Microsoft Foundry and Gemini Enterprise Agent Platform all host many vendors' models, including Claude, and two of them were recently renamed. Features, ids and quotas differ, so verify, and consider using both first party and platform routes. Try this now: map your cloud agreements, residency needs and required features, decide which workloads go where, and make one test call through your chosen platform.