Blog

Wie ein sauberes Tagging-Modell einen 6‑stelligen Betrag einsparen kann – Praxisbeispiel aus dem Cloud-Alltag

Im Cloud Finan­cial Manage­ment (CFM) gilt das Tag­ging oft als läs­ti­ge Pflicht – ein ope­ra­ti­ver Schritt, der eher aus Com­pli­ance-Grün­den mit­ge­zo­gen wird, aber wenig unmit­tel­ba­ren Nut­zen erken­nen lässt. Dabei ist gera­de ein sau­be­res, gut gepfleg­tes Tag­ging-Modell das Fun­da­ment für Kos­ten­trans­pa­renz, Zuor­den­bar­keit und letzt­lich Kos­ten­op­ti­mie­rung. In die­sem Arti­kel zei­ge ich anhand eines ech­ten Pra­xis­bei­spiels, wie allein durch kon­se­quen­te Tag­ging-Kor­rek­tur und ‑Stan­dar­di­sie­rung in einem mit­tel­stän­di­schen Unter­neh­men jähr­lich ein sechs­stel­li­ger Betrag ein­ge­spart wur­de – ohne tech­ni­sche Umstel­lun­gen oder har­te Restrik­tio­nen für Ent­wick­ler.

Warum Tagging mehr als nur Ordnung ist

Tags sind im Cloud-Kon­text struk­tu­rier­te Meta­da­ten, die ein­zel­nen Res­sour­cen – etwa VMs, Daten­ban­ken, Sto­rage oder Netz­werk­ele­men­ten – zuge­wie­sen wer­den. Sie die­nen der Klas­si­fi­zie­rung und ermög­li­chen Aus­wer­tun­gen, die nach Pro­jekt, Abtei­lung, Kos­ten­stel­le, Umge­bungs­art (Prod, Dev, Test) oder Ver­ant­wort­lich­keit geglie­dert sind. Die Hypers­ca­ler (AWS, Azu­re, Goog­le Cloud) bie­ten umfang­rei­che Mög­lich­kei­ten, die­se Tags aus­zu­wer­ten und dar­auf basie­ren­de Reports, Bud­gets und Alar­me zu erstel­len.

Ein ver­brei­te­ter Irr­tum: Tag­ging sei ledig­lich eine gute Pra­xis für grö­ße­re Unter­neh­men mit kom­ple­xer Gover­nan­ce. Die Rea­li­tät zeigt: Selbst in klei­ne­ren Umge­bun­gen mit monat­li­chen Cloud-Aus­ga­ben im mitt­le­ren fünf­stel­li­gen Bereich sum­mie­ren sich Fehl­al­lo­ka­tio­nen und man­geln­de Trans­pa­renz schnell zu hohen Oppor­tu­ni­täts­kos­ten.

Das Praxisbeispiel: Mittelständler im Maschinenbau

Ein mit­tel­stän­di­sches Unter­neh­men mit rund 600 Mit­ar­bei­ten­den und Pro­duk­ti­ons­stät­ten in Euro­pa und Asi­en nutz­te seit meh­re­ren Jah­ren AWS und Azu­re par­al­lel. Die IT war hybrid auf­ge­stellt, die Cloud wur­de pri­mär für Ent­wick­lung, Simu­la­tio­nen und eini­ge kun­den­na­he Platt­form­diens­te ver­wen­det. Die monat­li­chen Cloud-Kos­ten lagen bei rund 48.000 Euro, wovon knapp 80 % über AWS lie­fen.

Trotz vor­han­de­ner Fin­Ops-Initia­ti­ve und Cloud-Gover­nan­ce-Richt­li­nien fehl­te ein zen­tra­les, durch­gän­gi­ges Tag­ging-Modell. Jeder Cloud-Nut­zer – pri­mär Ent­wick­ler und DevOps-Teams – tagg­te nach eige­nem Ermes­sen. Eini­ge Bei­spie­le:

• “pro­ject” vs. “Pro­ject” vs. “Pro­jekt”
• “cos­t­cen­ter” vs. “Kos­ten­stel­le” vs. “cc”
• Tags wie “owner” wur­den mit nicht stan­dar­di­sier­ten E‑Mail-Adres­sen befüllt oder blie­ben leer
• Lega­cy-Res­sour­cen aus abge­schlos­se­nen Pro­jek­ten waren unge­taggt oder mit “test” ver­se­hen

Die Herausforderung: Sichtbarkeit und Verantwortung

Die Finanz­ab­tei­lung woll­te eine ver­brauchs­ba­sier­te Kos­ten­ver­tei­lung auf Pro­fit­cen­ter-Ebe­ne ein­füh­ren. Vor­aus­set­zung: eine ver­läss­li­che Zuwei­sung aller Res­sour­cen zu ihren Ver­ur­sa­chern. Doch in der Rea­li­tät waren rund 34 % aller monat­li­chen Aus­ga­ben nicht zuor­den­bar – ent­we­der wegen feh­len­der oder inkon­sis­ten­ter Tags. Das führ­te zu pau­scha­len Umla­gen, inter­ner Unzu­frie­den­heit und Miss­brauchs­ver­dacht: Eini­ge Berei­che ver­däch­tig­ten ande­re, sich „unsicht­ba­re“ Res­sour­cen leis­ten zu kön­nen, ohne dafür zu zah­len.

Eine genaue­re Ana­ly­se ergab, dass allein inak­ti­ve oder ver­ges­se­ne Res­sour­cen, die nicht oder falsch getaggt waren, monat­lich mehr als 8.000 Euro kos­te­ten. Dar­un­ter:

• Ent­wick­lungs­um­ge­bun­gen ohne Auto-Shut­down
• Nicht mehr ver­wen­de­te S3-Buckets mit hoher Red­un­danz­klas­se
• Nicht abge­rech­ne­te BYOL-Daten­ban­ken

Die Lösung: Einführung eines durchgängigen Tagging-Modells

Ein cross-funk­tio­na­les Team – bestehend aus Fin­Ops-Ver­tre­tern, IT Con­trol­ling, Archi­tek­tur und DevOps – ent­wi­ckel­te inner­halb von sechs Wochen ein stan­dar­di­sier­tes Tag­ging Frame­work. Die wich­tigs­ten Maß­nah­men:

1. Ein­füh­rung eines ver­pflich­ten­den Basis­tag-Sets:
   Jeder Res­sour­cen­typ muss­te min­des­tens die­se fünf Tags ent­hal­ten:
   • Pro­ject
   • Cos­t­Cen­ter
   • Owner
   • Envi­ron­ment
   • Life­cy­cle
2. Nut­zung zen­tra­ler Poli­ci­es und Tem­pla­tes:
   Über Infra­struc­tu­re-as-Code und CI/CD-Pipe­lines wur­den auto­ma­ti­sche Tag-Vor­ga­ben in Ter­ra­form- oder ARM-Vor­la­gen inte­griert.
3. Vali­die­rung und Nach­ver­fol­gung über AWS Con­fig / Azu­re Poli­cy:
   Feh­len­de oder feh­ler­haf­te Tags wur­den iden­ti­fi­ziert, doku­men­tiert und per monat­li­chem Report an die Teams zurück­ge­spielt.
4. Retag­ging-Kam­pa­gne für Alt­res­sour­cen:
   His­to­risch gewach­se­ne Res­sour­cen wur­den inven­ta­ri­siert, bewer­tet (nutzt sie noch jemand?), ggf. mit Default-Wer­ten getaggt oder gelöscht.
5. Gami­fi­ca­ti­on und Team­wett­be­wer­be:
   Teams mit dem höchs­ten Anteil kor­rekt getagg­ter Res­sour­cen erhiel­ten sym­bo­li­sche Prä­mi­en und Sicht­bar­keit im inter­nen Slack-Chan­nel.