Vitalij Bojatschkin

MCP-Server + AWS Bedrock: Wie Engineering-Teams interne KI-Workflows mit AI-Coding-Tools verbinden

Q: Was bringt es, MCP-Server vor Bedrock-Workloads zu setzen?

MCP macht eure Bedrock-basierten KI-Services (Dokumenten-Verarbeitung, RAG-Assistenten, Agent-Workflows) direkt in AI-Coding-Tools nutzbar. Engineers können während des Codens auf eure internen KI-Assistenten zugreifen, ohne separate UI oder Workflow-Wechsel.

Q: Verlangsamt der MCP-Layer Bedrock-Calls?

Bei strukturierter Implementation: <50ms Overhead pro Call. Der MCP-Server fügt nur Routing + Auth + Logging hinzu. Latenz dominiert durch Bedrock selbst (typisch 500-2000ms je nach Modell und Tokens). Der MCP-Layer ist nicht der Bottleneck.

Q: Wie bleibt das DSGVO-konform?

Bedrock läuft in eu-central-1 (Frankfurt), kein Datentransfer in Drittländer. MCP-Server läuft im selben AWS-Account oder VPC. AI-Coding-Tools senden nur die Query (nicht die Daten) an die LLM-API — die Daten bleiben innerhalb eurer AWS-Region. ZDR-konfigurierte Setups sind Standard.

Q: Wer sollte diesen Setup wählen?

Unternehmen, die schon Bedrock-Workloads betreiben (Dokumenten-KI, RAG, Agents) und parallel Engineering-Teams haben, die AI-Coding-Tools nutzen. Der Setup verbindet beide Welten und schafft messbare Produktivitätsgewinne ohne Duplikation.

Q: Wie aufwändig ist die Implementation?

Pro Bedrock-Workload als MCP-Tool: ~3-5 Engineer-Tage. Pro Bedrock-Knowledge-Base als MCP-Resource: ~2 Tage. Gesamt-Setup für einen typischen Mittelstand-Stack (2 Workloads + 1 Knowledge-Base + Auth + CI): 2-3 Wochen.

MCP-Server schaffen die Brücke zwischen euren AWS-Bedrock-basierten KI-Workflows und AI-Coding-Tools wie Claude Code. Wie ihr Dokumenten-KI, RAG-Assistenten und Bedrock-Agents direkt im Engineering-Workflow nutzbar macht.

import BlogFAQ from '../../src/components/BlogFAQ'; import KeyTakeaways from '../../src/components/KeyTakeaways';

<KeyTakeaways items= /

<p data speakable Viele Unternehmen betreiben heute schon AWS Bedrock Workloads — Dokumenten Verarbeitung, RAG Assistenten, Agent Workflows. Parallel dazu nutzen ihre Engineering Teams Claude Code, Cursor oder Codex. Beide Welten sind getrennt. Genau hier setzt das MCP Bedrock Bridge Pattern an: ein MCP Server vor euren Bedrock Workloads macht sie direkt in AI Coding Tools nutzbar. Dieser Post zeigt das Architektur Pattern, Implementations Schritte und konkrete Use Cases. </p

Das Problem: Zwei AI Welten ohne Brücke

Stellt euch einen typischen Mittelstand Stack 2026 vor:

AWS Bedrock basierte KI Workloads für Dokumenten Verarbeitung (Rechnungen extrahieren), RAG Assistenten (internes Wissen abfragen), Agent Workflows (Angebote generieren). DSGVO konform in eu central 1. Engineering Team nutzt Claude Code, Cursor und Codex für tägliche Entwicklungsarbeit.

Beide Welten sind getrennt. Engineers können nicht direkt aus ihrem AI Coding Tool auf die internen Bedrock Workloads zugreifen. Wer den internen RAG Assistenten zur Architektur Frage konsultieren will, muss separate UI öffnen, Query eingeben, Antwort kopieren, zurück in IDE — Reibung pro Task.

Resultat: Die internen KI Workloads werden unter ihrem Potenzial genutzt. Sie helfen Business Usern, aber nicht den Engineers, die sie gebaut haben.

Die Lösung: MCP Server als Bridge

Ein MCP Server vor euren Bedrock Workloads schließt die Lücke:

Engineers können direkt im Coding Tool:

Eine Frage an den internen RAG Assistenten stellen Ein Dokument durch die Bedrock Extraktions Pipeline schicken Einen Bedrock Agent für eine spezifische Aufgabe triggern

Die Antworten kommen strukturiert zurück und können direkt in Code, Doku oder PR Beschreibung verwendet werden.

Use Cases: Was Engineers damit machen

Use Case 1: Architektur Frage an internen RAG Assistenten

Engineer schreibt eine neue Komponente und ist unsicher über die existierende Pattern Library. Statt Slack Suche oder Confluence Walking:

``` Frag mein rag mcp: "Welches Pattern nutzen wir für Form Validation in React?"

Antwort kommt mit Quellenverweis auf interne ADR Doku. ```

Use Case 2: Dokumenten Extraktion im Test Setup

Engineer baut Tests für die Rechnungs Pipeline. Statt manueller Test Daten:

``` Trigger bedrock doc extraction für ./testdata/sample invoice.pdf

Bekommt JSON Output direkt zurück, kopiert in Test Fixture. ```

Use Case 3: PR Review mit Domain Kontext

Vor PR Review fragt der Engineer den Code Review Workflow:

``` /review mit Domain Kontext aus bedrock knowledge base "compliance rules"

Review enthält automatisch Hinweise auf domain spezifische Regeln. ```

In allen drei Fällen: keine UI Switching, keine Copy Paste, keine Reibung.

Architektur Pattern im Detail

So sieht ein produktiver MCP Bedrock Setup aus:

MCP Server Komponente (TypeScript oder Python): Läuft als Container in eurem AWS Account (ECS Fargate oder Lambda) HTTP Endpoint mit MCP Protocol über HTTPS Authentifizierung pro Tool Gruppe (Bedrock Read, Bedrock Invoke, KB Query) Strukturierte Logs pro Invocation an CloudWatch oder SIEM

Bedrock Tools im MCP Server:

Bedrock Workloads bleiben unverändert: Dokumenten KI Pipeline (Textract + Bedrock Klassifikation) RAG Knowledge Bases (S3 basierte Vector DB + Bedrock Retrieval) Bedrock Agents (für mehrstufige Workflows)

Der MCP Server ist die Schnittstelle, nicht die Workload selbst. Eure existierenden Bedrock Investitionen bleiben.

Permission Modell: das ist nicht optional

Bedrock Workloads haben oft sensitive Daten und Schreibrechte auf Production Systeme. Das Permission Modell ist nicht optional:

1. Read Only Default. Die meisten Engineer Use Cases brauchen Read Access (RAG Query, Doku Extraction). Schreibende Tools (Agent Triggers, KB Inserts) brauchen explizite Berechtigung.

2. Tool Group Tokens. Statt eines Master Tokens: separate Tokens für Read, Invoke, Admin. Engineers haben Read+Invoke. Platform Engineers haben Admin.

3. Audit Logs. Jeder MCP Tool Call landet als strukturierter Log in CloudWatch (oder eurem SIEM). Compliance kann genau nachvollziehen, was über AI Coding Tools an Bedrock geschickt wurde.

Ohne diese drei Schichten ist das Setup kein Production Pattern, sondern eine Sicherheitslücke.

DSGVO + Datenresidency: was bleibt im EU Raum

Ein häufiges Missverständnis: „Wenn ich Claude Code nutze, gehen meine Daten nach USA." Das stimmt für die LLM Anfrage (Sonnet Antwort kommt von Anthropic Servern), aber:

Eure Daten in Bedrock Workloads bleiben in eu central 1. Der MCP Server läuft in eu central 1. Der Engineer Prompt geht an Anthropic (USA oder EU je nach Vertrag). Die strukturierte Antwort vom MCP Server zurück enthält Bedrock Output — der bleibt in eu central 1 erzeugt, geht aber als String an den Engineer (und damit potentiell durch die LLM Pipeline).

Wer maximale Datenresidency will: Anthropic Bedrock Modelle in eu central 1 nutzen (Claude über Bedrock statt über Anthropic API direkt). Dann ist der gesamte Roundtrip in EU.

Mehr dazu im Service DSGVO konforme KI Integration — der MCP Bedrock Bridge Setup baut auf diese Foundation auf.

Implementierungs Schritte

Realistischer Zeitplan für ein typisches Mittelstand Setup mit 2 Bedrock Workloads:

Woche 1: Discovery + Tool Design Mapping: welche Bedrock Workloads gibt es, welche sollen via MCP zugänglich sein Permission Modell entwerfen (Read/Invoke/Admin pro Tool Gruppe) Auth Strategie (Token Provisioning, Rotation)

Woche 2 3: Implementation MCP Server Skeleton in TypeScript 2 4 Tools für die Bedrock Workloads (z.B. doc extract, rag query, agent trigger) 1 2 Resources für statische Konfiguration (z.B. KB Catalog) Unit + Integration Tests CI Pipeline (GitHub Actions oder GitLab CI)

Woche 4: Deployment + Team Übergabe Docker Container in ECR, Deploy via Fargate Engineer Setup Doku: wie verbindet man Claude Code mit dem MCP Server Team Session mit Live Demo Audit Log Dashboard für Compliance

Pro zusätzlichem Bedrock Workload danach: 3 5 Tage.