Einleitung
Wenn Ihre Cloud-Ausgaben wachsen und komplexer werden, reicht es nicht mehr, die Rechnung allein nach Service oder Projekt/Account aufzuschlüsseln, um wirklich zu verstehen, wie sich die Kosten in Ihrer Organisation verteilen.
Sie wollen Kosten so strukturieren, wie Ihr Geschäft funktioniert. Vielleicht haben Sie mehrere Teams, Umgebungen oder andere Kategorien, denen Sie Kosten zuordnen möchten. Solche Kategorien können jedoch komplex definiert sein. Die Definition Ihres Unternehmens für "Staging Environment" könnte zum Beispiel alle Projekte oder Accounts umfassen, deren Name mit "staging" beginnt – über mehrere Teams oder Services hinweg.
Mit Allocations in DoiT Cloud Intelligence ordnen Sie Cloud-Kosten individuellen Geschäftskategorien zu, indem Sie über mehrere Kostendimensionen hinweg gruppieren – etwa Labels/Tags, Projekte, Accounts, Servicetypen, Regionen oder sogar Abrechnungs-Metadaten. Allocations unterstützen direkte wie geteilte Kostenstrategien, inklusive automatisierter Regeln zur proportionalen Verteilung gemeinsam genutzter Services wie Support oder Networking.
Schauen wir uns an, was Allocations sind und wie sie funktionieren. Wenn Sie möchten, springen Sie direkt zur interaktiven Tour weiter unten.
Was sind Allocations?
Eine Allocation ist eine logische Gruppierung von Cloud-Ressourcen, die eine für Ihre Organisation individuelle Kostenkategorie definiert.
Unternehmen nutzen Allocations in der DoiT Platform, um Cloud-Verbrauch im Kontext ihres Geschäfts zu betrachten.
Sie sind außerdem ein grundlegender Schritt, um Kostenverantwortung über Teams und Funktionen hinweg zu verankern.
Werfen wir einen Blick auf einige Beispiele und wie Allocations in der Praxis funktionieren:
Allocations zur Definition der Kosten von Engineering-Teams
Bei DoiT nutzen wir Allocations intern, um den Cloud-Footprint jedes Engineering-Teams abzubilden. In diesem Beispiel haben wir eine Allocation für das Team Bruteforce angelegt: Sie gruppiert Ressourcen, bei denen entweder ein Label auf Ressourcen-Ebene oder ein Label auf Projekt-Ebene den Wert "bruteforce" hat.
Wir wenden eine "A ODER B"-Logik an, damit die Allocation alle Ressourcen erfasst, die:
- nur mit dem Ressourcen-Label team:bruteforce getaggt sind
- nur mit dem Projekt-Label team:bruteforce getaggt sind
- mit beiden Labels getaggt sind
So decken wir die Kosten von Bruteforce vollständig ab – egal, wo das Label gesetzt ist.
Screenshot
Viele Kunden setzen Allocations auf diese Weise ein, um teamspezifische Dashboards und Reports zu speisen, die die größten Kostentreiber sichtbar machen.
Im folgenden Beispiel schlüsseln wir die Kosten von Bruteforce nach Service auf – und sehen sofort, was die Ausgaben dieses Engineering-Teams treibt.
Screenshot
Allocations zur Definition von Umgebungs-Kosten
In diesem Beispiel definieren wir die Kosten unserer Staging-Umgebung, indem wir per Regex-Matching alle Google-Cloud-Projekte zusammenfassen, die das Wort "staging" enthalten.
Das zeigt anschaulich, wie Sie Allocations aufbauen können, ohne sich auf Labels oder Tags zu stützen.
Screenshot
Da Staging-Projekte im Lauf der Zeit häufig hinzukommen oder verschwinden, sorgt Regex dafür, dass die Allocation automatisch aktuell bleibt – Sie müssen sie nicht bei jedem neuen Projekt manuell anpassen.
Screenshot
Im folgenden Beispiel haben wir einen Cost-per-Environment-Report erstellt, der drei Allocations vergleicht: Development, Staging und Production. So lässt sich die Nutzung pro Umgebung leicht verfolgen und Trends im Zeitverlauf vergleichen.
Screenshot
Wir können die Kosten jeder Umgebung zudem nach Service, Account oder Region aufschlüsseln, um die Ursachen für Unterschiede zu erkennen.
Screenshot
Schließlich lassen sich diese Reports so planen, dass sie sich automatisch aktualisieren und in einem von Ihnen festgelegten Rhythmus an die wichtigsten Stakeholder gehen – damit alle informiert bleiben.
Screenshot
Allocations zur Schätzung von EBS-Storage-Einsparungen
Allocations sind nicht auf organisatorische oder teambezogene Kategorien beschränkt – Sie können damit auch Infrastrukturkomponenten für Analysen und Szenariomodellierung gruppieren.
Angenommen, Sie nutzen GP2-Volumes für AWS EBS und möchten die möglichen Einsparungen einer Migration auf GP3 abschätzen.
Sie würden zunächst eine Allocation anlegen, die alle EBS-Kosten rund um GP2-Volumes erfasst. Dazu filtern Sie auf relevante AWS-Service-Metadaten – etwa Volume-Typ, Usage-Type oder SKU – die GP2-Nutzung kennzeichnen:
Screenshot
Sobald die Allocation steht, kombinieren Sie sie mit Metrics in der DoiT Platform, um Ihr Einsparmodell zu rechnen.
Laut AWS sind GP3-Volumes bis zu 20 % günstiger pro GB als GP2. Erstellen Sie für die Schätzung der möglichen Einsparungen eine benutzerdefinierte Metrik, die die GP2-Allocation-Kosten mit 0,2 multipliziert.
Screenshot
Multiplizieren Sie dieselbe Allocation alternativ mit 0,8, um die angepassten Kosten zu schätzen, wenn Sie bereits auf GP3 wären.
So bekommen Sie eine schlanke Self-Service-Methode, um:
- tägliche Einsparpotenziale zu beziffern
- Storage-Migrationen zu priorisieren
- Architekturentscheidungen mit echten Kostendaten zu untermauern
Weitere Einsatzmöglichkeiten für Allocations
Einmal definiert, werden Allocations zu wertvollen Eingabewerten in der gesamten DoiT Platform – und liefern plattformweit präzisere, umsetzbare und geschäftsrelevante Insights.
Wie Allocations Ihnen helfen, aussagekräftigere Kosten-Reports zu erstellen, haben wir bereits gezeigt. Ihr Nutzen geht aber weit darüber hinaus. DoiT-Kunden setzen Allocations zusätzlich ein, um:
- Ausgaben präzise zuzuordnen
- Jeden Dollar Cloud-Kosten einer konkreten Business Unit, einem Produkt oder einer Initiative zuweisen – und so Lücken durch inkonsistentes Tagging oder fragmentierte Abrechnungsstrukturen schließen.
- Forecast-Genauigkeit und Durchsetzung mit Budgets verbessern
- Allocation-bezogene Budgets festlegen, um zu erkennen, ob ein Team, eine Umgebung oder eine Anwendung über dem Forecast liegt – und Verantwortliche proaktiv zu alarmieren.
- Granulare, gezielte Alerts erstellen
- Anomalien, Kostensprünge oder Nutzungsänderungen auf Allocation-Ebene sichtbar machen – statt nur auf Account- oder Service-Ebene –, damit die richtigen Teams handeln können.
- Bessere teamübergreifende Gespräche ermöglichen
- Da Allocations die Struktur Ihres Unternehmens widerspiegeln, sind sie eine gemeinsame Sprache für Finance, Engineering und Leadership, um Kostenverhalten zu bewerten und Entscheidungen zu treffen.
- Und vieles mehr.
Den Rest finden Sie in diesem Beitrag.
Was ist mit Tags und Labels?
Vielleicht denken Sie beim Lesen: "Aber kann ich das nicht auch mit Tags und Labels lösen?" Ersetzen Allocations Tags und Labels?
Es sind zwei eigenständige Konzepte mit gewissen Überschneidungen. Allocations helfen Ihnen, Cloud-Ausgaben zu strukturieren, ohne dass Ihr Tagging perfekt sein muss. Sie können Tags und Labels selbstverständlich als Eingaben für Ihre Allocations nutzen – sind aber nicht darauf festgelegt.
Ja, ähnliche Gruppierungen lassen sich allein mit Tags und Labels erreichen, sofern Ihre Organisation eine konsequente Tagging-Hygiene pflegt. Das bedeutet:
- Ein einheitlicher Tag-Key pro Kategorie (z. B. environment, product, team)
- Ein definierter Wertesatz pro Key (z. B. prod, dev, staging)
- 100 % Tag-Abdeckung über alle Ressourcen hinweg
So könnte ein Report im AWS Cost Explorer mit korrekt und konsistent gesetzten AWS-Tags aussehen:
Doppelte Tag-Keys und/oder -Werte
In vielen Organisationen sieht die Tagging-Realität jedoch fragmentierter aus. Da gibt es inkonsistente Tag-Keys wie Environment, Env oder environment und Tag-Werte wie prod, production oder Production.
Diese Inkonsistenz erschwert das Kosten-Reporting – denn nativ lassen sich diese Werte nicht zu einer logischen Einheit zusammenführen.
Mit Allocations definieren Sie eine einzige geschäftlich passende Gruppierung (z. B. "Production Environment"), die alle Tag-Varianten in einer Regel bündelt.
Im Beispiel unten haben wir Ressourcen mit den Environment-Tag-Werten prod, Production und production zu einer einzigen Allocation zusammengefasst:
Screenshot
Multi-Cloud
Angenommen, Ihre Anwendung läuft auf AWS und Google Cloud. Wie ermitteln Sie die Gesamtkosten dieser App?
Nativ in den Konsolen der Cloud-Anbieter geht das nicht – jede sieht nur ihre eigenen Daten.
Mit Allocations in der DoiT Platform gruppieren Sie Ressourcen über beide Clouds hinweg anhand gemeinsamer Metadaten wie Tags, Labels, Account-IDs, Projektnamen und mehr. So bekommen Sie eine einheitliche Kostensicht auf jeden Multi-Cloud-Service oder jedes Produkt.
Tags passen nicht zur gewünschten Kostengruppierung
Manchmal ergeben Tags für die gewünschte Gruppierung schlicht keinen Sinn.
Sie wollen die Kosten der "Staging Environment" zum Beispiel definieren, indem Sie AWS-Accounts oder GCP-Projekte zusammenfassen, deren Namen "staging" enthalten – unabhängig davon, ob diese Ressourcen getaggt sind.
Mit Allocations nutzen Sie Projekt-/Account-Namen, Regex-Matches und weitere Dimensionen, um solche Kostengruppen zu bauen.
Screenshot
Legacy-Systeme funktionieren nicht mit Tags
Manche Kunden betreiben Legacy-Systeme, die entweder keine Tags unterstützen oder Tagging-Standards nicht durchsetzen können.
In den nativen Konsolen gibt es dafür keinen brauchbaren Workaround. Mit Allocations gruppieren Sie diese ungetaggten Ressourcen jedoch über andere Metadaten – etwa Account-ID, Region, Servicename oder eine eigene Logik.
Fazit
Ob Sie Cloud-Ausgaben im Geschäftskontext verstehen oder Kostenverantwortung über Teams hinweg verankern wollen – der Anfang sind Allocations.
Bereit für ein klareres Bild Ihrer Cloud-Kosten? Starten Sie unten die interaktive Tour – oder kontaktieren Sie DoiT für eine maßgeschneiderte Demo und sehen Sie, was Allocations und die übrige DoiT Platform für Ihr Team leisten können.
Starten Sie jetzt die interaktive Tour durch Allocations