Tag-Abdeckung ist der Anteil der Kosten, der für einen bestimmten Tag-Schlüssel einen Wert trägt, gemessen in Geld je Schlüssel und Zeitraum. Sie ist der Tagging-Anteil des Zuordnungsgrads, der zusätzlich Konten und Regeln einbezieht. Die Zahl sagt, wie viel der Rechnung ein Bericht nach Team, Produkt oder Kostenstelle erklären kann. Der Rest sind nicht getaggte Kosten, und seine Zusammensetzung entscheidet, ob Tagging ihn überhaupt verkleinern kann. Wie ein Tag in die Abrechnungsdaten gelangt, beschreibt Tags und Labels; welche Schlüssel Pflicht sind, legt die Tagging-Richtlinie fest.
So funktioniert es
Die Berechnung
Für einen Schlüssel und einen Abrechnungszeitraum ist die Abdeckung die Summe der Kosten aller Posten mit einem Wert für diesen Schlüssel, geteilt durch die Summe der Kosten aller Posten. Gemessen wird je Schlüssel, denn ein Posten kann eine Kostenstelle tragen und trotzdem keinen Owner. Zähler und Nenner verwenden dieselbe Kostenspalte. Googles Beispielabfragen nach Projekt, Ordner und Tag addieren die Gutschriften zu den Kosten, die Abfrage nach einem Label-Schlüssel summiert nur cost. Wo Commitments bestehen, liegt die Zahl in der Sicht der amortisierten Kosten höher als in der Sicht der berechneten Kosten: AWS beschreibt, dass sich Gebühren für Reserved Instances und Savings Plans nicht taggen lassen, die amortisierten Kosten der abgedeckten Nutzung sich aber nach Tag-Schlüsseln gruppieren lassen. Ungenutzte Commitments bleiben in beiden Sichten ohne Tag.
Drei Gruppen unter hundert Prozent
| Gruppe | Was dazugehört | Was sie verkleinert |
|---|---|---|
| Nicht taggbar | Käufe, Commitment-Gebühren, Posten ohne Ressource | eine Regel, die sie als geteilte oder nicht zugeordnete Kosten führt |
| Tag erreicht die Nutzungsdaten nicht | Dienste ohne Tags in den Nutzungsdaten, nicht aktivierte AWS-Schlüssel, Azure-Tags an Ressourcengruppe oder Subscription ohne Vererbung | Aktivierung, Vererbung, Backfill |
| Ungetaggt aus Versäumnis | Ressourcen, an denen der Schlüssel fehlt | Tagging an der Ressource |
Azure trennt die Gruppen zum Teil selbst. In der Kostenanalyse, gruppiert nach einem Tag, stehen Käufe, Ressourcen ohne Subscription, Ressourcen außerhalb einer Ressourcengruppe und klassische Ressourcen unter „Tags not supported“, Dienste ohne Tags in den Nutzungsdaten unter „Tags not available“ und alles Übrige ohne Wert unter „Untagged“. Ressourcen, deren Tag nur an Ressourcengruppe oder Subscription hängt, stehen ohne Vererbung ebenfalls unter „Untagged“. AWS gibt an, dass sich Ressourcen aller kostenpflichtigen Dienste taggen lassen, und nennt einige ältere Dienste, für die es neuere mit Tagging empfiehlt.
Die Lücke finden
Bei AWS liefert eine Gruppierung nach einem Tag-Schlüssel in Cost Explorer und seiner API alle Werte einschließlich des leeren, unter dem die Kosten ohne den Schlüssel stehen; die Filteroption ABSENT zeigt nur diese Kosten. Welche Ressourcen betroffen sind, findet AWS Resource Explorer: Die Suche tag:none liefert Ressourcen ohne selbst gesetzten Tag, -tag.key:costcenter die ohne diesen Schlüssel. Der Compliance-Bericht der Tag Policies hilft hier nicht, denn ungetaggte Ressourcen erscheinen darin nicht als nicht konform; er entsteht im Management-Konto, nur in der Region us-east-1, und wird alle 48 Stunden neu bewertet. Cost Explorer selbst beschreibt AWS Cost Explorer und AWS Budgets.
Bei Azure zeigt die Kostenanalyse diese drei Kategorien direkt, sobald nach einem Tag-Schlüssel gruppiert wird; die Kostenanalyse selbst beschreibt Azure Cost Management and Billing.
Bei Google Cloud entsteht die Zahl im BigQuery-Export. Google setzt in seiner Beispielabfrage die Bedingung auf den Schlüssel in den LEFT JOIN über die Labels und nicht in die WHERE-Klausel, damit die Kosten ohne den Schlüssel mit leerem Wert im Ergebnis bleiben. Projektlabels stehen im eigenen Feld project.labels, über die Hierarchie geerbte Tags in tags mit dem Vermerk inherited.
Die Lücke schließen
Ein Tag an der Ressource wirkt ab dem Datum, an dem er gesetzt wird. Bei AWS erscheint ein neuer Schlüssel bis zu 24 Stunden später auf der Seite der Cost Allocation Tags, die Aktivierung braucht weitere bis zu 24 Stunden. Für die Vergangenheit kann das Management-Konto einen Backfill für bis zu zwölf Monate beantragen: Der heutige Aktivierungsstand wird rückwirkend angewendet, Werte erscheinen aber nur dort, wo die Ressource den Tag damals trug. Es läuft höchstens ein Backfill zur selben Zeit und höchstens einer je 24 Stunden; Cost Explorer, Data Exports und der Cost and Usage Report übernehmen ihn mit ihrer täglichen Aktualisierung.
Azure schreibt mit der Tag-Vererbung die Tags von Subscription und Ressourcengruppe, bei Microsoft Customer Agreement auch von Abrechnungsprofil und Rechnungsabschnitt, in die Nutzungsdatensätze. Die Vererbung steht bei Enterprise Agreement, Microsoft Customer Agreement und Microsoft Partner Agreement mit Azure-Plan zur Verfügung, dauert 8 bis 24 Stunden und gilt ab dem ersten Tag des laufenden Monats, mit den Tags vom Tag der Änderung; frühere Monate bleiben unverändert. Käufe und Ressourcen ohne Nutzung auf Subscription-Ebene erhalten keine Tags.
Bei Google Cloud trägt jeder Posten eines Projekts dessen Labels, und Ressourcen erben die Tags, die an ihrem Ordner oder an der Organisation hängen. Was danach fehlt, schließen Regeln, die Virtuelle Tags und Zuordnungsregeln beschreibt.
Was es für Ihre Kosten bedeutet
Ein Abdeckungsbericht zeigt je Pflichtschlüssel und je Team die Abdeckung pro Monat, als Verlauf. Die drei Gruppen stehen getrennt, weil sie verschiedene Verantwortliche haben: Das Versäumnis gehört den Teams, die fehlende Aktivierung oder Vererbung der Administration von Management-Konto oder Abrechnungskonto, der nicht taggbare Teil der Regel für geteilte Kosten oder dem nicht zugeordneten Rest. Der nicht taggbare Anteil gehört deshalb in kein Tagging-Ziel, denn Tagging senkt ihn nicht.
Ein Backfill ändert vergangene Monate: Die Abdeckung eines Vormonats steigt nachträglich, und ein Bericht, der vor dem Backfill gezogen wurde, stimmt mit einem späteren nicht mehr überein. Die Tag-Vererbung bei Azure ändert nur den laufenden Monat. Ein Zeitraumvergleich braucht deshalb das Datum solcher Änderungen.
Wo es schiefgeht
- Filter statt Join. Symptom: Die Abfrage im BigQuery-Export meldet volle Abdeckung. Ursache: Die Bedingung auf den Schlüssel steht in der WHERE-Klausel und wirft alle Posten ohne den Schlüssel aus dem Ergebnis.
- Compliance als Abdeckung gelesen. Symptom: Der Bericht der Tag Policies zeigt keine Verstöße, Cost Explorer eine große Gruppe ohne Wert. Ursache: Ungetaggte Ressourcen gelten in der Tag-Policy-Prüfung nicht als nicht konform.
- Backfill ohne historische Tags. Symptom: Nach dem Backfill bleiben frühere Monate leer. Ursache: Der Backfill überträgt nur den Aktivierungsstand; Werte gibt es nur, wo die Ressource den Tag damals trug.
- Vererbung rückwirkend erwartet. Symptom: Die Vormonate zeigen bei Azure weiter „Untagged“. Ursache: Die Tag-Vererbung gilt ab dem laufenden Monat.
- Projektlabels übersehen. Symptom: Die Abdeckung bei Google Cloud wirkt niedrig, obwohl alle Projekte gelabelt sind. Ursache: Die Abfrage liest nur
labels, nichtproject.labels.
Quellen
Gelesen am 2026-10-16. AWS Cost Allocation Tags nachträglich füllen, Selbst definierte Cost Allocation Tags aktivieren, Compliance in der gesamten Organisation bewerten, Was ist Tag Editor?, Beispielabfragen für Resource Explorer, GetCostAndUsage, TagValues und Eine Strategie für die Kostenzuordnung aufbauen; Microsoft Gruppieren und Filtern in der Kostenanalyse und Kosten mit Tag-Vererbung gruppieren; Google Cloud Beispielabfragen für den Abrechnungsexport und Struktur des Standard-Datenexports.