Cloud-Infrastruktur prüfen und dokumentieren

AWS MCP Server, Cloudflare API MCP Server und Filesystem MCP kombiniert: Ressourcen und Konfigurationen über zwei Cloud-Anbieter hinweg prüfen und als Bericht ablegen.

  • Skill Road
  • Cloud-Infrastruktur prüfen und dokumentieren

Wer Infrastruktur auf mehr als einem Cloud-Anbieter betreibt, kennt das Problem: Ein vollständiger Überblick über Ressourcen, Konfigurationen und potenzielle Risiken erfordert das Durchklicken mehrerer separater Konsolen. Dieser Workflow verbindet den AWS MCP Server und den Cloudflare API MCP Server mit Filesystem MCP, sodass ein Agent Ressourcen und Konfigurationen über beide Anbieter hinweg abfragen und die Ergebnisse als lesbaren, versionierbaren Bericht lokal ablegen kann, statt Informationen nur flüchtig im Chatverlauf zu präsentieren. Der AWS MCP Server gibt authentifizierten Zugriff auf über 300 AWS-Dienste über einen einzigen Endpunkt, der Cloudflare API MCP Server deckt DNS, Workers, Zero Trust und weitere Cloudflare-Produkte über einen kompakten Code-Mode-Ansatz ab, und Filesystem MCP schreibt das gesammelte Ergebnis als Datei ins Projektverzeichnis.

Wie die drei Werkzeuge zusammenspielen

Der Agent fragt zunächst über den AWS MCP Server relevante Ressourcen ab, etwa laufende EC2-Instanzen, S3-Bucket-Konfigurationen oder IAM-Rollen mit besonders weitreichenden Rechten. Parallel oder anschließend nutzt er den Cloudflare API MCP Server, um DNS-Einträge, Firewall-Regeln oder Zero-Trust-Richtlinien der zugehörigen Domains abzufragen. Statt die Ergebnisse nur im Gespräch zusammenzufassen, schreibt der Agent sie über Filesystem MCP als strukturiertes Markdown-Dokument in einen dafür vorgesehenen Ordner, etwa docs/infrastruktur-audit/, wo sie sich mit git versionieren und im Zeitverlauf vergleichen lassen.

Typischer Ablauf Schritt für Schritt

Ein typischer Auftrag lautet: „Erstelle einen Bericht über alle öffentlich erreichbaren S3-Buckets in meinem AWS-Konto und alle Cloudflare-Firewall-Regeln für Domain X, und speichere ihn in docs/infrastruktur-audit/2026-09-bericht.md." Der Agent fragt über den AWS MCP Server die Bucket-Konfigurationen ab, prüft über den Cloudflare API MCP Server die aktiven Firewall-Regeln der genannten Domain und fasst beide Ergebnisse in einem gemeinsamen Bericht zusammen, den Filesystem MCP anschließend als Datei ablegt. Wiederholt man diesen Auftrag regelmäßig, entsteht eine Historie von Audit-Berichten, an der sich Veränderungen der Infrastruktur über die Zeit nachvollziehen lassen.

Warum diese Kombination sich lohnt

Ohne den AWS MCP Server oder den Cloudflare API MCP Server müsste ein Mensch die relevanten Informationen manuell aus zwei getrennten Web-Konsolen zusammentragen, was bei wiederkehrenden Prüfungen viel Zeit kostet. Ohne Filesystem MCP verschwindet jeder Audit-Lauf am Ende der Chatsitzung, sodass sich Veränderungen zwischen zwei Zeitpunkten nicht ohne Weiteres vergleichen lassen. Erst die Kombination aus zwei Cloud-Anbieter-Servern und einem lokalen Ablageort macht aus einer einmaligen Abfrage einen wiederholbaren, dokumentierten Prüfprozess.

Für wen sich der Workflow eignet

Besonders nützlich ist dieser Workflow für DevOps- und Infrastrukturteams, die regelmäßig Sicherheits- oder Kostenprüfungen über mehrere Cloud-Anbieter hinweg durchführen und dafür bislang manuell zwischen Konsolen wechseln mussten. Auch für die Vorbereitung von Compliance-Nachweisen oder internen Audits eignet sich die Kombination gut, weil jeder Bericht als Datei nachvollziehbar bleibt. Für Teams, die nur einen der beiden Cloud-Anbieter nutzen, genügt entsprechend nur der jeweils passende MCP-Server zusammen mit Filesystem MCP.

Häufige Fragen zur Einrichtung

Braucht jeder der beiden Cloud-Server eigene Zugangsdaten? Ja, der AWS MCP Server nutzt IAM-Anmeldedaten über OAuth oder SigV4, der Cloudflare API MCP Server ein eigenes OAuth- oder API-Token – beide werden unabhängig voneinander konfiguriert. Sollte ein Agent bei diesem Workflow auch schreibend auf die Infrastruktur zugreifen dürfen? Für reine Audit-Zwecke empfiehlt sich ein möglichst eng begrenztes, lesendes Zugriffsprofil; Änderungen an der Infrastruktur sollten stets menschlich bestätigt werden. Wie oft sollte der Bericht aktualisiert werden? Das hängt vom Bedarf ab – für sicherheitskritische Umgebungen bietet sich ein wöchentlicher oder monatlicher Rhythmus an.

Bausteine dieses Workflows

Kostenlos

Kategorien