Wie Eon eine Multi-Cloud-Untersuchung mit einem MCP Gateway auf Amazon Bedrock AgentCore aufbaute

Dies ist ein Gastbeitrag, der in Zusammenarbeit mit Roei Zavida von Eon entstanden ist.

Unabhängige Softwareanbieter (ISVs), die KI-gestützte Produkte entwickeln, müssen Agenten und Menschen mit Dutzenden operativer Tools über mehrere Clouds hinweg verbinden, jedes mit unterschiedlichen Authentifizierungsmodellen, Netzwerkgrenzen und Zugriffsrichtlinien. Wenn diese Tools gleichzeitig AWS, GCP und Azure umfassen, vervielfacht sich die Integrationsfläche.

Dieser Beitrag beschreibt, wie Eon Amazon Bedrock AgentCore verwendete, eine Plattform zum Aufbau, zur Verbindung und zur Optimierung von Agenten in großem Maßstab mit beliebigen Frameworks oder Modellen. Eon nutzte sie, um werkelspezifische Anmeldeinformationen und lokale Model Context Protocol (MCP)-Prozesse durch ein einzelnes authentifiziertes Gateway zu ersetzen. Das Ergebnis gibt Entwicklern und autonomen Agenten vereinheitlichten Zugriff auf Untersuchungswerkzeuge über drei Clouds hinweg. Neue Ingenieure erreichen nun alle ihre Untersuchungswerkzeuge in etwa zwei Minuten statt der zuvor benötigten zwei Tage, um Anmeldeinformationen und lokale MCP-Server zu konfigurieren.

Über Eon

Eon bietet die Autonomous Data Foundation für das KI-Zeitalter. Die Plattform entdeckt und klassifiziert Cloud-Ressourcen über AWS, Azure und GCP hinweg. Sie stellt eine kontinuierliche, deduplizierte Sicherung bereit, die in Eons internen Messungen die Speicherkosten um bis zu 50 Prozent senkt. Sie erkennt außerdem Ransomware- und Rogue-Agent-Schäden und liefert live fundierten Kontext für KI-Agenten. All dies läuft über eine einzige schreibgeschützte AWS Identity and Access Management (IAM)-Rolle und speichert Daten in den Formaten Apache Parquet und Apache Iceberg. Eon wurde von ehemaligen AWS-Ingenieuren gegründet und betreibt seine Software-as-a-Service-Infrastruktur (SaaS) auf AWS.

Die Herausforderung

Eons internes Engineering-Team untersucht Produktionsvorfälle über mehrere Clouds und Dutzende operativer Systeme hinweg. Ein abgestürzter Kubernetes-Pod erfordert die Prüfung von Container-Protokollen, Grafana-Metriken, dem GitHub-Pull-Request (PR) des Deployments und dem Status der Verfügbarkeit des Cloud-Anbieters innerhalb derselben Sitzung.

Eon musste mehrere zentrale Anforderungen erfüllen:

• Konsolidierung von Anmeldeinformationen — Jedes neue Tool bedeutete eine weitere zu konfigurierende, sichernde und zu rotierende Integration, was mit wachsendem Werkzeugbestand immer schwerer konsistent zu halten war.
• Lokale MCP-Prozesse eliminieren — Jeder Entwickler führte mehrere MCP-Server lokal aus, was schwer zu standardisieren und aktuell zu halten war.
• Identitätstrennung — Ingenieure griffen mit rollenbasierten Berechtigungen auf jedes System zu, aber es gab keinen zentralen Ort, um festzulegen, welche Tools jede Person oder jeder Agent aufrufen durfte.
• Cross-Account-Zugriff ohne Netzwerk-Overhead — Das Hosting von MCP-Servern über mehrere AWS-Konten erforderte VPC-Peering (Virtual Private Cloud) oder AWS PrivateLink pro Konto, was Betriebskosten und Einrichtungsaufwand vervielfachte.
• Developer-Onboarding — Neue Ingenieure verbrachten rund 2 Tage mit der Konfiguration von Anmeldeinformationen und lokalen MCP-Servern, bevor sie ihren ersten Vorfall untersuchten.
• Agentenzugriff — Eons autonomer Site-Reliability-Engineering-Agent (SRE) (mit Claude auf Amazon Bedrock laufend) benötigte denselben Werkzeugzugriff wie Menschen, jedoch mit anderen Berechtigungen.

Ein wachsender Engineering-Personalbestand in Kombination mit einer sich schnell ausweitenden Menge an KI-Tools und MCPs machte die Pflege von Anmeldeinformationen und lokalen MCP-Servern zunehmend kostspielig. Dies veranlasste Eon, eine zentralisierte Lösung anzustreben.

Geprüfte Ansätze

Bevor Eon auf AgentCore aufbaute, wurden Alternativen bewertet:

Option 1: Zentralisierter Proxy mit eigener Authentifizierung

Jeder Harness hatte seine eigene Proxy-Konfiguration mit allen Zielen. Ein einzelner Reverse-Proxy, der alle Tools zusammenführte, mit einer eigenen Authentifizierungsschicht. Dies löste die Konsolidierung der Anmeldeinformationen, unterstützte jedoch nur Remote-MCP und erforderte den Aufbau und die Pflege von Tool-Protokollübersetzung, Sitzungsverwaltung und Autorisierungslogik von Grund auf. Der Implementierungs- und Wartungsaufwand war erheblich.

Option 2: Amazon Bedrock AgentCore Gateway

Das Amazon Bedrock AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, ist ein verwaltetes Gateway mit integrierter Identitätsföderation, Cedar-basierten Autorisierungsrichtlinien und Runtime-Hosting, das lokale MCP-Server in entfernte HTTP-Endpunkte umwandelt. Dies erfüllte alle Anforderungen ohne eigene Infrastruktur.

Eon wählte Option 2, weil sie Identitätstrennung, Cross-Account-Konnektivität und Richtliniendurchsetzung als verwaltete Funktionen bereitstellte statt als Code, den man selbst hätte entwickeln und pflegen müssen. Dies waren die einzigen beiden Optionen, die zur Debatte standen.

Lösungsübersicht

Eon setzte den vollständigen Amazon Bedrock AgentCore Stack ein: AgentCore Gateway, Policy in Amazon Bedrock AgentCore, AgentCore Runtime und AgentCore Identity – allesamt Funktionen von Amazon Bedrock AgentCore. Das folgende Diagramm zeigt, wie Client-Anfragen durch die Authentifizierungsschicht zu einem einzigen Gateway fließen. Das Gateway leitet autorisierte Tool-Aufrufe an Ziele weiter, die auf AgentCore Runtimes über mehrere AWS-Konten hinweg gehostet werden.

Abbildung 1: Eons zentrale Gateway-Architektur auf Amazon Bedrock AgentCore

Die Architektur besteht aus fünf Schichten:

Clients

Entwickler, die Claude Code, Cursor oder OpenAI Codex verwenden, verbinden sich mit einer einzigen MCP-URL. Ein autonomer SRE-Agent, der Claude auf Amazon Bedrock ausführt, verbindet sich mit demselben Gateway, jedoch mit einer anderen Identität.

Identitätsebene

Single Sign-On (SSO) auf Unternehmensebene wird über Amazon Cognito föderiert, das das JSON Web Token (JWT) ausstellt und an das Gateway übergibt. Amazon API Gateway steht davor als OAuth-Einstiegspunkt für Menschen und proxyt die MCP-Sitzung. Agenten authentifizieren sich über Cognito client_credentials Grants direkt am Gateway.

Ein Gateway, Zugriff nach dem Least-Privilege-Prinzip

Ein einzelnes AgentCore MCP Gateway dient als unternehmensweiter Eingang. Cedar-Policies im ENFORCE-Modus steuern, welche Principals welche Tools aufrufen dürfen. Leseoperationen stehen ausgewählten Gruppen zur Verfügung, nicht jedem authentifizierten Benutzer. Schreiboperationen sind auf kollaborative Aktionen mit geringer Auswirkung beschränkt, etwa das Kommentieren eines PR oder Tickets, und Produktionstools sind schreibgeschützt.

Policy in Amazon Bedrock AgentCore

Cedar-Policies ordnen jeden Principal zulässigen Tools zu. Schreiboperationen sind auf kollaborative Aktionen mit geringer Auswirkung beschränkt, etwa das Kommentieren eines PR oder Tickets, und Produktionstools sind schreibgeschützt. Das Gateway prüft jede tools/call Anfrage gegen Cedar, bevor sie an das Ziel weitergeleitet wird.

Ziele

Dutzende Ziel-MCP-Server, die hunderte Tools an dem einen Gateway bereitstellen, betrieben von AgentCore Runtimes, die auf mehrere AWS-Konten verteilt sind. Jede Runtime wandelt lokale stdio-basierte MCP-Server in Streamable-HTTP-Endpunkte um, die über das Gateway zugänglich sind.

Ein Entwickler öffnet seine integrierte Entwicklungsumgebung (IDE), konfiguriert eine einzige MCP-URL, authentifiziert sich über das Unternehmens-SSO, und das Gateway aggregiert hunderte Tools in eine einzige tools/list Antwort. Keine lokale Einrichtung und keine Tokens pro Tool.

Trennung von Identität und Zugriff

Die zentrale Sicherheitsentscheidung bestand darin, Lese- und Schreibgrenzen über Cedar-Policies auf Gateway-Ebene durchzusetzen.

Ein einzelnes Gateway, policy-durchgesetzte Trennung:

Das Gateway akzeptiert sowohl JWT-Tokens (Menschen über Unternehmens-SSO und Cognito) als auch client_credentials Tokens (Agenten). Cedar-Policies bestimmen, was jeder Principal tun darf. Menschen in genehmigten Gruppen erhalten Lesezugriff. Schreiboperationen erfordern explizite Cedar-Permits, die nur bestimmten Agenten-Identitäten gewährt werden.

Cedar verstärkt die Granularität pro Tool:

// Agent "sre-bot" can add comments on GitHub PRs
permit(
    principal == Agent::"sre-bot",
    action == Action::"tools/call",
    resource == Tool::"github_add_pr_comment"
);

// No human principal can invoke mutation tools
forbid(
    principal in Group::"humans",
    action == Action::"tools/call",
    resource in ResourceGroup::"write-tools"
);

Cedar-Policies werden als Code über GitHub-PRs mit Review-Kommentaren verwaltet, was dem Team Versionskontrolle und einen Audit-Trail für jede Berechtigungsänderung bietet.

Innerhalb des Gateways beschränken Cedar-Policies den Tool-Zugriff nach SSO-Gruppe, und Gruppen entsprechen den Berufsrollen. Ingenieure haben standardmäßig Zugriff auf Entwicklungs- und Testumgebungen. Der Produktionszugriff folgt Eons Sicherheits- und Compliance-Kontrollen: Er ist schreibgeschützt, wird just-in-time über einen Genehmigungsprozess gewährt und wird auditiert. Die Gruppe eines neuen Teammitglieds wird auf dieselbe Weise abgegrenzt, nach Rolle und nicht danach, welchen Dienst sie zufällig besitzt. Da jede Agenten-Aktion gegen Cedar im ENFORCE-Modus geprüft und auf einen Least-Privilege-Tool-Satz beschränkt wird, arbeitet der autonome Agent innerhalb sicherer, begrenzter Grenzen. Er kann nur die spezifischen Tools aufrufen, zu deren Aufruf seine Identität explizit berechtigt ist.

„Früher konnte unser interner Agent nicht auf dieselben Untersuchungstools zugreifen, die Entwickler nutzten. Danach nutzt er dasselbe Gateway mit seiner eigenen Identität und einem engeren Tool-Satz.“

— Roei Zavida, Senior DevOps Engineer, Eon

Kontenübergreifende Konnektivität

Eon betreibt Runtices über mehrere AWS-Konten hinweg, organisiert nach Umgebungs- oder Dienstgrenzen. AgentCore Gateway erreicht jede Runtime über IAM Cross-Account Role Assumption. Die Runtime in Konto B vertraut der AgentCore Gateway-Ausführungsrolle in Konto A über eine standardmäßige IAM-Trust-Policy.

Was dadurch entfiel:

• VPC-Peering-Konfiguration und Routing-Tabellenverwaltung über mehrere AWS-Konten hinweg.
• PrivateLink-Endpunktkosten pro Konto.
• Koordination von Sicherheitsgruppen zwischen Konten.
• Tage der Einrichtung pro neuem Konto (ersetzt durch eine einzige IAM-Trust-Policy, die in Minuten bereitstellbar ist).

Anbindungsmuster für Ziele:

Je nach Authentifizierungs- und Hosting-Modell des jeweiligen Tools verwendet Eon zwei primäre Anbindungsmuster. Die folgende Tabelle fasst zusammen, wann welches Muster zu verwenden ist, und gibt ein Beispiel.

Die meisten Ziele nutzen Runtime + IAM. Eon umhüllt nur ein entferntes MCP, um seinen Katalog zu verkleinern oder ein Credential einzuspeisen, das das Gateway anderweitig nicht bereitstellen kann.

Ablauf einer Investigation-Sitzung

Der folgende Ablauf verfolgt einen Entwickler, der einen Produktionsvorfall untersucht:

1. Authentifizierung. Der Entwickler öffnet Claude Code (oder Cursor/Codex) und verbindet sich mit der Gateway-MCP-URL. Die IDE initiiert OAuth über das unternehmenseigene SSO. Cognito stellt ein JWT aus, das die Identität des Entwicklers und seine Gruppenmitgliedschaften trägt.
2. Tool-Entdeckung. Das Gateway aggregiert `tools/list` von Dutzenden verbundenen Zielen und gibt ein vereinheitlichtes Manifest von Hunderten von Tools an die IDE zurück. Der Entwickler sieht alle verfügbaren Investigation-Tools in einer Liste.
3. Tool-Aufruf. Der Entwickler fragt: „Zeig mir den Fehlerquoten-Anstieg für den Payments-Service in der letzten Stunde.“ Der Agent der IDE wählt das Grafana-Query-Tool aus und sendet eine `tools/call`-Anfrage.
4. Policy-Auswertung. Das Gateway wertet die Anfrage gegen Cedar aus. Die Gruppenmitgliedschaft des Entwicklers gewährt Zugriff auf das Grafana-Tool. Die Anfrage wird akzeptiert.
5. Runtime-Ausführung. Das Gateway leitet die Anfrage an die Runtime weiter, die den Grafana-MCP-Server hostet (betrieben in einem separaten AWS-Konto). Die Runtime authentifiziert sich bei Grafana mit einem Service-Credential aus dem AgentCore Identity Vault, führt die Query aus und gibt die Ergebnisse zurück.
6. Korrerelation über Tools hinweg. Der Agent prüft anschließend den Kubernetes-Deployment-Status und den zugehörigen GitHub-PR, wobei jede Anfrage an unterschiedliche Runtimes geroutet wird. Der Entwickler sieht korrelierte Ergebnisse, ohne Tools zu wechseln oder sich neu zu authentifizieren.

Erkenntnisse bei Skalierung

Der Rollout an 100+ Entwickler und etwa 10,000 Sitzungen brachte Produktionsherausforderungen ans Licht:

Verwaltung der Cedar-Policy-Größe

Jedes Tool-Schema, das das Gateway vorindiziert, trägt zur Größe der Cedar-Policy bei. Mit Dutzenden Zielen, die umfangreiche Tool-Manifeste bereitstellen, näherte sich Eons Policy dem Größenlimit. Die Lösung: DYNAMIC-Listing-Modus für Ziele mit vielen Tools. Im DYNAMIC-Modus leitet das Gateway tools/list -Aufrufe zur Anfragezeit an den MCP-Server weiter, anstatt Schemas vorzuindizieren, und fügt der Policy null Bytes hinzu.

Der Nachteil ist, dass semantische Tool-Suche für DYNAMIC-Ziele nicht verfügbar ist. Eon betreibt eine hybride Konfiguration: DEFAULT-Modus für Ziele mit Per-User-OAuth (kleinere Tool-Anzahlen, benötigen vorindizierte Schemas für den Consent-Flow) und DYNAMIC-Modus für Ziele mit großen Katalogen.

OAuth-Sitzungsbindung für Standard-MCP-Clients

Claude Code, Cursor und Codex erwarten den OAuth- state parameter als Schutz vor Cross-Site-Request-Forgery (CSRF). AgentCore nutzt Session-URI-Binding. Eon baute einen Amazon API Gateway Shim, der zwischen den beiden Protokollen übersetzt, sodass Standard-MCP-Clients den OAuth-Flow ohne Änderungen abschließen können.

Filterung von Tool-Oberflächen

Einige MCP-Server stellen Hunderte von Tools bereit. Einzelne Entwickler benötigen nur eine Teilmenge für ihren Service. Eon baute einen Runtime-Wrapper, der das Tool-Manifest auf der Runtime-Ebene filtert, wodurch das Rauschen in tools/list -Antworten reduziert wird und versehentliche Aufrufe irrelevanter Operationen verhindert werden. Dieser Ansatz hält diese Ziele zudem im DEFAULT-Modus und bewahrt die semantische Suche sowie eingebettete Features, die der DYNAMIC-Modus opfert.

Ergebnisse

Die Single-Gateway-Architektur läuft seit mehreren Monaten im Produktivbetrieb für das interne Engineering-Team von Eon. Das deutlichste Ergebnis ist das Developer-Onboarding. Die Einrichtung des Zugriffs auf den gesamten Werkzeugsatz sank von rund zwei Tagen Konfiguration von Anmeldeinformationen und lokalen MCP-Servern auf etwa zwei Minuten. Ein neuer Ingenieur verbindet eine einzige Gateway-URL, authentifiziert sich über das unternehmenseigene SSO und sieht sofort die Tools, die seine Rolle erlaubt.

Das interne Agentenkonto macht den Großteil der eingesparten Zeit aus, da es durch das Gateway Zugriff auf mehr Kontext erhält, was die Genauigkeit der Untersuchungen verbessert. Ingenieure sparen die Zeit, die früher für die Einrichtung von KI-Tools aufgewendet wurde, da sie sich nur noch mit der Gateway-URL verbinden müssen.

Eon untersucht, wie dieselben Muster KI-Funktionen im eigenen Produkt unterstützen können.

„AgentCore hat uns ein authentifiziertes MCP-Gateway statt pro-Tool-Tokens und lokalen MCP-Prozessen verschafft. Entwickler und unser interner Agent erreichen nun Kubernetes, Grafana, GitHub und unsere Cloud-Konten über eine einzige URL.“

— Roei Zavida, Senior DevOps Engineer, Eon

Fazit

Dieser Beitrag beschrieb, wie Eon pro-Tool-Anmeldeinformationen und lokale MCP-Prozesse durch ein einziges Amazon Bedrock AgentCore MCP Gateway ersetzte. Das Ergebnis ist eine auf Cedar basierende Identitätstrennung, Cross-Account-Konnektivität ohne VPC-Peering und einheitlicher Tool-Zugriff für mehr als 100 Entwickler und autonome Agenten über drei Clouds hinweg. Die Single-Gateway-Architektur, die Cedar-Durchsetzung geringster Privilegien und der hybride DEFAULT- und DYNAMIC-Richtlinienmodus sind wiederverwendbare Muster für ISVs, die Agenten und Entwickler über mehrere Clouds hinweg mit Tools verbinden.

Um mehr über den Aufbau auf Amazon Bedrock AgentCore zu erfahren, lesen Sie diese Ressourcen:

• Amazon Bedrock AgentCore Gateway-Dokumentation.
• Amazon Bedrock AgentCore Runtime-Dokumentation.
• Getting Started with Amazon Bedrock AgentCore Workshop.

Über die Autoren