Zeitpläne und Auto-Scaling sind die zwei Wege, berechnete Rechenkapazität dem Bedarf folgen zu lassen statt der Spitze: Ein Zeitplan stoppt Instanzen zu festen Zeiten, in denen niemand sie braucht, und startet sie wieder; Auto-Scaling fügt einer Gruppe gleichartiger Instanzen bei wechselnder Last Instanzen hinzu und entfernt sie, gesteuert über eine Metrik, einen Zeitplan oder eine Vorhersage. Beide senken die Nutzung, nicht den Preis je Stunde. Was sie tatsächlich einsparen, hängt davon ab, was beim Stoppen weiterläuft, wie hoch die Mindestgröße liegt und ob ein Commitment die abgeschalteten Stunden ohnehin bezahlt.
So funktioniert es
Welcher Mechanismus passt, folgt aus der Form der Last und daraus, ob die Instanz einen eigenen Zustand trägt:
| Situation | Mechanismus | Warum |
|---|---|---|
| Einzelne VMs mit Zustand, genutzt nur zu Arbeitszeiten (Entwicklung, Test, interne Werkzeuge) | Zeitplan: stoppen und starten | Platten und Konfiguration bleiben erhalten, die Rechenstunden entfallen |
| Zustandsloser Dienst hinter einem Load Balancer, Last schwankt im Tagesverlauf | Auto-Scaling nach Metrik | Die Zahl der Instanzen folgt der gemessenen Last |
| Wiederkehrende Tages- oder Wochenspitzen, lange Startzeit | Zeitplan- oder vorhersagebasiertes Skalieren | Kapazität steht bereit, bevor die Last kommt |
Zeitpläne
AWS bietet mit Instance Scheduler on AWS eine Lösung, die per CloudFormation im eigenen Konto läuft: Sie stoppt und startet EC2- und RDS-Instanzen anhand von Tags über Lambda, auch über mehrere Konten und Regionen. Die AWS-Dienste, auf denen sie läuft, bezahlt der Kunde; in den Kostenbeispielen von AWS sind das vor allem Lambda, CloudWatch, KMS und DynamoDB. Microsoft bietet für einzelne VMs Auto-Shutdown, eine tägliche Abschaltzeit mit optionaler Benachrichtigung per E-Mail oder Webhook. Start/Stop VMs v2 startet und stoppt VMs über mehrere Subscriptions nach Zeitplänen und wird nach den Diensten abgerechnet, die es bereitstellt; Microsoft führt die Dokumentation inzwischen unter früheren Versionen und hat angekündigt, die Lösung nicht weiterzuentwickeln, außer um ihre Komponenten auf unterstützten Versionen zu halten. Google Cloud kennt Instanzzeitpläne: Sie gelten nur für VMs derselben Region, jede VM folgt höchstens einem Zeitplan, VMs mit Local SSD lassen sich so nicht stoppen, und eine Aktion kann bis zu 15 Minuten nach der geplanten Zeit beginnen.
Gestoppt heißt nicht kostenlos. Für eine gestoppte EC2-Instanz berechnet AWS keine Nutzung, aber die EBS-Volumes und zugeordnete Elastic-IP-Adressen; jeder Start kostet mindestens eine Minute. Azure stellt die Abrechnung der VM erst ein, wenn sie freigegeben ist, angezeigt als „Stopped (deallocated)“; im Zustand „Stopped“, etwa nach einem Herunterfahren im Gastbetriebssystem, läuft die Abrechnung weiter, und Platten und Netzwerk kosten auch nach der Freigabe. Google Cloud berechnet CPU in den Zuständen RUNNING und PENDING_STOP, Arbeitsspeicher zusätzlich in SUSPENDING und SUSPENDED (im angehaltenen Zustand zu einem eigenen Satz für die Speicherung des gesicherten Zustands), Platten und externe IP-Adressen, solange sie existieren. Die vollständige Liste je Dienst steht im Artikel Nicht-Produktionskosten steuern.
Auto-Scaling
Drei Einstellungen entscheiden, wie eng die Rechnung der Last folgt: die Mindestgröße, die rund um die Uhr läuft, die Metrik, die eine Skalierung auslöst, und die Wartezeit nach einer Skalierung, die Kapazität über die Spitze hinaus hält.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Gruppe | Auto Scaling Group mit Minimum, Maximum und gewünschter Kapazität | Virtual Machine Scale Set mit Autoscale-Einstellung, je Profil Minimum, Maximum und Standard, bis zu 20 Profile | verwaltete Instanzgruppe mit Autoscaler, Minimum und Maximum |
| Wartezeit | Cooldown 300 Sekunden als Standard, maßgeblich für einfache Richtlinien; Zielverfolgung und schrittweise Skalierung nutzen eine Aufwärmzeit je Instanz | Cooldown je Regel | Initialisierungszeit 60 Sekunden als Standard; Stabilisierungszeit 10 Minuten vor dem Verkleinern |
| Zeitplan | geplante Aktionen, wiederkehrend, mit Zeitzone | zeitbasierte Profile mit Wiederholung | bis zu 128 Skalierungszeitpläne je Gruppe |
| Vorhersage | ab 24 Stunden Historie, wertet bis zu 14 Tage aus, Prognose für 48 Stunden, nur Vergrößern | ab 7 Tagen Historie, nur CPU, nur Vergrößern | aus der Historie, für tägliche oder wöchentliche Zyklen |
AWS erhebt für EC2 Auto Scaling keine eigene Gebühr, berechnet werden Instanzen, Volumes und CloudWatch-Alarme. Instanzen in einem Warm Pool kosten im Zustand Stopped nur Volumes und Elastic-IP-Adressen; AWS warnt, dass ein unnötiger Warm Pool unnötige Kosten verursacht. Google löscht VMs erst, wenn die verbleibende Kapazität die Spitze der Stabilisierungszeit trägt; Scale-in-Controls begrenzen das Verkleinern zusätzlich.
Was es für Ihre Kosten bedeutet
Ein Zeitplan ändert die Stundenzahl: In den Abrechnungsdaten erscheint dieselbe Instanz mit weniger Stunden, während Platten und Adressen unverändert weiterlaufen. Auto-Scaling macht aus einer festen Größe eine Untergrenze: Die Mindestgröße kostet jede Stunde, alles darüber folgt der Last, verzögert um die Wartezeit. Eine hohe Mindestgröße oder eine lange Stabilisierungszeit ist eine bewusste Entscheidung für Verfügbarkeit, und ihr Preis lässt sich als Stunden über dem Bedarf ablesen.
Commitments rechnen stündlich. Eine Savings-Plans-Verpflichtung gilt nur in ihrer Stunde, eine Azure-Reservierung verfällt für jede Stunde ohne passende Ressource, und Committed Use Discounts kosten unabhängig von der Nutzung. Ein Zeitplan, der reservierte Instanzen abschaltet, senkt deshalb die Auslastung, nicht die Rechnung, solange der Rabatt keine andere passende Nutzung findet. Die Aufteilung folgt daraus: Das Commitment deckt die Mindestgröße und die Stunden, die immer laufen; was skaliert oder geplant abschaltet, bleibt On-Demand oder läuft auf Spot-Kapazität. Bei AWS kann eine Auto Scaling Group On-Demand- und Spot-Instanzen kombinieren, und Reserved Instances oder Savings Plans rabattieren ihren On-Demand-Teil. Wie das Portfolio darauf abgestimmt wird, behandelt Commitment-Strategie.
Wo es schiefgeht
- Gestoppt, nicht freigegeben. Symptom: Eine Azure-VM ist aus, kostet aber weiter Rechenstunden. Ursache: Sie wurde im Gastbetriebssystem heruntergefahren und steht in „Stopped“ statt „Stopped (deallocated)“.
- Zeitplan auf reservierte Instanzen. Symptom: Die Rechenstunden sinken, die Rechnung nicht. Ursache: Das Commitment wird stündlich berechnet, und die freien Stunden finden keine andere passende Nutzung.
- Gestoppte Instanz in einer Auto Scaling Group. Symptom: Nach dem geplanten Stopp läuft eine neue Instanz. Ursache: EC2 Auto Scaling betrachtet jede Instanz außerhalb von
runningals fehlerhaft und ersetzt sie. - Mindestgröße gleich Spitze. Symptom: Auto-Scaling ist eingerichtet, die Instanzstunden bleiben flach. Ursache: Minimum und Maximum liegen beieinander, oder das Minimum wurde für die Spitze gewählt.
- Verkleinern bleibt aus. Symptom: Nach einer Lastspitze bleibt die Gruppe lange groß. Ursache: Cooldown, Stabilisierungszeit oder Scale-in-Controls halten die Kapazität, oder die Metrik fällt nicht unter den Zielwert.
- Start zu spät. Symptom: Montags früh sind Dienste nicht erreichbar. Ursache: Google-Instanzzeitpläne können bis zu 15 Minuten verspätet starten; Google rät, 15 Minuten früher zu planen.
Beispiel
Eine Instanz mit dem Stundenpreis P läuft statt 168 Stunden pro Woche nur H Stunden; S sind die Wochenkosten ihrer Volumes und Adressen. Ohne Commitment sinken die Wochenkosten von P × 168 + S auf P × H + S, die Einsparung ist P × (168 − H). AWS rechnet in der Beschreibung des Instance Scheduler mit H = 50 und nennt dafür bis zu 70 % Einsparung für Instanzen, die nur zu Geschäftszeiten gebraucht werden; 50 von 168 Stunden sind rund 30 % der Laufzeit. Deckt eine Reservierung mit dem Stundensatz R die Instanz, kostet die Woche R × 168 + S, ob die Instanz läuft oder nicht: Die Einsparung ist null, bis der Rabatt andere Nutzung findet. Von der Einsparung gehen die Betriebskosten des Schedulers selbst ab.
Quellen
Gelesen am 2026-10-16. AWS Instance Scheduler on AWS: Überblick und Kosten, Instanzen stoppen und starten, Wie Stoppen und Starten funktioniert, Was ist Amazon EC2 Auto Scaling?, Zustandsprüfungen für Auto-Scaling-Instanzen, Auto Scaling Groups mit mehreren Instanztypen und Kaufoptionen, Scaling Cooldowns, Geplantes Skalieren, Wie Predictive Scaling funktioniert, Warm Pools und Wie Savings Plans angewendet werden; Microsoft Zustände und Abrechnungsstatus von Azure-VMs, Auto-Shutdown einer VM, az vm auto-shutdown in der Azure-CLI-Referenz, Start/Stop VMs v2, Autoscale in Azure Monitor, Autoscale-Einstellungen verstehen, Predictive Autoscale und Wie ein Reservierungsrabatt angewendet wird; Google Cloud Instanzzeitpläne, Lebenszyklus einer Compute-Instanz, Compute-Instanzen anhalten, stoppen oder zurücksetzen, Autoscaling von Instanzgruppen und Committed Use Discounts.