Amazon Web Services hat den AWS Well-Architected Agent als Preview vorgestellt. Der KI-gestützte Dienst untersucht AWS-Umgebungen anhand des Well-Architected Frameworks und empfiehlt Änderungen bei Kosten, Sicherheit, Leistung und Resilienz. Nach Angaben des Unternehmens deckt die Analyse mehr als 65 AWS-Dienste ab.
Der Agent soll nicht nur allgemeine Hinweise ausgeben. Er kann einzelne Ressourcen bewerten, finanzielle Auswirkungen beziffern, sofern das möglich ist, und konkrete Umsetzungspakete einschließlich Änderungen an Infrastructure-as-Code liefern. Verfügbar ist die Preview zunächst in US East (N. Virginia), US East (Ohio) und US West (Oregon). Analysiert werden können Workloads aus allen kommerziellen AWS-Regionen. Voraussetzung ist ein aktiver AWS Support Plan.
Der operative Unterschied zu einem weiteren Cloud-Dashboard liegt im Weg von der Prüfung zur Änderung: AWS übersetzt seinen eigenen Architekturstandard in ein System, das nicht nur Abweichungen findet, sondern bereits den passenden Umbau vorbereitet. Damit wird aus einem Beratungsrahmen ein skalierbares Produkt. Die Verantwortung für die Freigabe verschwindet dadurch allerdings nicht.
Aus einem Prüfkatalog wird eine laufende Architekturberatung
Das Well-Architected Framework beschreibt seit Jahren, wie AWS-Systeme nach Auffassung des Anbieters aufgebaut werden sollten. Solche Reviews mussten bislang wesentlich stärker von Cloud-Architekten, AWS-Mitarbeitern oder spezialisierten Partnern durchgeführt werden. Bei großen Umgebungen ist das aufwendig: Ressourcen verändern sich fortlaufend, Anwendungen bestehen aus zahlreichen Diensten, und dieselbe Konfiguration kann je nach Geschäftsziel unterschiedlich bewertet werden.
Vom AWS-Workload zur kontrollierten Änderung
Das Diagramm zeigt, wie der Well-Architected Agent eine AWS-Umgebung analysiert, Empfehlungen priorisiert und IaC-Änderungen für eine menschlich kontrollierte Umsetzung vorbereitet.
Der neue Agent soll Ressourcenkonfigurationen, Auslastungsdaten und Anwendungstopologien zusammenführen. Seine Empfehlungen lassen sich an deklarierten Geschäftszielen ausrichten. Zudem weist das System auf Zielkonflikte zwischen den Säulen des Frameworks hin. Eine günstigere Konfiguration kann beispielsweise zulasten von Leistung oder Ausfallsicherheit gehen. AWS verspricht daher keine abstrakte Bestkonfiguration, sondern eine Priorisierung anhand des vom Kunden vorgegebenen Ziels.
Die Ergebnisse reichen von Befunden zu einzelnen Ressourcen über konsolidierte Empfehlungen für eine Anwendung bis zu breiteren Architekturmustern. Das ist wichtig, weil Cloud-Kosten und Betriebsrisiken häufig nicht an einer isolierten Instanz hängen, sondern am Zusammenspiel mehrerer Dienste.
Der entscheidende Schritt ist der vorgeschlagene Code
Besonders relevant ist die Verbindung zu Infrastructure as Code. Der Well-Architected Agent kann Änderungen für Terraform, AWS CloudFormation und das AWS Cloud Development Kit vorschlagen. Außerdem kann er IaC-Vorlagen vor ihrer Bereitstellung prüfen und Abweichungen von den AWS-Empfehlungen markieren.
Damit rückt die Architekturprüfung näher an den regulären Entwicklungs- und Betriebsprozess. Ein Befund muss nicht mehr zuerst manuell in ein Ticket, anschließend in eine technische Änderung und schließlich in überprüfbaren Code übersetzt werden. Der Agent kann einen Teil dieser Kette vorbereiten. Unternehmen können die vorgeschlagenen Änderungen in Versionskontrolle übernehmen, als Differenz prüfen und durch bestehende Freigabeprozesse schicken.
Das relativiert zugleich die Bezeichnung als Agent. In der Preview steht nicht die autonome Rekonfiguration der Cloud im Mittelpunkt. AWS sieht mehrere manuelle Wege vor, um Empfehlungen anzuwenden, darunter die Kommandozeile. Das System liefert also umsetzbare Änderungen, nimmt dem Betreiber aber nicht automatisch die Entscheidung über deren Ausführung ab.
Automatisierung beseitigt nicht das Haftungsproblem
Genau an dieser Stelle entscheidet sich die praktische Akzeptanz von AIOps. Eine unpassende Empfehlung kann Kosten erhöhen, eine Anwendung verlangsamen oder ihre Ausfallsicherheit beeinträchtigen. Im Störungsfall genügt der Verweis auf eine maschinell erzeugte Änderung nicht. Verantwortlich bleibt die Organisation, die sie freigegeben hat.
Die Bereitstellung von IaC-Code macht die Vorschläge immerhin besser prüfbar als eine undurchsichtige automatische Aktion. Teams können Änderungen vergleichen, testen und bei Bedarf zurückrollen. Dafür müssen sie ihre Kontrollmechanismen jedoch tatsächlich nutzen. Sinnvoll sind klar definierte Freigaben, Tests in getrennten Umgebungen und eine dokumentierte Rückfalloption. Der Agent verkürzt den Review-Zyklus; er ersetzt nicht die Kenntnisse, mit denen ein riskanter Eingriff erkannt wird.
Der Preview-Status ist dabei mehr als ein Etikett. Unternehmen sollten zunächst prüfen, wie zuverlässig der Agent ihre Anwendungstopologie und ihre betrieblichen Prioritäten erfasst. Eine technisch korrekte AWS-Empfehlung muss nicht automatisch zur internen Kostenstruktur, zu regulatorischen Vorgaben oder zu vereinbarten Verfügbarkeitszielen passen.
AWS verwandelt Beratung in eine Plattformfunktion
Strategisch produktisiert AWS mit dem Agenten einen Teil der Arbeit, die bislang von Architekten, Support-Mitarbeitern und Partnern geleistet wurde. Standardisierte Reviews lassen sich häufiger und über größere Ressourcenbestände hinweg durchführen. Für Berater verschiebt sich der Schwerpunkt damit von der Suche nach bekannten Fehlkonfigurationen zur Bewertung von Zielkonflikten, Migrationen und organisatorischen Folgen.
Für AWS selbst hat das Modell einen doppelten Nutzen. Der Agent kann Kunden durchaus Einsparungen empfehlen, wenn überdimensionierte oder ungeeignete Ressourcen erkannt werden. Gleichzeitig bindet er Architekturentscheidungen enger an das vom Cloud-Anbieter definierte Framework und an dessen Support-Angebot. Dass ein Support Plan Voraussetzung ist, macht die Funktion zudem zu einem Bestandteil der kommerziellen Kundenbeziehung und nicht zu einem allgemein verfügbaren Prüfwerkzeug.
Die Unterstützung von Terraform verhindert zwar, dass der Umsetzungsweg ausschließlich über AWS-eigene IaC-Werkzeuge führt. Bewertungsmaßstab und Zielumgebung bleiben dennoch AWS-zentriert. Wer mehrere Clouds oder eigene Infrastruktur betreibt, erhält deshalb keine neutrale Gesamtoptimierung, sondern eine tiefere Optimierung des AWS-Teils.
Cloud-Architekten werden nicht überflüssig, ihre Arbeit verschiebt sich
Am stärksten profitieren zunächst Unternehmen mit Support Plan, komplexen AWS-Beständen und etablierten IaC-Prozessen. Dort können wiederkehrende Prüfungen automatisiert und vorgeschlagene Änderungen in bestehende Entwicklungsabläufe übernommen werden. Wer Infrastruktur überwiegend manuell verwaltet oder keinen geeigneten Freigabeprozess besitzt, bekommt dagegen zwar mehr Empfehlungen, aber nicht automatisch einen sicheren Weg zu ihrer Umsetzung.
Der Well-Architected Agent automatisiert damit vor allem das Erkennen und Vorbereiten von Änderungen. Knapp bleibt die Fähigkeit, ihre Nebenwirkungen zu beurteilen. Je mehr Architekturwissen AWS in ausführbaren Vorschlägen verpackt, desto weniger Zeit müssen Teams mit standardisierten Kontrollen verbringen – und desto wichtiger wird die Instanz, die am Ende bewusst Ja oder Nein zu einer Änderung sagt.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
