Virtuelle Maschinen in EC2 beruhen auf Vor­lagen, den Amazon Machine Images (AMIs). Um davon eine Instanz zu er­zeugen, muss man sich zwischen den zahl­reichen AMIs ent­scheiden, den Instanztyp wählen, Storage konfi­gurieren und Security Groups zu­ordnen. Dieser Beitrag zeigt, wie man dabei vorgeht.

Ausgangpunkt für das manuelle Erstellen virtueller Maschinen ist die EC2-Konsole im Services-Menü. Hier klickt man entweder im EC2-Dashboard oder im Instances-Menü auf Launch Instance. Danach wählt man zunächst ein Amazon-Machine-Image als Vorlage, vergleichbar einem VMTX-Template unter VMware.

Inhalt eines AMI

Jedes AMI umfasst eine Vorlage für das Boot-Volume, das AWS bei einer EBS-gestützten Instanz aus einem vorbereiteten Snapshot zusammen­baut, und das ein Betriebs­system, einen Anwendungs-Server und/oder ausgewählte Anwendungen enthält. Hinzu kommen Start­berechtigungen, die steuern, welche AWS-Konten das AMI zum Starten von Instances verwenden können.

Ferner steckt im AMI eine Blockgerät-Zuweisung, welche die Volumes angibt, die beim Laden der VM aus dem AMI an die Instance angefügt werden sollen.

Alle von AWS bereitgestellten Images können im Gegensatz zu den Community-AMIs bedenken­los verwendet werden, da AWS sie auf dem neusten Stand hält und sie über alle wichtigen Security-Patches verfügen. Außerdem sind die AWS-CLI-Tools und die wichtigsten APPs/SDKs und Entwickler-Tools vorinstalliert.

Auswahl eines Templates

Für Amazon Machine Images gibt es mehrere Quellen. Im Reiter Quick Startfinden sich die wichtigsten von AWS bereitgestellten und gepflegten Images für die gängigen Linux- und Windows-Systeme. Die Lizenzkosten bei Windows-AMIs sind bereits eingepreist.

Für die meisten allgemeinen Anwendungs­zwecke im Linux-Bereich ist Amazons Linux-AMI eine gute Wahl. In seiner Beschreibung sieht man, dass der root-Device-Typ ebs und der Virtualisierung-Typ hvm  ist. Außerdem ist es im Free Tier verwendbar. Man kann aber auch im gesamten AMI-Repository nach Free tier only filtern.

Ferner verraten die Versionshinweise zum halbjährlich aktualisierten Amazon Linux-AMI weitere Details, etwa dass dieses Template zu allen Instanztypen passt. Im Reiter My AMIs verbergen sich die vom Nutzer selbst erstellten und gepflegten AMIs. Er ist also anfangs noch leer.

Neben den von Amazon gepflegten gibt es noch Community-AMIs, die jeder AWS-Kunde hoch­laden kann. Schließlich verbirgt sich unter AWS Markplace ein prall gefülltes Portfolio von rund 3000 geprüften, meist kosten­pflichtigen Lösungen.

Diese gliedern sich in die Kategorien Software Infrastructure (aktuell 2360 Einträge), Developer-Tools (aktuell 577 Einträge) und Business Software(aktuell 1238 Einträge). Der Marketplace bietet selbstverständlich auch ein API, um eigene Entwicklungen zu handeln bzw. zum Verkauf anzubieten.

Instanztyp im Detail

Im nächsten Schritt wählt man den Instanztyp. Möchte man Free tier eligiblesein, dann bleibt ohnehin nur t2micro übrig. Allerdings hat AWS erst kürzlich den neuen Instanztyp t3x vorgestellt, der wohl künftig die Einstiegsbasis für kleine Allzweck-Instanzen bilden und den t2-Typ auch im Free-Tier ablösen wird.

Weitere Instance Details werden im nächsten Schritt konfiguriert, sofern man nicht gleich auf Review und Launch (mit Default-Einstellungen) klickt. So wählt man in Step 3 Configure Instance Details zuerst die Anzahl gewünschter Instanzen. Der Free Tier ist keineswegs auf eine Instanz beschränkt, allerdings werden die zeitlichen Grenz­werte für Compute dann im Zweifel schneller erreicht, und damit auch das Bezahl-Modell („Purchasing option“). Standard dafür ist On Demand.

Anschließend wählt der Nutzer das gewünschte Network (VPC), das Subnetund die Availability-Zone. Ferner kann man mit Auto-assign Public IP dafür sorgen, dass die Instanz, wenn es sich etwa um einen Web-Server handelt, von AWS eine öffentlich routbare IP-Adresse aus dem AWS-Public-IP-Pool zugewiesen bekommt. Sinn macht das natürlich vorerst nur, wenn die Instanz auch in einem Public Subnet provisioniert wird, funktionieren wird es aber auch in einem Private Subnet.

Darüber hinaus kann man eine Placement group wählen und bei Bedarf eine IAM-Rolle. Beide Konzepte benötigen wir an dieser Stelle noch nicht. Das Shutdown behavior hängt, wie zuvor geschildert, davon ab, ob es sich um eine Instanz nur mit EBS-Speicher oder um eine solche mit Instance-Storage handelt.

Ein Stoppen der Instanz ist also nur möglich, wenn das root-Volume auf einem EBS-Block-Volume liegt. Ferner lassen sich in den Instance-Details im Abschnitt Network Interfaces bei Bedarf zusätzliche virtuelle Netzwerk­schnittstellen anlegen.

User Data und Cloudinit

Bei Advanced Details schließlich kann der Nutzer der Instanz via Bootstrapping noch eine Reihe von Kommandos mitgeben, die beim Erzeugen aus dem AMI ausgeführt werden. In diesem Fall bietet sich neben dem Aktualisieren der Paketbasis das Installieren eines Web-Servers oder LAMP-Stacks an.

Das Bootstrapping realisiert AWS bei Linux-Instanzen mittels Cloudinit, bei Windows läuft in den betreffenden AMIs der AWS eigene EC2 Config Service. Bei Linux-Instanzen kann der Nutzer im Feld User data zum Beispiel Linux-Kommandos oder bash-Skripte übergeben, bei Windows PowerShell-Scripte. User-Data-Scripte lassen sich mit der Option As file auch als Datei anhängen.

In unserem Beispiel installieren wir einen einfachen LAMP-Stack mit Webserver und Datenbank auf dem gleichen virtuellen Server. Das sähe dann z. B. so aus:

Insgesamt ist das Verwenden von User-Daten aber optional. Wer mag, kann seine Instanzen auch nachträglich anpassen und aus diesen dann wieder ein indivi­duelles AMI erzeugen.

Wichtig: Der ec2-user ist der Standard­benutzer in Amazon Linux und auch der einzige, der sich via SSH und Public Key (ohne Password) mit der Instanz-Konsole verbinden kann.

Storage-Details

Was in Schritt 4 Add Storage möglich ist, hängt ebenfalls vom Instance-Typ ab, also ob dieser EBS-basiert ist oder auch Instance-Storage kennt. Dies wirkt sich auch auf den Typ des automatisch eingerichteten root-Devices (z. B. dev/xvda) aus, von dem AWS übrigens automatisch einen Snapshot anlegt.

Mit Add New Volume lassen sich dann je nach Instance Type wahlweise zusätzliche EBS-Volumes oder Instance-Storage-Festplatten hinzufügen. Bei EBS-Volumes hat der Nutzer je nach Instanz-Typ für ein Boot-Volume die Wahl zwischen General-Purpose-SSD (GP2), Provisioned IOPS SSD (IO1) und Platten­lauf­werken (Magnetic). Details zu den einzelnen Disk-Typen findet man in der guten Dokumentation.

Der Typ General-Purpose-SSD etwa garantiert eine Baseline-Performance von 3 IOPS pro GB, also 300 IOPS bei 100GB, dem Minimalwert. Allerdings erreichen General-Purpose-SSDs kleiner als 1000 GB bei Bedarf Burst-Werte von bis zu 3000 IOPS. SSDs größer als 1TB liefern ohnehin mindestens 10000 IOPS. Beim Typ Provisioned IOPS SSD hingegen kann sich der Nutzer die gewünschten IOPS garantieren lassen, wenn er sie entsprechend bezahlt.

Instanz mit Tags auszeichnen

Im Schritt 5 kann der Admin seiner Instanz dann nach Belieben Tags hinzufügen, beispielsweise „Name“=“Web-Server“.  Das kann man aber auch nachträglich im Reiter „Tags“ der Instances-Ansicht tun.

Nicht alle AWS-Ressourcen lassen sich mit solchen Metadaten beschreiben. Bei welchen es geht, steht in der EC2-Dokumentaton. Pro Ressource sind höchstens 50 Tags möglich. Dabei beträgt die maximale Schlüssel­länge 127 Unicode-Zeichen in UTF-8 und die Wertlänge 255 Unicode-Zeichen in UTF-8.

Security Groups

Schritt 6 widmet sich dann dem Zuweisen von so genannten Security Groups. Sie sind ein eminent wichtiges Konzept der VPC. Für den Anfang genügt es zu wissen, dass jede Instanz mit einer Security Group assoziiert sein muss, weil es sich bei ihr um eine Art Paketfilter handelt, der auf Instance-Ebene arbeitet.

Daher lassen sich Security-Groups sowohl in der VPC- als auch in der EC2-Konsole einrichten. Da sie so wichtig sind, kann aber auch der EC2-Launch-Assisitent an dieser Stelle eine Security-Group für den zu vorgesehenen Server „on-the-fly“ erstellen („Create a new secuirty group“) oder eine bereits vorhandene verwenden („Select an existing security group“).

Da Security Groups ähnlich funktionieren wie Regeln für Linux-iptables mit Stateful Inspection (Connection Tracking), genügt es an dieser Stelle, eine eingehende Regel für den gewünschten Port/Port-Range und die gewünschte Quelle (CIDR-Range oder ID einer anderen Security Group) anzugeben.

Da wir einen Web-Server provi­sionieren, ergänzen wie die Default-Regel für SSH (TCP 22) von überall (0.0.0.0/0) um eine TCP-Port-80-Regel von überall. Damit können wir uns später auf die Konsole der Instanz verbinden. Für diese Aufgabe genügt ein Klick auf Add Rule. Auch Name und Description sollten dem Verwendungs­zweck angepasst werden. In der Praxis würde man ggf. noch HTTPS (443) und ICMP erlauben, um die Fehlersuche zu erleichtern.

Launch

Nach einem Klick auf Review and Launch werden die konfigurierten Details wie AMI, Instanz, Typ und Security Groups noch einmal angezeigt, bevor man mit einem weiteren Klick auf Launch zum endgültigen Lauch-Screen gelangt. Hier gilt es, achtsam zu sein. Um sich später direkt mit der Instanz verbinden zu können, braucht man ein Public-Key-Pair (RSA). Ein Login über Username/Passwort ist nicht möglich. AWS bietet an dieser Stelle an, ein neues Key-Pair zu erzeugen.

Alternativ kann der Nutzer ein vorhandenes angeben und dies bestätigen. Lässt der Nutzer von AWS ein neues Key-Pair erstellen, kann er ihm einen Namen geben und mit Download Key Pair herunter­laden. Dieses sollte man gut aufheben, da AWS die Private Keys der Nutzer nicht speichert. Somit hat niemand bei AWS – auch kein Support – die Möglich­keit, sich mit Instanzen der Nutzer zu verbinden.

Bei Linux-Instanzen wird das Key-Pair für einen SSH-Login benötigt, bei Windows-Instanzen zum Entschlüsseln des generierten Administrator-Passworts für RDP. Das Starten dauert je nach AMI, Instanz-Typ und Größe zwischen wenigen Sekunden und einigen Minuten. Ein Klick auf die Schaltfläche View Instances führt zurück in die Instanzliste im EC2-Dashboard. Ein Verbinden ist dann mit der Connect-Schaltfläche frühestens möglich, wenn der Instance State running erreicht hat und in den Status Checks der Eintrag 2/2 checks passed erscheint.

Sofern die User-Daten korrekt interpretiert wurden (zur Kontrolle kann man bei markierter Instanz-Liste im Menü Actions auf Instance Settings => View/Change User Data klicken), sollte der installierte Apache Web-Server jetzt über den Public-DNS-Namen erreichbar sein.

Der Name wird von AWS Route 53 zugewiesen und ist im Description-Tab unter Public-DNS zu sehen. Voraussetzung dafür ist, dass die VPC für das Generieren von Public-DNS konfiguriert wurde. Ansonsten müsste er über die von AWS zugewiesene öffentliche IP-Adresse ansprechbar sein.