Anthropic API, Bedrock, Vertex AI or Foundry: how to choose your route to Claude

Two different questions hide inside 'how should we access Claude?'. One is whether people will use Claude directly, in chat, projects and connected tools, or whether Claude will run inside software you build. The other, for software, is whose platform carries the traffic: Anthropic's, or a cloud provider you already buy from.

For direct use, the Team and Enterprise plans provide Claude's apps with organisational administration. For applications, Anthropic lists five platforms: the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud and Microsoft Foundry¹. Bedrock and Google Cloud are operated by those providers, while Claude Platform on AWS and Foundry are operated by Anthropic on AWS and Azure infrastructure respectively¹. Google now presents Vertex AI as its Agent Platform, and Anthropic's documentation uses that name³.

The apps suit knowledge work done by people: drafting, analysis, research across connected documents and shared projects. The Enterprise plan adds controls such as SCIM provisioning, audit logs, custom data retention, a Compliance API and customer-managed encryption keys on top of everything in the Team plan⁵. Seats cover access to the platform while usage is billed separately at API rates, and the plan can also be bought through AWS Marketplace⁵.

The API suits work done by software: a contract-review step inside a matter system, a triage service or an agent that runs on a schedule. You design the prompts, retrieval, tools and validation yourself, and you choose a platform for the traffic. Most enterprises end up with both, which is why identity and audit decisions are best made once and then applied to each route.

Cloud routes inherit the controls your platform team already runs. On Bedrock, access is an IAM policy on specific model resources and activity lands in CloudTrail²; on Foundry, Entra ID and Azure role-based access control decide who can call a deployment⁴. That is often decisive for security teams, because no new identity system or log pipeline is introduced.

The trade-off is Anthropic's own administration tooling. The Admin API and the Compliance API are listed as unsupported on Bedrock, Google Cloud and Foundry²³⁴. Claude Platform on AWS is the exception among the AWS options: it documents Compliance API access authorised through AWS IAM, while only the workspace and encryption-key endpoints of the Admin API are available there⁶. If your compliance process depends on Anthropic-level records of API activity, that points to the Claude API or Claude Platform on AWS; if it depends on cloud-native audit trails, a cloud-operated route fits better.

Feature parity is the difference teams most often miss. Anthropic's features overview marks each capability by platform and by stage, from stable to beta¹. For example, the MCP connector, which lets the Messages API call remote MCP servers without a separate client, is listed as beta on the Claude API and is not offered on Bedrock or Google Cloud¹. Foundry adds a second layer: deployments hosted on Azure do not support code execution, Agent Skills or the Files API, while deployments hosted on Anthropic do⁴.

Model availability varies too. Each platform sets its own access rules and lifecycle dates, and regional endpoints may not offer every model³. The practical defence is a short verification step at design time: list the features and models your workflow needs, check them against the platform tables, record the date, and repeat the check before each major release.