0800 71 20000
Kontakt
...
Betrieb und Kosten

Cloud-Rechnung zu hoch: So findest du die eigentlichen Kostentreiber

In den meisten Rechnungen stecken die Überraschungen nicht bei den virtuellen Maschinen, sondern daneben: Datentransfer, NAT-Gateways, vergessene Volumes und Snapshots, Protokolldaten und öffentliche IP-Adressen. Nach Analysen aus dem AWS-Umfeld sind rund 40 Prozent der EC2-Instanzen zu groß dimensioniert, und 28 bis 35 Prozent der Ausgaben entfallen auf ungenutzte oder überdimensionierte Ressourcen. Die gute Nachricht: Ein großer Teil davon lässt sich in wenigen Tagen finden, ohne dass eine einzige Anwendung angefasst werden muss.

5 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Betriebsingenieur analysiert Kosten- und Monitoring-Dashboards an drei Bildschirmen
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Rechnung wächst, obwohl niemand etwas bestellt hat

Cloud-Kosten entstehen nicht durch Beschaffung, sondern durch Betrieb. Wer eine Ressource anlegt, löst damit eine monatlich wiederkehrende Zahlung aus, ohne dass jemand ein Angebot prüft oder eine Bestellung freigibt. Weil Anlegen einfach und Löschen unbequem ist, wächst der Bestand in eine Richtung. Dazu kommt, dass viele Posten nicht sichtbar mit einer Ressource verbunden sind: Ein NAT-Gateway berechnet Bereitstellung und verarbeitete Datenmenge, ein Snapshot lebt weiter, nachdem die zugehörige Maschine gelöscht wurde, und Protokolldaten kosten pro aufgenommenem Gigabyte.

Der zweite Grund ist die fehlende Zuordnung. In vielen Umgebungen wurden Tags nie durchgesetzt, deshalb lässt sich die Rechnung nicht nach Team, Projekt oder Kostenstelle aufteilen. Damit fehlt genau der Hebel, der in klassischer IT selbstverständlich ist: Es gibt niemanden, der sich für einen Posten zuständig fühlt. Solange die Rechnung nur als Summe existiert, diskutieren alle über die Cloud im Allgemeinen, statt eine konkrete Ressource abzuschalten. Zuordnung ist deshalb keine Fleißarbeit, sondern die Voraussetzung für jede Maßnahme.

Der dritte Grund ist Dimensionierung nach Gefühl. Größen werden aus der alten physischen Welt übernommen, in der eine Maschine für fünf Jahre gekauft und großzügig ausgelegt wurde. In der Cloud ist das ein dauerhafter Aufschlag. Nach Angaben aus AWS-Analysen sind rund 40 Prozent der EC2-Instanzen überdimensioniert, und 28 bis 35 Prozent der Cloud-Ausgaben entfallen auf ungenutzte oder zu groß gewählte Ressourcen. Diese Zahlen decken sich mit dem, was wir in Projekten sehen, sobald zum ersten Mal jemand systematisch nachrechnet.

Miniatur-Szene: Leitstand mit steigender Kostenanzeige, Münzstapel neben einer Cloud, Lupe über einem Leck

Die Rechnung in sechs Schritten auseinandernehmen

  1. 01 Monatskosten nach Dienst aufschlüsseln und Ausreißer markieren
  2. 02 Ausreißer bis zur einzelnen Nutzungsart verfolgen
  3. 03 Verwaiste Ressourcen einsammeln und abschalten
  4. 04 Dimensionierung mit Messwerten statt Bauchgefühl prüfen
  5. 05 Grundlast erst nach dem Aufräumen mit Zusagen binden
  6. 06 Budgets, Tags und Warnungen als Leitplanken einziehen
Was du mitnimmst

Die fünf Posten, die fast immer die Rechnung treiben

Die Ursachen sind über Branchen hinweg erstaunlich ähnlich. Wer diese fünf Bereiche durchgeht, findet in der Regel den größten Teil der Abweichung.

Datentransfer und Netzdienste

Ausgehender Verkehr ins Internet, Verkehr zwischen Verfügbarkeitszonen und die verarbeitete Datenmenge an NAT-Gateways stehen bei AWS als unauffälliger Posten in der Kategorie EC2 - Other. Ein einziges NAT-Gateway, durch das der gesamte Cluster-Verkehr läuft, kann mehr kosten als die Maschinen dahinter. Prüfe deshalb, ob Endpunkte innerhalb des Netzes den Umweg vermeiden.

Verwaiste Ressourcen

Nicht angebundene Volumes und verwaltete Datenträger, Snapshots gelöschter Maschinen, ungenutzte öffentliche IP-Adressen, leere Lastverteiler und alte Maschinenabbilder. Diese Posten erbringen keinerlei Leistung und sind der schnellste Gewinn, weil kein Abstimmungsbedarf besteht. Bei AWS werden nicht zugeordnete Elastic-IP-Adressen seit Februar 2024 ebenfalls berechnet.

Überdimensionierte Rechenleistung

Maschinen, die bei fünf Prozent Prozessorlast laufen, Datenbanken mit reservierter Leistung weit über dem Bedarf und Cluster-Knoten, die aus Vorsicht doppelt ausgelegt sind. Compute Optimizer bei AWS und Advisor bei Azure liefern dafür Vorschläge auf Basis echter Messwerte. Achte auf den Betrachtungszeitraum, sonst schrumpfst du eine Maschine, die nur zum Monatsabschluss ausgelastet ist.

Speicher in der falschen Klasse

Objektspeicher ohne Lebenszyklusregeln, Sicherungen ohne Aufbewahrungsgrenze, Protokolldaten mit unbegrenzter Vorhaltung und Datenträger der älteren Generation. Der Wechsel von gp2 auf gp3 bei AWS oder von Premium SSD auf Premium SSD v2 bei Azure ist meist ohne Ausfall möglich und wirkt sofort. Lebenszyklusregeln sind einmal eingerichtet und arbeiten danach dauerhaft.

Fehlende Zusagen für die Grundlast

Wer dauerhaft laufende Systeme zum vollen Preis bezahlt, verschenkt einen zweistelligen Prozentsatz. Savings Plans und Reserved Instances bei AWS, Reservierungen und der Azure-Sparplan bei Azure decken die Grundlast ab. Wichtig ist die Reihenfolge: erst aufräumen und richtig dimensionieren, dann binden. Sonst zahlst du drei Jahre lang für eine Größe, die du gar nicht brauchst.

Tutorial

Von der Monatsrechnung zur benannten Ursache

Die Überraschungen stecken selten bei den virtuellen Maschinen, sondern daneben: Datentransfer, NAT-Gateways, vergessene Volumes und Snapshots, Protokolldaten und öffentliche IP-Adressen. Ein großer Teil davon lässt sich in wenigen Tagen finden, ohne dass eine einzige Anwendung angefasst werden muss. Am schnellsten geht das so: die Rechnung nach Diensten aufschlüsseln, den größten Posten bis zur Nutzungsart verfolgen, verwaiste Ressourcen einsammeln, die Dimensionierung mit Messwerten prüfen und Leitplanken setzen.

01

Schritt 1: Die Rechnung nach Diensten aufschlüsseln

Die Portalansicht mit einer großen Zahl hilft niemandem. Der erste Schritt ist immer dieselbe Frage: Welche drei Dienste machen den größten Teil der Summe aus, und wie haben sie sich gegenüber dem Vormonat verändert?

AWS: Kosten nach Dienst und Veränderung zum Vormonat
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output json > kosten-dienste.json

# Nur die Posten oberhalb einer Schwelle ansehen
jq -r '.ResultsByTime[] | .TimePeriod.Start as $m |
  .Groups[] | select((.Metrics.UnblendedCost.Amount|tonumber) > 200) |
  [$m, .Keys[0], .Metrics.UnblendedCost.Amount] | @tsv' kosten-dienste.json

Zwei Monate abzufragen ist wichtiger als ein besonders langer Zeitraum. Der Vergleich zeigt, ob ein Posten dauerhaft hoch ist oder gerade gewachsen, und nur der zweite Fall hat eine konkrete Ursache mit Datum.

Azure: derselbe Blick über den Verbrauch
az consumption usage list \
  --start-date 2026-06-01 --end-date 2026-06-30 \
  --query '[].{kategorie:meterDetails.meterCategory,ressource:instanceName,kosten:pretaxCost}' \
  -o tsv | sort -k3 -rn | head -30

# Wiederkehrende Auswertung als Export in einen Storage Account
az costmanagement export list --scope "/subscriptions/$ABO" -o table

Für laufende Auswertungen ist der Kostenexport der bessere Weg als wiederholte Abfragen: Azure schreibt die Daten regelmäßig als Datei in ein Speicherkonto, von dort lassen sie sich in ein Berichtswerkzeug oder eine Datenbank übernehmen.

02

Schritt 2: Den Ausreißer bis zur Nutzungsart verfolgen

Ein Dienstname ist noch keine Ursache. Erst die Nutzungsart sagt, ob hinter der Kategorie eine Maschine, ein Gateway oder Datentransfer steckt.

AWS: die Sammelkategorie EC2 - Other aufbrechen
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["EC2 - Other"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --output table

Genau hier sitzen die Posten, die in Diskussionen fehlen: NatGateway-Bytes und NatGateway-Hours, EBS:VolumeUsage, EBS:SnapshotUsage und der Verkehr zwischen Verfügbarkeitszonen. Wenn die Datenmenge am NAT-Gateway auffällt, prüfe VPC-Endpunkte für S3 und DynamoDB, denn dieser Verkehr muss den Umweg nicht nehmen.

Typische Treiber, ihr Erkennungsmerkmal und die Sofortmaßnahme

TreiberWoran du ihn erkennstSofortmaßnahme
NAT-GatewayHohe Datenmenge in EC2 - Other, konstant über den MonatVPC-Endpunkte für S3 und andere Dienste einrichten, Gateways je Zone prüfen
Verkehr zwischen ZonenKosten steigen mit der Last, obwohl nichts nach außen gehtDatenintensive Dienste in derselben Zone platzieren, Zonenverteilung bewusst wählen
Verwaiste Volumes und DatenträgerSpeicherkosten trotz gelöschter MaschinenNicht angebundene Datenträger auflisten, sichern und löschen
Alte SnapshotsSpeicherposten wächst gleichmäßig ohne neue SystemeAufbewahrungsregel einführen und Altbestand nach Datum abbauen
ProtokolldatenÜberwachungsdienst unter den Top 5, ohne neues MonitoringAufnahme filtern, Aufbewahrung begrenzen, ausführliche Protokolle abschalten
Testumgebungen rund um die UhrGleichmäßige Kosten auch nachts und am WochenendeAbschaltzeitplan für Nicht-Produktionsumgebungen einrichten

Wenn Kubernetes im Spiel ist, verschiebt sich die Analyse eine Ebene nach oben, weil eine Knotengruppe als ein Posten erscheint, aber Dutzende Anwendungen trägt. Dann brauchst du eine Zuordnung auf Namensraum- oder Bezeichnungsebene, sonst endet die Diskussion bei der Summe des Clusters. Wie das geht und welche Stellschrauben dort wirken, steht in Kubernetes-Kosten senken.

03

Schritt 3: Verwaiste Ressourcen einsammeln

Das ist der schnellste Gewinn, weil niemand widerspricht. Diese Ressourcen erbringen keine Leistung und kosten trotzdem jeden Monat.

AWS: Volumes, Adressen und alte Snapshots finden
# Nicht angebundene EBS-Volumes
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].{Id:VolumeId,GB:Size,Typ:VolumeType,Zone:AvailabilityZone}' \
  --output table

# Elastic IPs ohne Zuordnung: werden seit Februar 2024 auch ungenutzt berechnet
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' --output table

# Snapshots, die älter als ein Jahr sind
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-07-01`].[SnapshotId,VolumeId,VolumeSize,StartTime]' \
  --output table

# Lastverteiler ohne Ziel
aws elbv2 describe-target-groups \
  --query 'TargetGroups[?length(LoadBalancerArns)==`0`].TargetGroupName' --output table

Arbeite die Liste in dieser Reihenfolge ab: erst dokumentieren, dann abklemmen, dann nach einer Wartezeit löschen. Ein Volume lässt sich vor dem Löschen mit einem letzten Snapshot sichern, dessen Kosten deutlich unter denen des Volumes liegen.

Azure: dieselbe Suche mit der Azure CLI
# Nicht angebundene verwaltete Datenträger
az disk list \
  --query "[?diskState=='Unattached'].{name:name,rg:resourceGroup,gb:diskSizeGb,sku:sku.name}" \
  -o table

# Öffentliche IP-Adressen ohne Konfiguration
az network public-ip list \
  --query "[?ipConfiguration==null].{name:name,rg:resourceGroup,sku:sku.name}" -o table

# Netzwerkkarten ohne virtuelle Maschine
az network nic list --query "[?virtualMachine==null].{name:name,rg:resourceGroup}" -o table

# Momentaufnahmen nach Alter sortiert
az snapshot list --query '[].{name:name,rg:resourceGroup,erstellt:timeCreated,gb:diskSizeGb}' \
  -o tsv | sort -k3 | head -40

Öffentliche IP-Adressen der SKU Standard kosten in Azure auch dann, wenn sie an nichts hängen. In gewachsenen Abonnements sammeln sich davon leicht dreistellige Mengen an, weil sie beim Löschen einer Maschine nicht automatisch mitgelöscht werden.

04

Schritt 4: Dimensionierung mit Messwerten prüfen

Rightsizing bringt den größten Einzeleffekt, ist aber der erste Schritt, der Anwendungen berührt. Deshalb gehören Messwerte und ein Rückweg dazu.

Empfehlungen auf beiden Plattformen abrufen
# AWS Compute Optimizer: nur die überdimensionierten Instanzen
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[?finding==`OVER_PROVISIONED`].{
    Instanz:instanceArn,
    Aktuell:currentInstanceType,
    Vorschlag:recommendationOptions[0].instanceType}' \
  --output table

# Azure Advisor: Empfehlungen der Kategorie Kosten
az advisor recommendation list --category Cost \
  --query '[].{ressource:impactedValue,problem:shortDescription.problem}' -o table

Beide Dienste bewerten anhand von Messwerten der letzten Wochen. Verlängere den Betrachtungszeitraum, bevor du folgst, sonst schrumpfst du ein System, das nur zum Monats- oder Quartalsabschluss unter Last steht. Systeme mit ausgeprägten Spitzen gehören nicht in einen automatischen Vorschlag, sondern in eine bewusste Entscheidung.

Vorgehen je Maschine, damit Rightsizing nicht zum Vorfall wird

  • Messwerte über mindestens vier Wochen betrachten, inklusive MonatswechselViele Systeme haben ihre Spitze am Monatsende. Ein Zeitfenster von sieben Tagen übersieht genau diese Last.
  • Eine Größenstufe nach unten gehen, nicht zweiDie zweite Stufe halbiert Prozessor und Arbeitsspeicher erneut. Fehler in kleinen Schritten sind schnell zurückgenommen, große Sprünge erzeugen Ausfälle.
  • Vor der Änderung eine Momentaufnahme des Systems anlegenWenn die kleinere Größe nicht trägt, brauchst du den Rückweg in Minuten und nicht über eine Neuinstallation.
  • Änderung außerhalb der Kernzeit und mit angekündigtem NeustartEin Größenwechsel erfordert bei den meisten Systemen einen Neustart. Ungeplant ist das ein Ausfall, geplant ein Wartungsfenster.
  • Nach der Änderung eine Woche lang Fehler- und Latenzwerte beobachtenDer Effekt einer knappen Auslegung zeigt sich nicht sofort, sondern beim nächsten Lastspitzen-Ereignis. Ohne Beobachtung fällt er erst den Anwendern auf.
  • Ersparnis je Maßnahme dokumentierenOhne Nachweis bleibt Kostenarbeit ein Nebenprojekt. Mit Nachweis bekommst du Zeit für die nächste Runde.
05

Schritt 5: Zusagen binden und Leitplanken einziehen

Erst nach dem Aufräumen lohnt sich die Bindung, und erst mit Leitplanken bleibt der Effekt bestehen. Beides gehört zusammen, sonst wiederholt sich die Analyse in einem Jahr.

Für die dauerhaft laufende Grundlast lohnen sich Verbrauchszusagen fast immer, aber niemals als erster Schritt. Wer eine überdimensionierte Landschaft für drei Jahre bindet, zementiert den Fehler. Sinnvoll ist die Reihenfolge aufräumen, dimensionieren, messen und dann binden, wobei die erste Zusage bewusst unter dem gemessenen Minimum liegen sollte. Bei AWS sind Compute Savings Plans flexibler als reine Reserved Instances, weil sie Instanzfamilie und Region weniger fest binden. Bei Azure decken Reservierungen und der Azure-Sparplan denselben Zweck ab, dazu kommt der Hybrid Benefit für vorhandene Windows- und SQL-Lizenzen.

Zuordnung erzwingen und Budgets setzen
# AWS: welche Tags sind überhaupt als Kostenzuordnung aktiv?
aws ce list-cost-allocation-tags --status Active --output table
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=kostenstelle,Status=Active

# Budget mit Warnschwelle aus Datei anlegen
aws budgets create-budget --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://warnungen.json

# Azure: Pflicht-Tags über eine Richtlinie durchsetzen
az policy assignment create \
  --name pflicht-kostenstelle \
  --policy "871b6d14-10aa-478d-b590-94f262ecfa99" \
  --scope "/subscriptions/$ABO" \
  --params '{"tagName":{"value":"kostenstelle"}}'

Zur eingebauten Richtlinie: Die genannte Kennung gehört zu Require a tag on resources. Prüfe vor dem Einsatz mit az policy definition list, welche Variante zu deinem Fall passt, denn es gibt getrennte Definitionen für Ressourcen und für Ressourcengruppen.

Damit die Wirkung bleibt, braucht es am Ende eine Zuständigkeit. Wer Kosten monatlich auswertet, Abweichungen mit den Teams bespricht und Maßnahmen nachhält, verhindert die nächste Eskalation. Der organisatorische Rahmen dafür heißt FinOps, und wie sich das ohne eigene Abteilung einführen lässt, beschreibt FinOps einführen. Wenn die Rechnung dagegen grundsätzlich infrage steht, also die Frage lautet, ob sich der Betrieb in der Cloud überhaupt rechnet, gehört diese Rechnung vor jede weitere Optimierung.

Passende Kurse

Kurse zu Cloud-Kosten und Kostenanalyse bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

AWS Cloud Financial Management for Builders 3 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Cloud Operations on AWS 3 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs AWS Well-Architected Best Practices 1 Tag Präsenz nächster Termin 28.09.2026 Zum Kurs AWS Cloud for Finance Professionals 2 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Amazon Web Services für Entscheider 1 Tag Präsenz nächster Termin 08.09.2026 Zum Kurs AZ-104 Training: Microsoft Azure Administrator (AZ-104T00) 4 Tage Präsenz nächster Termin 07.09.2026 Garantietermin Zum Kurs AZ-305: Designing Microsoft Azure Infrastructure Solutions (AZ-305T00) 4 Tage Präsenz nächster Termin 24.08.2026 Garantietermin Zum Kurs
Unverbindlich beraten lassen Alle AWS-Kurse ansehen
Gut zu wissen

Häufige Fragen zu Cloud-Kosten und Kostenanalyse

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie viel lässt sich realistisch einsparen?
In einer nie geprüften Umgebung sind 20 bis 30 Prozent innerhalb weniger Wochen üblich, ohne dass eine Anwendung umgebaut wird. Analysen aus dem AWS-Umfeld nennen 28 bis 35 Prozent der Ausgaben für ungenutzte oder überdimensionierte Ressourcen, und diese Größenordnung deckt sich mit unseren Projekten. Der erste Schnitt kommt aus verwaisten Ressourcen und Abschaltzeitplänen, der zweite aus Rightsizing, der dritte aus Verbrauchszusagen. Danach wird es deutlich mühsamer, weil dann Architekturarbeit ansteht, etwa der Umbau von Datenpfaden oder der Wechsel von Diensten. Plane die ersten drei Runden fest ein, alles weitere entscheidet sich am Aufwand.
Warum steht bei uns EC2 - Other so weit oben?
Weil das eine Sammelkategorie ist und kein Dienst. Darin stecken EBS-Volumes und deren Snapshots, NAT-Gateways mit Bereitstellungs- und Datenkosten, ungenutzte Elastic-IP-Adressen und Datenübertragung. Genau deshalb bleibt der Posten in Diskussionen unsichtbar, obwohl er häufig zweistellige Prozentanteile ausmacht. Brich ihn mit einer Gruppierung nach Nutzungsart auf, dann siehst du sofort, ob Speicher oder Netz die Ursache ist. Wenn die Datenmenge am NAT-Gateway auffällt, lohnt fast immer ein Blick auf VPC-Endpunkte, denn Verkehr zu S3 oder DynamoDB muss den Umweg über das Gateway nicht nehmen.
Wir haben keine Tags gepflegt. Wie ordnen wir die Kosten trotzdem zu?
Behelfsweise über die Struktur. Bei AWS lässt sich nach Konten gruppieren, bei Azure nach Abonnements und Ressourcengruppen, und in vielen Häusern ist diese Trennung ohnehin grob nach Team oder Umgebung gewachsen. Das reicht für die erste Runde und beantwortet die Frage, wo überhaupt gesucht werden muss. Parallel führst du Tags ein, aktivierst sie als Kostenzuordnung und erzwingst sie über Richtlinien für neue Ressourcen. Den Altbestand taggst du nach, sortiert nach Kosten, denn die teuersten zwanzig Ressourcen erklären meist den größten Teil der Rechnung.
Lohnen sich Reserved Instances oder Savings Plans für uns?
Für alles, was rund um die Uhr läuft und in den nächsten Jahren laufen wird, ja. Für alles andere nein. Der Fehler liegt selten im Produkt, sondern im Zeitpunkt: Wer vor dem Aufräumen bindet, zahlt jahrelang für eine Größe, die nach dem Rightsizing nicht mehr nötig wäre. Sinnvoll ist es, zuerst die tatsächliche Grundlast über mehrere Monate zu messen und dann bewusst unterhalb dieses Minimums zu binden, damit die Auslastung der Zusage nahe hundert Prozent liegt. Compute Savings Plans bei AWS sind flexibler als reine Reservierungen, weil sie weniger fest an Instanzfamilie und Region gebunden sind.
Wie verhindern wir, dass die Kosten wieder wegdriften?
Mit drei Dingen, die zusammen wirken. Erstens Budgets mit Warnschwellen je Konto oder Abonnement, damit eine Abweichung innerhalb von Tagen auffällt und nicht erst auf der Monatsrechnung. Zweitens verpflichtende Tags, die über Richtlinien durchgesetzt werden, denn ohne Zuordnung gibt es keine Zuständigkeit. Drittens einen festen Termin, an dem die Kosten mit den Teams besprochen werden, mit benannten Maßnahmen und einer Nachverfolgung. Werkzeuge allein reichen nicht: Eine Warnung, die niemandem gehört, wird weggeklickt. Der organisatorische Teil ist der, der über die Dauerhaftigkeit entscheidet.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Cloud-Themen

Alle Cloud-Themen im Überblick
Grundlagen & Einstieg FinOps einführen: Cloud-Kosten dauerhaft im Griff behalten Ansehen Betrieb & Kosten Kubernetes-Kosten senken: Wo das Geld im Cluster wirklich verschwindet Ansehen Entscheidung & Vergleich Lohnt sich die Cloud? So rechnest du den Business Case ehrlich Ansehen Grundlagen & Einstieg Landing Zone aufbauen: das Fundament vor der ersten Migration Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Super, komplett auf uns und unsere Bedürfnisse eingegangen. Der Tag hat uns viel geholfen und wir könnten das alles in unserem Arbeitsalltag nutzen.
Rückmeldung aus dem Kurs „DP-080 Training: Abfragen von Daten mit Microsoft Transact-SQL (DP-080T00)“
“
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Kostenanalyse als Fähigkeit im Team verankern

Wer die Rechnung einmal auseinandergenommen hat, will das nicht jedes Jahr neu erfinden. Der Kurs "AWS Cloud Financial Management for Builders" übt genau diese Analyse an echten Daten ein, "Cloud Operations on AWS" liefert die Betriebsseite dazu und "AWS Well-Architected Best Practices" die Architekturperspektive. Für die Azure-Seite deckt AZ-104 Kostenverwaltung und Tagging ab, AZ-305 die Auslegung. Sag uns, welche Plattform bei euch drückt, dann stellen wir den passenden Weg zusammen, als Live-Online-Termin oder als Inhouse-Schulung.

Beratung anfragen 0800 71 20000