Ein Architekturreview mit Kostenteil prüft, bevor eine Architektur gebaut oder ein Dienst eingekauft wird, ob ihre laufenden Kosten geschätzt, verstanden und einem Verantwortlichen zugeordnet sind. Ein großer Teil der späteren Rechnung folgt aus Entscheidungen, die im Entwurf fallen: Dienste, Regionen, Datenwege, Verträge. Was das Review nicht fragt, erscheint erst im Kostenbericht, wenn die Entscheidung nur noch mit Umbau zu ändern ist. Diese Seite beschreibt das Review als Prozess, seine Eingaben und die kürzere Beschaffungsprüfung für einen neuen Dienst oder ein Marketplace-Produkt. Die Abwägungen zwischen Architekturen selbst behandelt Architekturentscheidungen und Kosten.
So funktioniert es
Die FinOps Foundation ordnet das Thema in ihrem Framework der Capability Architecting & Workload Placement zu. Ab der Reifestufe Walk erwartet das Framework, dass die Entscheidung auf einer schriftlichen Abwägung beruht, in der Kosten neben Wert, Souveränität, Resilienz und Nachhaltigkeit stehen, und dass der Bau sich daran messen lässt; in der Stufe Run werden Abweichungen zwischen Entwurf und gebautem System erfasst. Die Fragen selbst liefern die Provider.
| Provider | Werkzeug | Kostenfragen |
|---|---|---|
| AWS | Well-Architected Tool mit der Säule Cost Optimization | elf Fragen, COST 1 bis COST 11, darunter Dienstauswahl (COST 5), Preismodelle (COST 7), Datentransfer (COST 8) und Bewertung neuer Dienste (COST 10) |
| Azure | Azure Well-Architected Review, ein Assessment auf Microsoft Learn | Checkliste CO:01 bis CO:14, darunter Kostenmodell (CO:02), Ausgabengrenzen (CO:04) und Umgebungskosten (CO:08) |
| Google Cloud | Well-Architected Framework, Säule Kostenoptimierung | keine nummerierten Fragen, sondern Empfehlungen je Prinzip; für das Review zählt vor allem das Prinzip Kostenbewusstsein |
AWS
Das Well-Architected Tool dokumentiert einen Workload entlang der Fragen, zählt hohe und mittlere Risiken und hält den Stand als Meilenstein fest; AWS empfiehlt, nach jeder Verbesserung einen Meilenstein zu speichern. Eigene Fragen kommen als Custom Lens hinzu, laut AWS etwa für die Governance-Anforderungen der Organisation, und Review-Vorlagen füllen Antworten vor, die für mehrere Workloads gleich sind. Drei Best Practices tragen den Kostenteil: COST05-BP06 verlangt eine Kostenanalyse bei der Nutzung, die über die Zeit erwartet wird, COST08-BP01 ein Modell des Datentransfers, dessen Kosten bei AWS von Quelle, Ziel und Volumen abhängen, und COST07-BP03 Verträge mit Drittanbietern, deren Preis nur mit dem Nutzen für Sie wächst.
Azure
Das Azure Well-Architected Review deckt neben Kosten auch Zuverlässigkeit, Sicherheit, Betrieb und Leistung ab und endet mit Empfehlungen. Für das Kostenreview zentral ist CO:02: ein Kostenmodell, das Anfangs- und laufende Kosten schätzt, und ein darauf verhandeltes Budget mit Reserve für Ungeplantes. CO:08 verlangt, die Ausgaben über Vorproduktion, Produktion, Betrieb und Disaster Recovery zu priorisieren und für jede Umgebung Verfügbarkeit, Lizenzen und Betriebszeiten zu bedenken.
Google Cloud
Google rät Teams, jede Bereitstellungsoption schon im Architektur-Blueprint mit ihren Kosten zu versehen, und zählt die erwarteten Ressourcenkosten zum Zeitpunkt von Entwurf und Bereitstellung zu den Kostendaten, die jede Rolle braucht.
Eingaben des Reviews
| Eingabe | Inhalt | Liefert |
|---|---|---|
| Erwartetes Volumen | Nutzer, Anfragen, Datenmenge je Monat, mit Wachstumsannahme | Product |
| Schätzung je Option | Preisrechner oder Preis-API, mit dem Vermerk, ob Listen- oder Vertragspreise | Engineering |
| Datentransfer-Wege | Quelle, Ziel und Volumen je Verbindung | Engineering |
| Commitment-Passung | ob vorhandene Commitments die neue Architektur abdecken | wer Commitments kauft |
| Umgebungen | Test, Staging und Disaster Recovery neben Produktion | Engineering |
| Exit- und Wechselkosten | Datenmenge für einen Auszug, Bindung, Kündigungsentgelte | Procurement |
| Verantwortlicher und Budget | wer die Kosten trägt, aus welchem Budget | Kostenverantwortlicher |
| Prüfpunkt nach Go-live | was wann mit der Schätzung verglichen wird | Kostenverantwortlicher |
Wie die Schätzung entsteht und was sie nicht weiß, beschreibt Shift Left: Kostenprüfung vor dem Deployment; die Datenwege erklärt Datentransfer und Egress, die Commitment-Typen Commitment-Rabatte im Vergleich. Für die Exit-Kosten verpflichtet Artikel 29 des EU Data Act (Verordnung (EU) 2023/2854) Anbieter von Datenverarbeitungsdiensten, vor Vertragsschluss klar über Standardentgelte, Entgelte für vorzeitige Kündigung und reduzierte Wechselentgelte zu informieren; ab dem 12. Januar 2027 dürfen sie für den Wechsel keine Wechselentgelte mehr erheben, zu denen die Verordnung auch Egress-Entgelte zählt. Was das für die Planung heißt, beschreibt EU Data Act: Cloud-Wechselkosten vor 2027; ob ein konkretes Entgelt darunter fällt, klären Rechtsberatung und Einkauf.
Die Beschaffungsprüfung
Ein SaaS-Dienst oder ein Marketplace-Produkt wird oft ohne Architekturänderung gekauft und braucht deshalb eine eigene, kürzere Prüfung mit vier Fragen: die Laufzeit mit Mindestabnahme und Kündigung; der Abrechnungsweg, also Rechnung des Cloud-Providers oder des Herstellers (Marketplace-Käufe auf der Cloud-Rechnung); die Daten, die der Hersteller erhält, geprüft von der Person, die den Datenschutz betreut; und die Verlängerung mit Frist und Preisregel. Bei AWS Marketplace ist AWS nicht Partei des Vertrags zwischen Käufer und Verkäufer. Private Offers mit Vertragspreisen können seit September 2026 eine automatische Verlängerung enthalten, deren Preisfortschreibung und Entscheidungsfrist der Verkäufer festlegt. Damit nur Geprüftes gekauft wird, bieten alle drei Provider eine Freigabeschicht: AWS Private Marketplace mit genehmigten Katalogen je Organisation, OU oder Konto; Private Microsoft Marketplace, in dem nur freigegebene Partnerangebote bereitgestellt werden können, während Microsofts eigene Anwendungen immer erlaubt sind; in Google Cloud Product Requests, die aus der Anfrage eines Nutzers eine Beschaffungsanfrage an die Administratoren machen. Vertragsfragen im Detail behandelt Beschaffungsverträge und Verlängerungen.
Das Review endet mit einer Entscheidung und einem Namen. Wer ab welcher Größe unterschreibt, legen die Freigabeschwellen fest.
Was es für Ihre Kosten bedeutet
Ein Review ändert die Rechnung nicht direkt, es ändert, welche Kosten überraschen. Die Schätzung aus dem Review wird zur Basis, an der der erste volle Monat gemessen wird; ohne sie hat eine Abweichung keinen Bezugspunkt. Weil der Prüfpunkt nach Go-live schon vereinbart ist, lässt sich eine Differenz einer Ursache zuordnen: anderes Volumen, nicht modellierter Datentransfer, ein Rabatt, der in der Schätzung fehlte. Festgehalten wird das Ergebnis so, wie es Kostenentscheidungen dokumentieren beschreibt.
Das Review ist kein einmaliges Ereignis. AWS führt unter COST 10 einen Review-Prozess je Workload und eine regelmäßige Überprüfung, und schreibt in COST05-BP06, dass der Analyseaufwand dem möglichen Ergebnis entsprechen soll. Für ein kleines Unternehmen heißt das: Eine ausgefüllte Eingabentabelle mit Datum und Unterschrift genügt für die meisten Entscheidungen, und die Schwellen bestimmen, wann mehr nötig ist.
Wo es schiefgeht
- Review nur aus Anlass. Symptom: Kostenfragen kommen erst nach einem Vorfall oder einer hohen Rechnung, und jede Antwort heißt Umbau. Ursache: Es gibt keinen festen Prüfpunkt im Entwurf; die FinOps Foundation ordnet anlassbezogene Reviews ohne Rhythmus der Stufe Crawl zu.
- Schätzung ohne Datenwege. Symptom: Die Rechnung zeigt Transfer zwischen Zonen, Regionen oder ins Internet, den die Schätzung nicht enthält. Ursache: Quelle, Ziel und Volumen der Verbindungen waren keine Eingabe.
- Listenpreis gegen Vertragspreis. Symptom: Schätzung und Ist weichen systematisch in eine Richtung ab. Ursache: Die Schätzung nutzt Listenpreise, die Rechnung verhandelte Preise, oder umgekehrt.
- Verwaistes Commitment. Symptom: Die Auslastung einer Reservierung sinkt nach einer Migration. Ursache: Die Commitment-Passung wurde nicht geprüft.
- Verpasste Verlängerungsfrist. Symptom: Ein Marketplace-Vertrag läuft zu neuem Preis weiter. Ursache: Die automatische Verlängerung wurde bei der Annahme akzeptiert, und vor der Entscheidungsfrist hat niemand die Ankündigung der Verlängerung geprüft.
- Katalog ohne Wirkung auf Bestand. Symptom: Trotz Private Marketplace laufen nicht freigegebene Produkte weiter. Ursache: AWS Private Marketplace blockiert neue Abonnements und Änderungen, keine bestehenden.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Architecting & Workload Placement (CC BY 4.0); AWS Kostenoptimierung im Well-Architected Framework, Fragen COST 5 bis COST 8, Fragen COST 10 und COST 11, COST05-BP06 Kostenanalyse für Nutzung über die Zeit, COST07-BP03 Drittanbieterverträge, COST08-BP01 Datentransfer modellieren, COST 10 Bewertung neuer Dienste, Was ist das AWS Well-Architected Tool?, Workloads, Meilensteine, Review-Vorlagen, Verträge in AWS Marketplace, Automatische Verlängerung von Private Offers, Ankündigung vom 1. September 2026 und Private Marketplace; Microsoft Azure Well-Architected Review, Checkliste der Säule Cost Optimization und Private Microsoft Marketplace; Google Cloud Säule Kostenoptimierung, Kostenbewusstsein fördern und Produktanfragen zulassen; EUR-Lex Verordnung (EU) 2023/2854 (Data Act).