AWS Well-Architected: Wie wir's wirklich machen.
Sechs Säulen. Hunderte Best Practices. Die meisten behandeln es wie eine Checkliste. Wir nicht.
AWS Well-Architected Framework. Sechs Säulen. Hunderte Best Practices. Dutzende Whitepapers. Jeder AWS-Partner kennt es. Die meisten behandeln es wie eine Checkliste: Lesen, abhaken, vergessen.
Wir nicht. Wir leben in diesen Säulen. Täglich. In 1.500+ AWS Accounts bei Siemens, in ML-Plattformen bei Volkswagen, in einer HR-Datenplattform, die über eine Million Euro pro Jahr eingespart hat. Hier ist, wie wir die sechs Säulen tatsächlich implementieren. Nicht die AWS-Marketing-Version. Unsere.
Operational Excellence: Observability statt Dashboards
AWS empfiehlt: Implementiere Monitoring und Logging. Die meisten Teams interpretieren das als: CloudWatch Dashboards erstellen und Alert-Regeln schreiben.
Wir gehen weiter.
Self-Healing Agents statt Alert-Fatigue. Beim HR Data Hub bei Siemens Energy überwacht unser AWS Architect Agent CloudWatch-Logs nicht passiv. Er analysiert sie. Erkennt Muster, die kein Mensch in einer Alert-Regel definieren würde. Erstellt Root-Cause-Analysen. Behebt einfache Probleme eigenständig. Komplexe eskaliert er mit Kontext.
Das Ergebnis: Keine Alert-Müdigkeit. Keine nächtlichen Pager-Alerts für False Positives. Ein Agent, der den Unterschied zwischen einem Cold-Start-Timeout und einem echten Infrastrukturproblem kennt.
Infrastructure as Code als Dokumentation. Wir schreiben keine separaten Architektur-Dokumente. Der CDK-Code IST die Dokumentation. Jede Ressource, jede Konfiguration, jede Beziehung zwischen Services ist im Code definiert. Wenn der Code sich ändert, ändert sich die Dokumentation automatisch. Kein Architekturdiagramm, das nach drei Monaten veraltet ist.
Security: Am Anfang, nicht am Ende
AWS empfiehlt: Security by Design. Die meisten Teams interpretieren das als: Security-Review vor dem Go-Live.
Wir implementieren Security ab der ersten Codezeile:
Least Privilege als Default. Jede IAM-Rolle startet mit null Berechtigungen. Wir fügen hinzu, was nötig ist. Nie mehr. Bei Siemens mit 1.500 AWS Accounts ist das nicht optional. Ein Account, der zu viel darf, ist ein Sicherheitsrisiko für den gesamten Konzern.
Cross-Account-Security. Kein Account vertraut einem anderen blind. Jeder Cross-Account-Zugriff ist explizit definiert, zeitlich begrenzt und auditiert. Das klingt aufwändig. Ist es auch. Aber bei 1.500 Accounts ist die Alternative nicht akzeptabel.
Security-Tests in der Pipeline. Jeder Push durchläuft SAST und Dependency-Checks. Nicht als separater Schritt nach der Entwicklung. Als Teil jedes Commits. Wenn ein Security-Test fehlschlägt, geht der Code nicht in Staging.
Kein Zugang für uns nach Übergabe. Wenn wir ein Projekt übergeben, verlieren wir den Zugang. Vollständig. Keine Admin-Hintertür, kein "für Notfälle". Ihr System, eure Zugänge.
Reliability: Serverless als Versicherung
AWS empfiehlt: Design for Failure. Wir interpretieren das als: Eliminiere, was ausfallen kann.
Serverless zuerst. Lambda, Step Functions, S3, DynamoDB, SQS. Kein Server, der abstürzen kann. Kein Container, der hängt. Kein EC2-Instance, das um 3 Uhr nachts einen Kernel-Panic hat.
Beim HR Data Hub verarbeitet die Plattform Daten aus 150+ Ländern mit unterschiedlichen Zeitfenstern und Formaten. Alles serverless. Betriebskosten unter 40.000 EUR pro Jahr. Keine einzige Nacht, in der jemand aufstehen musste.
Retry mit Exponential Backoff. Jeder externe Aufruf (API, Datenbank, AI-Modell) hat Retry-Logik. Nicht pauschal dreimal wiederholen. Sondern mit exponentiell wachsenden Wartezeiten und Circuit Breaker. Wenn ein AI-Provider temporär nicht erreichbar ist, fällt der Agent auf einen alternativen Provider zurück. Provider-Agnostik als Reliability-Feature.
Chaos Engineering (light). Wir schalten nicht zufällig Services ab. Aber wir testen regelmäßig, was passiert, wenn ein AI-Provider nicht antwortet, wenn eine Lambda ihre Timeout-Grenze erreicht, wenn DynamoDB throttled. Diese Tests sind Teil unserer CI/CD-Pipeline.
Performance Efficiency: Messen, nicht raten
Richtige Compute-Wahl pro Workload. Nicht alles ist Lambda. GPU-intensive ML-Workloads laufen auf SageMaker oder ECS mit GPU-Instances. Batch-Verarbeitung läuft auf Step Functions mit parallelen Lambda-Invocations. Real-Time-APIs laufen auf Fargate mit Auto-Scaling.
Bei VW Snowpark betreiben wir 100+ ML-Umgebungen. Jede mit eigenem Compute-Profil, optimiert für den spezifischen ML-Workload. Kein One-Size-Fits-All.
Caching mit Bedacht. Nicht alles muss gecacht werden. Aber AI-Modell-Responses, die für identische Inputs identisch sind, cachen wir. Das reduziert API-Kosten um 30-40 % bei bestimmten Workloads. DynamoDB als Cache für LLM-Responses, mit TTL basierend auf dem Modell-Release-Zyklus.
Cost Optimization: Architektur statt FinOps-Tools
Serverless als Kostenbremse. Der HR Data Hub bei Siemens Energy. Alte Lösung: Über 1.000.000 EUR pro Jahr. Neue Lösung: Unter 40.000 EUR. Kein FinOps-Tool hätte diese Einsparung gebracht. Die Architekturentscheidung hat sie gebracht.
Tagging-Policies ab Tag 1. Jede Ressource wird getaggt: Projekt, Team, Umgebung, Kostenstelle. Automatisiert über CDK. Keine Ressource existiert ohne Tags. Kein Tag, kein Deployment.
Right-Sizing durch Daten. Kein Engineer rät, welche Lambda-Größe oder welcher Fargate-Task passt. Wir messen. AWS Compute Optimizer plus eigene Metriken. Quartalsweise Review aller laufenden Ressourcen.
Sustainability: Weniger Compute, gleiche Ergebnisse
AI-Modell-Auswahl als Nachhaltigkeitsentscheidung. Nicht jede Aufgabe braucht Claude Opus. Für einfache Klassifikationen reicht Haiku. Für Standardtexte reicht Sonnet. Die Modellwahl reduziert nicht nur Kosten, sondern auch den Compute-Footprint.
Serverless = kein Idle-Compute. Kein Server, der 23 Stunden am Tag nichts tut und trotzdem Strom verbraucht. Lambda läuft nur, wenn es etwas zu tun gibt. Bei Workloads, die sporadisch laufen, reduziert das den Compute-Verbrauch um 90 %+.
Kein Framework. Eine Arbeitsweise.
Well-Architected ist bei uns kein Review, den wir vor dem Go-Live durchführen. Es ist die Art, wie wir jeden Tag arbeiten. Jede Architekturentscheidung, jeder Pull Request, jedes Code Review orientiert sich an diesen Prinzipien.
Nicht weil AWS es empfiehlt. Sondern weil es funktioniert. Bei 1.500 Accounts. Bei 120.000 Nutzern. Bei Betriebskosten unter 40.000 EUR für eine Plattform, die vorher über eine Million gekostet hat.
- Die Software, die auf dieser Infrastruktur läuft. Unser AI-Stack in der Praxis.
- Well-Architected in Aktion. 800.000 EUR Einsparung.
- Warum Security und Speed kein Widerspruch sind.
Jannik Frisch hat als Technical Advisor die AWS-Infrastruktur entworfen, die SiemensGPT, HR Data Hub und VW Snowpark trägt.
Profil ansehen →