Lesson 3.4
Bedrock, Vertex AI and Foundry
When to consume Claude through Amazon Bedrock, Google Vertex AI or Microsoft Foundry instead of the Claude API directly, how each differs in identity, billing and features, and how to design for feature parity gaps.
Enterprises rarely choose a model platform on model quality alone. Existing cloud commitments, procurement, identity, data governance and residency obligations often decide where Claude is consumed. Claude is available through Amazon Bedrock, Google Cloud Vertex AI and Microsoft Foundry as well as directly from Anthropic. The exam expects you to know what changes when you go through a cloud platform and what does not.
Why go through a cloud platform
| Driver | What the cloud platform provides |
|---|---|
| Procurement and billing | Spend against existing cloud commitments and invoices |
| Identity | Native IAM: AWS roles and policies, Google service accounts, Microsoft Entra ID |
| Data governance | Requests stay inside the cloud account's logging, networking and compliance regime |
| Residency | Region selection and, where offered, region-pinned inference |
| Platform services | Guardrails, private connectivity, cloud-native monitoring and cost allocation |
Against these sit the costs: feature availability lags or differs, model IDs and SDK clients differ, and some capabilities are Claude-API-only. Anthropic also operates a first-party Claude Platform on AWS that keeps API parity while living in AWS; check the docs for how it differs from partner-operated Bedrock.
What changes per platform
| Aspect | Claude API | Bedrock | Vertex AI | Foundry |
|---|---|---|---|---|
| Authentication | API key, OAuth, workload identity federation | AWS credentials and IAM | Application default credentials, service accounts | API key or Entra ID |
| Model identifier | Anthropic model ID | Platform-prefixed ID; cross-region inference profiles | Project and region scoped; the global region is recommended where available | Deployment-scoped |
| Billing | Anthropic | AWS | Google Cloud | Microsoft Marketplace |
| SDK client | Standard client | Bedrock client classes in the official SDKs | Vertex client classes | Foundry client classes |
| Feature set | Full, first | Subset; some betas and server tools differ | Subset; some server tools unavailable | Subset |
The official SDKs ship dedicated client classes for each platform. After construction they expose the same messages interface, which is what makes a platform-agnostic gateway feasible. Do not point the standard client at a cloud endpoint with a base URL override; use the platform client.
Feature parity is the architect's problem
Anthropic publishes availability tables listing which features work on which platform: structured outputs, prompt caching, batches, files, citations, specific server tools, the MCP connector, compaction, managed agents and more. The pattern is that new features arrive on the Claude API first and reach cloud platforms later or not at all, and that some server tools have different versions per platform.
Design consequences:
- Decide the platform before the feature list is final. A design that depends on a server tool unavailable on your platform is a redesign waiting to happen.
- Abstract the client, not the features. A gateway can swap client classes easily; it cannot conjure a missing feature.
- Plan for divergence. If you must run on two platforms (for example, direct API for innovation teams, Bedrock for regulated workloads), maintain a feature matrix and test both.
- Watch beta status. A beta on the Claude API may be absent on a cloud platform for a long time.
Capacity and throughput
Cloud platforms have their own quota models: on-demand limits per region, provisioned or reserved throughput, and cross-region routing that improves availability at the cost of data leaving a single region. Residency-sensitive workloads must disable cross-region routing explicitly and accept lower burst capacity. Separately, Anthropic's own priority capacity options are Claude-API-only; check current offerings before promising latency guarantees.
Claude Code and the Agent SDK on cloud platforms
Developer tooling can also route through cloud platforms by setting environment variables that select Bedrock, Vertex AI or Foundry and point at the right region and credentials. This is the usual answer when an enterprise wants engineers to use Claude Code but requires all model traffic to flow through its cloud account. Some Claude Code features depend on first-party services and may be unavailable in that mode; confirm in the docs.
Decision framework
Choose the Claude API directly when you need the newest features, Managed Agents, first-party capacity options or the simplest path. Choose a cloud platform when identity, billing, residency or compliance regimes make it mandatory, and accept the parity lag as a managed risk with a feature matrix and a review cadence. Choose a mixed estate only with a gateway abstraction and a clear policy for which workloads go where.
regulated workload, AWS landing zone, no need for betas -> Bedrock
Google-first estate, Vertex MLOps already in place -> Vertex AI
Microsoft estate, Entra ID, Marketplace procurement -> Foundry
innovation team, newest features, managed agents -> Claude API
Exam focus
- Cloud platforms are chosen for identity, billing, governance and residency, not for different models.
- Authentication, model identifiers, billing and SDK client classes differ per platform; the
messagesinterface is the same. - Feature parity is not guaranteed; new features and some server tools arrive on the Claude API first. Check availability tables before design sign-off.
- Cross-region inference improves availability but may conflict with residency; pin regions when required.
- Claude Code and the Agent SDK can route through cloud platforms via environment configuration, with some feature limits.
- Managed Agents and first-party capacity options are Claude-API-only; a mixed estate needs a gateway abstraction and a feature matrix.
Check yourself
5 questions
1.A multinational runs workloads on AWS, Google Cloud and Azure and plans to call Claude from each. A junior engineer asks whether the same Anthropic API key can be used everywhere. Which statement is CORRECT?
2.A data science team standardised on Vertex AI and designed an analysis agent that relies on the Anthropic-hosted code execution tool and the Message Batches API for nightly runs. In testing, the code execution tool is rejected and the batch endpoint does not exist. What should the architect conclude?
3.A team's configuration uses the first-party model identifier string in every environment. On the first-party API it works; on Amazon Bedrock the same string is rejected, and on Vertex AI a dated snapshot of an older model fails to resolve. Which statement about model identifiers is CORRECT?
4.A government contractor has an existing cloud commitment, private network connectivity requirements, and a security review process built around their cloud's IAM. They are deciding whether to call Claude via the first-party API or via their cloud marketplace. Which assessment is MOST balanced?
5.To improve resilience, an architect proposes that an application fail over automatically from the first-party API to the same model on a cloud marketplace during outages. Which consideration is MOST important to design for?