Wer Claude Code mit Amazon Bedrock für entfernte Aufgaben nutzen will, kann die native --cloud-Funktion nicht einfach dafür umschalten: Anthropic verlangt dafür ein Anthropic-Konto und schließt Amazon Bedrock als konfigurierten Anbieter aus. Für Entwickler, die Aufgaben stattdessen in AWS ausführen lassen wollen, beschreibt AWS einen eigenen Weg mit Amazon Bedrock AgentCore Runtime und GitHub-Pull-Requests zur menschlichen Prüfung. Anthropics Dokumentation zu Claude Code in der Cloud und AWS’ Anleitung zum AgentCore-Sample beschreiben zwei getrennte Ansätze.

Bei der AWS-Variante endet die Automatisierung mit einem Pull Request. Ob die Änderung in den Hauptzweig kommt, entscheidet ein Mensch.

Zwei Wege für Claude-Code-Aufgaben in der Cloud

WegAnbieter- und KontobedingungAusführung
Native Claude-Code-Cloud-SitzungErfordert ein Anthropic-Konto; nicht verfügbar, wenn Claude Code auf Amazon Bedrock eingestellt istClaude Code führt die Sitzung in seiner nativen Cloud-Umgebung aus
AWS-AgentCore-SampleVerwendet Amazon Bedrock im AWS-Konto, in dem das Sample bereitgestellt wirdEine eigene AWS-Bereitstellung startet Aufgaben in AgentCore-Runtime-Sitzungen und kann sie über ein Plugin oder eine Webkonsole annehmen

Wer Amazon Bedrock als Anbieter konfiguriert hat, muss für entfernte Aufgaben also den AWS-Ansatz separat einrichten. Das Sample heißt sample-remote-coding-agent; es ist kein Schalter für Anthropics native --cloud-Funktion.

Was das AWS-Sample mit einer Aufgabe macht

Eine Aufgabe lässt sich laut AWS über ein Claude-Code-Plugin mit lokalem MCP-Server oder über eine Webkonsole einreichen. Im ersten Fall läuft der API-Zugriff über IAM-Berechtigungen, bei der Webkonsole über Amazon Cognito. API Gateway, Lambda, SQS und DynamoDB übernehmen die Steuerung und Aufgabenzuordnung.

Für jede Aufgabe startet das Sample eine eigene AgentCore-Runtime-Sitzung in einer Micro-VM. Der Ablauf lässt Claude Opus planen, Claude Sonnet programmieren und Claude Opus das Ergebnis prüfen. Dabei führt die Sitzung die Setup- und Testbefehle des Repositorys aus. Eine Prüfung kann die Aufgabe zurück an die Planung geben; insgesamt sind bis zu drei Versuche vorgesehen.

Am Ende öffnet der Agent einen GitHub-Pull-Request und führt keinen Merge aus. Wenn die Verifizierung nicht erfolgreich ist, wird der Pull Request als Entwurf geöffnet. Ein Mensch prüft die Änderung und entscheidet über das Zusammenführen.

Voraussetzungen vor der Bereitstellung

Du brauchst ein AWS-Konto samt CLI-Zugangsdaten, Docker, Python 3.11 oder neuer, uv sowie Node.js 22.12 oder neuer. Außerdem muss das GitHub-Repository vertrauenswürdig sein und die Setup- und Testbefehle enthalten, die das Sample ausführt. Die Plugin-Installation ist optional, wenn du Aufgaben stattdessen über die Webkonsole einreichen willst.

AWS führt das Sample als ungeeignet für nicht vertrauenswürdige Repositorys und offene Aufgabenstellungen auf. Der Agent führt Befehle aus dem Repository aus; sein Aufgabenzyklus endet nach höchstens drei Versuchen.

Im am 6. November 2026 veröffentlichten AWS-Tutorial werden für AgentCore Runtime V2 die Regionen us-east-1, us-east-2, us-west-2, ap-northeast-1 und eu-west-1 aufgeführt. Der dortige Beispielablauf verwendet us-west-2.

Sample bereitstellen und mit GitHub verbinden

  1. Repository und Werkzeuge vorbereiten. Prüfe, dass das Repository vertrauenswürdig ist und die benötigten Setup- und Testbefehle enthält. Stelle außerdem AWS CLI, Docker, Python, uv und Node.js in den genannten Versionen bereit.
  2. AWS-Ressourcen bereitstellen. Führe den Bereitstellungsablauf des Samples in deinem AWS-Konto aus. AWS veranschlagt dafür 15 bis 25 Minuten; das ist die Zeitschätzung aus dem Tutorial.
  3. GitHub App installieren und autorisieren. Richte die App für den Zugriff auf das Repository ein. AWS beschreibt den Zugriff über AgentCore Identity und ein GitHub-App-Token für Inhalte und Pull Requests.
  4. Repository registrieren. Registriere das autorisierte Repository beim Sample. AWS schätzt diesen Schritt auf weitere 8 bis 12 Minuten.
  5. Aufgabe einreichen. Nutze das Plugin mit lokalem MCP-Server oder die Webkonsole. Das Sample legt die Aufgabe in seiner Steuerung ab und startet die Runtime-Sitzung.
  6. Pull Request prüfen. Lies Änderungen und Verifizierungsergebnis, bevor du über den Merge entscheidest. Das Sample übernimmt diesen letzten Schritt nicht.

Sicherheitsgrenzen und laufende Kosten

AWS beschreibt voneinander getrennte Sitzungen mit isoliertem Prozessor, Arbeitsspeicher und Dateisystem. GitHub-Zugriffe laufen über AgentCore Identity; das Nutzer-zu-Server-Token läuft laut AWS nach acht Stunden ab und wird automatisch erneuert.

Die Prompt-Schutzregel prüft die eingereichte Aufgabe, nicht aber Repository-Dateien oder die Ausgabe ausgeführter Befehle. Auch die Netzgrenze ist nicht vollständig geschlossen: Die Runtime liegt in privaten Subnetzen und nutzt private AWS-Endpunkte, kann über ein NAT-Gateway aber weiterhin HTTPS-Verbindungen zu GitHub und Paketregistern aufbauen. Die beschriebene DNS Firewall sperrt ausgewählte Ziele; sie ist keine allgemeine HTTPS-Erlaubnisliste.

AWS zufolge fallen auch im Leerlauf Kosten an, unter anderem für NAT-Gateway, Schnittstellenendpunkte, AWS WAF, Cognito-Benutzerpool, DNS Firewall, Images und Logs. Der Standard-Budgetalarm für Amazon Bedrock beträgt 200 US-Dollar pro Monat und verschickt eine E-Mail, begrenzt die Ausgaben aber nicht. AWS nennt in der Anleitung weder Gesamt- noch Aufgabenpreise für die Bereitstellung.

Ressourcen in der richtigen Reihenfolge entfernen

Wenn du das Sample nicht weiterbetreiben willst, deregistriere zuerst die Repositorys und trenne anschließend die GitHub-Verbindung. Danach kannst du die Stacks entfernen und zuletzt die GitHub App löschen. AWS weist darauf hin, dass zurückbehaltene Ressourcen weiter Kosten verursachen können, bis sie separat gelöscht sind.