Amazon Elastic Compute Cloud (EC2): Optionen für Hypervisor, Images, Storage

Über 100 Instanztypen in 5 Gruppen

Das für die Cloud typische Prinzip Pay As You Go liegt aber allen Modellen zugrunde. Wie behandeln hier nur On-Demand-Instanzen. Derzeit bietet AWS über 100 verschiedene Instanz-Typen, gruppiert in die 5 Familien Allgemeine Zwecke, Für Datenverarbeitung optimiert, RAM-optimiert, Accelerated Computing (GPU optimiert) und Speicher-optimiert.

Sie weisen jeweils ein dominierendes Attribut auf, um das beste Preis-/Leistungs-Verhältnis für bestimmte Anwendungen zu erzielen. Dazu gehören zum Beispiel der CPU-Typ des Hosts nebst verfügbarer Zahl virtueller Kerne, die Größe des RAM, die Netzwerk­bandbreite, die Nutz­barkeit von GPUs (etwa mit nVidia Tesla) oder die verfügbaren Typen des Instanz­speichers und dessen maximale Größe/Performance.

Die On-Demand-Preise bewegen sich je nach Region zwischen 0,0067 USD pro Stunde für eine Linux-basierte t2.nano-Instanz mit 1 vCPU und 512MB RAM bis zu 32,066 USD pro Stunde für eine Windows-SQL-Server-Enterprise-basierte r4.16xlarge-Instanz mit 64 vCPUs und 488 GB RAM (beide Beispiele gelten für Frankfurt).

AWS-Hypervisor

Auf den physischen Hosts läuft derzeit noch ein von AWS modifizierter Xen-Hypervisor in verschiedenen Iterations­stufen, heute meist im HVM-Modus (statt früher paravirtualisiert). Somit teilen sich Anwender den Host mit Instanzen anderer AWS-Kunden, wobei der Hypervisor für die Abschottung zwischen ihnen sorgt, so wie bei jeder anderen Virtua­lisierungs­lösung auch.

Wie obige Abbildung aus Brendan Greggs Blog zeigt, verwenden die derzeit meisten Amazon Machine Images (AMIs) die Ausbaustufe Xen AWS 2017 mit Support für SR-IOV (net UND store), die nahezu native Performance für CPU/Memory, Network I/O, Local Storage, Remote Storage, Interrupts, Timer und Motherboard bietet.

Allerdings arbeitet AWS aktuell an einem neuen Nitro-Hypervisor auf KVM-Basis, der wohl mittelfristig auf allen Systemen zum Einsatz kommen wird. Derzeit ist er aber nur experimentell verfügbar, genau wie der zusammen mit VMware entwickelte Bare-Metal-Typ mit C5-Instanzen.

Dies muss aber den Einsteiger nicht kümmern, wenn sie den Free-AWS-Tier mit 750 Stunden EC2 nutzen, weil dieser ohnehin nur den Typ t2micro mit 1 vCPU und 1 GB RAM umfasst.

Storage-Anbindung und Instance-Lifecycle

AWS unterscheidet zusätzlich zwischen Instanzen, deren virtuelle Festplatten auf Elastic Block Volumes (EBS) liegen oder die das so genannte Instance Storage verwenden. Bei Letzterem handelt es sich um ein direkt ange­schlossenes Block-Device-Storage, dessen Inhalt nicht persistent ist.

EBS hingegen entspricht beim Vergleich mit einem physischen Rechen­zentrum etwa einer via SAN bereit­gestellten LUN, so dass ein EBS-Volume immer über das Netzwerk an die Instanz angebunden ist. Dies verursacht je nach Leistungs­fähigkeit der Netzwerk­anbindung gewisse Latenzen, sorgt aber auf der anderen Seite für Persistenz.

Ein EBS-Volume bleibt stets mit dem Account verknüpft und lässt sich nach dem Terminieren einer Instanz behalten und bei Bedarf (z. B. bei Daten-Volumes) an eine andere Instanz binden. Es kann aber auch nach einer horizontalen Skalierung durch Ändern des Instanztyps als Boot-Volume weiter­verwendet werden.

Der Vorteil bei EBS besteht also darin, dass sich der Nutzer nicht um die Verfüg­barkeit der EBS-Volumes kümmern muss, da AWS diese innerhalb der Availability Zone automatisch repliziert. Die kleineren, etwa die im Free-Tier berechtigten Instanzen wie t2micro unter­stützten aus­schließlich EBS-Volumes.

Der Lebenszyklus einer Instanz ist unmittelbar an dem Typ des angebundenen Storage gekoppelt, wie die obige Abbildung zeigt.

Der gesamte Instanz-Lifecycle von der Erstellung einer Instanz auf Basis einer Vorlage (AMI = Amazon Machine Image) bis zu deren Terminierung lässt sich in der AWS Management Console steuern.