Agentic Ventures Wiki

AWS Multi-Account-Org als Hosting-Standard, Railway wird abgeloest

7 Min. Lesezeit

AWS Multi-Account-Org als Hosting-Standard

Kontext

Bis 2026-05-07 lief der eine produktive eigene Service (mcp-vf-hosted fuer Vibe Factory) auf Railway EU-West (Amsterdam). Privat hat Marvin AWS schon laenger genutzt (siehe cloud-infrastructure), aber nicht systematisch und nicht als Org.

Drei Treiber kommen jetzt zusammen:

  1. Becker als erster regulatorischer Industriekunde. becker hat dezidierte DSGVO-Anforderungen und einen GF (Ralf Schmid) der das Hosting-Konzept inhaltlich pruefen wird. Multi-Tenancy auf einem geteilten Railway-Container ist hier nicht mehr verteidigbar — saubere Account-Trennung pro Kunde mit Audit-Trail-Garantie ist Pflicht.

  2. MCP-as-a-Service-Vision. Marvin will alle eigenen MCPs (gsuite, m365, papierkram, ticketpay, runway, replicate, lexware, sevdesk, plus mcp-vf-hosted-Pattern) so betreiben, dass er einzelne Personen einfach „freischalten” kann — Endkunden, Partner, andere Software (claude.ai Custom Connector, ChatGPT, Claude Desktop, n8n, beliebige OAuth-Clients). Das erfordert OAuth, Multi-Tenant, Rate-Limiting pro Subject, sauberes Logging — also produktionsreife Cloud-Infra, nicht „ein Container auf Railway”.

  3. Sauberer steuerlicher Schnitt. Mit der UG-Gruendung 2026-04-27 muss alles UG-Eigene klar getrennt von Privat sein. Multi-Account loest das strukturell — privat in mk-privat, UG in av-*, Billing pro Account.

Optionen

Option A — Status quo: Railway plus ad-hoc AWS

Pro:

  • Railway-DX ist sehr gut (git push deployed)
  • Ein bestehender Service laeuft schon dort
  • Kein Setup-Aufwand jetzt

Contra:

  • Railway als US-Firma, EU-Region nur fuer Datenstandort — fuer regulatorische Audits dasselbe Argument wie AWS aber ohne die Compliance-Gegen-Belege (AVV mit AWS einfacher als mit Railway, AWS hat C5/SOC/ISO-Zertifikate fuer DE-Markt etabliert)
  • Keine echte Mandanten-Trennung — alle Kunden in einem Railway-Projekt
  • Skaliert nicht zu MCP-as-a-Service (kein OAuth-Server-Hosting, kein Multi-Tenant-Pattern)
  • Kein zentraler Audit-Trail ueber mehrere Services

Option B — Single AWS-Account fuer alles

Pro:

  • Eine Bill, eine Console, einfaches Setup
  • Reicht technisch

Contra:

  • Keine Mandanten-Trennung (Becker und Vibe Factory in einem Account = ein Kompromittierungs-Punkt fuer beide Kunden)
  • Cost-Allocation pro Kunde nur ueber Tags, fehleranfaellig
  • IAM wird ueberkomplex sobald >2 externe Mitarbeiter (Alex Gross, kuenftig Vibe-Factory-PM, Icking-Florian) Zugriff brauchen
  • Bei Sicherheits-Vorfall blast radius = alles

Option C — AWS Multi-Account-Org, ein Sub-Account pro Kunde (gewaehlt)

Pro:

  • Strukturelle Mandanten-Trennung. Kunde X kann technisch nicht auf Kunde Y zugreifen, auch nicht versehentlich. IAM-Mistakes haben begrenzten Blast Radius.
  • Cost-Allocation per Account. AWS zeigt pro Account Kosten — Kunde lesen oder Marge intern auswerten ohne Tag-Hygiene-Disziplin.
  • Audit-Trail Org-weit. Ein Org-CloudTrail im Mgmt-Account loggt alles, kann nicht von Sub-Account-Admins abgeschaltet werden.
  • Skaliert zu beliebig vielen Kunden. Account-Erstellung dauert ~1 Minute, ist programmatisch, kostet 0 €.
  • Identity Center zentral. Permission Sets pro Kunden-Use-Case (BeckerBasOperator ist das erste Beispiel) — least-privilege strukturell verankert.
  • Compliance-Dokumentation einfach. „Becker hat seinen eigenen AWS-Account, hier die Account-ID, hier das CloudTrail” ist als Antwort auf Audit-Fragen viel staerker als „wir nutzen Tags zur Trennung”.

Contra:

  • Mehr Setup-Aufwand pro Kunde (~10 Min: Account erstellen, Permission Set zuweisen, CLI-Profil ergaenzen, Doku-File anlegen)
  • Cross-Account-Resource-Sharing braucht explizite Konfiguration (im Default-Fall aber nicht noetig)

Option D — Hetzner Self-Managed

Pro:

  • DSGVO-strukturell (deutsches Unternehmen, Frankfurt-RZ)
  • Kein CLOUD-Act-Argument
  • Fuer hoch-LLM-Volumen-Kunden aus llm-hosting-eu-optionen empfohlen

Contra:

  • Mandanten-Trennung muesste auf Container-Ebene gebaut werden — viel mehr Engineering
  • Kein nativer OAuth-Server / Identity-Hub
  • Ops-Aufwand (Patches, Monitoring, Backups) signifikant
  • Laesst sich mit AWS kombinieren (Hetzner fuer LLM-Self-Hosting wenn noetig, AWS fuer App-Layer)

Entscheidung

Option C — AWS Multi-Account-Org wird der Hosting-Standard fuer Agentic Ventures.

Konkret:

Account-TypNamingZweck
Mastermarvinkuehlmann (343241684374)Org-Admin, Billing, zentrales Audit-Logging, eigene Web-Properties
UG-Productionav-production (425924867359)UG-eigene Workloads, MCP-as-a-Service-Hub mittelfristig
Privatmk-privat (210948569534)Marvin-Privat, steuerlicher Schnitt
Pro Kundeav-<kunde-slug>Kunden-Workload (Becker, Vibe Factory, Icking, …)

Zentrale Komponenten im Mgmt-Account:

  • Identity Center (d-996749743e) als einziger Login-Pfad fuer Marvin und externe Kunden-PMs
  • Org-CloudTrail av-mgmt-trail mit Bucket av-cloudtrail-logs-343241684374 (alle Sub-Accounts ohne Opt-Out)
  • SCPs aktiviert (heute keine Policy gebunden — bei Bedarf z.B. DenyRegionsExceptEU)

Default-Region: eu-central-1 (Frankfurt) fuer alle Workloads, US-Regions nur fuer dezidierte Ausnahmen (z.B. wenn ein Modell EU-only nicht verfuegbar ist).

Per-Account-Pflichten:

  • IAM-Identity-Center-Login statt IAM-User (Ausnahme: Service-Accounts wie bas-bedrock-pilot)
  • Permission Sets pro Kunden-Mitarbeiter mit Inline-Policy auf genau die Ressourcen die er braucht
  • Bedrock-Aktivierung pro Account auf Bedarf (im Becker-Account breit aktiviert, default-Modell pro Use-Case vorgeben)
  • Pro Sub-Account ein Doku-File intern/capabilities/aws/av-<kunde>.md mit Bestand

Railway-Migration: Alle Code-Sachen wandern mittel-/langfristig auf AWS. Kein hartes Cutoff-Datum — laufende Services bleiben auf Railway bis das AWS-Aequivalent steht und getestet ist (parallel-and-switch). Konkret:

  • mcp-vf-hosted — VF-Mono-MCP — primaerer Migrations-Kandidat. Ziel-Architektur: AWS App Runner oder ECS Fargate in av-production (nicht in av-vibe-factory — der MCP gehoert AV, nicht VF), OAuth weiter via Scalekit (oder Migrate auf Cognito wenn das Kosten-/Komfort-Budget besser ist).
  • Alle eigenen MCP-Repos (_index) — als hosted Services in av-production — siehe „MCP-as-a-Service” unten.

Sub-Accounts kuenftiger Kunden:

  • av-vibe-factory (Vibe Factory) — anlegen sobald Migration mcp-vf-hosted startet
  • av-icking (Icking) — leerer Sub-Account fuer eventuelle eigene Workloads die wir fuer Icking betreiben. Aktuell laeuft im Icking-eigenen AWS-Account 063507503859 nur die AI-Pipeline fuer Smart Dach Next (Mistral-Judge, 5.500 EUR Festpreis). HeyJulia laeuft heute noch gar nicht (Vertrag v4 vom 2026-05-06 wartet auf Antwort) und wird wenn er kommt bei uns gehostet

Aus dem Vault-Konvention-Set: Naming av-<kunde-slug>, Email-Plus-Alias aws+av-<kunde-slug>@agenticventures.de, dokumentiert in naming-konvention.

Konsequenzen

Wirtschaftlich

  • Account-Erstellung kostet 0 €. Unterschied zu Railway: Wir bezahlen die tatsaechlich genutzten AWS-Services (S3, Bedrock-Invocations, App Runner / Fargate). Bei niedrigem Volumen (Free-Tier-naehe) kann das billiger oder teurer als Railway sein — Detail-Vergleich pro Service.
  • Bedrock-Invocation-Kosten fuer Becker werden im Becker-Account sichtbar — Cost-Allocation gegen den Kunden ist trivial („Pass-Through” oder „Markup”, spaeter zu entscheiden).
  • Ops-Aufwand initial hoeher (Permission Sets pro Kunde, Doku, neue Sub-Accounts) — danach skaliert flach.

Technisch

  • Neue Code-Deployments laufen ueber AWS-Patterns (App Runner / Fargate / Lambda je nach Workload-Profil), nicht mehr Railway-Konventionen.
  • Secrets in AWS Secrets Manager oder SSM Parameter Store statt Railway-ENV.
  • IaC-Setup: Terraform oder AWS CDK. Heute nicht festgelegt — Vorschlag CDK-Python (passt zu MCP-Repos die alle Python sind), Entscheidung beim ersten Deploy.

Strategisch (MCP-as-a-Service)

Marvin formuliert die Vision: „Ich will alle unsere MCPs auf AWS haben. Damit ich einfach Leute freischalten kann, wenn die meinen MCP nutzen wollen oder die einfach an Software easy anbinden.” Das ist nicht „lift-and-shift bestehende MCPs”. Das ist ein eigenes Produkt:

  • Pro MCP ein hosted Endpoint mit OAuth (per-User-Anmeldung)
  • Multi-Tenant: Marvin gibt Kunde X Zugang zu MCP Y, Kunde X kann nicht Kunde Z’s Daten sehen
  • Subject-bezogene Rate-Limits + Audit-Trail
  • Mehrere Frontends moeglich: Custom Connector in claude.ai, ChatGPT-Custom-GPT, Claude Desktop, n8n etc.

Diese Architektur ist verwandt zum bestehenden mcp-vf-hosted-Pattern (Scalekit + create_proxy), aber breiter und zentralisiert. Eigener Brainstorm faellig — diese ADR commit-tet sich nur darauf, AWS als Plattform zu waehlen, nicht auf die konkrete Multi-Tenant-Auth-Architektur.

Compliance

  • Org-Trail = Audit-Trail Org-weit, kein Sub-Account-Admin kann ihn abschalten
  • AVV mit AWS pro Kunde der Bedrock nutzt — beim Hosting-Konzept-Anhang dokumentieren
  • DSGVO-Argument fuer Becker: „Becker BAS nutzt einen dedizierten AWS-Account 084400305827 in der Region Frankfurt, mit zentralem Audit-Trail im Mgmt-Account, Identity-Center-Login mit MFA, least-privilege Permission Sets pro Mitarbeiter.”
  • CLOUD-Act-Argument bleibt: AWS = US-Anbieter. Fuer Industriekunden mit harter „kein US-Recht” kann/muss Self-Hosted (Hetzner) als Alternative angeboten werden — siehe llm-hosting-eu-optionen. Bisher hat Becker mit AWS-Bedrock-Frankfurt + AVV das Risiko akzeptiert.

Was wegfaellt

  • Railway-Account bleibt aktiv solange Services dort laufen, wird mittelfristig gestoppt
  • Cloudflare bleibt als TLS/WAF/Rate-Schicht vor AWS-Origins (kein Wechsel)

Naechste Schritte

  1. Bedrock-Invocation-Logging im Becker-Account aktivieren — DSGVO-Audit-Trail fuer LLM-Calls.
  2. Migrations-Plan mcp-vf-hosted Railway → AWS ausarbeiten — Ziel-Account av-production, Architektur (App Runner vs Fargate), IaC-Tooling, Switch-over-Plan.
  3. MCP-as-a-Service-Brainstorm separat — Multi-Tenant-Auth, Pricing, Discovery.
  4. AVV mit AWS fuer Becker-Nutzung dokumentieren / abschliessen.
  5. GuardDuty + Cost-Alerting aktivieren — pro Account oder Org-weit.

Sub-Accounts on-demand statt prophylaktisch. Naming-Konvention av-<kunde> ist dokumentiert (naming-konvention) — wir legen einen Sub-Account an wenn der konkrete Workload kommt, nicht prophylaktisch. Plus-Alias verbrennt sonst dauerhaft ohne Use-Case. Aktuell zurueckgestellt:

  • av-vibe-factory — mcp-vf-hosted-Migration landet in av-production (der MCP gehoert AV, nicht VF). Anlegen wenn VF-eigene Workloads dazukommen
  • av-icking — Icking betreibt eigenen Account 063507503859 (AI-Pipeline Smart Dach Next, ausserhalb unserer Org). Cross-Org-Konsolidierung in unser Identity Center geht nicht direkt — siehe cross-org-zugriff-icking. Anlegen wenn HeyJulia-Vertrag rein kommt und Hosting bei uns landet
  • _index — operatives Inventar
  • llm-hosting-eu-optionen — Bedrock vs Mistral vs Self-Hosted
  • zugriffsmodell — Kunden-Trennungs-Doktrin (war schon vor AWS-Multi-Account formuliert, ist konsistent)
  • mcp-vf-hosted — der erste Migrations-Kandidat
  • stack — Tool-Inventar (Railway als „wird abgeloest” markiert)

Graphansicht

Backlinks