So verknüpfst du Hyperscaler mit Bestands-Services 
Die IT-Welt ist heute zweigeteilt – auf der einen Seite steht die klassische IT mit gewachsenen Servicekatalogen, transparentem Kostenreporting und etablierten Governance-Strukturen. Auf der anderen Seite wächst die Cloud rasant: mit flexiblen Ressourcen, granularen Abrechnungsmodellen und einer Vielzahl technischer Services, die täglich neu entstehen oder verschwinden. Zwischen diesen beiden Welten klafft oft eine Lücke – insbesondere dann, wenn es um die finanzielle Steuerung geht.
Viele Unternehmen arbeiten bereits mit Frameworks wie ITFM (IT Financial Management) oder TBM (Technology Business Management), um interne Services zu bewerten, Budgets zu planen und Verantwortlichkeiten klar zuzuweisen. Gleichzeitig etablieren sich FinOps-Methoden, um Cloud-Ausgaben effizient zu analysieren und zu optimieren. Doch solange diese beiden Disziplinen nebeneinander existieren, statt miteinander zu wirken, bleiben viele Potenziale ungenutzt.
Genau an dieser Stelle setzt das Mapping von FinOps-Services zu ITFM- oder TBM-Services an. Es geht darum, Cloud-Services wie „Amazon EC2“, „Azure Blob Storage“ oder „Google Cloud Functions“ den klassischen IT-Services wie „Webshop“, „CRM-System“ oder „Datenplattform“ zuzuordnen. Diese Zuordnung schafft die notwendige Brücke zwischen technischer Realität und finanziellem Steuerungsmodell. Und das ist nicht nur ein theoretisches Konstrukt – sondern ein hochgradig praktischer, operativer Prozess, der direkt messbaren Nutzen bringt.
Warum dieses Mapping so essenziell ist 
Die zentrale Herausforderung bei der finanziellen Steuerung von Cloud-IT liegt in ihrer Granularität. In klassischen IT-Strukturen ist klar definiert, wie viel ein E‑Mail-Service kostet oder wer für das ERP-System verantwortlich ist. Die Cloud hingegen fragmentiert diese Transparenz in tausende Einzelposten: Compute-Zeit, Netzwerkausgang, Storage-Tiers, Lizenzen, Serverless-Funktionen – alle mit eigenem Preismodell, alle dynamisch skalierbar.
Ohne eine konsistente, servicebasierte Zusammenführung dieser Einzelkosten ist keine sinnvolle Weiterverrechnung möglich. Budgetüberschreitungen bleiben unentdeckt, Verantwortlichkeiten verwischen, und strategische Entscheidungen zur Kostenoptimierung basieren auf unvollständigen Informationen.
Ein gutes Mapping sorgt also für:
- Klarheit: Welche Cloud-Kosten entfallen auf welchen IT-Service?
- Verantwortung: Wer ist für die Kostenentwicklung verantwortlich?
- Planungssicherheit: Welche Budgets müssen für welche Services bereitgestellt werden?
- Optimierungspotenzial: Wo können Ressourcen effizienter genutzt oder eingespart werden?
Der Weg zum Mapping: Von der Idee zur Umsetzung 
Bevor man sich in technische Details und Tools vertieft, sollte man zunächst das Ziel des Mappings klar definieren: Es geht nicht einfach darum, eine „Übersetzung“ zwischen AWS-Services und ITFM-Kategorien zu schaffen. Vielmehr soll ein durchgängiges Modell entstehen, das Verantwortlichkeiten, Kostenstrukturen und Optimierungspotenziale in einem konsistenten Service-Framework abbildet.
Ein typischer Ausgangspunkt ist ein bereits vorhandener IT-Servicekatalog. Dieser umfasst in der Regel alle Applikationen und technischen Dienste, die der internen oder externen Nutzung dienen – von klassischen Geschäftsanwendungen über zentrale Infrastrukturkomponenten bis hin zu digitalen Plattformen. In vielen Fällen ist dieser Katalog in einem ITSM- oder CMDB-System gepflegt, etwa in ServiceNow, Matrix42 oder einer eigenen Excel-Struktur.
Auf der anderen Seite steht die Welt der Cloud-Services, die über Tools wie den AWS Cost Explorer, Azure Cost Management oder dedizierte FinOps-Plattformen wie CloudHealth, Apptio Cloudability oder Kubecost analysiert werden. Hier finden sich detaillierte Abrechnungen einzelner Ressourcen – teils gut strukturiert, teils unübersichtlich und ungetaggt. Die Aufgabe besteht nun darin, diese beiden Datenwelten zusammenzuführen.
Vom Datensilo zur Kostenlandkarte 
In der Praxis beginnt das Mapping mit der Identifikation relevanter Cloud-Ressourcen und ihrer Beziehung zu bestehenden IT-Services. Oft gibt es bereits erste Hinweise – beispielsweise durch Ressourcennamen, Projektzuweisungen oder organisatorische Zuordnungen. Doch wer auf manuelle Nachverfolgung und Bauchgefühl setzt, wird schnell an Grenzen stoßen. Hier entfaltet sich die eigentliche Kunst: die Implementierung einer durchdachten Tagging-Strategie.
Tags sind der Schlüssel zum Erfolg. Durch konsistentes Tagging wird jede Ressource in der Cloud eindeutig einem IT-Service, einer Kostenstelle oder einem Projekt zugeordnet. Nur so ist es möglich, aus der Vielzahl technischer Einzelkosten ein schlüssiges Bild pro Service zu erzeugen. Ein Beispiel: Drei EC2-Instanzen, eine RDS-Datenbank und ein S3-Bucket gehören zusammen zum Service „Webshop“. Sie werden alle mit dem Tag Service=Webshop versehen. Künftig kann jede Kostenanalyse diese Zusammenhänge automatisch erkennen – unabhängig von Account oder Region.
Doch bevor dieses Idealbild Realität wird, ist meist einiges an Vorarbeit nötig: Das Cloud-Team muss die relevanten Tags definieren und durchsetzen, das FinOps-Team muss die Analysefähigkeiten aufbauen, und das ITFM-Team muss das neue Mapping in bestehende Controlling-Modelle integrieren. Diese Disziplinen agieren häufig noch in Silos – ein abgestimmtes Vorgehen ist deshalb essenziell.
Von der Theorie zur Praxis: Das strukturierte Mappingmodell 
Im nächsten Teil meiner Blogreihe zeige ich dir konkret, wie du Schritt für Schritt vorgehst:
- wie du deinen Servicekatalog vorbereitest
- wie du relevante Cloud-Ressourcen identifizierst
- wie du ein sinnvolles Tagging einführst
- wie du das Mapping dokumentierst und visualisierst
- und wie du daraus ein nachhaltiges Governance-Modell entwickelst.
Sei also gespannt auf den nächsten Artikel.
