Kostenbewusste Architektur behandelt Kosten als Eigenschaft eines Systems wie Verfügbarkeit oder Latenz: Ein großer Teil der Cloud-Rechnung steht fest, sobald entschieden ist, wer einen Dienst betreibt, auf welchem Modell er läuft, über wie viele Zonen und Regionen er verteilt ist, wo seine Daten liegen und auf welcher Prozessorarchitektur er rechnet. Rightsizing und Commitments optimieren danach nur noch innerhalb dieser Entscheidungen. AWS, Microsoft und Google führen Kosten deshalb als eigene Säule ihrer Well-Architected Frameworks, und die FinOps Foundation ordnet die Arbeit ihrer Capability Architecting & Workload Placement zu. Wie solche Entscheidungen geprüft und freigegeben werden, behandelt Kosten in Architektur- und Beschaffungsreviews.
So funktioniert es
Die drei Frameworks benennen ihre Grundsätze unterschiedlich, setzen aber denselben Rahmen: nur bezahlen, was genutzt wird, Kosten einem Ergebnis zuordnen und laufend nachsteuern.
| Framework | Grundsätze der Kostensäule |
|---|---|
| AWS Well-Architected, Cost Optimization Pillar | Implement cloud financial management; Adopt a consumption model; Measure overall efficiency; Stop spending money on undifferentiated heavy lifting; Analyze and attribute expenditure |
| Azure Well-Architected Framework, Cost Optimization | Develop cost-management discipline; Design with a cost-efficiency mindset; Design for usage optimization; Design for rate optimization; Monitor and optimize over time |
| Google Cloud Well-Architected Framework, Cost Optimization | Align cloud spending with business value; Foster a culture of cost awareness; Optimize resource usage; Optimize continuously |
Microsoft beschreibt zusätzlich ausdrücklich, wo Kostenoptimierung mit den anderen Säulen kollidiert: Zuverlässigkeit, Sicherheit, operative Exzellenz und Leistung. Diese Zielkonflikte sind der Kern jeder Architekturentscheidung mit Preis:
| Entscheidung | Was sie an Kosten festlegt | Wogegen sie abgewogen wird | Prüffrage |
|---|---|---|---|
| Verwalteter Dienst oder selbst betrieben | höherer Stückpreis gegen Betriebsaufwand für Patches, Backups und Failover, der auf keiner Rechnung steht | Kontrolle, Lizenzen | Wer betreibt es nachts und am Wochenende? |
| Serverless, Container oder virtuelle Maschine | Abrechnung je Aufruf und Laufzeit, je angeforderter Pod-Ressource oder je Instanzstunde | Dauerlast, Laufzeitgrenzen, Kaltstarts | Wie viele Stunden am Tag liegt Last an? |
| Eine Zone oder mehrere | Standbys und Replikate als zusätzliche Instanzen, Verkehr zwischen Zonen | Verfügbarkeitsziel | Welcher Ausfall rechtfertigt den Aufschlag? |
| Eine Region oder mehrere | doppelte Infrastruktur, Replikation und Transfer zwischen Regionen | Wiederanlaufziel | Was kostet ein Regionsausfall im Vergleich? |
| Datenplatzierung | Egress, Transfer zwischen Diensten und Zonen | Latenz, Datenresidenz | Wo werden die Daten gelesen? |
| Arm oder x86 | eigene Preislisten für Arm-Typen | Build- und Abhängigkeitskette | Gibt es arm64-Builds aller Abhängigkeiten? |
Die Abrechnungseinheiten der Betriebsmodelle erklären Serverless-Funktionen, Container und Kubernetes und Virtuelle Maschinen und Instanzfamilien; die Preise für Datentransfer stehen unter Datentransfer und Egress.
AWS
Amazon RDS for PostgreSQL führt eigene Preise für Single-AZ, Multi-AZ mit einem Standby in einer anderen Zone und Multi-AZ mit zwei lesbaren Standbys, die identische Instanzen in drei Zonen betreibt. Die Replikation zwischen den Zonen einer Multi-AZ-Bereitstellung ist kostenlos; Verkehr zwischen einer EC2-Instanz und einer RDS-Instanz in verschiedenen Zonen kostet den regionalen EC2-Datentransfersatz, den die RDS-Preisseite ohne Angabe einer Region mit USD 0,01 je GB in jeder Richtung nennt (gelesen am 2026-10-16). Eine Snapshot-Kopie in eine andere Region kostet den Transfer und danach Speicher in der Zielregion. Bei Arm verlangt AWS für Lambda-Funktionen, dass jede Bibliothek von Drittanbietern eine arm64-Fassung hat.
Azure
Zwischen den Verfügbarkeitszonen einer Region berechnet Azure keinen Datentransfer, und die Art der IP-Adresse spielt dabei keine Rolle. Die Arm-Größen der Dpsv6-Serie laufen auf Microsofts eigenem Prozessor Cobalt 100.
Google Cloud
Verkehr von einer VM zu einer VM, zu Cloud SQL oder zu GKE in einer anderen Zone derselben Region kostet USD 0,01 je GiB, ein Satz, den die VPC-Preisseite für jede Region nennt (gelesen am 2026-10-16), berechnet dem Projekt der sendenden VM. Cloud SQL berechnet für hochverfügbare, regionale Instanzen eigene HA-Preise; Verkehr aus Cloud SQL zu Compute Engine in derselben Region ist frei, zu einem Replikat in einer anderen Region kostet er USD 0,12 je GiB, innerhalb wie außerhalb Nordamerikas. Die Serien C4A und N4A laufen auf Googles Arm-Prozessor Axion.
Was es für Ihre Kosten bedeutet
Architektur legt Menge und Stückpreis fest, bevor ein Commitment den Satz senkt, und kein Rabatt ersetzt sie nachträglich. Eine Entscheidung wird deshalb mit drei Angaben festgehalten: den erwarteten Kosten in einer Geschäftseinheit, etwa je Anfrage oder je Kunde (Stückkosten), dem Zielkonflikt, der sie begründet, und dem Ereignis, bei dem sie neu geprüft wird. Die Reihenfolge im Kapitel gilt auch hier: erst die Architektur, dann Messung und Rightsizing, zuletzt Commitments (Commitment-Strategie). Eine Reservierung, die für eine Instanzfamilie gekauft wird, bevor über Serverless oder Arm entschieden ist, bleibt jede Stunde ihrer Laufzeit zu zahlen, ob die Familie noch läuft oder nicht. Die Hebel beim Verkehr selbst beschreibt Datentransferkosten senken.
Wo es schiefgeht
- Hochverfügbarkeit überall. Symptom: Test- und Entwicklungsdatenbanken laufen mit Standby oder zu HA-Preisen. Ursache: Die Produktionsvorlage wurde ohne Abwägung für alle Umgebungen übernommen.
- Zonenverkehr nicht eingeplant. Symptom: Die Position für regionalen Datentransfer wächst mit der Last. Ursache: Anwendung und Datenbank liegen in verschiedenen Zonen; AWS berechnet zwischen EC2 und RDS beide Richtungen, Google Cloud die Richtung von der VM zu Cloud SQL.
- Zweite Region ohne Budget. Symptom: Transfer- und Speicherpositionen in einer zweiten Region tauchen auf. Ursache: Snapshot-Kopien oder Replikate wurden für die Notfallvorsorge eingerichtet, ohne ihren Preis einzuplanen.
- Arm-Umstellung stockt. Symptom: Die Migration bleibt bei einem Dienst stehen. Ursache: Eine Bibliothek oder ein Layer hat keine arm64-Fassung.
- Selbstbetrieb sieht billiger aus. Symptom: Der eigene Datenbankserver kostet auf der Rechnung weniger als der verwaltete Dienst. Ursache: Patches, Backups und Failover erscheinen als Arbeitszeit, nicht als Cloud-Position; AWS fasst das unter dem Grundsatz „Stop spending money on undifferentiated heavy lifting“.
- Commitment vor der Entscheidung. Symptom: Nach dem Wechsel auf Serverless oder Arm bleibt eine Reservierung ungenutzt. Ursache: Sie wurde auf die alte Instanzfamilie gekauft.
Beispiel
Eine Anwendung auf virtuellen Maschinen liest aus einer verwalteten Datenbank in einer anderen Zone derselben Region; V₁ sind die Gigabyte zur Datenbank, V₂ die Gigabyte zurück. Mit den am 2026-10-16 gelesenen Sätzen kostet der Verkehr bei AWS zwischen EC2 und RDS USD 0,01 × (V₁ + V₂), auf der EC2-Seite in beiden Richtungen berechnet (ein Satz, den AWS ohne Region angibt). Bei Google Cloud mit Cloud SQL kostet nur die Richtung von der VM zur Datenbank, USD 0,01 × V₁ (in GiB, in jeder Region), denn Verkehr aus Cloud SQL zu Compute Engine in derselben Region ist frei. Bei Azure kostet derselbe Verkehr nichts. Dieselbe Architektur hat damit drei Preise, und der Abstand wächst mit dem Volumen.
Quellen
Gelesen am 2026-10-16. AWS Cost Optimization Pillar und ihre Gestaltungsgrundsätze, Amazon RDS Preise, Amazon RDS for PostgreSQL Preise, Lambda-Architekturen und arm64; Microsoft Grundsätze der Kostenoptimierung, Zielkonflikte der Kostenoptimierung, Verfügbarkeitszonen, Dpsv6-Serie; Google Cloud Säule Kostenoptimierung im Well-Architected Framework, Preise für VPC-Netzwerke, Cloud SQL Preise, Maschinenfamilien für allgemeine Zwecke; FinOps Foundation Architecting & Workload Placement (CC BY 4.0).