Claude on AWS: Choosing the Right Deployment Path
Picture the conversation that happens at most software vendors three weeks after someone in engineering quietly starts using Claude inside a feature.
.png)
Picture the conversation that happens at most software vendors three weeks after someone in engineering quietly starts using Claude inside a feature. Security asks where the prompts are processed and whether that conflicts with the SOC 2 commitments already made to a healthcare customer. Finance asks why there are four different invoices with four different units of measure.
The platform team asks why the chatbot prototype that worked beautifully in a side project can't get a remote MCP connection into the internal ticketing system. And the CTO, who approved none of this and is now accountable for all of it, has to explain to the board in one sentence why "we're using AI" doesn't actually answer any of those questions.
That scene repeats itself across the ISVs and SaaS builders we work with at CloudZone, regardless of company size. Claude on AWS isn't hard to use, and "deploying Claude" wasn't a single decision. There are three different operating models with the same name, and the one you pick determines your compliance posture, feature velocity, and unit economics months before anyone schedules a strategy review.
So, most enterprises are deploying Claude wrong, not because of the model they pick, but because they treat the access path as a procurement footnote instead of an architectural decision. Here's the detail behind that.
AWS offers three distinct ways to run Claude, each addressing a different question about who touches your data, who ships features first, and whom you call when something breaks.
Amazon Bedrock keeps AWS as the data processor. Traffic never leaves the AWS boundary, there's zero operator access from Anthropic, and you get in-region endpoints across the US, EU, AUS, JP, and GovCloud. You also get customer-managed KMS keys, HIPAA eligibility, and a 12-month minimum model availability guarantee, with a 6-month deprecation notice on top of that.
The trade-off is that you're consuming Claude through Amazon Bedrock's unified API layer alongside 100+ other foundation models. That means day-one access to Anthropic's newest capabilities, like Managed Agents, the Files API, and Remote MCP, isn't guaranteed. Amazon Bedrock optimizes for control and residency, not for being first.
Claude Platform on AWS, which went GA in May 2026, flips that trade-off. Anthropic operates it directly, so you get full native Claude API feature parity from day one, including Managed Agents, Web Search and Fetch, the Files API, Remote MCP, Agent Skills, prompt caching, citations, and batch processing. Authentication runs through AWS IAM rather than separate Anthropic API keys, and billing is consolidated on your AWS Marketplace invoice.
The catch is in the fine print on data residency. VPC and PrivateLink support cover the hop from your VPC to the AWS gateway, but traffic between that gateway and Anthropic's infrastructure still crosses the public internet, and Anthropic is the data processor, not AWS. If an end customer's compliance team asks, "Does this ever leave AWS?" the honest answer here is "mostly."
Claude Enterprise via AWS Marketplace serves people who aren't developers. It puts Claude Chat, Claude Code, and Claude Cowork in front of end users with SSO/SAML, SCIM provisioning, and native integrations into Google Drive, Gmail, GitHub, Microsoft 365, and Slack, all for a flat $20 per user per month plus pooled usage, no developer lift required.
It's the fastest path to seeing AI show up in ops, finance, and marketing workflows, but it's also the path with the least architectural flexibility. There's no Messages API, no multi-model access, no Guardrails or Knowledge Bases, and no PrivateLink.
None of these three is the "default" or the "advanced" option. They're answers to three different questions, and most organizations need answers to all three at once.
Abstract comparisons are easy to nod along to but hard to apply, so here's how this plays out for the kind of customers we work with at CloudZone.
A fintech SaaS company building on AWS, serving banking customers, has an end-customer compliance requirement that data never leaves the AWS security boundary and that every interaction be auditable with customer-managed keys. That requirement alone settles the question in favor of Amazon Bedrock, regardless of which Claude capabilities they'd ideally want.
The Managed Agents feature they saw in a demo simply isn't available there yet, and that's a real cost, nothing to fix later. It's the cost of the compliance posture they're selling to their own customers.
A cloud-native startup, racing to ship an agentic feature before a competitor, doesn't have a regulatory constraint pulling it toward Amazon Bedrock. What they have is a deadline and a roadmap that depends on Remote MCP and Agent Skills the day those ship, not months later through a multi-model layer.
For them, Claude Platform on AWS is the only path that doesn't make them wait on someone else's release cycle, and the public-internet hop between the AWS gateway and Anthropic is an acceptable trade for a company whose data isn't yet under a regulator's microscope.
Another well-established customer wants their ops and finance teams to stop copy-pasting into a free Claude.ai tab and start working inside something governed. They don't need an API; they need seats. Claude Enterprise via AWS Marketplace gets them there in a sales cycle measured in weeks, not quarters, and it's often the engagement that surfaces the next, bigger conversation about what their product team actually needs from the Platform path.
And then there's the case that trips people up the most. An ISV embedding Claude within their own AWS-hosted SaaS product, where the end customer is the one asking the residency question, must choose Amazon Bedrock because their vendor security certification can't withstand a customer's compliance team asking whether Anthropic processes any of this outside their region.
The pattern across all four scenarios is the same. The compliance, speed, or distribution constraint in the room is non-negotiable.
There are three trade-offs to weigh when picking the right access path to Claude on AWS.
Amazon Bedrock keeps AWS as the sole processor with in-region endpoints and zero operator access. It's the only path with HIPAA eligibility and customer-managed KMS keys. Claude Platform on AWS supports VPC/PrivateLink up to the AWS gateway, but Claude Enterprise via AWS Marketplace doesn't support PrivateLink at all.
However, both route through Anthropic as the data processor. If your customer base includes regulated industries such as healthcare, financial services, or the public sector, this axis alone often decides the conversation before any feature comparison starts.
Claude Platform on AWS gets new Anthropic capabilities the same day they ship anywhere else. Amazon Bedrock's multi-model architecture means Claude capabilities land there on AWS's integration timeline, not Anthropic's release timeline.
Claude Enterprise via AWS Marketplace sits in between. It gets Web Search, the Files API, and the consumer-facing product surface, but not the developer-facing API features, because it isn't built for developers.
Both Amazon Bedrock and Claude Platform on AWS assume a development team building something, whether that's APIs, agents, or integrations. Claude Enterprise via AWS Marketplace assumes a knowledge worker who wants to open an app and get work done.
Trying to force one path to do the other's job is where most of the friction we see in customer environments actually comes from. Developers fight with seat-based licensing, or business teams get handed an API key and a Postman collection.
As a simple rule of thumb, pick Amazon Bedrock when the constraint is "where does the data live," pick Claude Platform on AWS when the constraint is "how fast do we need the newest capability," and pick Claude Enterprise via AWS Marketplace when the constraint is "how many non-developers need this today."
One detail that gets lost in these comparisons deserves repeating. We aren't trading model quality for governance. Amazon Bedrock, Claude Platform on AWS, and Claude Enterprise all run the same Opus, Sonnet, and Haiku models, with the same weights and the same pricing as going directly to Anthropic. Nobody is buying a watered-down version of Claude by choosing the more controlled path.
What differs is the promise around how long a model sticks around and how new ones arrive. Amazon Bedrock comes with a 12-month minimum availability guarantee and a 6-month deprecation notice on legacy models, which matters enormously if you're running a production workload you don't want to re-validate every quarter.
Claude Platform on AWS follows Anthropic's own deprecation policy and gets day-one parity with whatever ships on Anthropic direct, which means new capabilities and new model versions can land closer together than most teams are used to planning for.
Claude Enterprise abstracts the whole question away by updating models automatically, managed by Anthropic, which is exactly what a non-technical user wants and exactly what a platform engineer building something stateful should be wary of. A workload that can't tolerate an unannounced model change underneath it has no business sitting on Claude Enterprise, no matter how convenient the seat-based billing looks.
The instinct to consolidate onto a single path "to keep things simple" is understandable but, in our experience, almost always wrong. We've watched CTOs centralize everything onto Amazon Bedrock for the compliance story and then quietly lose three months of feature parity on an agentic workload that genuinely needed Remote MCP.
We've also watched the opposite happen, teams pushing everything onto the Claude Platform on AWS for speed until a healthcare prospect's security questionnaire stalled a deal because nobody could answer the residency question convincingly.
The companies getting this right are running all three paths in parallel, deliberately mapped to workload, not centralized for the sake of a clean architecture diagram. A regulated core product sits on Amazon Bedrock. An internal agent prototype or a customer-facing feature racing a competitor sits on the Claude Platform on AWS. The ops, finance, and marketing teams that just need a capable assistant sit on Claude Enterprise. It's three contracts with reality, each one matched to the constraint that actually governs it.
What makes this manageable is that AWS has, deliberately, made the governance layer identical across all three. Billing consolidates into one AWS invoice regardless of path, with Claude spend counting toward Marketplace commitment retirement. IAM authentication works across Amazon Bedrock and the Claude Platform without separate credentials.
CloudTrail gives a unified audit trail across both interactions. The procurement and security teams don't need three different relationships. They need one AWS relationship and a clear map of which workload sits where and why.
When we sit down with a customer to map their Claude on AWS deployment, the order of questions matters more than the feature checklist.
First, does any workload have a hard residency, HIPAA, or zero-operator-access requirement that an end customer or regulator will actually audit? If yes, that workload goes to Amazon Bedrock, full stop, and the feature gap is a known cost you plan around rather than a surprise you discover once in production.
Second, for everything else, does the team building it need day-one access to whatever Anthropic ships next, including agentic and MCP capabilities? If yes, Claude Platform on AWS.
Third, is the actual user a knowledge worker who needs a governed app experience rather than an API? If yes, Claude Enterprise, and don't make them wait for a developer team's roadmap.
Most organizations answer "yes" to all three questions, for different parts of their business, in the same quarter, and that's a sign the decision was made correctly, three times over, not that it was unclear.
The real mistake was pretending there's only ever one box to check, not which of Amazon Bedrock, Claude Platform, or Claude Enterprise you picked.
If you're working through which of these three paths fits which of your workloads, that's exactly the kind of architecture decision CloudZone maps out with customers every week as an official AWS Anthropic Reseller for Claude on Amazon Bedrock. Book a Claude on AWS architecture review.
Amazon Bedrock keeps AWS as the data processor with zero operator access from Anthropic. Claude Platform on AWS is operated directly by Anthropic and gets full API feature parity from day one. Claude Enterprise via AWS Marketplace puts Claude Chat, Claude Code, and Claude Cowork in front of end users with no developer lift required.
Amazon Bedrock. It's the only path with HIPAA eligibility, customer managed KMS keys, and zero operator access from Anthropic, which settles the question for any workload with a hard residency or audit requirement.
Not entirely. VPC and PrivateLink cover the hop to the AWS gateway, but traffic between that gateway and Anthropic still crosses the public internet, and Anthropic is the data processor, not AWS.
No. Amazon Bedrock, Claude Platform on AWS, and Claude Enterprise all run the same Opus, Sonnet, and Haiku models, with the same weights and pricing as going directly to Anthropic.
Yes. The post argues that running all three in parallel, mapped to workload, works better than consolidating onto one path for the sake of simplicity.
.png)
