Überprovisionierung im Cloud-Compute GPUs, Serverless und die neue (falsche) Kostenlogik per Cloud - ein Realitäts-Check

Anbieter zum Thema

Rittal GmbH & Co. KG

Vertiv GmbH

PQ Plus GmbH

Cloud-Strategien wurden lange entlang einer vertrauten und geradlinigen Route optimiert: CPU-Kerne, Virtual-Machine-Größen, ein bisschen Rightsizing, etwas Reservierung. Der Datadog-Report „State of Containers and Serverless“ beschreibt jedoch, wie sich dieses Koordinatensystem, zu Lasten des Budgets, verschiebt .

Bekanntermaßen bieten Cloud-Provider ein breites Spektrum an Compute-Optionen an – von VMs über Container-Plattformen und Serverless bis hin zu spezialisierter Hardware. Doch welche Faktoren werden für Kosten, Skalierbarkeit und Innovationsfähigkeit entscheidend sein?

Wenn Compute plötzlich knapp wird

Ein zentraler Treiber dieser Verschiebung ist der wachsende Einsatz von GPUs, also Spezialprozessoren für viele parallele Rechenoperationen. Denn der Anteil an Organisationen mit GPU-Nutzung ist in den letzten zwei Jahren, von Oktober 2023 bis Oktober 2025, von etwa 4,5 Prozent auf etwas über 6 Prozent gestiegen.

Das wirkt auf den ersten Blick moderat doch die Dynamik liegt in der Nutzungstiefe. Denn diese Dynamik entsteht vor allem durch Early Adopter, die mittlerweile rund dreimal so viele GPU-Instance-Hours verbrauchen wie vor zwei Jahren. Auch wenn GPU-Compute insgesamt, mit unter drei Prozent im Vergleich zu CPUs und „traditional compute“, weiterhin einen kleinen Teil der konsumierten Instance Hours ausmachen.

KI-Workloads verändern

In der Praxis braucht es dennoch strategische Anpassungen; denn Kapazitätsplanung wird wieder begrenzt . Das verhält sich ähnlich zu On-Prem-Zeiten, nur in der Cloud. Das liegt vor allem daran, dass GPUs teurer, knapper und deutlich stärker von externer Verfügbarkeit abhängig sind.

Gleichzeitig wird die Platzierung von Workloads granularer: Statt auf pauschale Methoden „alles auf Kubernetes“ oder „alles auf VMs“ zu setzen, wächst der Druck Deployment-Strategien passend zu Performance-Profilen, Laufzeit und Lastspitzen, pro Workload anzupassen. Cloud-Compute ist dementsprechend ein Mix aus VMs, Container-Orchestrierung, Serverless und Spezialhardware.

Parallel macht sich KI in den „Top-Kategorien“ containerisierter Workloads bemerkbar. Auch wenn KI als neue Workload-Kategorie mit 7 Prozent zum Beispiel noch hinter Datenbanken (45 Prozent), Web- und App-Servern (42 Prozent) und CI und CD (27 Prozent) liegt, beginnt sie bereits, Architektur- und Betriebsentscheidungen zu beeinflussen.

Auch wenn KI noch nicht „die Mehrheit“ ist, ändern sich Architekturentscheidungen insgesamt, weil GPU-Workloads andere Betriebs- und Kostenlogiken erzwingen. Dazu passt, dass Inference-Ökosysteme das Tooling prägen. Vor allem Inference-Server wie „Triton“, „VLLM“ und „Ollama“ sind hier auf dem Vormarsch.

Die stille Kostenfalle heißt: Unterauslastung

Ein anderer Kostentreiber liegt seit Jahren offen auf dem Tisch: dauerhaft zu viel provisionierte Ressourcen. Das Problem zeigt sich plattformübergreifend. Egal ob für „Azure Container Apps“, „Google Cloud Run“, „Amazon ECS Fargate“, „AWS Lambda“ und „Kubernetes“, die meisten Workloads nutzen weniger als die Hälfte des angeforderten Speichers und weniger als 25 Prozent der angeforderten CPU.

Doch warum ist diese Überreservierung so hartnäckig? Ein Teil ist schlicht Risiko-Management: Teams dimensionieren bewusst großzügig, um Stabilität zu priorisieren und Drosselung oder Latenzspitzen bei Traffic-Peaks zu vermeiden.

Ein weiterer Teil ist Plattformlogik. Bei AWS Lambda skaliert beispielsweise die CPU proportional mit dem Memory, wodurch eine Dimensionierung entlang einer Ressource schnell die andere im Leerlauf lässt. Bei ECS Fargate wiederum müssen Teams aus vordefinierten CPU/Memory-Bundles wählen, die nicht immer zum tatsächlichen Profil passen.

Die Rolle von automatisiertem Wachstum

Auch dort, wo Autoscaling etabliert ist, verschwindet dieses Problem nicht automatisch. Zwar nutzen inzwischen über 64 Prozent der Kubernetes-Organisationen den „Horizontal Pod Autoscaler“ (HPA). Gleichzeitig zeigt sich aber auch, dass Cluster-Infrastruktur trotz weit verbreitetem HPA oft überprovisioniert bleibt, was zu ungenutzten Ressourcen und vermeidbaren Ausgaben führt.

Ein Detail ist dabei aufschlussreich: Von HPA-Deployments nutzt nur ein Fünftel „Custom Metrics“. Die Mehrheit skaliert nach CPU- oder Memory-Signalen. Das kann zwar für viele Anwendungen reichen, aber eben nicht für alle und verschiebt aber die Lastspitzen-Absicherung häufig wieder in Richtung „mehr reservieren“.

Dazu kommen kurzlebige Container, die sich klassischen Mechanismen und Regelkreisen entziehen. Fast zwei Drittel der Kubernetes-Container laufen unter zehn Minuten und rund ein Drittel unter einer Minute. Für diese kurzen Laufzeiten greifen HPA/VPA oft zu spät, was Überprovisionierung als „Workaround“ begünstigt.

Die neue Cloud-Realität: Das Zusammenspiel entscheidet

Die Befunde des Reports zeigen, dass es nicht darum geht „eine richtige Plattform“ zu wählen sondern „ein gemischtes Portfolio“ zu erstellen. So ist Serverless in der Breite angekommen: In AWS nutzen 65 Prozent der Kund:innen Lambda, in Google Cloud 70 Prozent Cloud Run und in Azure 56 Prozent App Service.

Gleichzeitig nutzen 66 Prozent der Organisationen, die Serverless Functions einsetzen, auch Container-Orchestrierung im gleichen Cloud-Ökosystem. Das spricht für eine selektive Workload-Platzierung je nach Anwendung statt eines einheitlichen Stacks. Die Teams, die abhängig vom Profil, containerisierte Services zu Serverless Functions verschieben können oder umgekehrt, werden ihre Effizienz zukünftig verbessern können.

Zudem wird bei Autoscaling mehr Präzision entscheidend sein. Denn trotz einer breiten Nutzung erleben 46 Prozent der unskalierten Workloads mehrere signifikante CPU-Spikes pro Tag und wären damit Kandidaten für horizontale Skalierung. Strategisch entscheidend ist jedoch nicht, ob Autoscaling eingesetzt wird. Es geht darum, auf welcher Ebene skaliert wird, welche Signale die Skalierung auslösen und wie schnell die Mechanismen reagieren. Diese Kombination bestimmt, ob Kapazität bedarfsgerecht nachzieht oder ob aus Sicherheitsreserven dauerhaft unnötige Kosten entstehen.

Überlegte Ausgewogenheit

Dazu kommt, dass die Hardware-Strategie zum Kosten- und Innovationshebel wird. Neben GPUs zeigt sich eine zunehmende ARM-Nutzung. Der Anteil von AWS-Lambda-Funktionen auf ARM stieg demnach von 9 auf 19 Prozent in zwei Jahren und ARM-basierte Cloud-Instances von 9 auf 15 Prozent.

Eine robuste Cloud-Strategie wird deshalb zweigleisig: auf der einen Seite gezielter, kontrollierter GPU-Einsatz für KI- und datenintensive Aufgaben und auf der anderen Seite eine Arm-Migrationsstrategie für breite CPU-Workloads, um strukturell günstiger zu rechnen und Budget für Innovation freizuspielen.

Der Report zeichnet ein Bild in der zwei Wahrheiten gleichzeitig gelten.. Einerseits wächst KI-Compute über GPUs messbar, getragen von frühen Anwendern und steigenden Instance-Hours. Andererseits bleibt Unterauslastung beziehungsweise Over-Provisioning quer über moderne Compute-Dienste der Normalfall.

Wer in den nächsten Jahren Kosten, Skalierbarkeit und Innovationsfähigkeit in Balance halten will, wird deshalb weniger über „die eine“ Cloud-Strategie sprechen können und mehr über die Fähigkeit, Workloads passend zu platzieren, Autoscaling präzise zu betreiben und Hardware-Entscheidungen bewusst je nach Anwendungsfall zu treffen, statt sie dem Standard zu überlassen.

(ID:50709979)