e-journal of Practical Business Research

Transkript

1 e-journal of Practical Business Research Amazon EC2 von Julius Ollesch, Dirk Schweim, Michael Aydemir, Maria Ehrhardt und Marcel Hansch Erschienen im e-journal of Practical Business Research unter: Amazon ist ein Unternehmen, das landläufig vor allem für seinen Onlineshop bekannt ist. Weitaus weniger bekannt ist, dass Amazon sich im Verlauf der letzten Jahre auch zu einem bedeutenden IT-Dienstleister entwickelt hat. Unter dem Namen Amazon Web Services werden heute alle Cloud-Computing-Lösungen des Unternehmens zusammengefasst. Amazon Elastic Compute Cloud (EC2) ist ein eben solches Produkt. Ziel des vorliegenden Artikels ist es, ein Grundverständnis der Dienstleistung EC2 und seiner Komponenten zu schaffen. Die Kurzversion dieses Artikels ist unter dem Titel Amazon EC2 im Überblick erhältlich. Zitation: Ollesch, Julius/Schweim, Dirk/ Aydemir, Michael/Ehrhardt, Maria/Hansch, Marcel (2011): Amazon EC2 In: e-journal of Practical Business Research, Sonderausgabe Best of WI08 (07/2011), DOI: /

2 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch Inhaltsverzeichnis 1 Amazon nur ein Onlineshop? Einführung und Beschreibung des Geschäftsmodells Grundgedanke von EC Marktmodell Nachfragemodell Wettbewerbsmodell Beschaffungsmodell Leistungserstellungsmodell Leistungsangebotsmodell Distributionsmodell Kapitalmodell Finanzierungsmodell Erlösmodell Zusammenfassung der Partialmodelle und Wertschöpfungskette Ausblick EC2 Architektur Grundelemente der Architektur Einrichtung eines EC2 Accounts Verwaltung von Instanzen Einstieg und Lernkurve Architekturbeispiele im praktischen Anwendungsfall Szenario 1 - Einstiegskonfiguration Szenario 2 Erweiterte Konfiguration Szenario 3 Availability Zones Dynamische Provisionierung in der Praxis Auslesen und Ansprechen von Ressourcen Steuern von Instanzen mit dem AWS Java SDK Zugriffsschutz im praktischen Anwendungsfall Autorisierung Schutz vor Angriffen aus dem Internet / 31

3 Amazon EC2 4 Rechtliche Aspekte bei der Nutzung von Amazon EC Personenbezogene Daten Datenschutz und Informationssicherheit Vorsteuerabzugsfähige Rechnungen Business Case für Szenario 3 Availability Zones Preismodell Berechnung Schlussbetrachtung Quellenverzeichnis Literaturquellen Internetquellen Amazon Dokumentation Abbildungen Abbildung 1: Partialmodelle eines integrierten Geschäftsmodells... 5 Abbildung 2: Illustration der Skalierbarkeit von IT- Umgebung... 8 Abbildung 3: Geschäftsmodell Amazon EC Abbildung 4: Darstellung der EC2 Gesamtarchitektur Abbildung 5: Architektur einer Micro- Instance mit Tomcat Installation Abbildung 6: Architektur einer verteilten Tomcat Installation mit Load- Balancer Abbildung 7: AWS- Konsole zur Einrichtung eines Load Balancers Abbildung 8: Apache Tomcat mit Load Balancer Abbildung 9: Verteilte Architektur mittels Availability Zones Abbildung 10: Management Konsole des Eclipse AWS Plug- In Abbildung 11: Berechnung des Preises einer Betriebsstunde mit On- Demand Instanzen Abbildung 12: Berechnung des Preises einer Betriebsstunde mit Reserved- Instanzen Abbildung 13: Vergleichsrechnung mit Hetzner Managed Servern / 31

4 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch Code Listings Listing 1: Anmeldung an EC2 Instanz via ssh Listing 2: Installation von Tomcat in EC2 Instanz Listing 3: Einrichtung eines Elastic Load Balancers via Terminal Listing 4: Registrierung von Instanzen beim Load Balancer Listing 5: Auflisten von Buckets und Instanzen in Java Listing 6: Programmatisches starten von Instanzen in Java Listing 7: Vergabe einer statischen IP- Adresse und Einrichtung eines Load Balancers in Java Abkürzungsverzeichnis ACL AMI API AWS EBS EC2 ECU GB, TB HTTP IaaS IPsec RDS REST S3 SDK SLA SOAP SSH SSL TCP/IP Access Control List Amazon Machine Image Application Programming Interface Amazon Web Services Elastic Block Storage Elastic Compute Cloud Elastic Compute Unit Gigabyte, Terabyte Hypertext Transport Protocol Infrastructure as a Service Internet Protocol Security Relational Database Service Representational State Transfer Simple Storage Service Software Development Kit Service Level Agreement Simple Object Access Protocol Secure Shell Secure Sockets Layer Transmission Control Protocol / Internet Protocol 3 / 31

5 Amazon EC2 1 Amazon nur ein Onlineshop? Amazon ist ein Unternehmen, das landläufig vor allem für seinen Onlineshop bekannt ist. Weitaus weniger bekannt ist, dass Amazon sich im Verlauf der letzten Jahre auch zu einem bedeutenden IT- Dienstleister entwickelt hat. Der Ursprung dieser Entwicklung liegt im stetigen Wachstum des Amazon- Onlineshops in Bezug auf Sortiment und Kundenstamm. Diese Veränderung hatte zur Folge das Amazon eine immer leistungsfähigere IT- Infrastruktur benötigte. Besonders vor Feiertagen zum Beispiel in der Zeit vor Weihnachten musste die IT- Infrastruktur enorme Zugriffsspitzen ausgleichen. Die Folge daraus war, dass Amazon das ganze Jahr über enorme zusätzliche Kapazitäten vorhielt. 1 Die hohen Kosten senkten dementsprechend langfristig die Profitabilität des Unternehmens. Amazon nutzte dieses Problem jedoch für sich und entwickelte ein neues Geschäftsmodell: Unausgelastete Ressourcen der eigenen IT- Infrastruktur wurden weitervermietet. Das Ziel des ab 2002 verfügbaren Amazon Web Services war zunächst also die Vermarktung der eigenen Überkapazitäten und die Reduzierung der dadurch entstehenden Kosten. 2 Unter dem Namen Amazon Web Services werden heute alle Cloud- Computing- Lösungen des Unternehmens zusammengefasst. 3 Der Begriff Cloud Computing wird in diesem Kontext als eine IT- Leistung mit verteilten Hard- und Software- Ressourcen aufgefasst, welche von einem oder mehreren Anbietern bereitgestellt und entsprechend der momentanen Anforderungen genutzt werden können. 4 Amazon Elastic Compute Cloud (EC2) ist ein eben solches Produkt welches genauer als Infrastructure as a Service (IaaS) 5 klassifiziert werden kann. Es wurde im Jahr 2006 zum Portfolio hinzugefügt. 6 Im Rahmen von EC2 stellt Amazon Rechenkraft in Form virtueller Maschinen zur Verfügung. 7 Der wesentliche Vorteil liegt in der Dynamik bzw. Skalierbarkeit des Services, wie im Folgenden noch näher beschrieben wird. Die Cloud- Computing- Lösungen kamen in der Folge bei den Kunden so gut an, dass Amazon stetig seine Kapazitäten weiter ausbauen musste, um die Nachfrage zu befriedigen. Aus der Idee, die Kosten der IT- Infrastruktur zu reduzieren entstand ein völlig neuer, profitabler Geschäftszweig. Ziel des vorliegenden Artikels ist es, ein Grundverständnis der Dienstleistung EC2 und seiner Komponenten zu schaffen. Der Leser wird dabei in die Lage versetzt, den Einsatz von EC2 für seine Zwecke, beziehungsweise die seiner Organisation, zu prüfen. Zudem wird eine erste Anwendung von EC2 demonstriert. Die Arbeit besteht im Wesentlichen aus drei logisch aufeinander aufbauenden Teilen: 1. Einführung & Beschreibung des Geschäftsmodells 2. Beschreibung der EC2 Architektur 3. Praktische Anwendung, Kosten und rechtliche Aspekte 1 Vgl. Baun, Kunze, Nimis, Tai (2009), S. 44 ff. 2 Vgl. ebenda 3 abgerufen am Vgl. abgerufen am Vgl. ebenda 6 Vgl. Krutz, Vines (2010), S. 7 7 Vgl. Abschnitt Amazon EC2 Funktionsweise, abgerufen am / 31

6 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch 2 Einführung und Beschreibung des Geschäftsmodells In diesem Kapitel wird zunächst einführend der EC2- Service kurz beschrieben. Aufbauend darauf wird das Geschäftsmodell von Amazon EC2 dargestellt. Im speziellen geht es dabei darum die Besonderheiten des Geschäftsmodells für die wichtigsten Kundengruppen im Vergleich zu Konkurrenzangeboten am Markt darzustellen. Dabei wird auf das viel zitierte Konzept zur Geschäftsmodell- Beschreibung von B.W. Wirtz zurückgegriffen. 8 Das Konzept besteht im Wesentlichen aus sechs einzelnen Partialmodellen, die im Gesamtmodell zusammengefasst werden. Eine Übersicht des Konzepts ist in nachfolgender Abbildung dargestellt. Abbildung 1: Partialmodelle eines integrierten Geschäftsmodells Grundgedanke von EC2 Prinzipiell ist Amazon EC2 vergleichbar mit dem seit langem am Markt angebotenen Service eines dedizierten Servers. Bei letzterem mietet der Kunde bei einem Dienstleister einen Server. Dieser kann physisch als auch virtuell (ein sogenannter V- Server) beim Hoster vorliegen. Der Server kann dann selbst verwaltet und administriert werden. So ist es zum Beispiel möglich eigene Software auf diesem Rechner auszuführen. Davon abzugrenzen ist das Angebot des managed Server, bei dem zum Beispiel das Betriebssystem und Server- Software vom Anbieter aktualisiert und gewartet werden. Die Angebote unterscheiden sich dabei oft von Anbieter zu Anbieter. Der Unterschied von EC2 zum dedizierten Server liegt vor allem in der Skalierbarkeit und damit zusammenhängend in der genauen - nutzungsdauerbasierten - Abrechnung. Der Kunde kann sich ein System mit sehr flexibler Architektur anlegen (technische Details dazu siehe 3 - EC2 Architektur). 8 Vgl. Wirtz (2010), S. 211 ff. 9 Vgl. ebenda 5 / 31

7 Amazon EC2 2.2 Marktmodell Das Marktmodell definiert, welchen Akteuren das Unternehmen in welchen Märkten gegenübersteht und welche Struktur die Märkte aufweisen. 10 Dabei wird zwischen dem Wettbewerbsmodell und dem Nachfragemodell entsprechend den auf dem Markt beteiligten Akteuren unterschieden Nachfragemodell Im Nachfragemodell wird die Frage beantwortet welche Personengruppen welche Leistung nachfragen, wie viel sie nachfragen und welchen Preis sie dafür bereit sind zu bezahlen. Dabei ist es gegebenenfalls sinnvoll mehrere Modelle für verschiedene Nachfrager anzufertigen. So auch bei Amazon EC2. Hier muss man im Wesentlichen drei Anwendergruppen unterscheiden: 1. Hobbyanwender, die sich aus Interesse an der Technologie mit dem Thema beschäftigen. In der Regel wird bei diesen Nachfragern die Bereitschaft Geld zu bezahlen sehr gering sein. Die Menge der Nachgefragten Ressourcen ist (in der Regel) demgegenüber auch gering. 2. Start- Ups und kleine Unternehmen, die recht geringe Systemanforderungen haben und eine zukunftsfähige, flexible Lösung suchen. Diese Nachfragergruppe ist bereit Geld für die Angebotenen Services auszugeben, achtet jedoch sehr genau darauf. Hohe Preise werden in der Regel nicht bezahlt werden, denn die Unternehmen können sehr leicht auf konkurrierende Angebote ausweichen (siehe unten 2.2.2). 3. Große Unternehmen, die sehr flexible Infrastrukturen benötigen und hohe Anforderungen an ihre IT haben. Die Bereitschaft viel Geld für IT- Infrastrukturen zu bezahlen, die ihren Anforderungen genügen, kann als recht hoch beschrieben werden. Die hohe Flexibilität der Systeme zum Beispiel ist ein guter Grund etwas mehr auszugeben. Der Vorteil für die Unternehmen liegt dann darin, dass sie nicht ständig die eigene IT erweitern müssen. Kostenvorteile sind bei Unternehmen, die sehr variierende Ressourcenanforderungen haben, im Vergleich zu konkurrierenden Angeboten durchaus möglich. Die Gruppe, auf die Amazon nun fokussiert, sind die Kunden aus diesen drei Bereichen, die besonders skalierbare bzw. flexible IT- Infrastrukturen benötigen. Die Analyse der Nachfrager am Markt könnte nun beliebig genau verfeinert werden. Im Rahmen dieser Arbeit soll jedoch diese erste Analyse ausreichen, um einen Eindruck der verschiedenen Nachfrager zu bekommen. Es muss darauf hingewiesen werden, dass sicher auch andere Nachfragergruppen existieren. Diese stehen aber nicht so sehr im Fokus des Amazon- EC2- Nachfragemodells, wie die oben genannten. Es muss zudem einschränkend festgestellt werden, dass der Übergang zwischen diesen Kundengruppen fließend sein kann. Ein Beispiel soll diesen Gedanken veranschaulichen: Ein Hobbyanwender erstellt testweise einen Service in Form einer Homepage auf Amazon EC2 online. Dieser wird von anderen Benutzern für gut befunden und genutzt. Der Entwickler sieht eine Geschäftschance und gründet ein kleineres Unternehmen. Dieses Unternehmen entwickelt sich innerhalb kurzer Zeit zu einem größeren Unternehmen. Wie man leicht sieht, kann der Übergang gerade vom Hobbyanwender zum kleinen Start- Up sehr fließend sein, was von Amazon wohl auch gewünscht ist (siehe Preismodell unten). 10 Wirtz (2010), S / 31

8 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch Wettbewerbsmodell Wie oben bereits beschrieben gibt es zudem Wettbewerbsmodelle. Sie geben Auskunft über das Wettbewerbsumfeld der Unternehmung. 11 Es ist zu beachten, dass für jeden Absatzmarkt ein eigenes Wettbewerbsmodell gelten kann, da sich die Märkte bezüglich ihrer Struktur und des Marktverhaltens z.t. deutlich unterscheiden. 12 Im konkreten Fall von Amazon EC2 sind besonders nachfolgende Wettbewerbsangebote zu beachten: 1. Für kleine Unternehmen, Start- Ups und Hobbyanwender sind dedizierte Server, insbesondere so genannte managed Server und virtuelle Server (auch V- Server), die wesentlichen Konkurrenzangebote zu EC2. Sie sind vor allem bei eher statischer Nutzlast z.t. günstiger als Amazon EC2 (siehe auch Kapitel 5 - Business Case für Szenario). In diesem Markt ist die Zahl der Anbieter groß. Bekannte Beispiele in Deutschland sind Hetzner, Strate oder 1&1. 2. Für große Unternehmen sind besonders das Hosting der eigenen Server im eigenen Rechenzentrum oder das Housing eigener Server in fremden Rechenzentren von Interesse insbesondere in Verbindung mit Virtualisierungslösungen. Auch hier kann der Kostenfaktor als Hauptgrund genannt werden. Ebenso ist das Outsourcing zur Konzentration auf das Kerngeschäft aber sicher für viele Unternehmen ebenso ein wichtiger Faktor. Anbieter in diesem Bereich sind zum Beispiel große Unternehmen wie IBM oder HP, aber auch kleinere Unternehmen wie Hetzner. Auch an dieser Stelle könnte die Analyse der Wettbewerber noch verfeinert werden, was jedoch auch an dieser Stelle nicht zielführend wäre. Wichtig zu erwähnen ist jedoch, dass es keinen direkt vergleichbaren Anbieter gleicher Größe gibt, der mit seinem Geschäftsmodell ausschließlich auf hoch skalierbare IT- Lösungen fokussiert. 2.3 Beschaffungsmodell Das Beschaffungsmodell zeigt, welche Produktionsfaktoren von welchen Lieferanten beschafft werden. 13 Beim Beschaffungsmodell geht es also im Wesentlichen um die Inputfaktoren, die zur Leistungserstellung benötigt werden. 14 Bei Amazon EC2 ist der wichtigste Inputfaktor wohl das Wissen der Administratoren bzw. Programmierer im Hintergrund des Services. Ähnlich wichtig ist zur Leistungserstellung die IT- Infrastruktur die Amazon Cloud besteht aus einem dichten, hochverfügbaren Rechnernetz verteilt auf verschiedene Rechenzentren weltweit. Die Beschaffung und Unterhaltung der Hardware in den Rechenzentren hängt vor allem von Kapital ab. Demgegenüber kann man davon ausgehen, dass die Personalbeschaffung von wesentlich mehr Faktoren als Geld abhängig ist. So könnten zum Beispiel Arbeitsbedienungen und der Ruf von Amazon als Arbeitgeber in diesem Punkt wesentlich kritischer bewertet werden. Somit ist das Personal der kritischste Produktionsfaktor um langfristig am Markt bestehen zu können. Die Beschaffung und Vorhaltung von Hardware kann heute als eher unkritisch bewertet werden. 11 Wirtz (2010), S ebenda 13 ebenda, S Vgl. ebenda 7 / 31

9 Amazon EC2 2.4 Leistungserstellungsmodell Beim Leistungserstellungsmodell geht es um eine ökonomische Sicht darauf wie die oben beschriebenen Inputfaktoren in die später anzubietende Leistung transformiert werden. 15 Bei Amazon EC2 ist dieser Leistungserstellungsprozess sehr weit automatisiert. Die Grundlage dafür sind die Administratoren beziehungsweise Programmierer im Hintergrund, die sich im Wesentlichen um Wartung und Erweiterung der Services kümmern. Der Kunde zahlt am Ende für die Bereitstellung von Rechenleistung. Der genaue Leistungserstellungsprozess ist zum Einen nicht transparent, zum Anderen ist er recht unwichtig für den Fokus dieser Arbeit, weshalb an dieser Stelle nicht näher darauf eingegangen wird. 2.5 Leistungsangebotsmodell Das Leistungsangebotsmodell hat das Ziel abzubilden, welches Leistungsspektrum welchen Nachfrager- bzw. Kundengruppen angeboten werden soll. 16 Zuvor wurde bereits beschrieben, dass die für Amazon interessanteste Nachfragergruppe die Unternehmen sind, die von ihrer IT- Infrastruktur eine hohe Flexibilität erwarten. Deshalb soll das Problem der Skalierbarkeit aus Unternehmenssicht an dieser Stelle kurz dargestellt werden. Kern des Problems ist die zum Teil schlechte Planbarkeit und die Variation in der Nutzung von IT- Ressourcen wie Rechenleistung, Speicherkapazität, Netzwerkbandbreite, et cetera. Unternehmen stehen vor dem Problem ein IT- System zu betreiben, welches in der Regel dauerhaft zu groß dimensioniert sein muss, um eine stetige Verfügbarkeit zu gewährleisten (siehe Abbildung 2). Unternehmen bräuchten für eine optimale Anpassung der Ressourcen an den Bedarf ein automatisch und sehr dynamisch skalierendes System. 17 Statische IT-Umgebung Skalierbare IT-Umgebung Zeit Zeit Nutzung!"#$%&&'()*%+, Abbildung 2: Illustration der Skalierbarkeit von IT- Umgebung Quelle: Eigene Abbildung 15 Wirtz (2010), S Ebenda 17 Vgl. s3- ec2- unbegrenzt- speicherplatz- virtuelle- maschinen /1/ 8 / 31

10 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch In einer klassischen, eher statischen IT- Umgebung (Bild links) müssen bei steigender Auslastung recht große Anpassungen am System vorgenommen werden. Des Weiteren ist es im statischen System aufwendiger Ressourcen zurückzufahren, wenn weniger Leistung benötigt wird. Demgegenüber ist eine skalierbare Umgebung (Bild rechts) wesentlich flexibler. Das System von Anfang an so designt, dass es von selbst sehr schnell auf Ressourcenanforderungen reagieren kann. Für Unternehmen bedeutet dies, das teure Ressourcen nicht verschwendet und nicht dauerhaft vorgehalten werden müssen (daraus resultierende Kosteneinsparung illustriert durch $ ) und dass viel weniger Störungen aufgrund partiell zu hoher Auslastung auftreten (illustriert durch Blitz ). Die System- und Ressourcenauslastung wird optimiert. Amazon EC2 bietet nun genau so eine Lösung: Unternehmen können dem System sehr schnell Ressourcen hinzufügen oder entfernen. Durch die Unterstützung von APIs ist es sogar möglich, dass Anwendungen sich selbst mehr bzw. weniger Ressourcen zuteilen diese Funktionalität wird im Kapitel Dynamische Provisionierung in der Praxis genauer beschrieben. Der Amazon EC2- Service erfüllt also genau die Anforderungen der oben beschriebenen Nachfrager- Zielgruppe. Andere Amazon- Services bieten anderen Nachfragergruppen (die wiederum andere Anforderungen haben) darüber hinaus auch andere Angebote. Dies soll im Rahmen dieser Arbeit jedoch nicht näher betrachtet werden. 2.6 Distributionsmodell Bei Amazon EC2- Service handelt es sich um ein rein immaterielles Gut. Zwar ist im Hintergrund Hardware, welche jedoch für den Kunden in dem Sinne nicht greifbar ist, sondern nur virtuell über die Datennetze zur Verfügung gestellt wird. Da die Distribution bei dem immateriellen, informationsbasierten Produkt rein über das Internet realisiert wird, fallen für beide Seiten eher geringe Transaktionskosten an. 2.7 Kapitalmodell Das Kapitalmodell setzt sich 1. aus dem Finanzierungsmodell zur Beschreibung der zur Verfügung stehenden finanziellen Ressourcen und 2. dem Erlösmodell zur Beschreibung der zur Verfügung stehenden Mittel zur Refinanzierung zusammen Finanzierungsmodell Das Finanzierungsmodell ist mit den zur Verfügung stehenden Informationen der Autoren leider nicht vollständig zu beschreiben. Jedoch erlaubt die bekannte Historie des Amazon EC2 einige Rückschlüsse, wie das Finanzierungsmodell aussehen könnte. Es sei jedoch darauf hingewiesen, dass es sich hier nur um begründete Vermutungen, keine durch das Unternehmen bestätigten Tatsachen handelt. Wie in der Einleitung zu dieser Arbeit bereits erwähnt, sind die Amazon Web Services historisch gewachsen und stellen im Gesamtunternehmen auch heute noch einen eher kleinen Geschäftsbereich dar. Der Verdacht liegt also nahe, dass die Ressourcen anfänglich durch Kapital aus dem Hauptgeschäft also Eigenkapital aufgebaut wurden. Zusätzlich kann man annehmen, dass 9 / 31

11 Amazon EC2 Fremdkapital herangezogen wurde um zum Beispiel Effekte wie den Leverage- Effekt zu nutzen. 18 Heute wird sich der Geschäftsbereich Web Services vermutlich selbst refinanzieren Erlösmodell Das Erlösmodell von Amazon EC2 basiert auf direkter Erlösgenerierung. Der Umsatz entsteht also direkt durch Erlöse vom Kunden. Die Erlöse lassen sich bei Amazon EC2 nicht streng dem transaktionsabhängigen oder dem transaktionsunabhängig Aufteilen: Es gibt die Möglichkeit einer festen Miete bestimmter Ressourcen über Grundgebühren (transaktionsunabhängig) und zugleich sind alle Ressourcen auch nur nutzungsbasiert Abrechenbar (transaktionsorientiert). 19 Eine genauere Beschreibung der Erlösformen findet sich im Kapitel 5- Business Case für Szenario. 2.8 Zusammenfassung der Partialmodelle und Wertschöpfungskette Die Zusammenfassung der Partialmodelle führt zu einer weitreichenden Betrachtung der Wertschöpfungskette des Unternehmens. Während über Beschaffungsmodell, Leistungserstellungsmodell und das Finanzierungsmodell nur wenige Informationen bekannt sind, konnten Leistungsangebotsmodell, Distributionsmodell, Erlösmodell und Marktmodell recht gut beurteilt werden. Abbildung 3 fasst noch einmal die wesentlichen Informationen zusammen: Abbildung 3: Geschäftsmodell Amazon EC2 Quelle: Eigene Abbildung in Anlehnung an Wirtz (2010), S Ausblick Im Rahmen der Analyse des Geschäftsmodells zeigte sich, dass das Amazon EC2 Kernangebot besonders im Bereich des eher statischen Hostings Nachteile gegenüber den Wettbewerbsangeboten hat. Die Tatsache, dass Amazon mit seinem Reserved Instance Angebot 18 Vgl. Hutschenreuter, S. 100 ff. 19 Vgl. Wirtz (2010), S. 216 ff. 10 / 31

12 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch eine Art Abonnement anbietet, deutet darauf hin dass sich Amazon diesem Nachteil bewusst ist. Spezielle Angebote für Kunden mit sehr dynamischem Umfeld gegenüber einem weiterausgearbeiteten Preismodell für Kunden mit sehr statischen Anforderungen würden das Angebot gut abrunden. Dabei sollte darauf geachtet werden, dass das Angebot trotzdem klar strukturiert und das Preismodell transparent für den Kunden bleibt. 3 EC2 Architektur Inhalt dieses Kapitels sind die wesentlichen Bestandteile der EC2 Architektur, insbesondere des Zugriffsschutzes. Beides soll anhand beispielhafter Anwendungsszenarien vertieft werden. Zudem wird grundlegendes Wissen vermittelt, was benötigt wird um eine EC2- Instanz aufzusetzen. Nicht Teil dieser Darstellung ist die interne Architektur, die im Anwendungsfall wenig relevant ist. Zudem ist die Quellenlage hierzu überaus spekulativ, so dass in einer Abhandlung hierzu kein Mehrwert gesehen wird. 3.1 Grundelemente der Architektur Die EC2- Architektur ist hierarchisch gegliedert. Grundelemente sind Region, Availability Zone und Instance, wobei die regionale Trennung übergeordnet ist. Danach werden verschiedene Rechenzentren in dieser Region als gekapselte Availability Zone dargestellt, in der Instanzen verfügbar sind (siehe auch Abbildung 4). 20 Region Der Begriff Region wird von Amazon für eine geographische Region verwendet, in welcher mehrere Rechenzentren (Availability Zones) zusammengefasst werden (siehe auch Abbildung unten). Logisch gesehen ist die Region die größte Einheit unter der Amazon EC2 Cloud. Es ist möglich Rechenleistung aus mehrere Regionen zu verwenden. Für den Datenaustausch zwischen Regionen fallen aber zusätzliche Kosten an. Für den Kunden besteht der Mehrwert darin, dass die Rechenkraft geographisch näher am Benutzer platziert werden kann: beispielsweise in Irland falls der Großteil der Besucher einer betriebenen Website aus Europa stammt. Auch gesetzliche Bestimmungen besonders im Bereich des Datenschutzes können hier eine Rolle spielen (siehe auch Kapitel 4 - Rechtliche Aspekte bei der Nutzung von Amazon EC2). Availability Zone Als Availability Zone fasst Amazon eine Anzahl Server zusammen, welche über einen logischen Netzwerkzugang mit dem Internet verbunden sind. Fällt dieser Netzwerkzugang aus, ist die komplette Availability Zone nicht verfügbar available. In einer Region gibt es verschiedene Availability Zones welche untereinander unabhängig aber hochperformant per Netzwerk miteinander verbunden sind. Praktisch handelt es sich somit um ein isoliertes Rechenzentrum, welches mit den anderen Rechenzentren in der Region verbunden ist. Kunden können Instanzen über mehrere Availability Zones verteilen um toleranter gegenüber Fehlern in einzelnen Rechenzentren zu sein. Instance 20 Die Quelle für die Definition der nachfolgenden Begriffe dieses Kapitels findet sich im Amazon EC2 User Guide in der Version vom , S.3 ff. 11 / 31

13 Amazon EC2 Eine Instance ist eine virtuelle Maschine. Amazon bietet zur Administration eine Web- Applikation - die AWS- Console - sowie ein eigenes API zur Erstellung und Steuerung von Instanzen an. Grundsätzlich ist es möglich On Demand Instances so komplett dynamisch zu erstellen und zu betreiben. Alternativ kann bei Abschluss eines Ein- oder Dreijahresvertrags über Reserved Instances eine Art Abonnement abgeschlossen werden. Hierdurch verringert sich die variable Nutzungsgebühr gegen eine einmalige Zahlung. Die Nutzungsgebühr für die Instance selbst variiert wiederum nach Region, eingesetzter Software (siehe AMI) und Typ der Instanz. Letzterer charakterisiert die Rechenleistung (siehe ECU) sowie Speicherausstattung der virtuellen Maschine. Amazon bietet eine Vielzahl an Konfigurationen, wahlweise mit Fokus aus Hauptspeicher oder Rechenleistung.!"#$%&'()*'!5#.3#6.3.78'9%&,':' +,-.%&/',01.2,3#&4'!5#.3#6.3.78'9%&,'*'!"#$%&$'()*&"+&,'-./0-1%$2/ "'-8"9*/0#-,0:- 1.$*;$7*;*&<-=/0"#- 1+&,";;->-8"9*/0"0- -?@1-ABC- 1#*"0-A5C- 3?-AD-E-F';$0:C-!5#.3#6.3.78'9%&,'&' Abbildung 4: Darstellung der EC2 Gesamtarchitektur Quelle: Eigene Darstellung Die im Folgenden genannten und erklärten Begriffe sind für den detaillierten Aufbau der EC2 Architektur wesentlich und für das Verständnis der Beispiele nachfolgender Kapitel notwendig. Amazon Machine Image (AMI) Amazon Machine Images sind vorbereitete Betriebssystem- Images, zumeist Linux- Distributionen - zum Teil mit vorinstallierter Software z.b. Apache Webserver httpd oder MySQL Datenbank Server mysqld. Seit einiger Zeit werden auch Images von Microsoft Betriebssystemen unterstützt, sowie Images mit kostenpflichtiger Software z.b. Microsoft SQL Server. Einmal konfigurierte Images können zur Wiederverwendung in anderen Instanzen abgespeichert werden. 12 / 31

14 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch Elastic Compute Unit (ECU) Eine Einheit für Rechengeschwindigkeit zur Abstraktion der virtualisierten Maschinen. Eine ECU entspricht laut Amazon in etwa der Rechenleistung eines 2007er 1,0-1,2GHz x86 Server- Prozessors. 21 CloudWatch Mit CloudWatch wird von Amazon ein komplexes Monitoring System bezeichnet. Dieses System überwacht den Status (Verfügbarkeit, Last, Speicher etc.) der betriebenen Instanzen nahe Echtzeit. Zusammen mit der Funktion AutomaticScaling können - regelbasiert - weitere Instanzen hinzugefügt oder entfernt werden z.b. bei durchschnittlicher Last über 80% füge eine Instanz hinzu, bei Last unter 20% entferne eine Instanz. Elastic Block Store Volume (EBS Volume) Das Elastic Block Store Volume ist der Datenspeicher hinter Amazon EC2 Instanzen. Mit Elastic Block Store steht ein dynamisches, blockbasiertes Speichervolume zur Verfügung. Dies ähnelt einem SAN im Rechenzentrum, auf welches mehrere Instanzen Zugriff haben können. EBS ist somit geeignet um gemeinsam genutzte Dateien abzulegen. Elastic Load Balancer Amazon Elastic Load Balancer kann Anfragen an mehrere Instanzen verteilen und schafft somit eine Lastverteilung. Dies ermöglicht auch eine dynamische Veränderung der Anzahl der Instanzen da der Load Balancer die Verteilung der Anfragen dynamisch anpasst. Elastic IP Elastic IP ist der Amazon Dienst zur Vergabe statischer IP- Adressen an Instanzen. Security Group Eine Security Group ist eine Firewall Regel, welche auf mehrere Instanzen angewandt werden kann. Auch kann eine Instanz mehrere Security Groups zugeordnet haben. In den Security Groups selbst können, analog einer Firewall Ports und Protokolle freigegeben oder gesperrt werden. Per Standard ist z.b. nur TCP Port 22 zum Zugriff via SSH auf die Instanz freigeschaltet. 3.2 Einrichtung eines EC2 Accounts Um EC2 nutzen zu können, wird ein Amazon Web Service (AWS) Account benötigt. Der AWS Account kann prinzipiell auf mehren Wegen freigeschaltet werden. Ein Internetzugang, aktueller Browser, Telefon und Kreditkarte sind die Vorbedingungen um erste Schritte mit Amazon EC2 zu machen. Ist bereits ein Amazon Konto vorhanden, welches beispielsweise für den normalen Einkauf bei Amazon.com genutzt wird, so kann der Anwender sich mit diesen Anmeldedaten registrieren, respektive sein vorhandenes Konto für AWS freischalten lassen. Die Freischaltung selbst erfolgte im Selbstversuch der Autoren innerhalb einer halben Stunde. Es wird eine gültige Kreditkarte sowie ein Telefon benötigt, denn nach Eingabe aller Daten verifiziert Amazon die Identität des Benutzers 21 Vgl. types/ im Abschnitt Measuring Compute Resources 13 / 31

15 Amazon EC2 telefonisch. Ist die Anmeldung erfolgt, wird das Verwaltungswerkzeug AWS Management Console freigeschaltet. Der Nutzer kann jetzt eine erste Instanz anlegen. Für die personenunabhängige Nutzung dieser administrativen Tools empfiehlt es sich, eine Zugangs ID zu definieren (sog. Access Key Identifiers). Dem Benutzer der Access Key Identifier müssen die Zugangsdaten des Amazon bzw. AWS Kontos nicht bekannt sein. Erreichbar ist diese Funktion unter Webservice Account - > View Access Key Identifiers. Dort wird unter X.509 Zertifikat angeboten, ein neues Zertifikat zu erstellen. Bestätigt man diesen Schritt, erscheint in einer Auswahlliste das eben erstellte Zertifikat als Dokument. Dieses kann auf beliebige Rechner geladen und z.b. im Team weiterverwendet werden. 3.3 Verwaltung von Instanzen Für die Verwaltung der EC2 Instanzen sorgt die AWS Management Console. Über dieses Tool lassen sich Instanzen hinzufügen, entfernen, starten und beenden. Darüber hinaus sieht der Administrator eine Übersicht über die bereitgestellten Instanzen inklusive System- Logs und weiteren Informationen. Diese zentrale Überwachung der Instanzen mit Hilfe verschiedener Kennzahlen und Werte ist gerade für kleine Organisationen ein Novum. Die Werte werden zur besseren Veranschaulichung auch graphisch dargestellt. Gegen einen Aufpreis erfolgt die Überwachung nahe Echtzeit, standardmäßig mit einer fünfminütigen Verzögerung. Hat der Nutzer über die Zeit einige Instanzen angelegt, so hat er in diesem Bereich die Möglichkeit nach einer Instanz zu suchen. Je nach Vorhaben des Nutzers kann sich dies als durchaus nützlich erweisen. Unter Administration fällt neben der Verwaltung der Instanzen selbst auch die von Datenträgern, Backup- Medien, Load Balancern und anderen Dienstleistungen die im Umfeld von EC2 angeboten werden. Für die meisten Administratoren zunächst relevant sind Sicherheitsgruppen, Schlüsselpaare sowie die Zuweisung von Elastic IPs lassen sich ebenfalls konfigurieren. Für alle aufgezählten Funktionen stehen interaktive Steuerelemente zur Verfügung. 3.4 Einstieg und Lernkurve Für den Einstieg attraktiv ist Amazons Free Tier Angebot, aus dem auch die Autoren Ihre praktische Erfahrung beziehen optimal geeignet. Hierbei erhält ein Neukunde eine Micro- Instance sowie ein bestimmtes Kontingent an Speicherplatz, Traffic etc. kostenlos. Die Nutzung der Instanz ist nicht auf Testzwecke beschränkt, kann also auch für die kommerzielle Zwecke z.b. eines Start- Ups eingesetzt werden. Die Lernkurve ist durch die gute Dokumentation und hilfreiche Tools sehr steil Schulungskosten sollten bei versiertem Personal zunächst gegen Null gehen. Die Installation einer Micro- Instance von der Registrierung als AWS Kunde, über die Freischaltung mittels Kreditkarte bis zum ersten Zugriff auf die Instanz via SSH dauerte im Selbstversuch der Autoren weniger als dreißig Minuten. Nach dem Pareto- Prinzip dürften die Schulungskosten jedoch überproportional steigen, wenn mehrere AWS Dienste eingesetzt werden. Die Dokumentation der EC2 API und Command- Line Tools umfasst beispielsweise jeweils ca. 250 Seiten dies sollte jedoch keinesfalls negativ gewertet werden. Nach einer ersten Einschätzung erscheinen die API-, Command Line- und Java- Funktionen weitestgehend konsistent und gut dokumentiert. Aber schließlich können hoch- komplexe 14 / 31

16 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch Anwendungen erstellt werden. Das Zusammenspiel von verschiedenen Diensten erfordert immer - auch bei AWS - sauber definierte Anforderungen und Schnittstellen. 3.5 Architekturbeispiele im praktischen Anwendungsfall An den nachfolgenden Beispielen soll die Architektur der zuvor beschriebenen Grundelemente illustriert werden. Hierfür werden drei Beispiele konstruiert. Zunächst eine Einstiegskonfiguration, welche hier für einen Apache Tomcat Server eingesetzt wird. Danach werden zwei Tomcat Server redundant ausgelegt und durch einen Load Balancer miteinander verbunden. Dieses Szenario wird dann in einer weiteren Ausbaustufe mit einer Verteilung der Anfragen auf mehrere Instanzen in verschiedenen Availability Zones ausgeweitet. Es ist an dieser Stelle sinnvoll Architekturbeispiele im praktischen Anwendungsfall zu erläutern, da die einzelnen Architekturen je nach Verwendungszweck stark voneinander abweichen können Szenario 1 - Einstiegskonfiguration Im zugrundeliegenden Szenario wird eine Micro- Instanz provisioniert. Diese bietet eine begrenzte Rechenkapazität von bis zu 2 ECUs, 613MB Arbeitsspeicher sowie ein EBS Volume mit 8 Gigabyte Speicherkapazität. Mit der Provisionierung wird eine Security Group mit den Ports 22 für SSH Zugriff und 8080 für Tomcat Zugriff eingerichtet (siehe Abbildung 5).!"#$%&'()*+,&%-).#/-%00%1+#)%2$) 3"&4+).#/-%#&()) 89":;<" 8989">+?+" =="((:" A7+(,/"0D@"E=!F=G!F=G!H=" #$%&'&()*+,-'" C1/4*&)M"N*-4<@"6JD"8989O"6JD"==" 6-%/+)"@"8989" ((:$"@"==" #$%&'&()*+,-'" #IC"CKL" #IC"J-'(-71" ABC" P$1?P($+F" #.0"2"3&'45" #.0"6--7("!!!" C'+<(:-)".&/*-"0'()+'/1" CG" Abbildung 5: Architektur einer Micro- Instance mit Tomcat Installation Quelle: Eigene Darstellung 15 / 31

17 Amazon EC2 Nun wird die Instanz über die AWS Console gestartet und bekommt die Elastic IP zugewiesen. Unter Unix Betriebssystemen kann der vorhandene SSH- Client verwendet werden um mit dem nachfolgen Kommando eine Verbindung herzustellen: ssh - i <<Schlüsseldatei>>.pem ec2- user@ Last login: Tue Mar 8 20:52: from brln- 4d0c102e.pool.mediaways.net _ ) Amazon Linux AMI _ ( / Beta \ See /usr/share/doc/amzn- ami/image- release- notes for latest release notes. :- ) Listing 1: Anmeldung an EC2 Instanz via ssh Nachfolgend kann beliebige Software hier Tomcat 6 installiert werden. Die Kommandos hierzu sind absolut identisch zu üblichen Linux Distributionen. Die Konfiguration von Tomcat 6 wird hier nicht näher erläutert. [ec2- user@ip /]$ sudo aptitude install tomcat6 Listing 2: Installation von Tomcat in EC2 Instanz Szenario 2 Erweiterte Konfiguration In diesem Szenario wird eine weitere Instanz hinzugefügt und ein Load Balancer konfiguriert, welcher Anfragen nach index.html auf Port 80 an die installierten Tomcats weiterleiten soll (siehe Abbildung 6). 16 / 31

18 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch!"#$"%&$"'()*$+),")' -%$'./-0+$' ()*$+&&+1/)")' -.,/01,$%"234/'#5, 66,&&/, P#&2'Q<%R,)<S,B-.-., A+#>)',B, 92><($'J,K(+<1B,AGL,-.-.M,AGL,66, &&/",B, 66,!;=, A++5&, 75)&*>,=LB,C64:6D4:6D4!$#!;=, A++5&, A+#>)',B, &&/",B, 66,!"#$%$&'()*+%,!"#$%$&'()*+%,!"#$%$&'()*+%,!F9,9HI,!F9,G+%&+52, ;2"$<#,=%&')%>2,!, ;2"$<#,=%&')%>2,8, N"2ON&"):, N"2ON&"):, 789,:, 9%)1&/+', 9D, 9%)1&/+', 789,6, Abbildung 6: Architektur einer verteilten Tomcat Installation mit Load- Balancer Quelle: Eigene Darstellung Die erforderlichen Schritte können sowohl über die AWS Konsole, Befehlszeile, Web Service API als auch programmatisch über ein SDK erfolgen. Nachfolgend wird kurz die Einrichtung des Load Balancers über die Befehlszeile gezeigt: elb- create- lb MyLoadBalancer - - headers - - listener "lb- port=80, instance- port=8080,protocol=http" - - availability- zones us- east- 1c I <<AWS Zugriffsschlüssel ID>> - S <<geheimer Zugriffsschlüssel>> Listing 3: Einrichtung eines Elastic Load Balancers via Terminal Der via Befehlszeile erzeugte Load Balancer wird dann auch in der AWS Management Console sichtbar: 17 / 31

19 Amazon EC2 Abbildung 7: AWS- Konsole zur Einrichtung eines Load Balancers Quelle: Eigene Darstellung Der Load Balancer ist zwar erzeugt, jedoch noch nicht mit der Instanz verbunden. Dies kann über die Befehlszeile recht einfach mittels nachfolgendem Befehl geändert werden: elb- register- instances- with- lb MyLoadBalancer - - headers - - instances i- c9010ba5, i- c9010da4 I <<AWS Zugriffsschlüssel ID>> - S <<geheimer Zugriffsschlüssel>> Listing 4: Registrierung von Instanzen beim Load Balancer Abbildung 8: Apache Tomcat mit Load Balancer Quelle: Eigene Darstellung Damit ist die oben beschriebene Architektur vollständig eingerichtet. Anfragen über http an den DNS- Namen des Load Balancers werden nun an Port 8080 der konfigurierten Instanzen weitergeleitet. Der Load Balancer ermöglicht auch die automatische Erzeugung und Verwaltung von sticky sessions, so dass zum Beispiel ein in der Session gespeicherter Warenkorb des Benutzers eines Online- Shops auch beim Umschalten auf eine andere Instanz nicht verloren geht Szenario 3 Availability Zones Die EC2 Architektur kann für große Installationen beliebig weit ausgebaut werden. Das letzte Beispiel illustriert eine über mehrere Availability Zones verteilte, somit relativ ausfallsichere, Tomcat Installation mit dahinter- geschalteten MySQL Datenbank Servern (siehe Abbildung 9). 18 / 31

20 Ollesch, Schweim, Aydemir, Ehrhardt, Hansch Konkret soll eine Internetplattform mit 99,999%er Erreichbarkeit implementiert werden, weswegen mindestens zwei Availability Zones verwendet werden müssen. 22 Da die Webanwendung relativ rechenintensiv ist, wird für die Tomcat Installationen der Instanz- Typ Medium gewählt, welcher gegenüber dem Standard ( Small ) ein mehr an Rechenleistung bei gleichem Hauptspeicher bietet. Es wird angenommen, dass für normalen Traffic eine Medium Instanz pro Availability Zone ausreicht, für ca. 3 Stunden am Tag wird jeweils eine zweite Instanz über einen Load Balancer hinzugeschaltet. In diesem Szenario fallen neben den Kosten für die Instanzen auch Traffic- Gebühren für den Datenaustausch zwischen den Availability Zones an, weswegen die Autoren auf eine praktische Demonstration verzichten. Die Kosten für dieses Szenario werden in Kapitel 5 genau berechnet. Es soll an dieser Stelle nur auf die Möglichkeit einer hochverfügbaren Architektur hingewiesen werden. 2F0)90G)9)/B$H4-'$%$ 840($"090-1':$%5$;<=%<>=%<>=?<$ 34+10/$5$6767$ &'()*+$,-./0-1'$2$ 34+10/$5$6767$ &'()*+$,-./0-1'$"$ 2F0)90G)9)/B$H4-'$<$!"#$%$!"#$%&$&B#C85$>>7D$ 80:@'$,-./0-1'$A$ 840($"090-1':$<5$%7?=<?D=<?D=6?$ 34+10/$5$6767$ 34+10/$5$6767$ &'()*+$,-./0-1'$A$ &'()*+$,-./0-1'$E$ K'I9)10L4-$ #90F'$&B#C85$>>7D$ &'()*+$,-./0-1'$A$!"#$<$!"#$"%&$"'()*$+),")'%)' -"#*./%"0")")' 1-+%&+2%&%$3'45)"*'6)0' 7%$'857.+$' #-0I.J4/$ #>$ #-0I.J4/$ %)'1)&"/)6)9'+):'#%9/$*.+&";.57' Abbildung 9: Verteilte Architektur mittels Availability Zones 3.6 Dynamische Provisionierung in der Praxis Quelle: Eigene Darstellung in Anlehnung an rightscale.com Besonderen Reiz für professionelle Software- Entwickler hat Amazon EC2 vor allem aus zwei Gründen: als Testsystem und als dynamisch skalierbare Plattform für den Betrieb. Als dynamische Testumgebung können EC2 Instanzen sehr kostengünstig und schnell bereitgestellt werden. Entwickler können eigene AMIs, z.b. mit spezifischen Softwarekonfigurationen, erstellen und dynamisch für einzelne Tests Instanzen mit diesen AMIs starten. Zwar ist die Praxis lokal virtuelle 22 Amazon garantiert in seinem SLA eine Verfügbarkeit von 99,95% von Availability Zones im Jahr. Durch redundante Auslegung auf zwei Availability Zones ergibt sich eine rechnerische Verfügbarkeit von 99,999975% was einem Ausfall von wenigen Minuten im Jahr gleichkommt. SLA vgl. aws.amazon.com/de/ec2- sla/ 19 / 31