CloudWatch MCP Server

Ein selbstentwickelter MCP-Server auf Basis von FastMCP, der Amazon-CloudWatch-Metriken, Logs Insights und Alarme als Tools bereitstellt, die ein KI-Assistent aufrufen kann. Er ist dafür ausgelegt, lokal für Entwicklungszwecke zu laufen und als Container-Image auf AWS Lambda bereitgestellt zu werden, erreichbar über eine Lambda-Function-URL.

Getestet gegen fastmcp==3.4.7 und boto3 mit moto-Mocks (alle unten aufgeführten Tools wurden gegen gemockte CloudWatch/Logs-Aufrufe geprüft). Trage deine eigene fastmcp-Version in requirements.txt ein, bevor du deployst, und gleiche diese README bei gofastmcp.com erneut ab, wenn es länger her ist – die API von FastMCP hat bereits mehr als einmal ihre Form verändert (siehe Abschnitt „Eine Anmerkung zur sich verändernden API von FastMCP“ weiter unten).

Bereitgestellte Tools

Alle Tools sind read-only – keines von ihnen kann in CloudWatch etwas verändern, löschen oder anlegen. Behalte das bei, sofern es keinen konkreten Grund gibt, Schreibzugriff hinzuzufügen; das Prinzip der geringsten Rechte (least privilege) wiegt deutlich schwerer, sobald ein KI-Modell entscheidet, wann diese Tools aufgerufen werden.

Related MCP server: cloudwatch-mcp

1. Erst einmal lokal ausführen

Das ist der schnellste Weg, um nachzuweisen, dass die Tools funktionieren, bevor du dich überhaupt um AWS kümmerst.

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

# Uses your normal AWS credentials (aws configure / AWS_PROFILE / SSO)
export AWS_PROFILE=your-profile
export AWS_REGION=us-east-1

python3 server.py   # defaults to stdio transport

Richte einen MCP-Client (Claude Desktop, Claude Code, etc.) direkt auf diesen Befehl aus – für Claude Desktop füge ihn der MCP-Konfigurationsdatei hinzu:

{
  "mcpServers": {
    "cloudwatch": {
      "command": "/full/path/to/.venv/bin/python3",
      "args": ["/full/path/to/server.py"],
      "env": { "AWS_PROFILE": "your-profile", "AWS_REGION": "us-east-1" }
    }
  }
}

Um den HTTP-Transport lokal zu testen (also den Modus, der auf Lambda verwendet wird):

MCP_TRANSPORT=http PORT=8080 python3 server.py
# then, from another terminal:
curl -X POST http://localhost:8080/mcp \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

2. IAM: Worauf der Server zugreifen darf

iam-policy.json in diesem Ordner ist der minimale Berechtigungssatz, den der Server braucht – GetMetricData/ListMetrics/DescribeAlarms* für CloudWatch, DescribeLogGroups/StartQuery/GetQueryResults/StopQuery für Logs Insights. Nicht mehr. Hänge ihn an nach Belieben an eine Identität, unter der der Server läuft:

• Lokal: hängt sie an einen IAM-Benutzer bzw. eine IAM-Rolle und nutzt sie über AWS_PROFILE, oder gewährst sie deiner SSO-Rolle.

• Auf Lambda: hängt sie an die Ausführungsrolle der Lambda-Funktion (zusätzlich zur Standardrolle AWSLambdaBasicExecutionRole für die eigene Protokollierung der Funktion) – Zugriffsschlüssel gehören niemals ins Image.

3. Bereitstellen auf AWS Lambda

Der von CloudWatch selbst empfohlene Weg, „eine vorhandene Funktion als MCP-Tool ohne Protokollcode zu exponieren", ist Amazon Bedrock AgentCore Gateway – einen Blick wert, falls später die Option einer vollständig verwalteten Lösung akzeptierbar ist. Was unten folgt, ist der wörtliche Pfad „wir betreiben den MCP-Server": Wir verwenden den AWS Lambda Web Adapter, um genau diese FastMCP-Anwendung unverändert in Lambda laufen zu lassen.

Container-Image bauen und pushen

aws ecr create-repository --repository-name cloudwatch-mcp-server

aws ecr get-login-password --region <region> | \
  docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com

docker build -t cloudwatch-mcp-server .
docker tag cloudwatch-mcp-server:latest \
  <account-id>.dkr.ecr.<region>.amazonaws.com/cloudwatch-mcp-server:latest
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/cloudwatch-mcp-server:latest

Lambda-Funktion erstellen

1. Erstelle die Funktion aus dem Container-Image, das du gerade gepusht hast.

2. Arbeitsspeicher: Beginne mit 512 MB; Timeout: 30 s reichen für die meisten Metrik-/Alarm-Aufrufe, erhöhe auf 60–120 s, falls deine Logs-Insights-Abfragen umfangreich sind (das max_wait_seconds von query_logs sollte bequem unter dem Funktions-Timeout bleiben).

3. Hänge die Ausführungsrolle mit der IAM-Policy aus Schritt 2 an.

4. Setze den **Invoke-Modus auf RESPONSE_STREAM, falls du eine Function URL mit Streaming aktivierst (notwendig, damit der Adapter lange Antworten weiterleiten kann).

5. Erstelle eine Function-URL:

   • Auth-Typ: AWS_IAM (verwende NONE nicht außerhalb eines schnellen persönlichen Tests – andernfalls sind deine CloudWatch-Daten für jeden mit der URL zugreifbar).

   • Dein MCP-Client muss Anfragen mit SigV4 signieren, um die URL aufrufen zu können; die meisten MCP-Clients können das noch nicht nativ – in der Praxis sitzt die URL deshalb normalerweise hinter etwas, das Anfragen signieren kann, zum Beispiel hinter einem internen Gateway/Proxy, das dein Team betreibt, oder einem API Gateway mit IAM-Auth, das direkt vor die Function-URL gesetzt wird statt auf die eigene IAM-Auth der Function-URL zu setzen.

6. Der MCP-Endpunkt lautet https://<function-url>/mcp.

Die bereitgestellte Funktion prüfen

aws lambda invoke --function-name cloudwatch-mcp-server \
  --payload '{}' /tmp/out.json && cat /tmp/out.json

und danach einen echten MCP-initialize-Aufruf gegen die Function-URL (mit SigV4- Signierung, per awscurl oder einem kleinen Skript für signierte Anfragen) – dasselbe in JSON, das curl-JSON testet mit oben.

4. Bekannte Stolpersteine (sei deinem Team gegenüber ehrlich)

• Kaltstarts: Ein vollwertiger HTTP-Server (uvicorn + FastMCP), der in einem Lambda-Kaltstart hochkommt, ist langsamer als ein typischer leichtgewichtiger Lambda-Handler – beim ersten Aufruf nach einer Leerlaufphase kannst du mit mehreren Sekunden Latenz rechnen. Provisioned Concurrency entschärft das, falls das für deinen Anwendungsfall wichtig ist.

• Kein Server-Push / keine langlebige Sitzung: stateless_http=True bedeutet, dass jeder Tool-Aufruf eine saubere, eigenständige Anfrage ist – es wird nichts zwischen den Aufrufen gemerkt, und der Server kann keine proaktiven Nachrichten an den Client schicken. Entwurfswerkzeuge so, dass jeder Aufruf alles enthält, was er braucht (dieser Server tut das bereits – Beispiel: query_logs erwartet vollständigen Zeitraum und Abfragezeichenfolge in einem einzigen Aufruf).

• Die Auth liegt bei dir: Die IAM-Auth der Function-URL (oder was immer du davorlegst) ist die einzige Grenze zwischen „KI-Assistent" und „jede Person mit der URL". Überspringen Sie auch bei frühen Tests nicht, wenn deine Funktion irgendetwas anfasst, das über ein Einweg-Sandbox-Konto hinausgeht.

• Logs-Insights-Abfragen werden gepollt, nicht gepusht: query_logs blockiert und befragt get_query_results, max. max_wait_seconds. Bei sehr großen Abfragen zehrt das das Lambda-Timeout auf – keep queries flach gehalten (limit, enge Zeitbereiche) statt „offen und offen".

5. Eine Anmerkung zur sich verändernden API von FastMCP

FastMCP hat seine HTTP-/state-lose API zwischen den Versionen mehr als einmal geändert (das Flag stateless_http wurde in verschiedenen Releases zwischen dem Konstruktor FastMCP() und mcp.run()/mcp.http_app() verschoben). Der Code in server.py wurde mit fastmcp==3.4.7 geprüft (mcp.run(transport="http", stateless_http=True, ...)). Wenn du die Version anhast und etwas bricht, prüfe zuerst gofastmcp.com/deployment/http – das ist die Stelle, die sich am wahrscheinlichsten verschoben hat.