Amazon Web Services hat seinen ursprünglichen verwalteten Agentendienst für Amazon Bedrock zur neuen Einführung in den Wartungsmodus versetzt. Der Dienst, der früher als Amazon Bedrock Agents bekannt war, ist jetzt als Amazon Bedrock Agents Classic dokumentiert und laut AWS ab dem 30. Juli 2026 nicht mehr für neue Kunden verfügbar.

Das bedeutet nicht, dass bestehende Bereitstellungen nicht mehr funktionieren. AWS gibt an, dass aktuelle Kunden Bedrock Agents Classic weiterhin nutzen können, und gibt separat an, dass Amazon Bedrock-Modelle, Wissensdatenbanken und Leitplanken von der Änderung nicht betroffen sind. Aber die Richtung für neue Agenten-Workloads ist klar: AWS empfiehlt Amazon Bedrock AgentCore als vergleichbaren Pfad für neue oder migrierte Agentenanwendungen.

Für Teams, die auf Bedrock aufbauen, ist dies mehr als eine Änderung des Servicenamens. Es verschiebt die Standardarchitektur für AWS-gehostete Agenten von der älteren Bedrock Agents-Schnittstelle auf einen neueren Laufzeit- und Tooling-Stack, der sich auf AgentCore konzentriert. Für Plattformen, die ein AI-API-Gateway, eine LLM-Routing-Schicht oder eine Enterprise-Agent-Infrastruktur bereitstellen, erstellt der Cutoff eine Kompatibilitäts- und Migrationsfrage, die neben der normalen Modellauswahl steht.

Was sich am 30. Juli geändert hat

Die AWS-Dokumentation identifiziert Amazon Bedrock Agents jetzt als Amazon Bedrock Agents Classic. Die gleiche Anleitung zum Wartungsmodus besagt, dass Bedrock Agents Classic ab dem 30. Juli 2026 für Neukunden geschlossen ist, während Bestandskunden es weiterhin nutzen können.

Die praktische Bedeutung hängt vom AWS-Konto des Kunden und der aktuellen Nutzung ab. Bestehende Produktionssysteme, die auf Classic basieren, sollten nicht allein aufgrund der öffentlichen Wartungsmitteilung von einer sofortigen Abschaltung ausgehen. Allerdings sollten neue Teams, neue Konten und Organisationen, die die zukünftige Agenteninfrastruktur standardisieren, Classic als Legacy-Pfad und nicht als Standard-Bedrock-Agentendienst betrachten.

AWS weist neue und migrierende Kunden auf Bedrock AgentCore hin. Das Unternehmen beschreibt, dass AgentCore verwaltete Orchestrierung und eine breitere Palette von Produktionsagentenfunktionen unterstützt, einschließlich der Bereitstellung von Tools über das Model Context Protocol, Speicher, Identität, Beobachtbarkeit und Ablaufverfolgung. Diese Funktionen deuten darauf hin, dass AWS von einem engeren Builder für verwaltete Agenten zu einer allgemeineren Agentenlaufzeit für langlebige, Tool-verwendende Anwendungen übergeht.

Eine Grenze ist auch wichtig: Die Änderung betrifft die Orchestrierungsschicht für verwaltete Agenten von Bedrock, nicht die gesamte Bedrock-Plattform. Laut AWS sind Bedrock-Modelle, Wissensdatenbanken und Leitplanken nicht betroffen. Ein Team kann weiterhin Bedrock-Modellinferenz- oder -Abruf- und Sicherheitskomponenten verwenden, selbst wenn es den Agenten-Orchestrierungsdienst um ihn herum überarbeiten muss.

Warum dies für Agentenentwickler wichtig ist

Die Agenteninfrastruktur lässt sich immer schwerer als dünne Hülle um einen Modellaufruf behandeln. Ein Produktionsagent benötigt häufig Werkzeugberechtigungen, Speicherregeln, Identitätszuordnung, Protokollierung, Auswertung und Kostenzuordnung. Wenn sich die verwaltete Orchestrierungsschicht ändert, müssen Entwickler möglicherweise überprüfen, wie Eingabeaufforderungen, Toolschemata, Abruf, Leitplanken und Überwachung miteinander verbunden sind.

Dies gilt insbesondere für Unternehmen, die Bedrock Agents Classic als verwaltete Alternative zum Aufbau ihrer eigenen Orchestrierung eingeführt haben. Wenn diese Unternehmen jetzt zusätzliche Umgebungen erstellen, neue Geschäftseinheiten einbinden oder neue AWS-Konten einbauen, können sie auf eine andere Verfügbarkeit und empfohlene Architektur stoßen als die, die von ihren bestehenden Bereitstellungen verwendet wird.

Die Sperrung betrifft auch Anbieter und interne Plattformteams, die Bedrock hinter einer einheitlichen Schnittstelle abstrahieren. Eine Multi-Cloud- oder Multi-Modell-Plattform kann dies nicht einfach als „Route zu einem AWS-Modell“ behandeln. Es muss möglicherweise wissen, ob ein Kunde eine einfache Modellinferenz, einen Wissensdatenbank-Workflow, eine Guardrails-Richtlinie, einen klassischen Agenten oder eine von AgentCore gehostete Arbeitslast aufruft. Dabei handelt es sich um unterschiedliche Betriebsoberflächen mit unterschiedlichen Migrationsrisiken.

Für Model Gate-Benutzer und ähnliche Gateway-Kunden ist die Lektion, dass es beim LLM-API-Routing nicht mehr nur um Preis, Latenz und Modellqualität geht. Auch die Platzierung der Agenten ist wichtig. Ein Gateway kann dabei helfen, API-Schlüsselverwaltung, Nutzungsanalysen, Teamkontrollen und Ausgabentransparenz zu zentralisieren, muss aber dennoch die Fähigkeiten und den Lebenszyklusstatus der zugrunde liegenden Anbieterdienste berücksichtigen.

Wer ist betroffen?

Die am stärksten betroffene Gruppe sind AWS-Kunden, die neue Managed-Agent-Builds auf Bedrock planen. Wenn sie Bedrock Agents Classic noch nicht verwendet haben, sollten sie davon ausgehen, dass AgentCore der empfohlene Pfad ist. Teams, die bereits klassische Agenten ausführen, können diese laut AWS weiterhin verwenden, sollten jedoch bei langfristigen Roadmap-Entscheidungen den Wartungsstatus des Dienstes einplanen.

Cloud-Architekten sind betroffen, da Referenzarchitekturen möglicherweise aktualisiert werden müssen.Dokumentation, Terraform-Module, interne goldene Pfade und Sicherheitsüberprüfungen, bei denen Bedrock Agents Classic als Standardschicht für verwaltete Agenten angenommen wurde, sollten anhand der APIs, des Identitätsmodells, der Beobachtbarkeitsfunktionen und der Betriebsanforderungen von AgentCore überprüft werden.

Sicherheits- und Governance-Teams sind ebenfalls im Umfang enthalten. Der Schwerpunkt von AgentCore auf Identität, Tool-Offenlegung, Beobachtbarkeit und Nachverfolgung spiegelt die Probleme wider, die Unternehmen jetzt zu lösen versuchen: Welcher Benutzer oder Dienst handelt, welche Tools ein Agent aufrufen kann, welche Daten er abrufen kann, wie eine Entscheidung überprüft werden kann und wie außer Kontrolle geratene Tool-Schleifen oder teure Modellaufrufe erkannt werden.

Softwareanbieter, die auf Bedrock aufbauen, benötigen möglicherweise einen Dual-Support-Zeitraum. Bestehende Kunden nutzen möglicherweise weiterhin Classic, während Neukunden möglicherweise AgentCore benötigen. Das kann zusätzliche Tests, Feature-Flags, kundenspezifische Bereitstellungslogik und eine klarere Dokumentation darüber bedeuten, welcher Bedrock-Agentenpfad unterstützt wird.

Praktische Konsequenzen und offene Fragen

Der erste praktische Schritt ist die Bestandsaufnahme. Teams sollten ermitteln, ob sie Bedrock Agents Classic, einfache Bedrock-Modell-APIs, Wissensdatenbanken, Leitplanken oder benutzerdefinierte Orchestrierung außerhalb von Bedrock verwenden. Der Hinweis zum Wartungsmodus wirkt sich unterschiedlich auf diese Kategorien aus.

Der zweite Schritt besteht darin, Migrationsabhängigkeiten abzubilden, anstatt von einem direkten Lift-and-Shift auszugehen. Die Arbeitslast der Agenten kann von Tooldefinitionen, Abrufkonfiguration, Eingabeaufforderungsvorlagen, IAM-Berechtigungen, Prüfprotokollen und anwendungsspezifischer Fehlerbehandlung abhängen. Der Wechsel zu AgentCore bietet möglicherweise die Möglichkeit, die Beobachtbarkeit und die Identitätskontrolle zu verbessern, kann jedoch dennoch Integrationsarbeit erfordern.

Der dritte Schritt ist die Kosten- und Governance-Überprüfung. Neue Agentenlaufzeiten erleichtern oft die Anbindung weiterer Tools und die Ausführung autonomerer Arbeitsabläufe. Das erhöht den Wert von Nutzungsanalysen, Zuordnung auf Anfrageebene und Budgetkontrollen. In einer Gateway-Umgebung sollten Teams entscheiden, welche Aufrufe über eine zentrale Richtlinienebene fließen und welche innerhalb der von AWS verwalteten Orchestrierung bleiben.

Einige Details bleiben kontospezifisch. Unabhängige Kommentare haben darauf hingewiesen, dass die Berechtigung möglicherweise von der vorherigen Kontonutzung abhängt und dass einige neu veröffentlichte Modelle nach dem Cutoff möglicherweise nicht über Classic verfügbar sind. Diese Punkte sollten anhand des AWS-Kontos des Kunden und der aktuellen Dokumentation zum Wartungsmodus von AWS überprüft werden, bevor sie als Richtlinie behandelt werden.

Das größere Signal ist klar genug: AWS verlässt Bedrock-Agenten nicht, verlagert jedoch die Arbeit neuer Agenten von der ursprünglichen Bedrock Agents-Schnittstelle weg. Für Entwickler und Plattformteams ist die sichere Annahme, dass sich zukünftige Investitionen in AWS-Agenten auf AgentCore konzentrieren werden, während Bedrock Agents Classic zu einem Kompatibilitätsproblem für bestehende Bereitstellungen wird.