Deploying Claude in the Enterprise: Bedrock, Vertex AI & Foundry (CCAR-P)

Where Claude runs is an architecture decision, and the Claude Certified Architect - Professional (CCAR-P) exam treats it as one. An enterprise can call Claude through Anthropic's own API, through Amazon Bedrock, through Google Cloud Vertex AI, or through Microsoft Foundry, and each path changes who processes the data, how identity and access are enforced, where inference runs, which features are available, and whose invoice the tokens land on. This guide covers the four access paths at architect altitude: the selection criteria the exam expects you to weigh (cloud commitments, data residency, identity integration, procurement, private networking), the deployment design that follows (authentication, secrets, network isolation, logging, cost governance), and the regulated-industry constraints that HIPAA, GDPR, and FedRAMP impose. Two worked scenarios close with the exam-correct choice and the reasoning behind it.

Why the access path is an architecture decision

A model endpoint looks like a URL, so teams tend to treat the choice of endpoint as a procurement detail to settle after the design is done. On CCAR-P, that ordering is backwards. The access path determines the data processor (the party that handles your prompts and completions on your behalf), the identity system that authorizes each call, the geography where inference can be pinned, the audit trail your compliance team will read, and the feature set your agents can use. Each of those is a Domain 3 or Domain 5 concern, and a stem that mentions a cloud commitment, a residency clause, or a named regulator is usually asking you to pick the path before you pick the pattern. The exam tests whether you can read those constraints and choose the deployment that satisfies all of them with the least added complexity.

The four access paths

Claude API (direct)

The first-party Claude API at api.anthropic.com is the reference surface. Anthropic operates the inference stack and is the data processor. Authentication uses API keys issued in the Claude Console and organized into workspaces (isolated groupings of keys, limits, and settings inside one organization), and the Admin API automates that structure. Every feature lands here first: the Messages API, prompt caching, tool use, the Message Batches API (asynchronous, discounted processing for non-interactive work), the Files API, Agent Skills, the MCP connector, server-side tools, and the Usage and Cost API. Data residency is controlled per request with the inference_geo parameter, which currently accepts "global" or "us", and can be locked per workspace with allowed_inference_geos and default_inference_geo. Zero data retention (ZDR, an arrangement under which Anthropic does not store prompts or responses at rest after the response is returned) is available on request, and HIPAA readiness (a signed business associate agreement plus organization-level enforcement that rejects requests using non-eligible features) can be enabled from the Console by eligible organizations.

Pick the direct API when there is no cloud commitment to draw down, when the team needs new features on release day, and when Anthropic's own arrangements satisfy the regulator. Traffic travels over the public internet with TLS, so a requirement for private connectivity from your own network is the first signal that a cloud path may fit better.

Amazon Bedrock

Amazon Bedrock is AWS's managed foundation-model service. AWS operates the inference infrastructure and is the data processor; Anthropic's documentation describes the current Bedrock endpoint as running with zero operator access, meaning Anthropic personnel cannot reach the inference infrastructure. Authentication is AWS-native: requests are signed with AWS credentials using SigV4 (the AWS request-signing scheme), and Anthropic ranks the options as a Bedrock service role first, identity-federated IAM roles second (SAML, OIDC, or AWS Identity Center, issuing time-limited credentials), and short-lived bearer tokens last. Model access is enabled per model in the Bedrock console and varies by region, so verify current model availability on the Bedrock model access page before committing a design. Bedrock offers global endpoints (dynamic routing across regions for availability) and regional endpoints (routing pinned to the region you specify, at a pricing premium), plus inference profiles that route within a geography such as US, EU, Japan, or Australia. Logging flows to CloudWatch and CloudTrail, invocation logging can capture prompts and completions, encryption uses AWS KMS keys, and AWS PrivateLink keeps traffic inside your VPC (virtual private cloud). AWS lists Bedrock as HIPAA eligible and GDPR-compliant, and as FedRAMP High authorized in the AWS GovCloud (US-West) region.

The trade-off is feature lag. As of this writing, Bedrock does not offer the Message Batches API, the Files API, server-side tools, Agent Skills, the MCP connector, or the Admin and Usage APIs, and the newer Bedrock Messages endpoint lacks structured outputs. Confirm the current list on the Claude features overview page before promising a capability.

AWS also hosts a distinct offering called Claude Platform on AWS: an Anthropic-operated service billed through AWS Marketplace, with typically same-day feature access, IAM or API-key authentication, and PrivateLink support. Anthropic is the data processor there, data may not reside in AWS, and HIPAA readiness is not available on it. Anthropic's guidance is direct: organizations that require FedRAMP High, IL4, IL5, or HIPAA-ready compliance, or that need AWS to be the sole data processor, should use Claude in Amazon Bedrock. Keep the two separate on exam day.

Google Cloud Vertex AI

Google Cloud Vertex AI is Google's managed AI platform (Google's documentation now brands the same surface as the Gemini Enterprise Agent Platform, while Anthropic's docs still title the integration Claude on Vertex AI). Google Cloud operates the infrastructure and is the data processor. Authentication uses Google Cloud credentials through IAM (identity and access management, the permission system governing Google Cloud resources), typically Application Default Credentials bound to a service account. Two request-shape differences catch teams porting code: the model is named in the endpoint URL instead of the request body, and anthropic_version travels in the body. Models are enabled through Model Garden and availability varies by region, so check the listing before designing. Endpoint options are richer than Bedrock's: global (dynamic routing), multi-region (routing within a geography such as us or eu, for residency with higher availability), and regional (a single region, required for strict single-region residency and for provisioned throughput). Multi-region and regional endpoints carry a pricing premium. Request-response logging captures prompts and completions, and feature gaps track Bedrock's: no Message Batches endpoint, Files API, code execution, Agent Skills, MCP connector, or Admin and Usage APIs.

Pick Vertex AI when the enterprise's data platform, identity, and committed spend already live in Google Cloud, or when EU multi-region residency with automatic failover across regions is the deciding requirement.

Microsoft Foundry

Microsoft Foundry is Azure's AI platform. You create a Foundry resource (which holds security and billing configuration) and then one or more Claude deployments inside it; the deployment name becomes the model parameter in your requests. Authentication is either an Azure-issued API key or a Microsoft Entra ID token (Entra ID is Microsoft's cloud identity service, formerly Azure Active Directory) governed by Azure RBAC roles such as Foundry User, and the resource can sit inside an Azure Virtual Network. Foundry adds a twist the other paths lack: two hosting options. Hosted on Azure runs an Anthropic-operated service on Azure infrastructure, keeps prompts and completions within Azure (only usage metadata and content flagged by Anthropic's safety systems egress to Anthropic), and supports a US Data Zone Standard deployment type that keeps inference in the United States. Hosted on Anthropic runs on Anthropic infrastructure and exposes more features. Anthropic acts as an independent processor for Microsoft on both. Billing is metered in Claude Consumption Units through Azure Marketplace, and monitoring runs through Azure Monitor, Log Analytics, and Cost Management.

Feature caveats matter more here than anywhere else. Foundry does not offer the Message Batches, Admin, Compliance, or Models APIs, and deployments hosted on Azure additionally lack structured outputs, server-side tools, the MCP connector, Agent Skills, programmatic tool calling, and the Files API; requests that use them return a 400 by design. Anthropic's HIPAA-ready program is not available on Foundry, so a healthcare design there rests on Microsoft's own compliance offerings, which you verify on Microsoft's compliance pages. Foundry also omits Anthropic's rate-limit response headers, so throttling telemetry comes from Azure monitoring. Pick Foundry when identity, procurement, and networking are Entra-and-Azure-first, and when the required feature set fits the hosting option the security team will accept.

How an architect chooses

The exam rarely asks "which cloud is best." It embeds two or three constraints in a stem and expects you to notice which one dominates.

Cloud commitments and procurement. Enterprises with committed spend want Claude usage to draw down that commitment and appear on an invoice procurement already approves. Bedrock bills as native AWS usage, Claude Platform on AWS and Foundry bill through their marketplaces in Claude Consumption Units, and Vertex AI bills through Google Cloud. A stem that says "the cloud account's security review is complete and finance wants a single vendor" is pointing at the cloud path.

Data residency. A US-only requirement can be met on every path: inference_geo: "us" on the direct API and Claude Platform on AWS, US regional endpoints or inference profiles on Bedrock, us multi-region on Vertex AI, and US Data Zone Standard on Foundry hosted on Azure. An EU-pinned requirement narrows the field, because the direct API's inference_geo values are currently global and us only, so inference that must stay inside the EU points to Bedrock EU inference profiles or Vertex AI's eu multi-region or EU regional endpoints. Every provider prices pinned routing above global routing, and the correct answer names that trade-off.

Identity and authorization. The tested anti-pattern is a shared, long-lived key used on behalf of every user, which erases per-user attribution and audit. Cloud paths attach Claude access to the identity system the enterprise already runs: federated IAM roles on AWS, service accounts on Google Cloud, Entra ID with RBAC on Azure. On the direct API, the equivalent discipline is per-workspace keys held by a backend service with your own identity layer in front.

Private networking. If traffic may not traverse the public internet, look for private connectivity from the enterprise's own network: PrivateLink for Bedrock and Claude Platform on AWS, an Azure Virtual Network around the Foundry resource, and Google Cloud's private connectivity controls for Vertex AI (verify current options for Claude on the provider's page). The direct API is reached over TLS on the public internet.

Data processor and compliance posture. If the regulator or contract requires that the cloud provider alone process the data, choose the provider-operated path (Bedrock, Vertex AI, or Foundry hosted on Azure). If Anthropic's own arrangements are acceptable, the direct API's ZDR and HIPAA readiness are the fastest route. Note the asymmetry: HIPAA readiness under Anthropic's program applies to the direct API and is not available on Claude Platform on AWS or Foundry.

Feature needs. If the design depends on the Message Batches API, the Files API, Agent Skills, the MCP connector, or server-side tools, the provider-operated paths will not serve it today. That pushes you to the direct API, Claude Platform on AWS, or Foundry hosted on Anthropic, and it may force a conversation about which matters more, the feature or the processor boundary. An architect surfaces that conflict in discovery.

Designing the deployment

Choosing the path is half the Domain 3 work. The other half is designing the controls around it, and each control has a recognizable exam-correct shape.

Authentication and authorization

Prefer short-lived, identity-bound credentials over long-lived keys: a service role or federated IAM role scoped to specific model resources on Bedrock, a dedicated service account with the minimum predict permission on Vertex AI, Entra ID tokens with the narrowest RBAC role on Foundry, and one key per workspace held only by the backend that fronts the model on the direct API. Authorization for what the model can do is a separate layer: tool permissions, MCP server credentials, and downstream API scopes are granted per user or per agent, never inherited from whoever deployed the service. Every call should be attributable to a principal in your logs, because "which user triggered this action" is the first question an auditor asks and the first thing a confused-deputy incident hides.

Secrets

Keys and tokens live in a secrets manager (AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or an equivalent), are injected at runtime, and rotate on a schedule. Credentials in prompts, source code, container images, or committed configuration are automatic wrong answers. Where the path supports it, prefer the identity mechanism (Entra ID, IAM roles) that removes standing keys entirely.

Network isolation

Place the calling service in a private subnet, egress through a private endpoint where the path supports one, and deny direct internet egress where policy demands it. Pair isolation with the provider's encryption controls (customer-managed keys on the cloud paths, TLS everywhere), and remember that isolation covers the model call only; retrieval stores, tool backends, and log sinks need the same treatment or the boundary has a hole in it.

Logging and observability

Every path shares one baseline: retain activity logs on at least a 30-day rolling basis, which is Anthropic's stated recommendation across the direct API, Bedrock, Vertex AI, and Foundry. Beyond that, specify three log streams. Control-plane and access logs (CloudTrail on AWS, Cloud Audit Logs on Google Cloud, Azure activity logs) answer who called what. Invocation or request-response logs capture prompts and completions when policy allows, and in a HIPAA design they are PHI stores with the same access controls. Application traces tie the model call to the retrieval step, the tool calls, and the final answer, because multi-step failures surface several hops from their cause. Two provider quirks: Foundry omits Anthropic's rate-limit headers, so throttling telemetry comes from Azure Monitor, and CloudTrail data-event logging on AWS is opt-in with its own charges.

Cost governance

The usage object in every response is consistent across the direct API, Bedrock, Claude Platform on AWS, Foundry, and Vertex AI, so cost per task can be computed the same way everywhere. Governance differs by path: the Claude Console offers organization and workspace spend limits and a Usage and Cost API; Bedrock and Vertex AI usage lands in the cloud billing tools you already tag and budget with; Claude Platform on AWS and Foundry meter in Claude Consumption Units on the marketplace invoice. Structure workspaces, projects, or deployments per team so costs attribute cleanly, and show the stakeholder the premium that pinned residency carries, with the provider's pricing page as the reference. Prompt caching and model-tier routing are the main levers once the path is chosen; the CCAR-P cost and latency guide covers them in depth.

Regulated-industry considerations

Compliance questions on CCAR-P reward candidates who match the regime to the data type and jurisdiction, then name the control that answers it. State the obligation generically and verify the specific product claim on the official page.

HIPAA. HIPAA is the US law governing protected health information (PHI). The architectural obligations are a business associate agreement (BAA) with whoever processes PHI, safeguards over the full lifecycle (encryption, access control, audit logging), and keeping PHI out of places the BAA does not cover. On the direct API, Anthropic's HIPAA readiness provides the BAA and enforces feature eligibility at the organization level, and Anthropic warns that PHI belongs in message content only and must not appear in JSON schema definitions for structured outputs. On AWS, Bedrock is HIPAA eligible under AWS's program. Anthropic's HIPAA-ready program is not available on Claude Platform on AWS or Foundry, so a design on those paths depends on the cloud provider's own arrangements. Evaluation datasets and invocation logs that contain PHI are PHI stores and are governed as such.

GDPR. GDPR is the EU regulation on personal data. It drives data minimization (send the model only what the task needs), purpose limitation, lawful basis, data-subject rights such as erasure, and rules on international transfers. GDPR does not mandate a single geography by itself, but many enterprises translate transfer risk into an EU-residency requirement, and that requirement selects the endpoint type: EU inference profiles on Bedrock, or eu multi-region and EU regional endpoints on Vertex AI, since the direct API's inference geographies are currently global and us. Erasure obligations reach retrieval indexes, logs, and evaluation sets, so a retention arrangement on the model call is only part of the answer.

FedRAMP. FedRAMP is the US federal program that authorizes cloud services for agency use, and authorization attaches to a specific service in a specific boundary. AWS states that Bedrock is FedRAMP High authorized in the AWS GovCloud (US-West) region, and Anthropic's guidance sends FedRAMP High and IL4/IL5 requirements to Claude in Amazon Bedrock. For any federal scenario, verify the current authorization on the FedRAMP Marketplace and the provider's compliance page, and design inside the authorized boundary; an authorization does not travel with the model.

Worked scenario 1: PHI, an AWS estate, and a sole-processor clause

A US hospital network wants a clinical-note summarization assistant. Clinical text is PHI. The organization has a large AWS commitment, runs identity through AWS Identity Center, and its security policy states that PHI may only be processed by vendors inside the approved AWS boundary and must never traverse the public internet. The team also asks for the Message Batches API for overnight backfills. Which deployment do you recommend?

Option A uses the direct Claude API with HIPAA readiness enabled and the Batches API for backfills. Option B uses Claude Platform on AWS with PrivateLink so billing lands on the AWS commitment. Option C uses Claude in Amazon Bedrock with a US regional endpoint, federated IAM roles from Identity Center, PrivateLink, KMS encryption, and CloudTrail plus invocation logging into a restricted account, with the backfill rewritten as a scheduled asynchronous job. Option D uses Microsoft Foundry hosted on Azure with a US Data Zone deployment.

The exam-correct choice is C. The dominant constraints are the sole-processor policy and the private-network rule, and only Bedrock satisfies both while drawing down the AWS commitment: AWS operates the inference infrastructure, Bedrock is HIPAA eligible under AWS's program, PrivateLink keeps traffic off the public internet, and Identity Center federation gives per-user attribution. Option A is defensible on the BAA alone, but the direct API is reached over the public internet, Anthropic is the processor, and it ignores the commitment. Option B is the trap: it sits on AWS and supports PrivateLink, yet Anthropic is the processor, data may not reside in AWS, and HIPAA readiness is not available there. Option D introduces a second cloud and identity system for no stated reason. The Batches request is a feature conflict the architect surfaces honestly: the Message Batches API is unavailable on Bedrock, so the backfill becomes a scheduled asynchronous job, and that trade-off goes into the architecture record.

Worked scenario 2: EU residency with an availability target

A European insurer standardized on Google Cloud is building a policy-document assistant for EU customers. Legal requires that model inference for EU customer data stay within the European Union, operations has a strict availability target, and finance accepts a modest premium for pinned routing. Provisioned throughput is not required. Which endpoint strategy do you recommend?

Option A uses the Vertex AI global endpoint for maximum availability and documents that Google Cloud is the processor. Option B uses a single EU regional endpoint on Vertex AI. Option C uses the Vertex AI eu multi-region endpoint with a service-account identity, request-response logging into an EU log bucket, and a documented retention window. Option D uses the direct Claude API with inference_geo: "us" and a workspace lock.

The exam-correct choice is C. The residency clause eliminates A, because global routing may run inference outside the EU. D fails the same clause; the direct API's inference geographies are global and us, neither of which pins the EU. B meets residency but concentrates the design in one region, which fights the availability target, and the stem removed the one reason to prefer it by stating that provisioned throughput is unnecessary. The eu multi-region endpoint routes across EU regions for availability while keeping inference inside the geography, at the premium finance already accepted. The complete answer also covers logging and retention, because GDPR erasure and minimization obligations extend to what you store.

How the exam tests this material

Access-path questions on CCAR-P are multi-constraint stems where one clause is decisive: a named regulator, a residency phrase, an identity provider, a private-network rule, or a required feature. Read for that clause first, eliminate every path that fails it, and only then weigh cost and familiarity. Distractors are real, adjacent options that satisfy most of the constraints: the Anthropic-operated marketplace offering when the stem needs the cloud provider as processor, a global endpoint when the stem needs a pinned geography, an API key when the stem asks for per-user attribution. Multiple-response items here often pair the path with one control, so practice naming both. The common CCAR-P mistakes article covers the trap of choosing a technically valid option that violates a governance constraint, and the governance guide covers the control layers that sit on top of whichever path you choose.

Frequently asked questions

Next steps

Deployment questions sit inside the largest domain on the exam, so pair this article with the CCAR-P cheat sheet for the Integration and Governance trigger rules, then work the CCAR-P practice questions with explanations to see how residency, identity, and processor constraints appear in real stems. When you are ready for full-length simulation, Preporato's CCAR-P practice tests are available through Preporato Pro (see pricing) or the single-cert bundle.

Sources:

• Claude in Amazon Bedrock (Anthropic docs)
• Claude Platform on AWS (Anthropic docs)
• Claude on Google Cloud Vertex AI (Anthropic docs)
• Claude in Microsoft Foundry (Anthropic docs)
• Data residency and API and data retention (Anthropic docs)
• Amazon Bedrock security and compliance (AWS)