AWS hat ein Framework das dir sagt, wie du deine Cloud-Architektur “richtig” baust. Sechs Pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, und seit 2021 auch Sustainability. Klingt umfassend.
Das Problem: die Pillars widersprechen sich. Und das Framework sagt dir nicht wie sehr.
Multi-AZ Deployment? Gut für Reliability. Verdoppelt deine Kosten. Encryption everywhere? Gut für Security. Kostet Performance. Auto-Scaling mit Headroom? Gut für Performance. Schlecht für Cost Optimization.
Das Well-Architected Review, das AWS dir anbietet, geht durch einen Fragebogen und sagt dir wo du “at risk” bist. Was es nicht sagt: welche Risiken du bewusst akzeptieren solltest.
Klick durch die Szenarien und schau, wie die Pillars sich gegenseitig auffressen:
Kein Szenario ist überall grün. Das “Well-Architected Ideal” hat einen blinden Fleck: Kosten. Und das “Cost-Optimized” Szenario hat einen blinden Fleck: alles andere.
Die Pillars im Widerspruch
AWS bewirbt das Framework als “learn, measure, improve.” Was sie nicht sagen: improve in einem Pillar heißt oft regress in einem anderen. Das ist kein Bug, es ist ein Trade-off. Aber das Whitepaper behandelt es wie ein Problem das du durch mehr AWS-Services löst.
Reliability vs Cost. Multi-AZ RDS kostet doppelt so viel wie Single-AZ. Aurora Global Database für Multi-Region Failover nochmal 2x. Ein Service der in einer AZ 500$/Monat kostet, kommt über drei Regions mit Failover schnell auf 3.000$. Das Whitepaper sagt: “Design for failure.” Es sagt nicht: “Das kostet dich 6x.”
Security vs Performance. KMS Encryption auf jedem S3 Object, jeder SQS Message, jeder DynamoDB Row. Jeder Encrypt/Decrypt-Call kostet Latenz. Bei einer Lambda die 50ms laufen soll, macht ein KMS-Call 5-15ms aus — 10-30% der Execution Time für Encryption. Plus: KMS hat ein Request Limit von 30.000/s pro Region. Bei hohem Throughput musst du Caching einbauen, was mehr Komplexität bedeutet.
Operational Excellence vs Speed. IaC für alles. Runbooks für jeden Incident. Deployment Pipelines mit 4 Stages. Review-Prozesse. Gut für Stabilität, schlecht wenn du in einer Woche drei Features shippen musst. Startups die das Well-Architected Framework ab Tag 1 befolgen, shippen nichts.
Was das Whitepaper richtig macht
Ehrlich: das Framework ist nicht schlecht. Die Fragen im Review-Prozess sind gut. “Wie recovert ihr von einem Failure?” “Wie trackt ihr Kosten?” “Wie managed ihr Access?” Das zwingt dich, über Dinge nachzudenken die du sonst ignorierst.
Der Fehler ist, alle Pillars gleich zu gewichten. In der Realität:
Phase 1 (0-10 Kunden): Cost Optimization und Performance zählen. Sonst nichts. Bau schnell, bau billig.
Phase 2 (10-1000 Kunden): Security und Reliability kommen dazu. Kein Multi-Region nötig, aber Backups und IAM Policies die nicht * auf alles geben.
Phase 3 (1000+ Kunden): Operational Excellence wird relevant: IaC, Monitoring, Incident Response. Jetzt lohnt sich der Investment.
Phase 4 (Enterprise): Alle Pillars. Audit-Compliance, Multi-Region, Full Observability. Und ein Cloud-Budget das groß genug ist.
AWS bietet “Well-Architected Reviews” durch Partner an. Die kosten 10-50k. Der Output: ein Report der dir sagt was du schon weißt, plus Empfehlungen die fast immer “mehr AWS Services nutzen” bedeuten. Überrascht niemanden, AWS verdient an jedem Service den du hinzufügst.
Meine Empfehlung
Mach den Well-Architected Review. Ernsthaft. Die Fragen sind wertvoll. Aber behandle die Ergebnisse nicht als Checkliste sondern als Input für eine bewusste Entscheidung.
“Wir akzeptieren das Single-AZ Risiko weil Multi-AZ unsere Kosten verdoppelt und wir noch keinen Revenue haben” — das ist eine bessere Architektur-Entscheidung als blindes “Multi-AZ weil das Whitepaper es sagt”, wenn du danach kein Budget mehr für Features hast.
Schreib deine Trade-offs auf. Reviewe sie quartalsweise. Und wenn AWS dir sagt du bist “at risk” in einem Pillar, frag dich: ist dieses Risiko für uns, jetzt akzeptabel? Manchmal ist die Antwort ja.