AWS hat der Konsole diese Woche eine neue Karte hinzugefügt: Agent Toolkit for AWS. Es ist kostenlos, allgemein verfügbar und funktioniert mit Claude Code, Codex, Cursor und Kiro. Ein einziger Setup-Prompt gibt dem Coding-Agent einen MCP-Server für AWS-APIs, kuratierte Skills für gängige Aufgaben und IAM-Guardrails. Das Toolkit selbst ist nützlich. Was es eingesteht, ist größer: Der primäre Leser der AWS-Dokumentation ist kein Mensch mehr.

Was im Paket steckt

Drei Ebenen, und sie funktionieren unabhängig voneinander:

  • Der AWS MCP Server. Ein gehosteter Endpoint (aws-mcp.us-east-1.api.aws), den der Agent über mcp-proxy-for-aws erreicht. Er gibt dem Agent Zugriff auf AWS-APIs, Skript-Ausführung in einer Sandbox und Dokumentationssuche in Echtzeit. Credentials sind nur für API-Aufrufe nötig; die Dokumentationssuche funktioniert auch ohne.
  • Plugins. aws-core deckt Service-Auswahl, CDK und CloudFormation, Serverless, Container, Storage, Observability und Billing ab. aws-agents ergänzt Skills für Bedrock und AgentCore, aws-data-analytics und aws-agents-for-devsecops bedienen ihre eigenen Domänen. In Claude Code kommen sie mit einem einzigen /plugin install aus dem offiziellen Plugin-Marketplace.
  • Skills. Kuratierte Aufgabenanweisungen, installiert mit npx skills add aws/agent-toolkit-for-aws/skills. Sie werden bei Bedarf geladen: Der Agent zieht nur heran, was zur aktuellen Aufgabe passt, sie kosten also nichts, bis sie gebraucht werden.

Die Authentifizierung läuft über den neuen browserbasierten aws login Flow, verifiziert mit aws sts get-caller-identity. Wer im Terminal lebt, verdrahtet dasselbe per aws configure agent-toolkit über die AWS CLI.

Das Setup ist ein Prompt, kein Skript

Hier ist das Detail, bei dem es sich lohnt, kurz innezuhalten. Die Konsole reicht kein Shell-Skript herüber. Sie reicht einen einzigen Satz, den man in den Agent einfügt:

Set up Agent Toolkit for AWS by following instructions:
https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md

Diese URL ist eine Markdown-Datei. Der Agent liest sie, erkennt das Betriebssystem, installiert die AWS CLI, falls sie fehlt, führt aws login aus, verdrahtet den MCP-Server und installiert die Skills. Das Dokument ist strukturiert wie ein Runbook für eine Maschine: nummerierte Schritte, Tabellen zur Fehlerbehandlung, Verifikationskommandos nach jeder Etappe. AWS hat eine Installationsanleitung geschrieben, deren Zielpublikum nicht der Mensch ist. Man bestätigt nur noch die Berechtigungsabfragen.

Das ist das Muster, auf das es zu achten gilt. Installationsanleitungen waren früher Prosa für Menschen mit Codeblöcken zum Kopieren. Das hier ist Code für Agents mit Prosa, die der Mensch einmal überfliegt.

Niemand liest mehr die Docs, außer den Agents

Ich gebe etwas zu. Jahrelang bestand meine Wochenendlektüre nicht aus Krimis oder Belletristik. Es war AWS-Dokumentation: Service Quotas, API-Grenzfälle, das Changelog irgendeiner Storage Class, über die niemand spricht. Diese Lektüre baute den mentalen Index auf, der mich schnell machte, denn zu wissen, wo die Antwort steht, war der größte Teil der Arbeit.

Dieser Index ist jetzt eine Commodity. Ein Agent mit Dokumentationssuche liest die aktuelle Seite, nicht die, die ich vor zwei Jahren auswendig gelernt habe, und er liest sie in Sekunden. Das Toolkit macht das offiziell: AWS betreibt jetzt eine eigene Pipeline, die die hauseigenen Docs an Maschinen verfüttert, mit "up-to-date documentation and tested procedures" als Hauptfeature. Der wichtigste Kunde des Docs-Teams hat die Spezies gewechselt.

Was keine Commodity wird, ist Urteilsvermögen. Welcher Service passt, wie groß der Blast Radius einer Änderung ist, ob der Plan des Agents den Kontakt mit den Realitäten des eigenen Accounts übersteht. Deshalb ist das dritte Wort in AWS' eigenem Pitch Guardrails: Ein Agent mit funktionierenden Credentials ist ein Principal wie jeder andere, und er bekommt Least Privilege wie jeder andere. Zwei praktische Hinweise dazu:

  • Die Proxy-Version pinnen (im Stil von mcp-proxy-for-aws@1.6.3). AWS' eigenes README empfiehlt das gegen Supply-Chain-Risiken, und das zu Recht.
  • Die Rolle des Agents standardmäßig read-only zuschneiden und jeden mutierenden Pfad separat absichern. Die IAM-Guardrails des Toolkits helfen, aber die Policy schreibt man immer noch selbst.

Fazit

Die agentische Ära der AWS-Entwicklung kam nicht mit einer Keynote. Sie kam als kleine Karte in der Konsole, die einen Setup-Prompt anbietet. AWS geht jetzt davon aus, dass der erste Mitstreiter in jedem Projekt ein Agent ist, und liefert Dokumentation, Prozeduren und Permission Boundaries für genau diesen Leser. Meine Wochenenden haben vielleicht endlich Platz für einen Kriminalroman. Die Docs sind in guten Händen, und die interessante Arbeit, zu entscheiden, was gebaut wird und was ein Agent anfassen darf, war ohnehin schon immer der Teil, der sich nicht indexieren ließ.

Lies das als Nächstes