AWS MCP Server

Der AWS MCP Server ist ein von AWS verwalteter Remote-MCP-Server und Kernbestandteil des Agent Toolkit for AWS. Er läuft nicht lokal, sondern als gehosteter Endpunkt bei AWS und wird über ein reguläres AWS-Konto genutzt.

Laut Dokumentation kann ein Agent darüber jeden der über 300 AWS-Dienste über einen einzigen authentifizierten Endpunkt ansprechen, Python-Code in einer isolierten Sandbox gegen AWS-Dienste ausführen (ohne Zugriff auf das lokale Dateisystem), aktuelle AWS-Dokumentation durchsuchen und abrufen sowie über nachladbare "Agent Skills" projektspezifische Anleitungen einbinden. Dokumentationssuche und Skill-Abruf funktionieren ohne AWS-Anmeldedaten; für tatsächliche AWS-API-Aufrufe ist eine Authentifizierung über die eigenen AWS-Berechtigungen (IAM) erforderlich.

AWS bietet zwei Authentifizierungswege an. Bei OAuth authentifiziert sich ein Mensch im Browser bzw. ein automatisierter Agent per Token-Anfrage; das funktioniert mit Web-Clients (etwa Claude.ai) und den meisten IDE-, Terminal- oder Desktop-Clients, ohne dass lokal etwas installiert werden muss. Bei SigV4 meldet man sich zunächst über die AWS CLI an (aws login) und nutzt anschließend den separaten MCP Proxy for AWS, um Anfragen mit den eigenen AWS-Zugangsdaten zu signieren – das ist laut Dokumentation der empfohlene Weg für Terminal-/IDE-Coding-Agenten wie Claude Code, Kiro oder Codex, und der einzige Weg, um in einer Sitzung zwischen mehreren AWS-Konten zu wechseln oder Schreib-Werkzeuge über einen Read-only-Modus komplett auszublenden.

Der Server ist aktuell in zwei Regionen erreichbar: US East (N. Virginia) unter https://aws-mcp.us-east-1.api.aws/mcp und Europe (Frankfurt) unter https://aws-mcp.eu-central-1.api.aws/mcp.

Einbindung per OAuth in Claude Code:

claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http

Einbindung per SigV4 (z. B. Cursor, Claude Desktop) über den MCP Proxy for AWS:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws-cli@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

AWS rät ausdrücklich dazu, ältere, separate Server wie aws-api-mcp-server und aws-knowledge-mcp-server aus der Client-Konfiguration zu entfernen, um Werkzeugkonflikte zu vermeiden, da der AWS MCP Server diese Funktionen laut Dokumentation zusammenführt und zusätzliche IAM-Sicherheitskontrollen bietet.

Warum ein einziger Endpunkt statt vieler Einzelserver

Vor dem AWS MCP Server mussten Teams, die mehrere AWS-Dienste ansprechen wollten, oft mehrere separate MCP-Server parallel betreiben und konfigurieren. Der zentrale Endpunkt löst das, indem er über 300 Dienste hinter einer einzigen authentifizierten Verbindung bündelt. Für Nutzer bedeutet das weniger Konfigurationsaufwand und eine einheitliche Stelle für Berechtigungsverwaltung über IAM, statt Zugriffsrechte über mehrere unabhängige Server hinweg pflegen zu müssen.

Für wen sich der Server eignet

Besonders nützlich ist der Server für Entwicklungsteams, die AWS bereits aktiv für Infrastruktur, Datenbanken oder KI-Dienste nutzen und wiederkehrende Cloud-Operationen direkt aus dem Coding-Agenten heraus erledigen wollen – etwa das Debuggen fehlgeschlagener Lambda-Ausführungen, das Nachschlagen aktueller Servicelimits oder das Ausführen kleiner Analyse-Skripte in der isolierten Sandbox. Für Organisationen mit strengen Compliance-Anforderungen ist der SigV4-Weg über den MCP Proxy for AWS relevant, weil er sich sauber in bestehende IAM-Rollen und CloudTrail-Protokollierung einfügt.

Ein AWS-Konto. Für OAuth genügt ein MCP-Client mit OAuth-Unterstützung, dessen IAM-Rolle/-Nutzer die verwaltete Richtlinie AWSMCPSignInOAuthAccessPolicy zugewiesen bekommt. Für SigV4 zusätzlich die AWS CLI (Version 2.32.0 oder neuer) und uv/uvx für den MCP Proxy for AWS.

Für OAuth die verwaltete Richtlinie arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy an die eigene IAM-Rolle bzw. den eigenen IAM-Nutzer anhängen, dann die Endpunkt-URL im Client hinterlegen (bei manchen Clients mit Zusatz ?oauth=initialize). Beim ersten Werkzeugaufruf öffnet der Client ein Browserfenster zur AWS-Anmeldung; erteilte Zugriffstoken gelten laut Dokumentation 1 Stunde und werden bis zu 12 Stunden automatisch verlängert.

Für SigV4 zunächst die AWS CLI installieren, mit aws login anmelden (rotiert Zugangsdaten laut Dokumentation automatisch alle 15 Minuten für Sitzungen bis 12 Stunden) und mit aws sts get-caller-identity prüfen. Anschließend uv installieren und den MCP Proxy for AWS (mcp-proxy-for-aws-cli) wie im Beispiel per uvx im Client konfigurieren.

claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http

Zwei Wege: OAuth (browserbasierte Anmeldung oder Token-Anfrage durch automatisierte Agenten, kein lokaler Prozess nötig) oder SigV4 über die AWS CLI plus MCP Proxy for AWS, der Anfragen mit den eigenen AWS-Zugangsdaten signiert. Nur SigV4 unterstützt den Wechsel zwischen mehreren AWS-Konten in einer Sitzung.

Die wirksamen Rechte entsprechen exakt den Berechtigungen der verwendeten IAM-Rolle bzw. des IAM-Nutzers oder der OAuth-Sitzung – der Server selbst vergibt keine zusätzlichen Rechte. Je nach zugewiesenen IAM-Berechtigungen sind Lese- und Schreibzugriffe auf beliebige der über 300 unterstützten AWS-Dienste möglich. Laut AWS lassen sich Zugriffe zusätzlich über IAM-Bedingungsschlüssel (condition keys) speziell für den MCP-Server einschränken.

Anfragen und Werkzeugparameter werden über HTTPS an den von AWS betriebenen Endpunkt in der gewählten Region gesendet. Antworten können Ressourcendaten aus beliebigen genutzten AWS-Diensten enthalten und werden an den MCP-Client sowie dessen Sprachmodell weitergegeben. Python-Code läuft laut Dokumentation in einer isolierten AWS-Sandbox ohne Zugriff auf das lokale Dateisystem. AWS protokolliert Nutzung über CloudWatch und CloudTrail.

Da der Server beliebige der über 300 AWS-Dienste ansprechen kann, ermöglicht eine zu breit berechtigte IAM-Rolle oder ein kompromittiertes OAuth-Token weitreichende Aktionen im AWS-Konto, bis hin zu Änderungen an Produktionsressourcen. Nur minimale, aufgabenbezogene IAM-Berechtigungen vergeben, wo möglich IAM-Bedingungsschlüssel für den MCP-Server nutzen, bei SigV4 Read-only-Modus für reine Analyseaufgaben aktivieren und CloudTrail-Protokolle auf ungewöhnliche Aktivität prüfen.