Betrieb & Kosten

Kubernetes-Kosten senken: Wo das Geld im Cluster wirklich verschwindet

Der weitaus größte Teil der Rechnung entsteht bei den Worker-Nodes, nicht bei der Control Plane. Wer Requests großzügig setzt, bezahlt Kapazität, die nie jemand nutzt, denn der Scheduler rechnet mit den angeforderten Werten und nicht mit der echten Last. Mit korrigierten Requests, Verdichtung auf Node-Ebene und Spot-Kapazität für die richtigen Workloads sind dreißig bis fünfzig Prozent drin, ohne dass die Verfügbarkeit leidet.

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 Cluster-Rechnung schneller wächst als die Last

Die Control Plane ist bei den verwalteten Angeboten von AWS, Azure und Google ein Fixposten von wenigen Dutzend Euro im Monat. Alles darüber hinaus zahlst du für Worker-Nodes, für angehängte Volumes, für Load Balancer und für Datenverkehr zwischen Availability Zones. Deshalb bringt es fast nichts, am Cluster-Typ zu sparen. Der Hebel liegt bei der Frage, wie viele Nodes laufen und wie gut sie ausgelastet sind. In vielen Clustern liegt die tatsächliche CPU-Auslastung im einstelligen Prozentbereich, während dieselben Nodes rechnerisch bis an die Grenze belegt sind.

Der Grund dafür ist der Scheduler. Er verteilt Pods nicht nach gemessener Auslastung, sondern nach den Requests, die im Manifest stehen. Ein Deployment, das zwei CPU-Kerne und vier GiB anfordert und davon 0,2 Kerne und 800 MiB nutzt, blockiert trotzdem den vollen Anteil auf dem Node. Sobald mehrere Teams so arbeiten, kauft der Cluster Autoscaler weitere Nodes ein, obwohl die vorhandenen nahezu leer laufen. Die Requests sind dabei selten böswillig zu hoch gesetzt. Sie stammen aus einem kopierten Beispiel-Manifest oder aus einer Lastspitze, die einmal im Jahr auftritt.

Dazu kommen Posten, die niemand einem Team zuordnet. Volumes von gelöschten Pods bleiben liegen, wenn die Reclaim Policy auf Retain steht. Jeder Service vom Typ LoadBalancer erzeugt eine eigene Cloud-Ressource mit eigenem Stundenpreis. Verkehr zwischen Zonen wird in beide Richtungen berechnet, und ein Service Mesh ohne topologiebewusstes Routing verteilt Anfragen gleichmäßig über alle Zonen. Am Monatsende steht eine Summe, die niemand erklären kann, weil die Zuordnung zu Namespace, Team und Anwendung fehlt. Ohne diese Zuordnung bleibt jede Sparrunde eine Verhandlung nach Bauchgefühl.

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

Der Weg von der Rechnung zur Ersparnis

01 Kosten je Namespace und Workload sichtbar machen
02 Requests am gemessenen 95. Perzentil ausrichten
03 Node-Autoscaling und Verdichtung aktivieren
04 Spot-Kapazität für unterbrechbare Lasten nutzen
05 Zonen-Traffic, Volumes und Load Balancer aufräumen
06 Quotas, Budget-Alarme und einen Monatstermin verankern

Was du mitnimmst

Sechs Hebel, in dieser Reihenfolge

Die Reihenfolge ist nicht beliebig, denn jeder Schritt bestimmt die Wirkung des nächsten. Wer Spot-Kapazität einführt, bevor die Requests stimmen, spart lediglich auf zu vielen Nodes weiter.

Requests an der echten Nutzung ausrichten

Miss über mindestens zwei Wochen, nimm das 95. Perzentil von CPU und Speicher und setze die Requests knapp darüber. Der Vertical Pod Autoscaler liefert diese Empfehlung im Modus Off, ohne einen einzigen Pod anzufassen. Bei CPU verzichtest du in der Regel auf Limits, weil sie zu Drosselung führen. Beim Speicher setzt du sie, weil sonst ein einzelner Pod den ganzen Node mitreißt.

Nodes automatisch skalieren und verdichten

Der Cluster Autoscaler skaliert vorhandene Node-Gruppen, Karpenter wählt den Instanztyp passend zum tatsächlichen Bedarf und räumt unterausgelastete Nodes selbst ab. Bei AKS steckt dieselbe Idee hinter Node Autoprovisioning. Entscheidend ist die untere Grenze: Node-Gruppen, die nie unter drei Knoten fallen dürfen, verhindern jede Ersparnis in der Nacht und am Wochenende.

Spot-Kapazität für das, was sie verträgt

Batch-Jobs, CI-Runner, zustandslose Web-Frontends mit mehreren Replikaten und komplette Testumgebungen laufen gut auf Spot-Kapazität. Datenbanken, Ingress-Controller, Message Broker und alles mit lokalem Zustand gehören auf reguläre Nodes. AWS kündigt eine Rückholung zwei Minuten vorher an, Azure gibt dir dreißig Sekunden. Danach ist der Node weg, ob die Anwendung darauf vorbereitet war oder nicht.

Instanztyp und Prozessorarchitektur prüfen

Ein Wechsel auf ARM-Nodes, also Graviton bei AWS sowie Ampere oder Cobalt bei Azure, senkt den Preis je Kern spürbar, sobald deine Images für arm64 gebaut werden. Bei mehrstufigen Container-Builds ist das oft weniger Arbeit als befürchtet. Ebenso lohnt der Blick auf die Node-Größe, denn zu große Nodes verschwenden Reste und zu kleine kosten überproportional viel Systemreserve.

Datenverkehr, Volumes und Reste aufräumen

Zonenübergreifender Verkehr ist der stillste Kostenblock im Cluster. Topologiebewusstes Routing hält Anfragen in derselben Zone. Dazu kommt der Frühjahrsputz: freigegebene Volumes, alte Snapshots, Load Balancer ohne Backend und Log-Pipelines, die jede Debug-Zeile nach außen schicken. Keiner dieser Posten taucht in einer Pod-Metrik auf, in der Rechnung aber sehr wohl.

Kosten je Team sichtbar machen

OpenCost und Kubecost rechnen die Node-Kosten auf Namespaces, Labels und einzelne Workloads herunter. Erst wenn ein Team seine eigene Zahl sieht, wird aus der Sparrunde ein sachliches Gespräch über Prioritäten. Verbindliche Labels für Team, Umgebung und Kostenstelle sind dafür die Voraussetzung, am besten über eine Policy erzwungen statt über eine Bitte im Wiki.

Tutorial

Von der ersten Messung bis zur dauerhaft niedrigeren Rechnung

Der größte Teil der Rechnung entsteht bei den Worker-Nodes, und der wirksamste Hebel sind Requests, die an gemessener Nutzung hängen statt an einer Schätzung im Review. Die Reihenfolge ist dabei nicht beliebig, denn wer Spot-Kapazität einführt, bevor die Requests stimmen, spart lediglich auf zu vielen Nodes weiter. Deshalb geht es hier erst ums Messen und Zuordnen, dann um Requests, danach um Verdichtung und Spot-Kapazität und zum Schluss um Reste und Grenzen, jeweils mit EKS und AKS nebeneinander.

Schritt 1: Sichtbar machen, wohin das Geld fließt

Ohne Zuordnung auf Namespace und Workload bleibt jede Maßnahme eine Vermutung. Der erste Schritt ist deshalb reine Messarbeit, einmal in der Cloud-Rechnung und einmal im Cluster.

Auslastung gegen reservierte Kapazität stellen

kubectl top nodes
kubectl top pods -A --sort-by=cpu | head -20

# Was ist reserviert, was laeuft wirklich?
kubectl describe node ip-10-42-1-17.eu-central-1.compute.internal \
  | sed -n '/Allocated resources/,/Events/p'

# Requests je Namespace aufsummieren
kubectl get pods -A -o json | jq -r '
  .items[] | .metadata.namespace as $ns
  | .spec.containers[].resources.requests
  | select(. != null) | "\($ns) \(.cpu // "0") \(.memory // "0")"' | sort | uniq -c

Der Abschnitt Allocated resources zeigt die Reservierung, kubectl top die tatsächliche Nutzung. Die Lücke zwischen beiden Zahlen ist dein Sparpotenzial, und sie beträgt in ungepflegten Clustern regelmäßig mehr als die Hälfte.

Die Cloud-Rechnung nach Dienst aufschlüsseln

# AWS: Monatskosten nach Dienst
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Azure: laufender Monat, taeglich aufgeloest
az costmanagement query --type ActualCost \
  --scope "/subscriptions/$SUB_ID" \
  --timeframe MonthToDate --dataset-granularity Daily

Erwartbar ist ein Bild, in dem EC2 beziehungsweise Virtual Machines den Löwenanteil ausmachen, während der Posten für den verwalteten Cluster selbst kaum auffällt. Genau das ist die Begründung dafür, bei den Nodes anzusetzen und nicht beim Cluster.

Für die Zuordnung innerhalb des Clusters brauchst du ein Werkzeug, das Node-Preise auf Pods herunterrechnet. OpenCost ist das quelloffene Projekt der CNCF und liest die Preislisten der Anbieter selbst ein, Kubecost setzt darauf auf und ergänzt Oberfläche und Berichte. Beide brauchen saubere Labels, sonst landet der größte Anteil im Topf unallocated und die Diskussion beginnt von vorn. Wie aus der einmaligen Auswertung ein dauerhafter Prozess mit klaren Zuständigkeiten wird, steht auf FinOps einführen.

Schritt 2: Requests und Limits an der Realität ausrichten

Hier entsteht der größte Teil der Ersparnis. Wichtig ist nur, dass die neuen Werte aus gemessenen Daten stammen und nicht aus einer Schätzung im Review.

vpa-recommender.yaml: Empfehlung ohne Eingriff

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
  namespace: shop
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: "Off"   # nur empfehlen, nichts neu starten

Nach zwei bis vier Wochen liefert kubectl describe vpa api-vpa -n shop unter Target einen belastbaren Vorschlag für CPU und Speicher. Übernimm ihn bewusst in das Deployment, statt den Modus auf Auto zu stellen.

Vier Autoscaler, vier verschiedene Aufgaben

Werkzeug	Was es tut	Was es spart	Wo es wehtut
HPA	Mehr oder weniger Replikate je nach Metrik	Kapazität in der Nacht und am Wochenende	Braucht Metriken, die die Last wirklich abbilden
VPA	Passt Requests je Pod an die Messung an	Reservierung, die nie genutzt wird	Neustarts im Auto-Modus, Konflikt mit dem HPA
Cluster Autoscaler	Skaliert bestehende Node-Gruppen hoch und runter	Nodes, die leer laufen	Instanztyp bleibt fest, Untergrenzen bremsen
Karpenter	Startet passende Nodes und verdichtet sie laufend	Reste durch falsch geschnittene Nodes	Bei AWS ausgereift, bei AKS als Node Autoprovisioning

Wer diese Werkzeuge betreibt, entscheidet mit darüber, wie viel Aufwand die Kostenkontrolle bindet. Bei einem verwalteten Cluster übernimmt der Anbieter die Control Plane und einen Teil der Autoscaling-Logik, im Eigenbetrieb liegt beides bei dir. Die vollständige Abwägung dazu steht auf Managed Kubernetes oder selbst betreiben.

Schritt 3: Nodes verdichten und Spot-Kapazität nutzen

Erst wenn die Requests stimmen, lohnt die Arbeit an den Nodes. Sonst optimierst du den Preis für Kapazität, die du gar nicht brauchst.

karpenter-nodepool.yaml: Spot bevorzugen, laufend verdichten

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m
  limits:
    cpu: "200"

consolidationPolicy ist der eigentliche Sparschalter: Karpenter verschiebt Pods zusammen und beendet Nodes, die danach überflüssig sind. Das Feld limits ist deine Notbremse gegen eine fehlerhafte Anwendung, die in einer Schleife Pods erzeugt und dabei Nodes nachkauft.

Spot-Pool in AKS anlegen, regulären Pool als Basis behalten

az aks nodepool add \
  --resource-group rg-k8s --cluster-name aks-prod \
  --name spotpool --priority Spot \
  --eviction-policy Delete --spot-max-price -1 \
  --node-vm-size Standard_D4as_v5 \
  --enable-cluster-autoscaler --min-count 0 --max-count 10

az aks nodepool update \
  --resource-group rg-k8s --cluster-name aks-prod \
  --name systempool --update-cluster-autoscaler --min-count 2 --max-count 6

--spot-max-price -1 bedeutet, dass du höchstens den regulären Preis zahlst und nur bei Kapazitätsmangel verdrängt wirst. Ein eigener Preisdeckel klingt sparsamer, sorgt aber für Verdrängung genau dann, wenn die Nachfrage in der Region steigt, also im ungünstigsten Moment.

Bevor eine Anwendung auf Spot-Kapazität darf

Mindestens zwei Replikate, verteilt über verschiedene NodesEin einzelnes Replikat auf einem zurückgeholten Node bedeutet Ausfall statt Ersparnis.
Pod Disruption Budget mit minAvailable setzenOhne PDB räumt auch die Verdichtung durch Karpenter alle Replikate gleichzeitig ab.
Reguläre Kapazität als Basis behaltenWird Spot-Kapazität in der Region knapp, muss die Anwendung trotzdem weiterlaufen können.
Das Terminationssignal verarbeiten und Verbindungen sauber schließenAWS gibt zwei Minuten Vorwarnung, Azure dreißig Sekunden. Wer sie ignoriert, verliert laufende Anfragen mitten in der Verarbeitung.
Zustand außerhalb des Pods haltenLokale Daten auf einem Spot-Node sind mit der Rückholung ersatzlos verloren.

Schritt 4: Zonen-Traffic, Volumes und Reste

Diese Posten stehen in keiner Pod-Metrik, summieren sich aber verlässlich. Sie lassen sich meist an einem Tag abarbeiten und kommen ohne jede Änderung am Anwendungscode aus.

Liegengebliebene Ressourcen finden

# Volumes, die kein Pod mehr braucht
kubectl get pv -o custom-columns='NAME:.metadata.name,SIZE:.spec.capacity.storage,STATUS:.status.phase,CLAIM:.spec.claimRef.name'
kubectl get pv --field-selector status.phase=Released

# AWS: nicht angehaengte EBS-Volumes
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,CreateTime]' --output table

# Azure: nicht angehaengte Managed Disks
az disk list --query "[?diskState=='Unattached'].{Name:name,GB:diskSizeGb,RG:resourceGroup}" -o table

Prüfe vor dem Löschen, ob ein Volume zu einem StatefulSet gehört, das gerade nur heruntergefahren wurde. Ein Snapshot vor dem Löschen kostet wenige Cent und rettet im Zweifel den Tag.

Anfragen in der eigenen Zone halten

apiVersion: v1
kind: Service
metadata:
  name: api
  annotations:
    service.kubernetes.io/topology-mode: "Auto"
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

Topologiebewusstes Routing schickt Anfragen bevorzugt an Endpunkte in derselben Availability Zone. Verkehr zwischen Zonen wird bei AWS und Azure in beide Richtungen berechnet, und bei gesprächigen Microservices ist das ein vierstelliger Betrag im Monat. Voraussetzung sind genügend Endpunkte je Zone, sonst schaltet Kubernetes wieder auf gleichmäßige Verteilung um.

Schritt 5: Die Ersparnis halten

Eine einmalige Aufräumaktion ist nach einem Quartal aufgebraucht. Damit die Zahl unten bleibt, brauchst du harte Grenzen im Cluster und einen festen Termin im Kalender.

resourcequota.yaml: Obergrenze je Namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-shop-quota
  namespace: shop
spec:
  hard:
    requests.cpu: "40"
    requests.memory: 80Gi
    limits.memory: 120Gi
    persistentvolumeclaims: "20"
    services.loadbalancers: "2"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: shop
spec:
  limits:
    - type: Container
      default:
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 256Mi

Die Quota begrenzt, was ein Team insgesamt anfordern darf, die LimitRange verhindert Pods ganz ohne Angabe. Der Posten services.loadbalancers ist kein Detail, denn jeder dieser Services erzeugt eine eigene Cloud-Ressource mit eigenem Stundenpreis.

Budget-Alarm, damit die Überraschung vorher kommt

# AWS: Budget mit Schwelle, Definition liegt in den JSON-Dateien
aws budgets create-budget --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notify.json

# Azure: monatliches Budget fuer die Subscription
az consumption budget create --budget-name aks-prod \
  --amount 4000 --category cost --time-grain Monthly \
  --start-date 2026-08-01 --end-date 2027-08-01

Der Alarm ersetzt keine Analyse, er verkürzt nur die Zeit bis zur Reaktion. Weder AWS noch Azure schalten beim Erreichen der Schwelle etwas ab. Wie du eine auffällige Rechnung systematisch zerlegst, steht auf Cloud-Kosten analysieren.

Ein realistischer Zielkorridor liegt bei dreißig bis fünfzig Prozent, wenn vorher niemand systematisch auf die Kosten geschaut hat. Der größte Teil davon kommt aus korrigierten Requests und aus Nodes, die nachts verschwinden, nicht aus einem Anbieterwechsel. Plane einen festen Termin im Monat, an dem ein Mensch die Zahlen ansieht und die Entscheidungen aufschreibt. Ohne diesen Termin steht die Rechnung binnen zwei Quartalen wieder auf dem alten Stand, weil jedes neue Deployment die alten Requests aus der Vorlage mitbringt.

Passende Kurse

Kurse zu Kubernetes im Betrieb 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.

Kubernetes Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 03.08.2026 Garantietermin Zum Kurs Cloud Operations on AWS 3 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs AWS Cloud Financial Management for Builders 3 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Monitoring mit Prometheus und Grafana - Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 07.09.2026 Zum Kurs

Unverbindlich beraten lassen Alle Cloud-Native-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest Kubernetes Grundlagen Quiz Teste dein Wissen zu Pods, Deployments, Services, ConfigMaps, kubectl und der Cluster-Architektur. Quiz starten Wissenstest Docker & Container Grundlagen Quiz Teste dein Wissen zu Docker-Architektur, Dockerfiles, Volumes, Networking und Compose. Quiz starten

Gut zu wissen

Häufige Fragen zu Kubernetes im Betrieb

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

Frag uns direkt

Wie viel lässt sich realistisch einsparen?

In Clustern, in denen vorher niemand systematisch auf die Kosten geschaut hat, sind dreißig bis fünfzig Prozent ein realistischer Korridor. Der größte Einzelposten sind zu hoch gesetzte Requests, danach folgen Nodes ohne Untergrenze null in Testumgebungen und der Verkehr zwischen Availability Zones. In einem Cluster, der bereits mit Karpenter oder Node Autoprovisioning verdichtet wird und in dem Requests aus Messdaten stammen, sind es eher fünf bis zehn Prozent. Die Zahl sagt also mehr über den Ausgangszustand als über das Werkzeug.

Sind Spot-Instanzen im produktiven Betrieb vertretbar?

Ja, für zustandslose Arbeitslasten mit mehreren Replikaten und einem Pod Disruption Budget. Entscheidend ist eine Basis aus regulärer Kapazität, damit die Anwendung auch dann läuft, wenn Spot-Kapazität in der Region knapp wird. Nicht auf Spot gehören Datenbanken, Message Broker mit lokalem Zustand, Ingress-Controller und alles, was beim Neustart mehrere Minuten braucht. AWS kündigt die Rückholung zwei Minuten vorher an, Azure dreißig Sekunden. Diese Frist muss deine Anwendung nutzen, um Verbindungen sauber zu schließen.

Reicht OpenCost oder brauche ich Kubecost?

OpenCost ist das quelloffene Projekt und deckt den Kern ab: Node-Preise auf Namespaces, Labels und Workloads herunterrechnen und als Metrik bereitstellen. Wer bereits Prometheus und Grafana betreibt, baut sich daraus in einem Tag die nötigen Auswertungen. Kubecost setzt auf denselben Kern auf und liefert Oberfläche, Berichte, Empfehlungen und Mandantenfähigkeit dazu. Für einen einzelnen Cluster und ein Team reicht OpenCost fast immer. Bei mehreren Clustern und Rückbelastung an Fachbereiche zahlt sich das Produkt eher aus.

Lohnt sich ein Wechsel von EKS zu AKS aus Kostengründen?

Fast nie. Die Gebühr für die Control Plane liegt bei beiden Anbietern im Bereich weniger Dutzend Euro im Monat und ist damit nicht der Grund für eine hohe Rechnung. Die Preise für vergleichbare Instanztypen liegen dicht beieinander, und der Wechsel kostet Migrationsaufwand, doppelte Betriebszeit und Einarbeitung. Ein Anbieterwechsel lohnt sich wegen bestehender Rahmenverträge, wegen vorhandener Kompetenz im Team oder wegen benötigter Dienste, nicht wegen des Cluster-Preises.

Wie überzeuge ich Teams davon, ihre Requests zu senken?

Mit Zahlen statt mit Appellen. Solange niemand weiß, was der eigene Namespace im Monat kostet, ist jede Bitte um kleinere Requests eine Zumutung ohne Gegenwert. Nach der Zuordnung über OpenCost oder Kubecost ändert sich das Gespräch, weil jedes Team seine Position selbst sieht. Hilfreich ist außerdem eine Empfehlung aus dem Vertical Pod Autoscaler, die schwarz auf weiß zeigt, wie weit Anforderung und Nutzung auseinanderliegen. Eine Quota je Namespace setzt danach die Grenze, ohne dass jemand verhandeln muss.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

“

Sehr kompetent, kurzweilig, hat mich nochmals sehr weitergebracht in meinem täglichen doing.

Rückmeldung aus dem Kurs „AZ-400 Training: Designing and Implementing Microsoft DevOps solutions (AZ-400T00-A)“

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

Weiterbildung & Beratung

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

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

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