AWS Professional Services hat ein Multi-Agenten-System detailliert beschrieben, das große Cloud-Migrationen in Unternehmen automatisieren soll, wobei Amazon Bedrock AgentCore zur Koordination von Erfassung, Infrastrukturcode-Erzeugung, Governance und Post-Migrations-Betrieb eingesetzt wird.

Das System ist auf Migrationsprogramme mit Hunderten von Anwendungen ausgerichtet, bei denen manuelle Erfassung und Infrastrukturentwicklung mehr Zeit in Anspruch nehmen können als der eigentliche Umzug. AWS sagt, sein internes Framework habe die Entwicklung von Infrastructure as Code pro Anwendung von drei oder vier Wochen auf Minuten reduziert, und zwar über ein Portfolio von mehr als 300 Anwendungen hinweg. Dieses Ergebnis stammt aus internen Projektnachverfolgungsdaten und wurde nicht unabhängig verifiziert.

Die Veröffentlichung ist bedeutsam, weil AgentCore damit nicht einfach als Laufzeitumgebung für einzelne Assistenten dargestellt wird, sondern als Steuerungsebene für einen Workflow, der Bewertung, Bereitstellung und Betrieb umfasst. Für Technologie-Teams in Unternehmen lautet die wichtigere Frage, ob agentische Automatisierung wiederholbare, kontrollierte Migrationsarbeit liefern kann, ohne die menschliche Freigabe bei Infrastrukturentscheidungen mit hoher Auswirkung zu entfernen.

Ein Migrations-Workflow, aufgeteilt auf spezialisierte Agenten

AWS beschreibt ein Framework, das von AWS Professional Services mit dem Strands Agents SDK erstellt wurde. Statt ein einziges Allzweckmodell der gesamten Migration zuzuweisen, verteilt die Architektur die Arbeit auf Agenten mit enger gefassten Zuständigkeiten.

Ein Intake-Agent automatisiert Anwendungs-Erkennung, Abhängigkeitszuordnung und die Definition einer Zielarchitektur. Ein IaC-Agent erstellt dann Infrastruktur as Code gemäß den Sicherheitspraktiken und Standards eines Unternehmens. Ein Migration-Intelligence- und Governance-Agent erzeugt Portfolio-Reports, Well-Architected-Assessments und Governance-Informationen über Tools wie Jira, Confluence und Webex hinweg.

Nach der Bereitstellung überwacht ein SRE-Agent migrierte Workloads, erkennt potenzielle Verschlechterungen und unterstützt automatisierte Behebungen. AWS nennt außerdem angrenzende Dienste für spezifische Migrationstätigkeiten, darunter AWS Database Migration Service für unterstützte Schema-Konvertierung und Datenbank-Cutover sowie AWS Transform für die Modernisierung älterer Anwendungen.

Diese Aufteilung spiegelt die unterschiedlichen Risikoprofile in einem Migrationsprogramm wider. Die Erfassung erfordert das Extrahieren von Fakten aus Dokumenten und bestehenden Systemen. Die Code-Erzeugung erfordert die Einhaltung von Infrastrukturstandards. Governance erfordert Sichtbarkeit auf Portfolio-Ebene, während der Betrieb Zugriff auf Live-Systeme und sorgfältig kontrollierte Behebungen verlangt. Diese Aufgaben als separate Agentenrollen zu behandeln, kann Berechtigungen und Bewertung besser handhabbar machen, als einem einzigen Agenten weitreichende Autorität zu geben.

Wie Amazon Bedrock AgentCore in das System passt

Laut dem AWS Machine Learning Blog wird jeder Agent durch ein Foundation Model, einen System-Prompt und eine Reihe von Tools definiert. Amazon Bedrock AgentCore Runtime hostet die Agenten in einer serverlosen Umgebung mit Sitzungsisolierung und Unterstützung für Multi-Agenten-Orchestrierung.

Die Agenten greifen über Model Context Protocol-Tools auf externe Funktionen zu. AgentCore Gateway kann APIs, AWS Lambda-Funktionen und bestehende Dienste in MCP-kompatible Tools umwandeln, sodass das Framework Migrationsagenten mit Unternehmenssystemen verbinden kann, ohne jede Integration um eine neue Schnittstelle herum neu aufbauen zu müssen.

Die Identität wird über AgentCore Identity verwaltet, das nach Angaben von AWS Aufrufe mit eingeschränkten AWS Identity and Access Management-Rollen und dem Identitätsanbieter einer Organisation authentifiziert. Das ist ein zentraler Punkt für Infrastrukturautomatisierung: Die praktische Sicherheitsgrenze ist nicht nur die Anweisung des Modells, sondern auch das, was jeder Agent technisch lesen, ändern oder ausführen darf.

AWS sagt, dass das Framework während des gesamten Migrationslebenszyklus Sicherheitskontrollen anwendet und Menschen für Entscheidungen verantwortlich hält. Die Quelle nennt jedoch nicht die genauen Freigabepunkte, Rollback-Mechanismen oder Bewertungsschwellen der internen Bereitstellung, daher sollten Teams nicht annehmen, dass das beschriebene Muster automatisch produktionsreife Kontrollen für jede Umgebung bietet.

Die Daten hinter dem Leistungsversprechen

Die stärkste Effizienzbehauptung in der Ankündigung stammt vom Anbieter selbst. AWS schreibt die Reduzierung von drei oder vier Wochen IaC-Entwicklung pro Anwendung auf Minuten über ein Portfolio von mehr als 300 Anwendungen seinen internen Projektnachverfolgungsdaten zu. Der Blog liefert keine vollständige Vorher-Nachher-Methodik, keine Details zur Komplexität jeder Anwendung, keinen Umfang der menschlichen Prüfung und keinen Anteil des generierten Codes, der ohne wesentliche Änderungen akzeptiert wurde.

Diese Unterscheidung ist wichtig. „Minuten“ kann die erste Generierung beschreiben und nicht den gesamten Weg zu genehmigter, getesteter, sicherer und bereitgestellter Infrastruktur. Bei Migrationsarbeit in Unternehmen können Validierung, Ausnahmebehandlung, Netzwerkentscheidungen, Datenabhängigkeiten, Compliance-Prüfungen und Änderungsmanagement weiterhin erheblich sein, selbst wenn das Schreiben von Code automatisiert ist.

Die verfügbaren Belege zeigen dennoch, was AWS präsentiert: eine funktionierende interne Architektur, die speziell entwickelte KI-Agenten, Unternehmenswerkzeuge und AWS-Migrationsdienste kombiniert. Sie belegt jedoch noch keine allgemein wiederholbare Zeitersparnis über Branchen oder Anwendungsportfolios hinweg. Die zweite Quelle in diesem Cluster ist ein von AWS kontrollierter Blog, während der bereitgestellte Wire-Beitrag keinen zusätzlichen Artikeltext oder unabhängige Berichterstattung enthält.

Was das für Cloud-Migrationsteams bedeutet

Für Entwickler bietet das Framework ein Referenzmuster, um KI-Agenten mit vorhandenen Migrationsdaten und Betriebssystemen zu verbinden. Die am besten wiederverwendbare Idee ist die Trennung von Agenten nach Lebenszyklusphase und Berechtigungsumfang. Ein Erfassungsagent könnte Zugriff auf Inventare und Architekturunterlagen haben, während ein Infrastrukturagent Dateien erzeugt, aber keine direkten Berechtigungsrechte für Produktivbereitstellungen besitzt. Ein Betriebsagent könnte Telemetrie prüfen und Behebungen vorschlagen, bevor ein Mensch oder eine Richtlinie Änderungen genehmigt.

Diese Struktur kann auch Tests konkreter machen. Teams können die Genauigkeit der Erfassung über Ergebnisse der Abhängigkeitszuordnung bewerten, generiertes IaC gegen Richtlinien- und Sicherheitsprüfungen messen und operative Agenten an Alarmpräzision, Erfolg von Behebungen und Rollback-Verhalten messen. Das sind nützlichere Kennzahlen als nur die Geschwindigkeit der Modellantwort.

Für Unternehmenskäufer liegt der zentrale Kompromiss zwischen schnellerem Standardgeschäft und den Kosten für die Steuerung des Agentenzugriffs. Die Laufzeit-, Gateway- und Identitätsfunktionen von AgentCore decken Teile von Bereitstellung und Autorisierung ab, aber Organisationen benötigen weiterhin Richtlinien zur Modellauswahl, Audit-Protokolle, Umgebungstrennung, Secret-Management, menschliche Freigaben und einen Prozess für Anwendungen, die nicht in Standardmuster passen.

Der Ansatz könnte besonders relevant für Programme zum Verlassen von Rechenzentren mit festen Fristen sein, bei denen repetitive Erfassung und Codevorbereitung eine Warteschlange an Arbeit erzeugen. Weniger klar ist, wie gut das System bei hochgradig angepassten Systemen, undokumentierten Abhängigkeiten oder Migrationen mit erheblichem Anwendungs-Redesign funktioniert. Die Einbeziehung von AWS DMS und AWS Transform deutet darauf hin, dass die Orchestrierungsebene allgemeine Agenten mit spezialisierten Diensten kombinieren und nicht jedes Migrationstool ersetzen soll.

Worauf man als Nächstes achten sollte

Die nächsten nützlichen Signale werden unabhängige Fallstudien sein, die die gesamte Migrationszeit zeigen, nicht nur die Zeit für die IaC-Erzeugung. Käufer sollten auf Zahlen achten, die den Prüfaufwand, den Bereitstellungserfolg, Rollback-Raten, Sicherheitsbefunde und den Anteil der ohne maßgeschneiderte Entwicklung bearbeiteten Anwendungen abdecken.

Weitere Details zu den menschlichen Freigabepunkten des Frameworks würden ebenfalls seine betriebliche Reife klären. Beispiele für abgelehnte oder korrigierte Agentenausgaben, Audit-Trails aus AgentCore Identity und Richtlinien für automatisierte Behebungen würden Teams helfen, das Risiko einzuschätzen.

Schließlich werden die Verfügbarkeit wiederverwendbarer Referenzimplementierungen, unterstützter Modelle nach AWS-Region und Integrationen über die im Blog genannten Tools hinaus zeigen, ob dies ein Muster von AWS Professional Services bleibt oder zu einer breit nutzbaren Plattformarchitektur wird. Die Übernahme durch Migrationspartner und Belege von Kunden außerhalb von AWS würden ein stärkeres Marktsignal liefern als das derzeitige interne Ergebnis.

Creati.ai-Perspektive

AWS positioniert AgentCore als Infrastruktur für koordinierte Enterprise-KI-Agenten, und Cloud-Migration ist ein glaubwürdiger Testfall, weil die Arbeit repetitiv ist, aber dennoch spezialisiertes Urteilsvermögen erfordert. Der Wert der Architektur wird wahrscheinlich weniger aus autonomen Entscheidungen entstehen als daraus, verstreute Migrationstätigkeiten in kontrollierte, überprüfbare Workflows zu verwandeln.

Die gemeldete Beschleunigung ist bemerkenswert, sollte aber als interner Benchmark und nicht als Ergebnis für den Gesamtmarkt gelesen werden. Für KI-Entwickler und Unternehmen ist die dauerhafte Lehre, enge Agentenverantwortlichkeiten mit strikten Identitätsgrenzen, messbaren Prüfpunkten und operativen Nachweisen zu kombinieren, bevor generierte Infrastruktur oder automatisierte Behebungen Produktivsysteme beeinflussen dürfen.