When teams compare Claude platforms, they usually compare models and prices, find them essentially identical, and conclude the platforms are interchangeable. Models and list prices are indeed the same. The feature surface around them is not. Batch processing, file handling, and the built-in tools that make some architectures dramatically simpler exist on some platforms and not others. Check this table against your planned architecture before you commit.
The gaps at a glance
| Feature | Claude Platform on AWS | Amazon Bedrock | Google Vertex AI | Microsoft Foundry |
|---|---|---|---|---|
| Messages API, streaming, tool use, vision, extended/adaptive thinking, prompt caching | Yes | Yes | Yes | Yes |
| Batch API | Yes | No | No | No |
| Files API | Yes | No | No | Mostly beta |
| Code execution tool | Yes | No | No | Mostly beta |
| Web fetch tool | Yes | No | No | Mostly beta |
| Web search tool | Yes | No | Basic variant only | Broad support, largely beta |
| Managed Agents | Yes (also on the 1P API) | No | No | No |
The pattern is easy to summarize. The core of the API — sending messages, streaming responses, tool use, vision, adaptive thinking, and prompt caching — works everywhere, so a straightforward chat or document workload ports cleanly across all four platforms. The differences are concentrated in the newer, higher-level capabilities. Claude Platform on AWS, being Anthropic-operated with same-day parity to the first-party API, has everything. Microsoft Foundry supports a broad set of features, though some of that support is in beta, which matters if your organization has rules about beta services in production. Bedrock and Vertex AI cover the core well but lack the Batch API, the Files API, code execution, and web fetch entirely.
Why the gaps exist
The explanation is organizational, not technical. Amazon Bedrock, Google Vertex AI, and Microsoft Foundry are operated by the cloud providers, who integrate each Claude capability into their own service on their own schedules. Claude Platform on AWS is operated by Anthropic itself, so new API features typically land there the same day. There is nothing to fix here, just a cadence difference to plan around — and it means this table is a snapshot. Recheck current availability against official documentation when you evaluate.
What the gaps mean for real architectures
Three common plans run into these gaps. Overnight bulk processing: if you intend to push large volumes through the Batch API for asynchronous work, Bedrock and Vertex cannot do that today; you would build your own queueing and pacing instead, which is real engineering effort. Document-heavy workflows: without the Files API you re-send document content with requests rather than referencing uploaded files, which prompt caching can soften but not fully replace. Agentic features: if Managed Agents or the built-in code execution and web tools are central to your design, your realistic options narrow to the first-party API or Claude Platform on AWS, or you implement equivalent tooling yourself via ordinary tool use, which works everywhere but is more code you own.
How to use this in your decision
Write down the features your architecture actually requires, not the ones that sound nice, and strike out platforms that lack them. If everything you need is in the core row of the table, choose on other grounds: your existing cloud, IAM and networking fit, and procurement. If you need the advanced rows, weigh Claude Platform on AWS seriously even if Bedrock feels like the default in an AWS shop — it runs on AWS too. And wherever Foundry's beta labels appear, ask your security and platform teams how they treat beta services before assuming the feature is usable.
Where to go next
Fold this into the full decision framework in How to Choose Between Bedrock, Vertex AI, Foundry, and Claude Platform on AWS, see where batch processing genuinely pays off in Batch vs. Real-Time, or check the feature matrix on the main guide.