Cloud-Ressourcen stundenweise mieten

Es dürfte der Albtraum jedes Entwicklers sein: Ein US-Medium erwähnt um drei Uhr nachts den hauseigenen Service, woraufhin die Zugriffszahlen raketenartig in den Himmel schießen. Leider ist der Administrator der Server-Farm nicht erreichbar, außerdem gibt es im Rechenzentrum sowieso nur noch wenig verfügbare Kapazität.

Wer seine Ressourcen aus der Cloud bezieht, bezahlt unterm Strich sicher mehr als beim Kauf. In der Industrie kursiert die Faustregel, dass man nach dem einjährigen Mieten einer Ressource diese auch kaufen kann. Auf der Haben-Seite der Cloud-Lösung steht, dass man komplett flexibel ist: Braucht man zu einem gewissen Zeitpunkt nur wenige Ressourcen, so kann man unbenötigte Instanzen zurückgeben. Die Arbeit in der Cloud setzt jedoch ganz unterschiedliche architekturale Konzepte vo­raus, die wir näher vorstellen wollen.

Das universelle Gesetz von Cloud-Ressourcen lautet: Jede Ressource, die in der Cloud lebt, muss als vergänglich betrachtet werden. Permanent ist nur die Infrastruktur selbst. Amazon-Vertreter erklären etwa, dass es sich nicht lohnt, in ein Problem viel Aufwand zu investieren, das durch einen Reboot der Ressource problemlos behoben werden kann.

Dieses Vorgehen bewirkt Unterschiede bei der Abbildung von Strukturen aus dem gewöhnlichen Bereich in die AWS-Domäne. Statt physikalischer Server kommen in der Amazon-Welt als EC2 bezeichnete Instanzen zum Einsatz. Es handelt sich um virtuelle Maschinen, die sich im AWS-Backend ohne großen Aufwand erzeugen und wieder herunterfahren lassen. Sicherheitsbewusste Entwickler können anweisen, dass ihre VMs auf einer exklusiv genutzten Maschine laufen müssen. Dann entstehen allerdings empfindliche Zusatzkosten.

Aus der Vergänglichkeit dieser Maschinen folgt, dass der Aufbau der Speicherstruktur komplett unterschiedlich ist. Während man in einem gewöhnlichen Enterprise-Deployment oftmals davon ausgeht, dass die auf Festplatte oder SSD gespeicherten Daten zumindest eine gewisse Zeit lang überleben, ist in der AWS-Welt die Veränderung ständiger Partner. Daraus folgt, dass man für die Ewigkeit vorgesehene Informationen in separaten Speicherdiensten ablegt. Dazu bietet Amazon eine Vielzahl verschiedener Storage-Backends an, denen wir uns weiter unten zuwenden.

Vorher wollen wir einen Blick auf die geografische Verteilung der Ressourcen werfen. Denken Sie daran, dass Latenzen auch in Zeiten immer schnellerer Verbindungen ein Thema sind. Bis ein Paket aus den USA nach Australien gelangt ist, vergeht Zeit. Die Lösung ist, die Infrastruktur nahe zum Kunden zu bringen.

Als oberstes Hierarchieelement dient die Region, die die geografische Lokalisierung festlegt. Der String auf der linken Seite beschreibt den Namen, unter dem die jeweilige Region im Backend bekannt ist, rechts steht der geografische Ort.

Innerhalb der einzelnen Regionen findet sich eine Amazon-spezifische Konstruktion, die als Availability Zone (AZ) bezeichnet wird. Es sind redundante Zonen innerhalb einer Region, die über ein Hochgeschwindigkeitsnetz miteinander verbunden, sonst aber voneinander unabhängig sind. In der Praxis kann es sinnvoll sein, zusammengehörende Ressourcen in einer AZ unterzubringen, um die Latenzen zu reduzieren. Manche Dienste belegt Amazon mit Einschränkungen, die die Verteilung der Komponenten in verschiedene AZs oder Regionen unterbinden. Die Anzahl der AZs pro Region ist unterschiedlich. Amazon verspricht, in jeder Region mindestens zwei Verfügbarkeitszonen zu betreiben.

Zu guter Letzt gibt es als Edge Locations bezeichnete Standorte. Zu Redaktionsschluss waren es 149. Es handelt sich um Tore, an denen sich die AWS-Infrastruktur mit dem öffentlichen Internet verbindet. An diesen Stellen betreten oder verlassen Daten den Amazon-spezifischen Teil des Netzes.

---

Nachdem wir nun wissen, wo wir unsere Ressourcen verorten, müssen wir uns mit der Bereitstellung von Rechenleistung in der Elastic Compute Cloud auseinandersetzen. Eine EC2-Maschine ist eine virtuelle Maschine, die irgendwo im privaten AWS-Netz von Amazon steht. Amazon erweist sich insofern als flexibel, als man sowohl Windows wie Linux als Betriebssystem einsetzen kann.

Amazon empfiehlt, jede angelegte AWS-Ressource mit einem sprechenden und suchbaren Tag auszustatten, da es immens schwer ist, in einem großen Deployment Ressourcen wiederzufinden. EC2 kennt Dutzende verschiedener Instanzen. Wichtig ist, dass die Instanzen von Amazon grob in fünf Nutzungskategorien unterteilt werden: Die für die allgemeine Nutzung vorgesehenen Instanzen sind am preiswertesten; besonders interessant sind hierbei die T2-Instanzen, die bei Bedarf kurzfristig mehr Rechenleistung bekommen können. Im Feld „Accelerated Computing“ findet man bei Amazon die G3-Instanzen, die neben den überall verwendeten Intel-Xeon-Prozessoren zusätzlich Tesla-Grafikbeschleuniger von Nvidia mitbringen.

Auch wenn es über AWS-EC2-In­stanzen noch einiges zu sagen gäbe, wollen wir mit der Konfiguration eines Beispiels beginnen. Die Konzepte werden am lebenden Objekt wesentlich schneller verständlich. Rufen Sie die Administrationskonsole unter https://aws.amazon.com auf und loggen Sie sich mit Ihrem - oder einem neu angelegten - Amazon-Account ein. Wer sich erstmals für AWS anmeldet, bekommt eine Vielzahl von Ressourcen innerhalb einer einjährigen Testphase zur Verfügung gestellt, die sich mit Hilfe einer kooperativen Bank strecken lässt: Lassen Sie sich einfach eine neue Kreditkarte ausstellen und melden Sie damit einen weiteren Account an. Alternativ muss man bezahlen - für die folgenden Schritte dürften keine nennenswerten Kosten anfallen.

Klicken Sie auf „Services“, „Compute“ und „EC2“, um das EC2-Dashboard auf den Bildschirm zu holen. Der blaue Button „Launch Instance“ öffnet das Auswahlmenü, in dem Sie als AMI bezeichnete Basis-Images auswählen. Wir entscheiden uns für .NET Core with Ubuntu Server 16.04 – Version 1.0. Für Spezialaufgaben wie Deep Learning gibt es extra Images.

Amazon bietet nach der Auswahl eines AMIs verschiedene Instanzen an. Wählen Sie „t2.micro“ und klicken Sie auf „Next: Configure Instance Details“. Die Möglichkeit, einen Schnellstart durch „Review and Launch“ zu befehlen, würde uns didaktisch interessante Parameter vorenthalten. Die Checkbox „Request Spot instances“ erlaubt das Aktivieren des Spot-Beschaffers. Amazon optimiert die Ressourcen-Auslastung, indem es das Bieten auf brachliegende Instanzen ermöglicht. Entwickler legen den Maximalpreis pro Instanz fest, Amazon teilt dann nach Bedarf Maschinen zu. Wichtig ist, dass die VM nur so lange zur Verfügung steht, bis sie besser verkauft werden kann. In diesem Fall bekommen Sie ein Signal, die Instanz wird danach binnen zwei Minuten ter­miniert.

Die Zuweisung von Subnet und Co. darf übernommen werden. Danach wählen Sie das Speichermedium aus und weisen ein Tag zu. Im Interesse der Sicherheit sollten Sie in der Security Group den Zugriff auf die VM beschränken. Klicken Sie in der Source-Combobox die Option „My IP“ an, um die IP der aktiven Workstation ins Textfeld zu übernehmen. Nach dem Abnicken der Übersichtsseite folgt ein Klick auf „Launch“, um den eigentlichen Startprozess zu befehligen.

Aus Sicherheitsgründen arbeiten EC2-Instanzen nicht mit vorgefertigen Passwörtern. Das Ausweisen bei der VM erfolgt stattdessen mit einem Schlüsselpaar, zu dessen Anlegen Sie aufgefordert werden. Beim erstmaligen Erzeugen einer EC2-Instanz wählen Sie die Option „Create a new key pair“ aus und vergeben einen Namen. Der Button „Download Key Pair“ erlaubt das einmalige Herunterladen einer PEM-Datei. Diese lässt sich später nicht nochmals beschaffen. Nach dem einige Sekunden dauernden Startprozess finden Sie sich in einer Übersichtsseite wieder, in der die neue VM durch eine nach dem Schema
i-09f1f4639938a250d aufgebaute ID aufgelistet ist. Klicken Sie diese an, um Detailinformationen zu laden. Von besonderer Wichtigkeit ist der im Feld „Public DNS“ eingegebene String, der nach dem Schema ec2-54-235-15-230.compute-1.amazonaws.com aufgebaut ist.

Für den eigentlichen Verbindungsaufbau ist die PEM-Datei erforderlich, die mittels CHMOD mit stark eingeschränkten Rechten ausgestattet sein muss. Erst danach wird sie von SSH akzeptiert.

Die folgende Befehlssequenz liefert eine Shell zurück, die in die neue VM eingeloggt ist:

Kritisch ist der Benutzername, da er von AMI zu AMI unterschiedlich ist. Der Kasten „Nutzernamen bei AWS“ auf Seite 91 zeigt einige häufige User-Namen, die man in der AWS-Praxis immer wieder antrifft.

An dieser Stelle ist unsere EC2-Instanz eine Linux-Box wie jede andere. Sie unterscheidet sich von einem Prozessrechner nur insofern, als sie auf die Hardware nicht physikalisch zugreifen kann. Im Rahmen des erstmaligen Bootens der VM arbeitet Amazon als User Data bezeichnete Parameter ab. Diese können in Form eines Shell-Skripts oder als Cloud-Init-Befehle vorliegen. Informationen zu den beiden Vorgehensweisen finden sich unter https://docs.aws.amazon.com/AWS
EC2/latest/UserGuide/user-data.html. Zur Laufzeit stehen diese Infos unter http://169.254.169.254/latest/ bereit, wo sie mit CURL oder einer gewöhnlichen HTTP-Transaktion abgerufen werden können.

Ein weiterer interessanter Aspekt ist das Metadatensystem, das Informationen zur Selbstreflektion bereitstellt. Auf unserer soeben neu angeworfenen EC2-VM würde sich das Stammverzeichnis beispielsweise so präsentieren:

 

Wer zur Laufzeit den öffentlichen Hostnamen der VM erfahren will, vertraut auf CURL:

 

Bei der Arbeit mit der Kommandozeile beziehungsweise mit einem SSH-Fenster ist die seltsame Platzierung des nächsten Prompts auffällig. Amazon terminiert die im Metadatensystem liegenden Strings nicht mit einem Carriage Return, um das Abernten mit Skripts zu erleichtern.

Zur Demonstration der Persistenz bietet es sich an, im ersten Schritt eine Datei anzulegen und danach einen Neustart der virtuellen Maschine anzuweisen. Danach, also nach dem abermaligen Aufbauen einer SSH-Verbindung zum Host, ist die Datei nach wie vor am Platz:

 

 

Dieses Verhalten erschließt sich, wenn man den Lebens­zyklus der Instanz näher betrachtet. Eine EC2-Instanz kennt zwei Arten der Ruhe. Erstens kennt sie den Stop-Zustand, wenn wir sie mit shutdown -h herunterfahren. In diesem Zustand verbraucht die EC2-VM zwar keine Rechenleistung und verursacht so auch keine Mietkosten, die in S3 bereitliegenden Speicherzellen für das Dateisystem bleiben allerdings erhalten. Daraus folgt, dass Speicherkosten anfallen. Im Zustand zwei, der sich erreichen lässt, indem man die virtuelle Maschine im Backend rechts anklickt, ist die virtuelle Maschine zerstört. Dann würde die weiter oben angelegte Datei gelöscht werden, sodass keinerlei S3-Kosten mehr anfallen.

Bevor Sie dies tun, werfen Sie einen Blick auf das kleine Glockensymbol in Alarm-Status. Es öffnet ein Fenster, in dem Sie Alarmbedingungen für den Monitor festlegen können. Das Backend kann Sie so beispielsweise darüber informieren, wenn die CPU der virtuellen Maschine zu sehr ausgelastet ist.

Die Inhalte der AWS-Konsole aktualisieren sich nicht automatisch. Wenn Sie die Speicherliste in einem Tab öffnen und Sie im anderen Tab die dazugehörige EC2-Instanz terminieren, verschwindet das schon gelöschte Volume erst nach manueller Aktualisierung aus der Liste.

---

Das Betreiben vollwertiger Server ist oft Overkill. Denken Sie an Aufgaben, in denen eingehende Informationen nur an andere Dienste weitergeleitet werden. In diesem Fall schlägt die Stunde eines als Lambda bezeichneten Features: eine in der Cloud gehostete Ausführungsumgebung, die „Funktionen“ bei Auftreten eines Trigger-Ereignisses ausführt, ohne im Hintergrund eine virtuelle Maschine anzuwerfen.

Derzeit können Sie die für Lambda vorgesehenen Funk­tionen in einer Gruppe verschiedener Programmiersprachen erstellen: C# (.NET Core), Go, Java (Java 8), Node.js (Java­Script) und Python.

Im nächsten Schritt erfolgt das Generieren der Funktion. Hierbei ist es empfehlenswert, auf Amazons hauseigene Erweiterungen für die Eclipse-IDE zurückzugreifen, die das komfortable Generieren ermöglichen. Ein grundlegendes Projektskelett würde folgendermaßen aussehen:

 

Zum erfolgreichen Fertigstellen der Lambda-Funktion müssen Sie diese im Editor hochladen und im Backend mit einer Aktivierungs-Rolle ausstatten.

In der Praxis ist das primäre Problem beim Umgang mit Lambda nicht das Erzeugen der Logik, sondern das erstmalige Einarbeiten des Workflows.

Während EC2-Instanzen einen lokalen Speicher mitbringen, in dem Sie das Ergebnis Ihrer Arbeit ablegen können, ist eine Lambda-Funktion definitionsgemäß heimatlos. Amazon stellt eine Gruppe von Speicherverfahren bereit, einerseits Datenbanken, andererseits block- und objektorientierte Speicher.

Beginnen wollen wir mit S3, dem ältesten AWS-Dienst, der von Amazon seit Jahren unverändert angeboten wird. Der Simple Storage Service wird als Speichersystem für das Internet betrachtet. Daraus folgt, dass es keine Möglichkeit zum blockbasierten Zugriff gibt; ein S3-Speicher lässt sich also nicht wie ein gewöhnlicher Festwertspeicher mounten und mit einem beliebigen Dateisystem wie NTFS oder EXT4 versehen. Stattdessen implementiert Amazon ein ungewohnt aussehendes Schema (siehe Bild unten).

Im S3-Account finden sich als Bucket bezeichnete Strukturen, die der Verwaltung der Informationen dienen. Buckets erlauben das Zuweisen von Lese-, Schreib- und sonstigen Berechtigungen auf globaler Ebene. Da Sie pro AWS-Account bis zu hundert Buckets haben können, bietet es sich an, jeder Applikation einen Bucket zuzuweisen. Dies ist auch in Bezug auf die Abrechnung von Vorteil, da Sie so leicht feststellen können, welches Programm für wie viel Prozent Ihrer Kosten verantwortlich zeichnet.

Eine Besonderheit ist: Alle Buckets sind öffentlich und stellen ihre Inhalte unter http://<bucketname>.s3.amazonaws.com/<key> zum Zugriff bereit. Diese Öffentlichkeit ist insofern kritisch, als der für den Bucket gewählte Name weltweit einzigartig sein muss, selbst dann, wenn man über die Access Control List (ACL) ausschließlich angemeldete Benutzer freigibt.

In den Buckets finden sich als Object bezeichnete Unterfelder, die die eigentlichen Informationen bereitstellen. Jedes Element darf bis zu 5 Terabyte Speicherplatz in Anspruch nehmen; der Zugriff erfolgt über die genannten URLs.

Bemerkenswert an S3 ist die Versionierung. Wenn man die Funktion aktiviert, so legt der Bucket bei jedem Upload oder Löschvorgang eine neue Version an. Auf diese Art und Weise sind Sie vor Überschreiben und Löschen geschützt, allerdings zu wesentlich höheren Betriebskosten. Die Versionen werden nacheinander verrechnet. Laden Sie zehn Versionen eines 4 GByte großen Images hoch, so dürfen Sie unterm Strich für insgesamt 40 GByte bezahlen.

Apropos Kosten: Die pro Monat anfallenden Gebühren sind nicht nur von ihrem absoluten Speicherverbrauch, sondern auch von der ausgewählten Zuverlässigkeitsklasse abhängig. Da eine vollständige Besprechung der Preise - sie sind unter anderem von der Region abhängig.

Zur Langzeitarchivierung bietet Amazon mit Glacier einen Spezial-Speicher an. In manchen Regionen fällt pro Gigabyte nur ein Dollarcent pro Monat an. Der Nachteil ist, dass der Zugriff auf in Glacier befindliche Infos zwischen drei und fünf Stunden in Anspruch nimmt. Beachten Sie zudem, dass das Verschieben von Informationen in den Infrequent-Access-Bereich keine Universallösung ist. Greift man auf dort befindliche Infos zu, so verrechnet Amazon Transferspesen, die die gesparte Monatsmiete für den eigentlichen Speicherplatz in vielen Fällen sehr schnell auffressen.

Amazon garantiert keine hundertprozentige Sicherheit, sondern setzt in Sachen Haftung auf ein als Shared Responsibility bezeichnetes Konzept: Amazon haftet für die Verfügbarkeit der Cloud als Ganzes, der Kunde ist für die Sicherheit der Informationen verantwortlich, die von ihm in die Cloud übertragen werden.

Von besonderem Interesse ist für diese Fragen das SLA unter https://aws.amazon.com/s3/sla. Eine kurze Recherche ergab, dass es mit S3 in der Praxis bisher keine größeren Datenverluste gab. Angesichts der immensen Menge von in AWS gehaltenen Informationen gab es allerdings sicher den einen oder anderen Kandidaten. Es ist immer vernünftig, von wirklich wichtigen Informationen zusätzlich ein On-Site-Backup zu ziehen.

In der Datenschutz-Anleitung des Dienstes findet sich zudem der Hinweis, dass S3 darauf ausgelegt ist, bei gleichzeitigem Datenverlust in zwei verschiedenen Facilities nach wie vor Informationen zurückliefern zu können.

S3 ist zur Verwaltung größerer Datenmengen ideal, auf die man von Zeit zu Zeit zugreift. Allerdings gibt es - etwa bei den oben genannten EC2-Systemen - Situationen, in denen man einen klassischen blockorientierten Speicher benötigt. Im Hause Amazon heißt dieser Dienst Elastic Block Store (EBS). Amazon bietet Entwicklern auf SSD beziehungsweise klassischen Festplatten liegende EBS-Volumina. In beiden Fällen identisch ist der Lebenslauf, der mit der Anlage eines Snapshots in S3 beginnt und endet.

Besonders wichtig ist, dass EBS-Speicher in einer einzigen Availability Zone liegt. Daten werden zwar von Zeit zu Zeit repliziert, das eigentliche blockorientierte Volume ist aber aus Gründen der Performance nur in einer einzigen Availability Zone anzutreffen und dementsprechend verwundbar.

Bei einer EC2-Instanz wird oft ein als Amazon EC2 Instance Storage bezeichneter Speicherbereich angeworfen. Es handelt sich dabei um eine EBS-Abart, die dank geringer Latenz eine Geschwindigkeit von 365.000 Lese-Operationen und 315.000 Schreib-Operationen pro Sekunde schafft. Der wichtigste Unterschied zwischen der gewöhnlichen EBS-Instanz und der Instance-Storage-Instanz ist, dass Instance Storage nach dem Sterben des EC2-Servers, der für seine Erzeugung verantwortlich war, automatisch ebenfalls zerstört wird.

Wer Amazon AWS nutzen, sich selbst aber nicht einarbeiten möchte, kann auf die von Amazon bereitgestellten beziehungsweise zertifizierten Advisors zurückgreifen. Es handelt sich dabei um ein an Microsofts MCP- beziehungsweise MOS-Programm angelehntes Zertifizierungssystem, über das Unternehmen ihre Kompetenz in Sachen AWS unter Beweis stellen können.

Amazon unterteilt die hauseigenen Dienste auch in AWS Foundation Services und AWS Platform Services. Die bisher besprochenen Dienste waren in der Welt der Foundation Services angesiedelt, während wir uns nun in Richtung der AWS Platform Services weiterbewegen. Hinter dem zunächst seltsam klingenden Namen verbirgt sich der Gedanke, dass der Administrator beziehungsweise Entwickler von Amazon Datenbanken und andere Dienste in vorkonfigurierter Form mieten kann. Diese Vorgehensweise hat Vorteile: Erstens müssen sie sich nicht mit der oft aufwendigen Administration und Optimierung des unterliegenden Datenbank-Servers auseinandersetzen, sondern können mit der Umsetzung ihrer Applikation beginnen. Updates  erledigt Amazon, womit das regelmäßige Hinterherhecheln der aktuellsten MySQL-Version der Vergangenheit angehört.

Vorteil Nummer zwei ist, dass es eine Vielzahl von Diensten beziehungsweise EC2-Instanzen gibt, bei denen sich Amazon auch um die Lizenzierung kümmert. Ein gern genanntes Einsatzszenario ist das Ausprobieren von Servern und sonstigen Produkten, für die man nur schwer eine Lizenz bekommt: Die Instanz erspart den oft nervtötenden Verkaufsdialog mit einem Sales-Team.

Auf der Soll-Seite steht, dass man bei der Nutzung einer vorkonfigurierten Instanz im Bereich der Parametrisierung eingeschränkt ist. Wer seine Datenbank oder seinen Load Balancer von Hand extrem feingranular einstellt, wird mit AWS nicht glücklich. Er muss eine EC2-Instanz anwerfen und mit den gewünschten Informationen parametrieren.

Die einfachste Datenbank ist der Amazon Relational Database Service (RDS), die klassische Implementierung einer relationalen Datenbank. Amazon unterstützt neben der hauseigenen Datenbank Aurora auch MySQL, MariaDB, Microsoft SQL Server, Oracle und PostgreSQL.

Im Grunde genommen legen Sie eine EC2-Instanz an, die einen Datenbank-Server darstellt, der in der AWS-Cloud lebt. Innerhalb dieser Instanz können Sie eine oder mehrere Datenbanken anlegen, in der Sie die eigentlichen Nutzdaten unterbringen.

Amazon hat den hauseigenen RDS-Service mit diversen Komfortfunktionen erweitert. Erstens gibt es regelmäßige automatisierte Backups. So können Sie Ihre Datenbank schnell und unbürokratisch zurücksetzen; die Vorhaltephase für alte Versionen kann auf bis zu 35 Tage ausgedehnt werden. Alternativ dazu gibt es die Möglichkeit, von Hand das Aufnehmen eines Snapshots anzuweisen. Dieser wird so lange aufbewahrt, bis Sie ihn löschen – die Daten liegen in einem S3-Bucket, für dessen Nutzung Kosten anfallen.

Von Haus aus sitzt RDS immer nur in einer einzigen Availability Zone. Sie können alternativ auf ein Verfahren namens Multi-AZ RDS Deployment zurückgreifen, in dem die Datenbank synchron in mehreren Zonen angelegt wird. Wichtig ist, dass alle Availability Zones in derselben Region liegen müssen, da sonst für Amazon nicht tragbare Latenzen auftreten. Ist ein Datenbankverbund in diesem Betriebsmodus, kommt es im Fall eines Ausfalls einer Datenbank automatisch zu einem Fail-over. Beachten Sie aber, dass geplante Wartungsmaßnahmen zuerst auf die Stand-by-Server ausgeführt werden, bevor sie die eigentliche Haupt- und Staats-Datenbank berühren.

Amazon bietet optional auch eine Gruppe von NoSQL-Datenbanken an, die sich analog zum klassischen RDS verhalten. Die Datenbanksysteme im NoSQL-Bereich sind allerdings allesamt Eigenentwicklungen, die sich von den Marktführern mehr oder weniger stark unterscheiden.

Die Flexibilität cloudbasierter Architekturen bringt in der Praxis keine nennenswerten Vorteile, wenn die Skalierung nach wie vor von Hand erfolgen muss. Das manuelle Entwickeln von Autoscale-Skripts ist nicht bequem: Im Fall eines Fehlers kann es schnell zu immensen Kosten kommen, die - zumindest in vielen Abonnementplänen - im Backend von Amazon nicht einzuschränken sind.

Die klassische Architektur für einen Load Balancer ist - um einen Server-Pool herum - ein Dreieck aus einem Elastic Load Balancer, einer Cloudwatch-Instanz und einem automatischen Skalierer. Zur Erklärung: Der Balancer hat die Aufgabe, eingehende Anfragen von Kunden auf die im Server-Pool befindlichen Arbeiter (Worker-Prozesse) zu verteilen. Die Interaktion zwischen Endgerät und Server erfolgt also ausschließlich im Arbeiter und im Balancer. Cloudwatch hat die Aufgabe, Limits vorzuhalten und die Autoscaling-Politik vorzugeben. Der Autoscaler passt die Größe des auch als Auto Scaling Group bezeichneten Server-Pools dynamisch gemäß den Richtlinien des Entwicklers an, um sicherzustellen, dass immer ausreichend Kapazität zur Verfügung steht. Dabei empfiehlt es sich, Instanzen nicht auf Volldampf zu fahren. Das Hochfahren weiterer Elemente nimmt mitunter etwas Zeit in Anspruch, was zu schlechter User Experience führen kann.

Schon an dieser Stelle sei gewarnt: Load Balancer behalten die Interessen von Amazon sehr offensichtlich im Hinterkopf. Sie dürfen nicht davon ausgehen, dass ein Load Balancer nicht mehr benötigte EC2-Instanzen beendet. Es gibt Konfigura­tionen, in denen eine einmal gestartete Maschine bis zum Sankt-Nimmerleins-Tag weiterlaufen darf.

Zur Unterscheidung der verschiedenen Load Balancer ist es hilfreich, auf das klassische OSI-Schichtenmodell zurückzugreifen. Auf Layer vier findet sich die Transportschicht: In der Welt von TCP/IP handelt es sich dabei um TCP. Sowohl ein Network Load Balancer als auch ein Classic Load Balancer bewerkstelligen ihre Arbeit ausschließlich auf dieser Ebene, beschäftigen sich also nicht weiter mit den angelieferten Inhalten. Der primitivste Load Balancer hört auf den Namen Classic Load Balancer. Er ist eine Verteilungs-Engine, die TCP-, SSL-, HTTP- und HTTPS-Sessions vermitteln kann.

Der wichtigste Vorteil des Oldies ist, dass er das - formal 2013 eingestellte - EC2-Classic-Vernetzungssystem unterstützt. Trotz der Einstellung ist es nämlich möglich, bestehende Applikationen weiterhin zu warten. Wenn Sie in einer derartigen Infrastruktur Balancing durchführen wollen, müssen Sie auf Classic setzen. Sein modernerer, also in der VPC-Umgebung arbeitender Kollege namens Network Load Balancer, beschränkt sich auf TCP, bietet dafür aber fortgeschrittene Funktionen. So ist er in der Lage, auf einer Instanz mehrere Ports als voneinander unabhängige Ziele zu betrachten und voneinander unabhängig mit Sessions zu belagern. Das ist etwa dann sinnvoll, wenn man sehr alte Server-Software verwendet, die einen einzigen Kern auslasten kann - Single-Core-VMs sind nicht kosteneffektiv.

Ein weiterer Vorteil des Network Load Balancers ist seine Leistungskraft. Der Dienst bewältigt laut Amazon mehrere Millionen Anfragen pro Sekunde ohne Probleme.

Während der Network Load Balancer unter einer statischen API ansprechbar ist, ist der fortgeschrittene Application Load Balancer nur über einen DNS-String erreichbar. Der wichtigste Unterschied zu seinen Kollegen ist, dass er ausschließlich HTTP und HTTPS unterstützt. Es handelt sich also um einen auf OSI-Layer sieben arbeitenden Lastverteiler.

Wer einen solchen Balancer einsetzt, wird von Amazon automatisch als Kunde mit besonderen Zuverlässigkeitsansprüchen eingeschätzt. Daraus folgt, dass der Balancer die Verwendung von mehr als einer AZ voraussetzt. Dies kann im Fall von Server-Ausfällen Gold wert sein.

Zwei weitere interessante Features betreffen die Möglichkeit zur Inspektion des Contents. Die Zuweisung zwischen Balancer und dem für die Ausführung verantwortlichen Element kann sowohl anhand von Header-Feldern als auch anhand von Static Sessions durchgeführt werden. Der Load Balancer merkt sich beim erstmaligen Auftauchen des Clients, wo dieser wohnt. Spätere Anfragen werden immer an dasselbe Gerät weitergeleitet, was das Recyceln von in lokalen Caches befindlichen Informationen erleichtert.

In der Praxis entscheidet man zwischen Classic und Application Load Balancer, der NLB findet sich in der Literatur nur selten. Der Weg zur Unterscheidung ist einfach: Wenn Ihre Algorithmen mit IP-Adressen und TCP-Ports auskommen, so reicht der im Betrieb preiswertere Classic aus. Wollen Sie stattdessen in die HTTP-Informationen einsteigen, um detailliert zu makeln, so müssen Sie den ALB loslassen.

Abschließend noch ein paar Worte zum Internet of Things. Amazon bietet dafür eine Komplettlösung vom Embedded-Betriebssystem bis zur Event-Verarbeitung. Analog zu Microsoft setzt man auf ein Gateway, das die von den verschiedenen Endgeräten eingehenden Informationen entgegennimmt und mit AWS-Ressourcen verbindet.

Das unter AWS IoT Core laufende Produkt arbeitet im Großen und Ganzen mit dem MQTT-Protokoll, erlegt Entwicklern allerdings Schwierigkeiten auf. So wird der QoS-Level 2 prinzipiell nicht unterstützt, was bei Hochverfügbarkeitsanwendungen für Probleme sorgt. Auf der Haben-Seite steht eine als Rules Engine bezeichnete Komponente: Eingehende Informationen werden im ersten Schritt analysiert, mit diesen Daten lässt sich eine Lambda-Funktion oder Ähnliches anstoßen.

Das arbeitsintensive Makeln zwischen eingehenden Sen­sordaten und den sie bearbeitenden Aktoren sollen dabei Amazons Cloud-Dienste übernehmen - zu nicht unerheblichen Kosten. Deshalb hält sich Amazon auch nicht aus dem Geschäft mit Device Shadows und Provisionierung heraus.

Ein interessanter Aspekt, der zum Abschluss unseres Streifzugs durch AWS nicht unerwähnt bleiben soll, betrifft Free RTOS. Der einst durchaus teure Industriestandard steht seit der Übernahme durch Amazon komplett kostenlos zur Ver­fügung – und Amazon ist damit einer der we­nigen Anbieter von IoT-Cloud-Diensten mit einem eigenen Echtzeit-Betriebssystem.