Glossar
Tagging-Strategie
Auch: Kostenstellen-Tags · Cost Allocation Tags · Ressourcen-Kennzeichnung
Ein verbindliches Schema, mit dem jede Ressource ihrem Team, ihrer Umgebung und ihrem Kostenträger zugeordnet wird.
Tags sind Schlüssel-Wert-Paare an einer Ressource. Technisch trivial, organisatorisch der Punkt, an dem Kostenarbeit gelingt oder scheitert. Ohne Zuordnung lässt sich nicht sagen, welches Team welche Kosten verursacht, und ohne diese Zuordnung wird jede Sparmaßnahme zur Chefsache statt zur Teamentscheidung.
Ein brauchbares Schema ist klein. Vier Pflichtfelder reichen in den meisten Organisationen: Team, Umgebung, Anwendung und Kostenstelle. Wer zwanzig Tags vorschreibt, bekommt keine zwanzig gepflegten Tags, sondern gar keine. Optionale Zusatz-Tags dürfen daneben existieren, aber sie sind nicht Teil der Pflicht.
Die Werte müssen genormt sein. „prod", „Prod", „production" und „PROD" sind für die Auswertung vier verschiedene Umgebungen. Eine feste Werteliste, geprüft in der Pipeline, ist der Unterschied zwischen einem Bericht und einem Ratespiel.
Entscheidend ist die Durchsetzung. Ein Tag, das freiwillig ist, fehlt nach einem halben Jahr auf einem Drittel der Ressourcen, und dann ist jede Auswertung wertlos. Durchsetzung heißt konkret: Ein Deployment ohne Pflicht-Tags schlägt fehl, geprüft in der Infrastruktur-Pipeline, ergänzt durch Tag Policies auf Organisationsebene.
Damit Tags in der Rechnung auftauchen, müssen sie zusätzlich als Cost Allocation Tags aktiviert werden. Das wird oft vergessen. Und die Aktivierung wirkt nicht rückwirkend: Kosten aus der Zeit davor bleiben unzugeordnet.
Nicht jede Ressource lässt sich kennzeichnen. Datenverkehr, einige verwaltete Dienste und geteilte Infrastruktur wie NAT Gateways tragen keine sinnvollen Tags oder werden gemeinsam genutzt. Für diesen Rest braucht es eine bewusste Aufteilungsregel, sonst landet er als unerklärter Block in der Auswertung.
Woran Sie es erkennen
- Ein nennenswerter Teil der Rechnung lässt sich keinem Team zuordnen.
- Es gibt ein dokumentiertes Tagging-Konzept, aber keine Prüfung in der Pipeline.
- Dieselbe Umgebung heißt an verschiedenen Stellen unterschiedlich.
- Tags existieren, tauchen aber im Cost Explorer nicht als Filter auf.
Nicht zu verwechseln mit
- Getrennte AWS-Konten
- Die härtere Trennung: Ein Konto je Team oder Umgebung ordnet Kosten ohne Tags zu. Aufwendiger im Aufbau, aber nicht zu umgehen. In größeren Organisationen die bessere Grundlage.
- Cost Categories
- Regeln, die Kosten nachträglich gruppieren, etwa mehrere Konten zu einem Bereich. Ergänzt Tags, ersetzt sie nicht, weil sie innerhalb eines Kontos nichts auflösen.
- Cost Allocation Tags
- Kein eigenes Konzept, sondern der Schalter, der ein vorhandenes Tag für die Kostenauswertung freischaltet. Ohne ihn taucht das beste Tagging in der Rechnung nicht auf.
Wann es trägt
- Mehrere Teams oder Anwendungen teilen sich ein Konto.
- Vor dem Start jeder Kostenarbeit, weil ohne Zuordnung nichts steuerbar ist.
- Wenn Kosten intern weiterverrechnet werden sollen.
Wann nicht
- Als Ersatz für Kontentrennung in großen Organisationen. Tags sind weicher und lassen sich umgehen.
- Mit mehr als vier bis fünf Pflichtfeldern. Ein überladenes Schema wird nicht gepflegt.
- Ohne Durchsetzung. Freiwilliges Tagging erzeugt Daten, auf die man sich nicht verlassen kann, und das ist schlechter als keine.
Wie man rangeht
- Schema festlegen, klein haltenTeam, Umgebung, Anwendung, Kostenstelle. Je Feld eine feste Werteliste. Mehr Felder bedeuten weniger Pflege, nicht mehr Information.
- In der Pipeline erzwingenPrüfung im Infrastrukturcode, die ein Deployment ohne Pflicht-Tags ablehnt. Das ist der Punkt, an dem aus einer Absicht eine Tatsache wird.
- Tag Policies auf Organisationsebene ergänzenSie normieren Schreibweisen und verhindern, dass an der Pipeline vorbei angelegte Ressourcen abweichen.
- Als Cost Allocation Tags aktivierenOhne diesen Schritt erscheinen die Tags nicht in Cost Explorer und CUR. Er wirkt nicht rückwirkend, also früh erledigen.
- Bestand nachkennzeichnenÜber den Resource Groups Tag Editor oder ein Skript. Nach Kostenanteil vorgehen: Die zwanzig teuersten Ressourcen bringen mehr als zweihundert kleine.
- Nicht zuordenbaren Rest bewusst aufteilenGeteilte Infrastruktur nach einem festen Schlüssel verteilen und diesen dokumentieren. Ein unerklärter Block macht sonst jede Auswertung angreifbar.
Häufig gefragt
Wie viele Pflicht-Tags sind sinnvoll?
Vier bis fünf. Team, Umgebung, Anwendung und Kostenstelle decken die üblichen Auswertungen ab. Jedes weitere Pflichtfeld senkt die Wahrscheinlichkeit, dass überhaupt gepflegt wird. Zusätzliche freiwillige Tags dürfen daneben existieren, sie sind nur nicht Teil der Prüfung.
Reicht Tagging oder brauchen wir getrennte Konten?
Für zwei bis drei Teams reicht Tagging. Ab einer gewissen Größe ist die Kontentrennung die bessere Grundlage, weil sie nicht umgangen werden kann und zugleich Berechtigungen und Fehlerradius trennt. Beides schließt sich nicht aus: getrennte Konten für die grobe Trennung, Tags für die feine.
Wie geht man mit Kosten um, die sich nicht zuordnen lassen?
Bewusst aufteilen und die Regel dokumentieren, etwa nach Anteil an der zuordenbaren Nutzung. Wichtig ist, dass die Regel benannt ist. Ein unerklärter Restblock macht jede Auswertung angreifbar, und die erste Zahl, die jemand anzweifelt, kostet mehr Glaubwürdigkeit als drei richtige aufbauen.
Wirken neu aktivierte Tags rückwirkend?
Nein. Cost Allocation Tags gelten ab dem Zeitpunkt der Aktivierung. Kosten aus der Zeit davor bleiben unzugeordnet. Deshalb lohnt es sich, das Schema früh festzulegen und zu aktivieren, auch wenn gerade keine Auswertung ansteht.