Die Möglichkeit zur Entwicklung elastischer Systeme stellt eine der entscheidenden Eigenschaften von Cloudplattformen wie AWS dar. Derartige Systeme sind in der Lage, die von ihnen genutzten Ressourcen flexibel, basierend auf der aktuellen Auslastung, zu erweitern oder zu verringern. Eine solche automatisierte Skalierung von Ressourcen bringt verschiedene Vorteile mit sich. So lässt sich die Leistung eines Systems auch unter Einfluss von Bedarfsspitzen konstant aufrechterhalten und die Fehlertoleranz steigern, indem beschädigte und fehlerhafte Ressourcen wie virtuelle Server oder Anwendungen automatisiert erkannt und ersetzt werden.

Ein zentraler Vorteil ist dabei das Potenzial für Kostenoptimierung, denn durch eine kontinuierliche Anpassung der in Anspruch genommenen Ressourcen an den tatsächlichen Bedarf vermeiden IT-Verantwortliche die Überprovisionierung eines Systems.

Eine Vielzahl von Workload-Typen profitiert von diesen Vorteilen. So kann ein Webshop während des Weihnachtsgeschäfts temporär die genutzten Server- und Datenbankressourcen erhöhen, um das gesteigerte Transaktionsvolumen abzufangen. Nachrichtenportale können im Falle von wichtigen Eilmeldungen agil und kurzfristig Ressourcen bereitstellen, um Lastspitzen abzufangen. Eine Streaming-Plattform skaliert vorausschauend zur Veröffentlichung eines neuen Films die Kapazität, um den initialen Zuschau-erandrang zu bedienen und ein reibungsloses Erlebnis zu bieten.

Amazon Web Services stellt eine Reihe von Werkzeugen zur Verfügung, die die Entwicklung einer elastischen und skalierbaren Umgebung ermöglichen. Der Service Auto Scaling ermöglicht es dabei dank vorgefertigter Richtlinien, schnell und einfach eine Skalierung über mehrere Ressourcentypen und AWS-Dienste hinweg aufzusetzen. So lässt sich damit beispielsweise ein einheitliches Skalierungsverhalten für eine Gesamtanwendung bestehend aus EC2-Instanzen und einer Aurora-Datenbank konfigurieren.

Für eine präzisere Einflussnahme auf das Verhalten von Ressourcen und zur separaten Verwaltung des Skalierungsverhaltens verschiedener Ressourcentypen kann diese Automatisierung auch auf der Ebene einzelner AWS-Services verwaltet werden. Speziell für Instanzen, die eine Kernkomponente einer Vielzahl von Cloudarchitekturen auf AWS darstellen, kommt Amazon EC2 Auto Scaling zum Einsatz.

Mit Auto Scaling lässt sich die Verfügbarkeit einer Anwendung verbessern, EC2-Instanzen lassen sich automatisiert hinzufügen und entfernen sowie Kosten einsparen, indem eine Überprovisionierung von Ressourcen vermieden wird. Für den Dienst selbst fallen keine zusätzlichen Kosten an. Lediglich die dabei verwendeten unterliegenden Ressourcen wie EC2-Instanzen schlagen zu Buche.

Grundlage für die Nutzung von EC2 Auto Scaling sind Auto-Scaling-Gruppen (ASGs). Eine ASG stellt eine logische Gruppierung von Amazon-EC2-Instanzen dar, die das gemeinsame automatisierte Verwalten und Skalieren zum Zweck hat. Sie bietet damit die Grundlage für Funktionen wie den Austausch defekter Instanzen und von Skalierungsrichtlinien. Die Größe der ASG hängt initial von der Anzahl von Instanzen ab, die als gewünschte Kapazität konfiguriert wird. Initial startet eine ASG Instanzen, bis die gewünschte Kapazität erreicht ist. Die ASG führt periodische Zustandsprüfungen (Health Checks) durch und tauscht fehlerhafte Instanzen selbstständig durch neue aus, um die gewünschte Kapazität aufrecht zu erhalten. Ausgehend davon lässt sich die Größe der Gruppe manuell oder automatisiert durch die Definition von Skalierungsrichtlinien an den aktuellen Bedarf anpassen.

Zum Start einer neuen Instanz im Rahmen einer Skalierungsaktion nutzt die ASG eine benutzerdefinierte EC2-Startvorlage (Launch Template). Diese spezifiziert Eigenschaften der zu startenden Instanzen wie das zu nutzende Amazon Machine Image (AMI), den Instanztyp, zulässige SSH-Schlüsselpaare, Netzwerkeinstellungen, Festplattenkonfiguration und mehr. Die auf der Instanz auszuführende Software ist entweder bereits im AMI enthalten oder wird im Laufe des Startprozesses dynamisch über Skripts geladen und installiert.

Um eingehenden Anwendungsdatenverkehr automatisiert auf mehrere Instanzen innerhalb einer ASG zu verteilen, kommt Elastic Load Balancing zum Einsatz. Das Anfügen eines Loadbalancers an die ASG definiert diesen als Kontaktpunkt für die ASG. Instanzen innerhalb der ASG werden automatisiert am Loadbalancer registriert und können Traffic erhalten. Gleichermaßen werden beendete Instanzen deregistriert und erhalten keinen weiteren Datenverkehr. Neben der ASG kann auch Elastic Load Balancing Zustandsprüfungen durchführen und basierend auf deren Ergebnis fehlerhafte Instanzen entfernen und erneuern lassen.

ASGs können sich über mehrere Availability Zones (AZ) erstrecken und somit die Sicherheit und Zuverlässigkeit geografischer Redundanz nutzen, um die Fehlertoleranz einer Anwendung zu steigern. Bei AZs handelt es sich um isolierte Standorte innerhalb einer AWS-Region, deren Autonomie durch eine separate Stromversorgung, eine eigene Netzwerkanbindung und weitere Sicherheitsvorkehrungen sichergestellt ist.

Eine ASG kann beispielsweise so konfiguriert sein, dass stets Instanzen in mindestens zwei AZs verfügbar sind. In Verbindung mit einem Loadbalancer lässt sich nun auch im Fall einer Störung einer der AZs der Betrieb der Anwendung sicherstellen, indem neue Instanzen in einer AZ hochfahren, die nicht vom Ausfall betroffen ist.

Neben der Aufrechterhaltung der gewünschten Kapazität können Admins Skalierungsrichtlinien verwenden, um die Größe der ASG im Falle von Bedarfsveränderungen dynamisch zu erhöhen oder zu verringern. Zusätzlich zur gewünschten Kapazität lässt sich in diesem Fall eine minimale sowie eine maximale Kapazität definieren, die die ASG nicht unter- beziehungsweise überschreitet.

Eingeleitet wird jeder Skalierungsvorgang von einem Ereignis, das die Auto-Scaling-Gruppe anweist, entweder Instanzen zu starten oder zu terminieren. EC2 Auto Scaling bietet verschiedene Optionen, die Größe einer ASG zu beeinflussen. Ein manuelles Skalieren durch die Anpassung der gewünschten minimalen und maximalen Kapazität der ASG stellt dabei die einfachste Option dar.

Für Workloads mit präzise vorhersehbaren Bedarfsmustern ist zudem die Nutzung eines Zeitplans möglich. In diesem Fall hängt die Kapazität der ASG von einem wiederkehrenden Zeitplan mit Datum und Uhrzeit ab.

Die dynamische Skalierung stellt eine konfigurierbare Skalierungsoption dar, die die Größe der ASG flexibel basierend auf dem aktuellen Bedarf anpasst. Der aktuelle Bedarf leitet sich dabei von durch AWS bereitgestellten oder benutzerdefinierten Metriken ab. Zu den vom Anbieter bereitgestellten Metriken gehören beispielsweise die durchschnittliche CPU-Auslastung der Instanzen in der ASG, der durchschnittliche Netzwerkeingang und -ausgang in Bytes oder die Anzahl der Anfragen an einen Application Loadbalancer. Zur Erfassung dieser Metriken nutzt EC2 Auto Scaling den Überwachungs- und Beo-bachtungsservice CloudWatch.

EC2 Auto Scaling unterstützt drei dynamische Skalierungsrichtlinien: Zielnachverfolgung (Target Tracking), schrittweise Skalierung (Step Scaling) und einfache Skalierung (Simple Scaling).

Mit der Zielnachverfolgung lässt sich die Kapazität der ASG auf Grundlage eines Zielwerts für eine bestimmte Metrik erhöhen oder verringern. Dies ähnelt der Art und Weise, wie ein Thermostat die Temperatur in einem Haus konstant hält – eine Temperatur wird eingestellt und der Thermostat erledigt den Rest. Beispielsweise ließe sich ein Zielwert von 40 Prozent für die durchschnittliche aggregierte CPU-Auslastung der Instanzen in einer ASG festlegen. Wird dieser Wert durch steigenden Bedarf überschritten, startet die ASG automatisch neue Instanzen, bis der Durchschnitt wieder bei oder nahe des Zielwerts von 40 Prozent liegt. Sinkt der Bedarf, werden entsprechend Instanzen entfernt. Die Zielnachverfolgung empfiehlt sich also für Metriken, die sinken, wenn die Kapazität der ASG erhöht wird, und steigen, wenn sich die Kapazität verringert. Eine benutzerdefinierte Metrik sollte ebenfalls die direkte Auslastung der Instanzen abbilden und sich (wie auch beispielsweise die CPU-Auslastung) proportional zur Anzahl der Instanzkapazität verhalten.

Die einfache und schrittweise Skalierung nutzen CloudWatch-Alarmereignisse, um Aktionen auszulösen. Im Fall der einfachen Skalierung verändert sich die Kapazität der ASG basierend auf einem Alarmereignis. Exemplarisch lässt sich ein Alarmereignis so konfigurieren, dass es bei der Überschreitung der durchschnittlichen CPU-Auslastung der ASG von 60 Prozent für einen Zeitraum von fünf Minuten ausgelöst wird.

Die einfache Skalierung kann nun festlegen, dass sich beim Auftreten dieses Alarmereignisses die Kapazität der ASG um zwei Instanzen erhöht. Steigt die durchschnittliche CPU-Auslastung nach diesem Ereignis weiter an, kommt es im Fall der einfachen Skalierung zu keiner weiteren Aktion. Für das Herunterskalieren der ASG muss der Administrator einen weiteren CloudWatch-Alarm und eine entsprechende einfache Skalierung konfigurieren.

Auch mit der schrittweisen Skalierung lässt sich die Automatisierung über CloudWatch-Alarmereignisse steuern. Gegenüber der einfachen Skalierung sind allerdings mit einer einzigen Richtlinie mehrere Schritte definierbar, die abhängig von der Höhe des Alarmwertes zum Tragen kommen. Exemplarisch lässt sich festlegen, dass bei einer durchschnittlichen CPU-Auslastung der ASG zwischen 60 und 70 Prozent eine EC2-Instanz, bei einer Auslastung zwischen 70 und 80 Prozent zwei EC2-Instanzen und bei einer Auslastung über 80 Prozent drei Instanzen zur ASG hinzukommen. Ein entsprechender Alarm und eine passende Richtlinie greifen ebenso für das Herunterskalieren.

Grundsätzlich stellt die dynamische Skalierung eine Reaktion auf veränderte Metriken dar. Um die Geschwindigkeit der Automatisierung weiter zu verbessern, lässt sich dieser reaktive Ansatz mit einer vorausdenkenden Skalierung kombinieren, die darauf abzielt bereits vor Eintritt eines Lastereignisses zusätzliche Ressourcen bereitzustellen. Hierfür analysiert Auto Scaling die Auslastung der ASG, trifft basierend auf einem Machine-Learning-Modell eine Auslastungsprognose und legt ein entsprechendes Skalierungsverhalten fest. Die vorausdenkende Anpassung eignet sich insbesondere für Anwendungen mit wiederkehrenden Bedarfsmustern, für die keine manuelle Auslastungsanalyse möglich ist.

EC2 Auto Scaling macht es einfach, neben On-Demand-Instances auch Spot-Instanzen flexibel in eine ASG einzubinden, wodurch sich Kosten einsparen lassen. Mit Spot-Instanzen sind nicht genutzte EC2-Kapazitäten in der AWS-Cloud mit bis zu 90 Prozent Rabatt im Vergleich zum On-Demand-Preis abrufbar.

Spot-Instanzen sind in ihren Eigenschaften und ihrer Performance identisch zu On-Demand-Instanzen. AWS behält sich jedoch vor, mit einer Vorlaufzeit von mindestens zwei Minuten einen Anspruch auf eine Spot-Instanzen zu erheben und diese zu terminieren.

Spot-Instanzen eignen sich damit insbesondere für fehlertolerante und zustandslose Workloads, die flexibel auf verschiedenen Instanztypen laufen können. Dies umfasst etwa Batchdatenverarbeitung, Container-Workloads, Webanwendungen, Buildserver im Kontext von CI/CD Pipelines oder Big-Data-Anwendungen.

AWS bietet für EC2 diverse Instanzfamilien und -typen, die sich in einer ASG flexibel kombinieren lassen. In der Regel ist eine Workload mit mehreren Instanzfamilien und -typen kompatibel. Um optimal von Spot-Instanzen zu profitieren, empfiehlt es sich, mehrere Instanzfamilien und -typen als zulässig für die ASG auszuwählen. Damit steigt die Wahrscheinlichkeit, dass Spot-Instanzen verfügbar und in großer Zahl vorhanden sind. Dies senkt wiederum die Wahrscheinlichkeit einer Rückforderung der Spot-Instanzen durch AWS.

Die aktuell zur Verfügung stehenden ungenutzten Instanzen eines Typs (beispielsweise m5.large) innerhalb einer AZ (etwa eu-central-1) werden als Spot-Instance-Pool bezeichnet.

Um Spot-Instanzen in einer ASG zu nutzen, lässt sich die prozentuale Instanz-Verteilung aus On-Demand- und Spot-Instanzen zum Start festlegen. Zusätzlich zu dieser Verteilung ist eine On-Demand-Basiskapazität konfigurierbar, die in jedem Fall vorgehalten wird.

ASGs unterstützen zwei Spot-Zuweisungsstrategien, die festlegen, welche der als zulässig ausgewählten Spot-Instanztypen die ASG starten soll. Mit der Strategie "kapazitätsoptimiert (capacity-opimized)" startet die ASG mit hoher Priorität Instanzen mit einem Typ, der aktuell über eine hohe Spot-Kapazität in der AWS-Cloud verfügt. Darauf aufbauend bezieht die ASG mit der "Strategie Instanztypen priorisieren (capacity-optimized-prioritized)" neben der verfügbaren Spot-Kapazität auch die festgelegte Prioritätsreihenfolge bei der Auswahl der zu startenden Instanztypen mit ein. Mit der Strategie "Niedrigster Preis (lowest-price)" wählt die ASG immer die günstigsten Instanzfamilien und -typen aus, ohne die aktuelle Spot-Kapazität in Betracht zu ziehen.

Das Konfigurationsbeispiel im Kasten zeigt den Start einer ASG mit dem Namen "my-asg" via der Auto-Scaling-API. Für die ASG ist eine gewünschte Kapazität von 4 (DesiredCapacity), minimale Kapazität von 2 (MinSize) und maximale Kapazität von 8 (MaxSize) definiert. Die "MixedInstancesPolicy" legt eine Zusammensetzung sowohl aus On-Demand- sowie Spot-Instanzen fest. Zulässige Instanzfamilien und -typen für diese ASG sind "c5.large", "c5a.large", "m5.large" und "m5a.large".

Die "InstanceDistribution" beschreibt die Instanzverteilung in Bezug auf Spot- und On-Demand-Instanzen. Mit der "OnDemandBaseCapacity" lässt sich eine Mindestanzahl von On-Demand-Instanzen, die im Falle einer Skalierung zuerst starten, für die ASG definieren. Im vorliegenden Beispiel gibt es keine OnDemandBaseCapacity. Dies hat zur Folge, dass die ASG durch die "OnDemandPercentage­AboveBaseCapacity" von 50 stets darauf abzielt, eine gleichmäßige Verteilung von On-Demand- und Spot-Instanzen aufrechtzuerhalten. Durch die "SpotAllocationStrategy" namens "lowest-price" wählt die ASG für den Start einer neuen Spot-Instanz stets den Spot-Instance-Pool des aktuell günstigsten Instantypen aus.

Auto Scaling hilft als mächtiges Werkzeug dabei, die Leistungsfähigkeit eines Systems auch während Bedarfsspitzen aufrechtzuerhalten. Es steigert die Fehlertoleranz, indem es problematische Ressourcen wie fehlerhafte virtuelle Server oder Anwendungen automatisiert erkennt und ersetzt. Durch die automatisierte Anpassung der genutzten Ressourcen und damit die Vermeidung einer Überprovisionierung sowie die flexible Integration von Spot-Instanzen ist zudem das Potenzial für Kosteneinsparungen gegeben.