Claude Cowork Third Party: Bedrock, Vertex, Foundry oder Gateway?

Claude Cowork Third Party laeuft auf Amazon Bedrock, Google Vertex AI, Azure Foundry oder einem LLM-Gateway. Welche Plattform fuer welches Unternehmen passt und wie der Rollout laeuft.

22 Apr.. 2026 | AI

Inhaltsverzeichnis

 

Phillip Pham, Pexon Consulting | 10 Min. Lesezeit | 22.04.2026


TL;DR

Claude Cowork Third Party deploys Claude Desktop auf der eigenen Cloud-Infrastruktur: Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry oder einem vorhandenen LLM-Gateway. Anthropic sieht weder Prompts noch Antworten. Welche Plattform die richtige ist, hängt von drei Faktoren ab: bestehender Cloud-Stack, Per-User-Governance und VDI-Bedarf. Wir zeigen die Entscheidungs-Matrix aus 40+ Rollouts.

Plattform Stärke Schwäche
Amazon Bedrock Breiteste Region-Abdeckung, VPC-Endpoints Keine Web Search on-Platform
Google Cloud Vertex AI Private Service Connect, Web Search Claude in der EU nur über die EU-Multi-Region
Azure AI Foundry Microsoft-Stack-Integration, Web Search Keine EU-Datenzone für Claude, API-Key-Auth Standard
LLM-Gateway Re-use bestehender Infrastruktur, Per-User-Limits Ops-Overhead beim Unternehmen

Warum „Third Party“ das neue Standard-Deployment wird

Noch vor einem Jahr war die Frage einfach: Claude Enterprise oder selbstgebautes RAG-System auf der eigenen Cloud. Dazwischen gab es nichts. Seit Anthropic das Third-Party-Deployment für Cowork freigegeben hat, verschiebt sich das Bild.

Der Grund ist simpel. Enterprise-Kunden wollen drei Dinge gleichzeitig: die fertige Desktop-App mit Projekten, Memory und Artefakten — Datenhoheit auf der eigenen Cloud — und Abrechnung über bestehende Cloud-Verträge. Das geht nur, wenn die Inferenz beim Kunden läuft.

Der Effekt in unseren letzten Projekten: Regulierte Branchen springen auf. Versicherer, Banken, Energie-Versorger und der öffentliche Sektor machen den größten Teil der Anfragen aus. In 9 von 10 Fällen geht es nicht um eine technische Abwägung, sondern um die Frage, ob das Deployment von der Konzern-IT-Security freigegeben werden kann — und ob die bestehenden Auftragsverarbeitungsverträge reichen.

Hier lohnt sich die Unterscheidung zwischen den vier Optionen. Sie sind nicht austauschbar, und die Wahl entscheidet über Rollout-Zeit, Betriebsaufwand und welche Features Ihre Mitarbeiter bekommen.


Die Plattformwahl entscheidet über Rollout und Betrieb, nicht über die Arbeitsweise im Team danach. Wie Entwickler Agentic Coding produktiv nutzen, vermittelt unsere Claude-Code-Schulung für Entwicklerteams in praxisnahen Modulen zu Custom Commands, Sub-Agents und MCP-Servern.

Die vier folgenden Optionen entscheiden nur die Technik dahinter. Was Cowork im Alltag der Fachabteilung bringt: Claude Cowork im Überblick →

Die vier Third-Party-Optionen im Direktvergleich

Alle vier Plattformen liefern denselben Kern: Claude Desktop mit Projekten, Memory, Artefakten, Skills, Plugins und MCP. Der öffentliche Chat-Tab, Computer Use, Dispatch, Voice-Mode, die Account-Management-UI und der Skills Marketplace sind in allen Third-Party-Varianten deaktiviert.

Was sich unterscheidet, sind sechs Details — und die sind im Alltag relevant:

Feature Bedrock Vertex AI Azure Foundry LLM-Gateway
Private-Network-Anbindung VPC Interface Endpoint Private Service Connect VNET + Private Endpoint Interne Gateway-URL
Web Search im Client Nein Ja Ja Abhängig vom Gateway
Standard-Auth IAM oder API-Key Service Account API-Key Custom (meist OAuth)
Per-User-Rate-Limits Nur Blanket Nur Blanket Nur Blanket Ja, im Gateway
Skills und Plugins Lokal oder Admin-Push Lokal oder Admin-Push Lokal oder Admin-Push Lokal oder Admin-Push
Memory Lokal Lokal Lokal Lokal

Drei dieser Zeilen sind Entscheidungs-relevant.

Per-User-Rate-Limits sind nur über einen eigenen LLM-Gateway möglich. Wenn Ihre Compliance fordert, dass einzelne Nutzer nicht mehr als X Tokens pro Tag verbrauchen, führt kein Weg am Gateway vorbei — oder Sie bauen die Enforcement-Logik außerhalb der App.

Web Search entscheidet, wie gut Claude für Recherche-Use-Cases taugt. Ohne Web Search bleibt der Agent auf den lokalen Dokumenten und MCP-Servern hängen. Bedrock-Nutzer müssen dafür einen eigenen Web-Search-MCP betreiben, auf Vertex und Foundry ist es nativ dabei.

Die Auth-Standardwahl entscheidet über den Betriebsaufwand: IAM Identity Center auf AWS rotiert automatisch, API-Keys auf Azure landen oft im Passwort-Manager oder — im schlechtesten Fall — auf dem Laptop im Klartext.


Wann Amazon Bedrock die richtige Wahl ist

Bedrock ist die naheliegende Option für alle Unternehmen, die bereits AWS als Haupt-Cloud fahren. Die Integration in die Pexon-Landing-Zone steht in wenigen Tagen, und das EU-Profil (Einstieg über Frankfurt, Verarbeitung in sechs EU-Regionen) deckt fast alle DACH-Anforderungen ab.

Besonders stark: VPC Interface Endpoints. Der Claude-Desktop-Traffic verlässt das private Netz nie. Für Banken und Versicherer mit strengen Netzwerk-Segmentierungs-Anforderungen ist das oft der ausschlaggebende Faktor.

Der Haken: Web Search ist nicht dabei. Wer Claude auch für Live-Recherche nutzen will, braucht einen eigenen MCP-Server dafür. Das ist keine Raketenwissenschaft, aber ein zusätzliches Stück Infrastruktur mit eigenen Ops-Kosten.

Unsere Empfehlung: Bedrock, wenn Ihre AWS-Landing-Zone bereits produktiv ist und Sie bereits Claude Code oder andere Bedrock-Workloads betreiben. Dann ist das Setup in zwei Wochen fertig und nutzt die bestehende IAM-, CloudTrail- und Cost-Allocation-Infrastruktur mit.

Wie das konkret aussieht, haben wir in unserem Detail-Post zu Claude Cowork auf Amazon Bedrock beschrieben.


Wann Google Cloud Vertex AI besser passt

Vertex kommt für zwei Zielgruppen infrage. Erstens: Unternehmen, die Google Workspace flächendeckend im Einsatz haben und ihre Kollaborations-Daten dort verarbeiten. Zweitens: Data-Teams, die BigQuery und Vertex-ML-Pipelines bereits produktiv fahren.

Der technische Pluspunkt gegenüber Bedrock ist Private Service Connect. Damit lässt sich Vertex-Inferenz so anbinden, dass der Traffic in der Google-Backbone bleibt und nie über public Internet läuft. In Kombination mit VPC Service Controls ergibt das ein härteres Netzwerk-Containment als Bedrock — allerdings mit höherem Konfigurationsaufwand.

Zweiter Pluspunkt: Web Search ist nativ dabei. Kein Zusatz-MCP, keine zusätzliche API-Subscription. Für Marktforschung, Competitive Intelligence und Due-Diligence-Workflows ist das ein klarer Vorteil.

Schwachpunkt: Claude läuft auf Vertex in der EU nur über die EU-Multi-Region und für ältere Modelle in Belgien (europe-west1), nicht in Frankfurt. Außerdem nutzen Anthropics Code-Beispiele den weltweiten Endpunkt, der ohne Anpassung auch außerhalb der EU verarbeitet. Für Konzerne mit harten Regional-Failover-Anforderungen kann das zum Thema werden.

Wir raten zu Vertex, wenn Sie Google-Cloud-native arbeiten und Web Search ohne Eigenbau wichtig ist. Für reine AWS-Shops ist der Mehrwert kaum zu rechtfertigen.


Wann Azure AI Foundry die pragmatische Wahl ist

Azure AI Foundry ist die natürliche Option für Microsoft-Stack-Unternehmen. Entra ID steht, Intune als MDM läuft, Purview und Defender sind eingebunden. In dieser Welt bedeutet „noch eine Plattform aufsetzen“ meist „vier Wochen politische Klärung“.

Foundry spart genau diese Klärung. Die bestehende Azure-Subscription dient als Inferenz-Backend und das bestehende Cost-Management greift. Rechtlich gilt allerdings nicht Ihre Microsoft-DPA: Für Claude ist Anthropic selbst Verarbeiter, unter Anthropics DPA, Data Zone Standard gibt es nur für die USA, und CSP-Subscriptions können Claude in Foundry nicht kaufen. EU-Verarbeitung läuft über Bedrock mit EU-Inferenzprofil. Claude Desktop wird über Intune verteilt, genauso wie Edge, Teams oder Office.

Web Search ist wie bei Vertex nativ verfügbar. Das macht Foundry zu einer starken Default-Wahl für Fachabteilungen in Microsoft-Shops, die viel recherchieren.

Das zweite Manko: API-Key-Auth als Standard. Azure Foundry nutzt einen Resource-Key für die Authentifizierung. Die Key-Rotation muss manuell geregelt werden, und die Revocation bei verlorenen Laptops ist weniger elegant als bei IAM Identity Center auf AWS. In der Praxis landen die Keys via Intune-Secret-Policies auf den Geräten — sauber, aber mit mehr Betriebsaufwand als AWS IAM.

Unsere klare Empfehlung: Foundry, wenn Ihre Cloud-Welt primär Azure ist, EU-Verarbeitung für den Anwendungsfall keine Pflicht ist und Sie keine harten Per-User-Governance-Anforderungen haben. Für reine Microsoft-Shops mit 500+ Mitarbeitern ist es oft die schnellste produktive Rollout-Variante.

Details zu Azure-spezifischen Integrationen finden Sie in unserer Azure Consulting Übersicht.


Die Matrix klärt die Technik. Ob die Variante zu Ihrer Abteilung passt, klärt eine Analyse.

Die Cowork-Einführung bewertet Ihre bestehenden Abläufe und vorhandene RPA, wählt mit Ihnen die passende Betriebsvariante und übernimmt danach die Freigabe-Stufe. 2.500 EUR Festpreis, Einstieg über die kostenlose Erstanalyse.

Cowork-Einführung ansehen

Wann ein LLM-Gateway die clevere Option ist

Der Gateway-Pfad ist die flexibelste — und die mit dem höchsten Eigenanteil. Statt Claude Desktop direkt gegen Bedrock, Vertex oder Foundry zu routen, zeigt die MDM-Konfiguration auf eine interne URL wie https://ai-gateway.internal.example.com/v1/messages. Hinter dem Gateway kann alles stehen: eigenes Routing zwischen mehreren Cloud-Providern, zentrale Rate-Limits, Prompt-Audit, Content-Filtering, Tenant-Isolation.

Voraussetzung: Der Gateway muss /v1/messages exponieren und die Header anthropic-beta sowie anthropic-version korrekt weiterreichen. Die gängigen Open-Source-Gateways (LiteLLM, LangSmith Proxy, eigene Implementierungen auf Envoy oder Kong) können das — oft nach ein paar Konfigurationszeilen.

Der mit Abstand größte Vorteil: Per-User-Rate-Limits. Nur über den Gateway lassen sich harte Obergrenzen pro Nutzer durchsetzen („Max. 500.000 Tokens pro Tag pro User“). Das ist bei Finanzinstituten oft nicht verhandelbar — Consumption-basierte Abrechnung ohne User-Cap ist dort ein KO-Kriterium.

Zweiter Vorteil: Wenn Sie Claude Code schon über einen Gateway zentralisiert haben, nutzt Cowork denselben Endpunkt. Kein zweites Setup, keine zweite Authentifizierung, keine zweite Audit-Pipeline.

# Beispiel: LiteLLM Gateway als Claude Cowork Backend
# /v1/messages Endpoint mit Bedrock-Backend
curl -X POST https://ai-gateway.internal.example.com/v1/messages 
  -H "Authorization: Bearer $USER_API_KEY" 
  -H "anthropic-version: 2023-06-01" 
  -H "anthropic-beta: prompt-caching-2024-07-31" 
  -d '{
    "model": "eu.anthropic.claude-sonnet-4-6",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hallo"}]
  }'

Der Nachteil: Sie betreiben den Gateway. Uptime, Skalierung, Incident-Response, Security-Patching — alles liegt bei Ihnen. Für Teams ohne Platform-Engineering-Kapazität ist das ein No-Go. Wer das Thema ernsthaft angeht, sollte parallel zum Platform-Engineering-Setup denken.

Wir raten zum Gateway, wenn Sie entweder bereits einen zentralen AI-Gateway betreiben oder harte Per-User-Governance-Anforderungen haben. Sonst ist der direkte Weg über Bedrock, Vertex oder Foundry schlanker.


Die Entscheidungs-Matrix in einem Bild

Wir haben die Fragen aus 40+ Bewertungsgesprächen in einen Entscheidungsbaum übersetzt:

  1. Haben Sie harte Per-User-Rate-Limits in der Compliance? → Ja: LLM-Gateway. Nein: weiter.
  2. Läuft Ihre Produktiv-Infrastruktur primär auf AWS? → Ja: Bedrock. Nein: weiter.
  3. Ist Ihre Cloud-Welt Microsoft-dominiert (Entra, Intune, Purview)? → Ja: Foundry. Nein: weiter.
  4. Nutzen Sie Google Workspace und BigQuery? → Ja: Vertex. Nein: Bedrock als Default.

In 80 Prozent der Fälle ist die Antwort nach zwei Fragen klar. Die restlichen 20 Prozent sind hybrid — meist Konzerne mit mehreren Clouds. Dort endet der Entscheidungsweg fast immer beim Gateway, weil nur der eine einheitliche Oberfläche über Multi-Cloud-Inferenz legt.


VDI und Remote-Arbeit: eine oft übersehene Einschränkung

Ein Punkt, der in jedem zweiten Projekt hochkommt und der in den Produktbeschreibungen leicht übersehen wird: VDI-Kompatibilität.

Claude Cowork läuft in VDI-Umgebungen nur, wenn nested virtualization unterstützt wird. Das funktioniert auf Azure Virtual Desktop, Windows 365 auf nested-virt-fähigen SKUs und Citrix/VMware Horizon auf selbst verwaltetem vSphere oder Hyper-V.

Nicht unterstützt sind: AWS WorkSpaces, AWS AppStream 2.0, Google Cloud Workstations und Citrix DaaS auf AWS oder GCP. GPU-Instanzen wie Azure N-Series oder vSphere mit PCI-Passthrough funktionieren auch nicht, weil sie kein nested virt exponieren.

Für on-prem vSphere- oder Hyper-V-Deployments ist nested virt meist standardmäßig aus und muss im VM-Template aktiviert werden. Anthropic liefert ein Readiness-Check-Binary für macOS, Windows x64 und Windows ARM64 — das sollte vor jedem VDI-Rollout gelaufen sein.

Wer FSLogix oder Roaming Profiles nutzt: der vm_bundles-Ordner (ca. 10 GB Baseline) darf nicht ins Roaming Profile wandern. Umleiten auf lokalen ephemeren Storage, sonst explodiert die Profil-Größe.

Die praktische Konsequenz: Wenn ein großer Teil Ihrer Mitarbeiter über VDI arbeitet und Ihre VDI-Plattform nicht auf der Liste steht, ist Claude Cowork aktuell kein Kandidat — egal welche Third-Party-Plattform Sie wählen. Das ändert nichts an Cowork selbst, sondern an der darunter liegenden Client-Architektur.


Kosten: Was Consumption in der Praxis heißt

Egal welche Plattform: Sie zahlen über Tokens, nicht über Seats. Die Faustregel aus unseren Projekten:

Ein gelegentlicher Nutzer (10-20 Minuten Claude pro Woche) verursacht 10-20 Euro Inferenz-Kosten pro Monat. Ein typischer Knowledge-Worker mit Claude als täglichem Begleiter landet bei 80-120 Euro monatlich. Ein Power-User, der Claude als Research- und Schreibassistent durchgehend einsetzt, kann auf 200-300 Euro kommen.

Für 500 Nutzer mit typischer Verteilung (300 gelegentlich, 150 täglich, 50 Power) rechnen wir mit etwa 30.000 Euro Inferenz-Kosten pro Monat. Bei Bedrock, Vertex und Foundry ist das die Total-Cost-of-Ownership. Beim Gateway-Setup kommen Betriebskosten hinzu — realistisch 3.000-6.000 Euro pro Monat für Betrieb und Monitoring eines robusten Gateways mit Per-User-Limits.

Die Einsparung gegenüber Claude Enterprise liegt in der Seat-Gebühr: Enterprise kostet laut Anthropic 20 US-Dollar pro Nutzer und Monat und rechnet die Nutzung zusätzlich zu API-Preisen ab. Bei vielen Gelegenheitsnutzern ist die Seat-Gebühr der größere Posten, bei wenigen Power-Usern fällt sie kaum ins Gewicht. Auf Bedrock, Vertex und Foundry kommt für EU-Verarbeitung ein Aufschlag von 10 Prozent auf den Tokenpreis dazu.


Cowork-Einführung für Fachabteilungen

Vier Plattformen verglichen. Ob Ihre Abteilung bereit ist, bleibt offen.

Pexon bewertet in der Analyse Ihre bestehenden Abläufe, prüft vorhandene RPA-Lösungen und wählt gemeinsam mit Ihnen die passende Betriebsvariante aus den vier Optionen oben, vor dem Rollout statt danach.

Ihre Investition: 2.500 EUR FestpreisEinmalig, unabhängig von der Zahl geprüfter Abläufe. Enthält Analyse und die anschließende Freigabe-Stufe.

Cowork-Einführung anfragen

Kostenlose Erstanalyse als Einstieg, keine Verpflichtung.

Häufig gestellte Fragen

Welche Claude Cowork Third Party Plattform ist am einfachsten aufzusetzen?

In reinen Microsoft-Shops ist Azure Foundry oft in der schnellsten Rollout-Zeit produktiv, weil Intune und Entra ID bereits etabliert sind. Bei bestehender AWS-Landing-Zone ist Bedrock genauso schnell. Der Zeitengpass ist selten die Technik, sondern interne Freigaben — Betriebsrat, Datenschutz und CISO brauchen in der Regel vier bis sechs Wochen, unabhängig von der Plattform.

Kann ich Claude Cowork Third Party auf mehreren Plattformen gleichzeitig betreiben?

Grundsätzlich ja, aber wir raten davon ab. Zwei parallele Inferenz-Backends verdoppeln den Betriebsaufwand (Monitoring, Cost-Attribution, Security) und verwirren die Nutzer. Wenn Multi-Cloud aus Regulierungsgründen nötig ist, sollten Sie einen LLM-Gateway davorschalten — damit wird aus zwei Clouds eine Oberfläche.

Bekomme ich mit Third Party alle Claude-Features?

Nein. Nicht verfügbar sind: der öffentliche Chat-Tab, Computer Use, Dispatch, Mobile-App, Voice-Mode, Claude in Chrome, der Skills-Marketplace und die Account-Management-Web-UI. Die Kernfunktionen (Projekte, Artefakte, Memory, File-Upload, MCP, Skills, Plugins) sind vollständig verfügbar.

Werden bei Claude Cowork Third Party Daten an Anthropic übertragen?

Nein. Prompts, Antworten, Tool-Inputs, Tool-Outputs und Dateien verlassen Ihre gewählte Cloud-Region nicht. Anthropic erhält ausschließlich anonymisierte Telemetrie (Token-Counts, Error-Codes, Geräte-Hash) — und auch die lässt sich per MDM-Konfiguration vollständig abschalten.

Funktioniert Claude für Excel, PowerPoint und Word auch mit Third Party?

Ja. Die Office-Add-ins unterstützen dieselben Third-Party-Backends (Bedrock, Vertex, Foundry, Gateway). Wichtig: Cowork und die Office-Add-ins kommunizieren nicht direkt miteinander, sie sind getrennte Clients, die zufällig dieselbe Inferenz-Plattform nutzen. Für den Setup-Prozess gibt es eine separate Dokumentation von Anthropic.


Nächster Schritt

Die Plattform-Entscheidung sollte nicht im Vakuum getroffen werden. Welche Cloud Sie nutzen, welche Compliance-Anforderungen Sie haben und ob Per-User-Governance greift, entscheidet gemeinsam — nicht nacheinander. Wir prüfen in drei Sessions Ihren bestehenden Stack, die Anforderungen aus Compliance und Betriebsrat und liefern eine belastbare Plattform-Empfehlung.


Verwandte Themen



Umsetzung im Unternehmen: KI als Managed Service für Unternehmen.

Wenn Sie den Vergleich bis zur Entscheidung treiben wollen: die Entscheidungsmatrix der vier Bezugswege stellt Claude Enterprise, Claude Platform on AWS, Bedrock mit Vertex AI und Foundry nach Datenverarbeiter, Datenort, Funktionsumfang und Kosten pro Kopf nebeneinander. Den technischen Überbau dazu finden Sie in Claude in der eigenen Cloud.

Microsoft Fabric. Bilder Blogtemplate Whitepaper

Claude Code im Unternehmen

  • Praxis-Guide für IT-Leiter – mit konkreten Einblicken zu Kosten, Sicherheit und Rollout von Claude Code im Unternehmen.

Beratungsgespräch

Sichern Sie sich Ihre kostenfreie Erstberatung

Analyse Ihres individuellen Cloud- oder KI-Bedarfs
Erste Empfehlungen zu Umsetzungsstrategien
Transparente Einblicke in unsere Methoden, Technologien & Referenzen