AWS Bedrock vs. Azure AI Foundry vs. Google Vertex AI

Die eigentlich relevante Frage bei AWS Bedrock, Azure AI Foundry und Google Vertex AI ist nicht, welcher Anbieter in diesem Quartal das stärkste Modell hat. Die Modellqualität ändert sich schnell, die drei Kataloge überschneiden sich stark, und jede ernstzunehmende Anwendung ruft ohnehin meist mehr als ein Modell auf. Die eigentliche Entscheidung betrifft die Frage, welches Control Plane am besten zu den Systemen passt, die bereits Identität, Daten, Netzwerk, Observability und operative Verantwortung tragen — denn einen Prompt zwischen Anbietern zu verschieben ist trivial, alles rund um diesen Prompt neu aufzubauen dagegen nicht.

Die Plattform ist Teil der Architektur

Diese drei Produkte sollten als Anwendungsplattformen verstanden werden, nicht als austauschbare Modell-Endpunkte. Einen Prompt von der einen zur anderen zu verschieben, dauert Minuten. Die IAM- oder Entra-Berechtigungsgrenzen, die Retrieval-Pipeline, die Tool-Autorisierung, die Audit-Trails, die private Konnektivität, die Evaluierungs-Jobs und die Deployment-Workflows rund um diesen Prompt neu aufzubauen dagegen nicht.

AWS Bedrock passt am natürlichsten, wenn eine Anwendung bereits innerhalb von AWS lebt und ihr Betriebsmodell bereits auf IAM, VPCs, CloudWatch, CloudTrail, S3 und AWS-eigenen Datendiensten läuft. Die Funktion Knowledge Bases kann Ingestion, Indexierung, Retrieval und Connectors zu Quellen wie SharePoint, Confluence, Google Drive und OneDrive verwalten, inklusive dokumentenbasierter Zugriffskontrollen für die Connectors, die dies unterstützen.

Azure AI Foundry — von Microsoft mittlerweile in Microsoft Foundry umbenannt — ist dort am stärksten, wo Entra-Identität, Azure AI Search, Microsoft-365-Inhalte und Azure-Netzwerke bereits das Fundament des Unternehmens bilden. Der Agent Service erlaubt Teams, zwischen deklarativen Prompt-Agenten und eigenen, containerisierten Hosted Agents zu wählen, während ein verwalteter Endpunkt, Session-State, Identität, Tools, Skalierung und Tracing erhalten bleiben — was wichtig ist, wenn ein Agent als Enterprise Principal auftreten muss und nicht nur ein Modell aufruft.

Google Vertex AI ist die naheliegendste Erweiterung für Organisationen, die Google Cloud bereits für Daten, ML und Analytics einsetzen: Es verbindet generative KI mit der breiteren Vertex-ML-Plattform, während Model Garden Googles eigene Modelle neben ausgewählten offenen und Drittanbieter-Modellen zugänglich macht. Das stärkste Argument lautet selten „Gemini überall einsetzen", sondern eher „KI-Anwendungen nah an den Daten, der Evaluierung und den ML-Operations halten, die in GCP bereits etabliert sind."

Die Modellwahl ist eine bewusste Ebene, keine Einkaufsliste

Alle drei Plattformen unterstützen eine Multi-Modell-Strategie, doch ihre Kataloge lassen sich eher als Deployment-Verträge lesen denn als Einkaufslisten. Die Verfügbarkeit eines bestimmten Modells kann je nach Region, Account-Konfiguration, Kontingent, Anbieterbedingungen und Funktionsumfang variieren — AWS macht das explizit, da der Zugriff auf Drittanbietermodelle in Bedrock Marketplace-Berechtigungen, anbieterspezifisches Onboarding und eine Lizenzzustimmung erfordern kann, die vor dem Produktiveinsatz geprüft werden muss.

Das ist relevant, weil die Modellauswahl selten eine einmalige Entscheidung ist. Teams kombinieren routinemäßig ein günstigeres Modell für Extraktion, ein leistungsstärkeres für komplexes Reasoning, ein dediziertes Embedding-Modell für Retrieval und ein spezialisiertes multimodales Modell für Dokumente oder Bilder — und die Plattform muss diese Entscheidungen steuerbar machen, ohne jedes Anwendungsteam zu zwingen, Authentifizierung, Kontingente, Logging und Datenverarbeitung von Grund auf neu aufzubauen.

Bedrock ist attraktiv, wenn diese Optionsvielfalt neben AWS-Kontrollen auf Account-Ebene bestehen muss. Azure AI Foundry passt, wenn der Modellzugriff neben Azure OpenAI und Entra-gesteuerten Enterprise-Tools stehen soll. Vertex AI funktioniert besonders gut, wenn Geminis native Multimodalität oder Long-Context-Fähigkeit zum Workload passt, während Model Garden Raum für andere Modelle lässt. Es gibt hier eine Grenze, die es nicht zu überschreiten gilt: Eine schlanke, portable Schnittstelle über Inferenz, strukturierte Outputs, Embeddings und Tool Calls zu bauen, ist solides Engineering — sie verhindert, dass der Anwendungscode fest an einen Anbieter geschweißt wird. Anzunehmen, dass sich darunter alles über alle Anbieter hinweg gleich verhält, ist es dagegen nicht: Tokenisierung, Safety-Verhalten, Context-Limits, Latenz und regionale Verfügbarkeit unterscheiden sich je nach Plattform, und eine portable Schnittstelle verbirgt diese Unterschiede vor der Anwendung nur — sie lässt sie nicht verschwinden.

Retrieval ist zuerst ein Autorisierungsproblem, erst dann ein RAG-Problem

Die meisten Enterprise-KI-Anwendungen scheitern beim Retrieval, bevor sie beim Prompting scheitern, und der schwierige Teil war nie das Aufteilen von Dateien in Chunks. Schwierig ist sicherzustellen, dass eine Antwort dieselben Berechtigungen, Aufbewahrungsregeln, Provenienz und Incident-Grenzen respektiert wie die Systeme, aus denen sie abgerufen wird.

Bedrocks verwaltete Knowledge Bases reduzieren den operativen Aufwand rund um Ingestion und Retrieval, doch diese Bequemlichkeit sollte die Architektur darunter nicht verdecken: Teams müssen weiterhin entscheiden, wie Quellberechtigungen synchronisiert werden, wie Chunking gesteuert wird und ob sich die Retrieval-Qualität anhand repräsentativer Fragen messen lässt. Azure AI Foundry passt oft leichter, wenn das Autorisierungsmodell bereits auf Entra-Identitäten läuft und der Wissensbestand von Azure- und Microsoft-365-Ressourcen dominiert wird — der Integrationsaufwand verschwindet dabei nicht, er verändert nur seine Form: vom Aufbau einer parallelen Zugriffskontrollebene hin zur Abbildung der Unternehmensidentität in einen Agenten-Workflow. Vertex AI ist besonders überzeugend, wo operative Daten bereits in BigQuery, Cloud Storage oder Cloud SQL liegen, und seine Agent-Laufzeitumgebung unterstützt VPC Service Controls, sodass ein bereitgestellter Agent den Zugriff auf Google-Dienste innerhalb eines definierten Sicherheitsperimeters behält.

Der praktische Test, der für alle drei gilt: Kann die Plattform Quellberechtigungen zum Zeitpunkt des Retrievals durchsetzen, zeigen, warum ein Dokument abgerufen wurde, bewerten, ob es die Antwort verbessert hat, und einen fehlerhaften Korpus isolieren, ohne die gesamte Anwendung lahmzulegen? Wenn nicht, ist das RAG-System noch ein Prototyp — unabhängig davon, auf welcher Cloud es läuft.

Managed Agents reduzieren Infrastruktur, nie die Verantwortlichkeit

Agent-Plattformen zahlen sich aus, wenn eine Anwendung State, Tool-Ausführung, Retrieval, Policy Enforcement und Lifecycle-Management rund um Modellaufrufe benötigt — sie ersetzen kein Anwendungsdesign. Ein Agent, der auf Produktivsysteme zugreifen kann, braucht weiterhin dasselbe Threat Modeling, dieselben Autorisierungsgrenzen, Idempotenz, Auditierbarkeit, Rollback-Verhalten und Rate Limiting wie jedes andere Stück Automatisierung.

Bedrock Agents bieten einen verwalteten Weg, um Modelle, Knowledge Bases und Action Groups zu kombinieren, wobei AWS einen Großteil der Orchestrierung übernimmt, während Teams die Actions, Prompts, Tests und Versionierung konfigurieren. Azure AI Foundry hat die klarste Trennung zwischen prompt-definierten Agenten und gehosteten, codebasierten Agenten, was es zu einer starken Option macht, wenn eine Anwendung einfach beginnt und später eine individuelle Orchestrierung oder eine bestimmte Laufzeitumgebung benötigt. Vertex AIs Agent Engine überzeugt am meisten, wenn die Agentenausführung neben einem bestehenden GCP-Daten- oder ML-Workflow stattfinden soll, und seine Evaluierungsfunktionen können prüfen, ob ein Agent definierte Aufgaben anhand eines Datensatzes tatsächlich erfüllt — nützlicher, als eine Demo-Konversation danach zu beurteilen, wie sie sich „anfühlt".

Der sinnvolle Standardansatz ist bei allen dreien meist bescheiden: mit deterministischem Anwendungscode rund um Modellaufrufe beginnen, Tools mit Least-Privilege-Zugangsdaten ergänzen und erst dann auf autonome Planung setzen, wenn sie den Workflow nachweislich verbessert.

Safety, Observability und die eigentliche Entscheidung

Safety muss bei jeder dieser Plattformen in den gesamten Request-Pfad eingebaut sein, nicht nachträglich an die finale Antwort angeflanscht werden — eine Policy, die nur den Output prüft, lässt Retrieval und Tool-Ausführung einer ganz anderen Klasse von Fehlern ausgesetzt. Bedrock Guardrails lassen sich über Inferenz, Agenten, Knowledge Bases und Flows hinweg anwenden, sodass die Policy-Durchsetzung wiederverwendbar ist, statt für jeden Use Case dupliziert zu werden. Azure AI Foundrys Vorteil liegt darin, wie selbstverständlich sich seine Safety- und Agenten-Kontrollen mit Entra-Identitäten, Azure RBAC und privatem Networking verbinden lassen — auf Kosten der operativen Komplexität, die mit privatem DNS, Endpoint-Freigaben und Rollenzuweisungen einhergeht. Vertex AI gibt GCP-Organisationen vertraute Primitive an die Hand — IAM, Datenresidenz-Kontrollen, Access Transparency, VPC Service Controls —, mit dem wichtigen Vorbehalt, dass diese die Plattformgrenze absichern, ohne einen unsicheren Prompt oder ein zu weit gefasstes Tool automatisch sicher zu machen; diese Verantwortung bleibt bei der Anwendung.

Dieselbe Logik gilt für Observability. Eine Demo beweist, dass ein Modell einen Prompt beantworten kann, doch ein Produktivdienst muss beantworten können, welche Modellversion eine bestimmte Anfrage bearbeitet hat, welche Dokumente dabei abgerufen wurden, was die Reproduktion eines Fehlers kosten würde und ob sich die Latenz nach der letzten Änderung verschlechtert hat. CloudWatch, Application Insights und Vertex' eigenes Monitoring können diese Fragen jeweils unterstützen, doch keines von ihnen ersetzt die Notwendigkeit eines dauerhaft gepflegten Evaluierungs-Sets, das vor dem ersten Produktiv-Rollout aufgebaut und getestet wurde.

In der Summe folgt die Entscheidung meist der Cloud-Grenze, in der eine Organisation bereits operiert. Bedrock wählen, wenn der Dienst primär in AWS liegt und das Team Multi-Modell-Zugriff will, ohne eine separate KI-Plattform aufzusetzen. Azure AI Foundry wählen, wenn Microsoft-Identität und Enterprise-Workflow der wichtigste Integrationspunkt sind. Vertex AI wählen, wenn die Anwendung neben einem bestehenden GCP-Daten- und -ML-Bestand angesiedelt ist. Für eine wirklich multi-cloud-fähige Organisation ist die tragfähigere Antwort oft eine kleine, anbieterneutrale Anwendungsschicht mit einer primären Plattform, die für Identität, Retrieval, Telemetrie und Betrieb ausgewählt wird — das bewahrt einen Ausstiegsweg, ohne die Verantwortung auf drei unvollständige Implementierungen zu verteilen.

Die Plattform, die diese Entscheidung für sich gewinnt, ist jene, die das Produktivsystem leichter nachvollziehbar macht, wenn etwas ausfällt. Eine Plattform, die den Modellzugriff verbessert, dabei aber Identität, Governance und Incident Response fragmentiert, hat Komplexität nicht beseitigt — sie hat sie nur an eine weniger sichtbare Stelle verschoben.