Schritt 1: Die Struktur schneiden
Schneide entlang von Verantwortung und Umgebung, nicht entlang von Projekten. Projekte enden, Verantwortung bleibt.
# AWS: Organisation mit allen Funktionen, danach Organisationseinheiten
aws organizations create-organization --feature-set ALL
ROOT=$(aws organizations list-roots --query 'Roots[0].Id' --output text)
aws organizations create-organizational-unit --parent-id "$ROOT" --name Workloads
aws organizations create-organizational-unit --parent-id "$ROOT" --name Security
aws organizations create-organizational-unit --parent-id "$ROOT" --name Sandbox
# Azure: Verwaltungsgruppen unterhalb der Mandantenwurzel
az account management-group create --name mg-plattform --display-name "Plattform"
az account management-group create --name mg-workloads \
--display-name "Workloads" --parent mg-plattform
az account management-group subscription add --name mg-workloads \
--subscription "00000000-0000-0000-0000-000000000000"Ein eigenes Konto oder Abonnement je Umgebung ist die einzige Trennung, die im Alltag wirklich hält. Rechte, Kontingente und Rechnungen folgen dieser Grenze automatisch, während eine Trennung über Ressourcengruppen oder Namenskonventionen immer nur so gut ist wie die Disziplin des Teams.
Wo die Grenze verläuft
| Trennung nach | AWS | Azure | Warum |
|---|---|---|---|
| Umgebung | Eigenes Konto je Stufe | Eigenes Abonnement je Stufe | Ein Fehler in der Entwicklung kann die Produktion nicht erreichen |
| Fachbereich | Organisationseinheit je Bereich | Verwaltungsgruppe je Bereich | Richtlinien und Rechte lassen sich vererben statt einzeln zu pflegen |
| Sicherheit | Eigenes Konto für Protokolle und Werkzeuge | Eigenes Abonnement für Protokolle | Protokolle bleiben lesbar, auch wenn ein Konto übernommen wurde |
| Experimente | Sandbox mit engem Budget und kurzer Lebensdauer | Sandbox-Verwaltungsgruppe mit Ausgabenwarnung | Ausprobieren bleibt möglich, ohne die Regeln der Produktion aufzuweichen |