AWS macht Kostenübersicht zur Grundausstattung statt zum Bastelprojekt

AWS Billing bekommt fünf vorgefertigte Kostenperspektiven

AWS Billing and Cost Management bekommt seit dem 14. August 2026 eine neue Schublade: Managed Dashboards. Wie AWS in der Ankündigung schreibt, ergänzen die AWS Billing and Cost Management (BCM) Dashboards nun um eine Sammlung vorkonfigurierter, schreibgeschützter Ansichten, die direkt in der bestehenden Dashboard-Liste jedes Kontos erscheinen. Wer bislang für jede Kostenfrage erst eine eigene Abfrage im Cost Explorer gebaut hat, bekommt hier einen fertigen Ausgangspunkt geschenkt, ohne dafür ein einziges Formular auszufüllen. Der Zeitpunkt der Einführung fällt dabei nicht zufällig in eine Phase, in der viele Unternehmen ihre Cloud-Ausgaben ohnehin genauer prüfen, weil Budgets enger kalkuliert werden als noch vor zwei Jahren.

Der Clou liegt im zweiten Satz der Ankündigung: Die Dashboards liefern verwertbare Kosteneinblicke, bei denen die eigenen Kontodaten bereits eingetragen sind, ganz ohne Einrichtung. Für AWS Managed Dashboards heißt das konkret: kein Rollen-Setup, keine Datenquellen-Verknüpfung, kein Warten auf den ersten Sync. Insgesamt fünf kuratierte Dashboards bilden die neue Kategorie, von denen AWS in der Ankündigung drei namentlich beschreibt – was zugleich zeigt, wie viel Deutungsspielraum bei den übrigen zwei bleibt, bis AWS selbst mehr dazu veröffentlicht.

Bemerkenswert ist auch, wo AWS die neue Kategorie einordnet: nicht als eigenständiges Produkt mit neuem Namen, sondern als Erweiterung der bestehenden BCM-Dashboards, die es seit Jahren gibt. Für Bestandskunden bedeutet das, dass die Umstellung ohne Migrationsprojekt passiert – die neuen Ansichten tauchen einfach in der vorhandenen Liste auf, sobald sie ausgerollt sind, ohne dass jemand einen Vertrag anpassen oder ein Feature-Flag aktivieren müsste. Für Teams, die Cloud-Kosten bislang über verteilte Excel-Tabellen zusammengetragen haben, ist allein diese Integration in die bestehende Konsolenoberfläche schon ein kleiner Fortschritt, weil kein zusätzlicher Login und kein separates Tool nötig werden.

Schreibschutz als Designprinzip, nicht als Einschränkung

Dass die neuen Ansichten schreibgeschützt sind, klingt zunächst nach einer Einschränkung. Tatsächlich ist es eine bewusste Entscheidung: Managed Dashboards sollen laut AWS eine verlässliche, unveränderliche Referenz liefern – eine Art Kontrollinstanz, die nicht versehentlich durch einen falsch gesetzten Filter oder eine gelöschte Kennzahl verzerrt wird. Für AWS Managed Dashboards bedeutet das: Jedes Team im Unternehmen sieht dieselbe Zahl, wenn es dieselbe Ansicht öffnet, egal ob Finance, Engineering oder Geschäftsführung zuschauen.

In der Praxis löst das ein Problem, das FinOps-Teams seit Jahren kennen: Sobald mehrere Personen eigene Dashboards bauen, driften die Definitionen auseinander. Was der eine als ‚ungenutzte Kapazität‘ zählt, zählt der andere als ‚geplante Reserve‘. Ein schreibgeschütztes Standarddashboard schließt diese Debatte nicht endgültig, verschiebt sie aber wenigstens auf die Interpretation derselben Zahlen – süffisant gesagt: Der Streit wird nicht kleiner, aber ehrlicher, weil beide Seiten von derselben Datengrundlage ausgehen müssen.

Für die Systemseite ändert sich außerdem die Fehlerquelle: Ein selbst gebautes Dashboard kann durch einen falschen Join oder eine veraltete Formel leise falsche Werte anzeigen, ohne dass es jemand merkt. Ein von AWS gepflegtes Dashboard verschiebt dieses Risiko zumindest teilweise zum Anbieter – was nicht bedeutet, dass es fehlerfrei ist, aber dass die Fehlerkorrektur zentral erfolgt, statt in Dutzenden internen Kopien parallel gepflegt werden zu müssen. Wer heute schon ein internes Kostenwiki mit Formeldefinitionen pflegt, kann diese Dokumentation künftig zumindest für die fünf Standardansichten schlanker halten.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA finance hand compares a locked transparent tray of sorted cloud resource stones with a flexible tray assembled from loose pieces under crisp side light. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Vorkonfiguration spart Aufbau, nicht Analyse

Von den fünf kuratierten Dashboards benennt AWS in der Ankündigung namentlich drei. Cost Overview & Trends verfolgt die Ausgabenentwicklung über Services, Konten und Regionen hinweg über zwölf Monate und liefert dazu eine vorausschauende Prognose. Compute and Database bündelt die Ausgaben je Servicekategorie mit passenden Kennzahlen zu Commitment-Abdeckung und Auslastung in einer einzigen Ansicht. Reservations and Savings Plans zeigt, wie gut die eigenen Commitments über alle berechtigten Services hinweg performen, und beziffert Lücken und Unterauslastung direkt in Geldbeträgen. Alle drei genannten Ansichten teilen sich dabei denselben Grundgedanken: Kosten werden nicht isoliert gezeigt, sondern immer im Verhältnis zu einer Nutzungs- oder Commitment-Kennzahl, was die reine Ausgabenzahl erst einordbar macht.

Der Name der Kategorie ist also Programm: Vorkonfiguration erspart den Aufbau, nicht die Analyse. Eine zwölfmonatige Prognose bleibt eine Prognose, eine Auslastungskennzahl bleibt erklärungsbedürftig. Wer verstehen will, warum eine Reservierung unterausgelastet ist, muss trotzdem ins Detail – AWS liefert nur den Anlass, nicht die Ursache. Gerade die Bezifferung von Lücken in Geldbeträgen dürfte für viele Finance-Teams der eigentliche Mehrwert sein, weil sich damit Prioritäten leichter gegenüber dem Management begründen lassen als mit reinen Prozentzahlen.

Wichtig ist dabei die Reihenfolge der Aussagen in der Ankündigung: erst die Sichtbarkeit, dann die Handlungsempfehlung. AWS verspricht nirgends, dass die Dashboards automatisch sparen – sie zeigen nur, wo sich ein genauerer Blick lohnen könnte. Die eigentliche Entscheidung, eine Reservierung anzupassen oder eine Instanzgröße zu ändern, bleibt weiterhin bei den Teams, die die Workloads verantworten. Das ist konsequent, weil AWS als Anbieter kaum eine automatische Kaufentscheidung für Savings Plans treffen sollte, ohne die individuelle Risikobereitschaft eines Kunden zu kennen.

Regionale Verfügbarkeit und der Preis von null Euro

AWS Managed Dashboards stehen laut Ankündigung in allen kommerziellen AWS-Regionen zur Verfügung, und zwar ohne zusätzliche Kosten. Für Unternehmen mit Workloads über mehrere Regionen bedeutet das: Es gibt keinen Grund, mit der Einführung zu warten, bis eine bestimmte Region nachzieht – die Funktion ist von Tag eins an überall gleich verfügbar, unabhängig davon, ob die Workloads in Frankfurt, Ohio oder Singapur laufen.

Der Zugang führt laut AWS über den Menüpunkt Dashboards in der AWS Billing and Cost Management Console oder über das offizielle Benutzerhandbuch. Wer die Konsole ohnehin regelmäßig für Rechnungen und Budgets öffnet, muss also keinen neuen Dienst aktivieren oder ein separates Onboarding durchlaufen. Das senkt die Einstiegshürde – und macht gleichzeitig deutlich, dass es sich nicht um ein Premium-Feature handelt, sondern um eine Grundausstattung, die AWS offenbar für selbstverständlich hält.

Ein Nebeneffekt der regionalen Gleichbehandlung: Unternehmen mit verteilten Teams müssen nicht erst klären, ob Kolleg:innen in einer bestimmten Region überhaupt Zugriff auf die Funktion haben. Das reduziert die Zahl der Sonderfälle, die eine interne Kostendokumentation sonst aufführen müsste, spürbar – ein kleiner, aber angenehmer Nebeneffekt für jedes Unternehmen mit globaler Kontostruktur. Auch für Compliance-Teams, die ohnehin jede regionsspezifische Ausnahme dokumentieren müssen, bedeutet die einheitliche Verfügbarkeit weniger Prüfaufwand.

Editierbare Kopien statt Pull Requests fürs Kostenmodell

Wer die feste Struktur eines AWS Managed Dashboards nicht mag, muss sie nicht hinnehmen. AWS erlaubt, jedes Dashboard zu duplizieren und daraus eine vollständig editierbare Kopie zu machen, einzelne Widgets zu bestehenden Dashboards hinzuzufügen und Daten als PDF oder CSV zu exportieren. Der Schreibschutz gilt also nur für das Original, nicht für das, was daraus entsteht, und die Standardansicht bleibt jederzeit als Rückfallpunkt erhalten, falls eine angepasste Kopie versehentlich verändert wird.

Damit verschiebt sich die Frage von ‚Baue ich mir ein eigenes Dashboard?‘ zu ‚Reicht mir die Kopie mit ein paar zusätzlichen Widgets?‘. Für viele Teams dürfte Letzteres reichen, gerade wenn die Ausgangsstruktur bereits die richtigen Kennzahlen zeigt. Ähnliche Abwägungen zwischen Standardkomponenten und Eigenbau kennen Teams auch aus anderen Cloud-Bereichen; unser Beitrag zur Latenzreduktion bei AWS-Bedrock-Agenten beschreibt ein vergleichbares Spannungsfeld zwischen vorgefertigten Bausteinen und individueller Justierung. Der PDF- und CSV-Export ist dabei kein Nebendetail: Er erlaubt, dieselben Zahlen auch außerhalb der AWS-Konsole zu präsentieren, etwa in einem Board-Meeting oder einem internen Kostenreview, ohne dass jemand die Grafik von Hand nachbauen muss.

Wo FinOps-Teams weiterhin selbst rechnen müssen

So praktisch die neue Kategorie ist, sie deckt nicht alles ab, was FinOps-Arbeit ausmacht. AWS beschreibt Managed Dashboards ausdrücklich als Einstieg: Ob man am Anfang der eigenen FinOps-Praxis steht oder eine einheitliche Basis über mehrere Konten sucht, die Dashboards liefern Kostensichtbarkeit ohne Einrichtung, damit Analyse und Handeln im Vordergrund stehen statt Konfiguration. Sichtbarkeit ist damit vorausgesetzt gelöst – Handeln bleibt Aufgabe der Teams, die die Zahlen anschließend in Budgetentscheidungen übersetzen müssen. Ob dieser Chargeback pro Kostenstelle in einer künftigen Ausbaustufe nachgereicht wird, lässt die Ankündigung offen; für heutige Multi-Team-Organisationen bleibt das ein spürbarer Unterschied zu ausgereiften internen FinOps-Tools.

Was fehlt, ist unter anderem ein Chargeback pro Kostenstelle, eine Verknüpfung mit internen Budgetsystemen oder ein Vergleich mit Wettbewerbspreisen. Auch Zugriffsrechte auf Kostendaten bleiben Sache jedes einzelnen Unternehmens, nicht des Dashboards selbst. Wie eng Standardisierung und Eigenverantwortung nebeneinander bestehen müssen, zeigt sich auch abseits der Kostenrechnung, etwa dort, wo IT-Teams Basiskonfigurationen erst selbst absichern müssen; unser Beitrag zur Rootless-Härtung von Docker und Podman zeigt ein ähnliches Muster in einem ganz anderen Feld. Auch dort liefert der Hersteller eine sichere Grundeinstellung, während die konkrete Absicherung im Betrieb weiterhin bei den verantwortlichen Teams verbleibt.

Standard ersetzt Fleiß, nicht Urteilsvermögen

Am Ende bleibt eine nüchterne Bilanz: AWS Managed Dashboards ersetzen die Fleißarbeit, ein Kosten-Dashboard von Grund auf zu bauen, nicht das Urteilsvermögen, die Zahlen richtig einzuordnen. Wer schon eine ausgereifte eigene FinOps-Praxis hat, gewinnt vor allem eine gemeinsame Referenz für Diskussionen mit anderen Teams. Wer noch am Anfang steht, gewinnt einen Startpunkt, der sofort verwertbare Daten zeigt, statt erst Wochen mit Aufbauarbeit zu verbringen und dabei möglicherweise dieselben Fehler zu machen, die AWS mit der zentralen Pflege der Dashboards von vornherein vermeidet.

Süffisant formuliert: AWS hat im Grunde ein Produkt gebaut, das viele interne Wikis überflüssig macht, in denen bislang stand, wie man sich sein eigenes Kostendashboard zusammenklickt. Für die eigene Cloud-Rechnung heißt das konkret, in der Billing-Konsole nachzusehen, ob die neuen Ansichten schon aktiv sind – und sie dort zu nutzen, wo sie eine Frage schneller beantworten als die bisherige Eigenbau-Lösung.

Wer die Einführung nutzen will, sollte trotzdem nicht blind vertrauen: Die Kennzahlen sind nur so gut wie die Kontostruktur darunter. Ein Konto ohne konsistente Tagging-Praxis bekommt auch mit AWS Managed Dashboards keine plötzliche Ordnung – die Übersicht wird lediglich schneller sichtbar, nicht automatisch sauberer. Wer also von den neuen Dashboards wirklich profitieren will, sollte parallel einen Blick auf die eigene Tag-Disziplin werfen, statt sich allein auf die neue Standardansicht zu verlassen.