Windows Server 2012 auf Amazon Web Services einsetzen

Amazon-AWS-Konto anlegen, virtuelle Instanz mit Windows Server 2012 anlegen und dann noch die Ports für RDP öffnen – und schon ist eine virtuelle Maschine im Einsatz. In diesem Test haben wir das AWS-Angebot für Windows Server 2012 aus der Cloud getestet. Dabei muss der Administrator aufpassen: Die Sicherheit der AWS-Infrastruktur garantiert Amazon, für die Security in der Virtuellen Maschine ist er selbst zuständig.

Wer heutzutage im IT-Bereich unterwegs ist, der wird an allen Ecken und Enden mit dem Begriff “Cloud” konfrontiert. Es ist die Rede von Cloud Services, von Cloud Security, von Private Clouds, Hybrid Clouds – und der Erfindungsgabe der Marketing-Verantwortlichen scheinen keine Grenzen gesetzt.

Als Vorreiter in Sachen Cloud ist Amazon bekannt, denn es bietet derartige Lösungen schon seit mehr als fünf Jahren an. Seine kompletten Cloud-Angebote hat Amazon in der Zwischenzeit gebündelt und bietet sie in Form der AWS (Amazon Web Services) an. Dabei gibt es vor allem verschiedene Ausprägungen des IaaS-Konzepts (Infrastructure as a Service).

Verwendet ein Unternehmen die AWS-Angebote, ist es selbst für das Verwalten der eigenen virtuellen Maschinen (VMs) verantwortlich. Auch die Software, die in den VMs zum Einsatz kommt, liegt komplett in der Verantwortung des Anwenders.

Das stellt einen Unterschied zu Unternehmen dar, die weitergehende Angebote im Programm haben: Unter der Rubrik Platform as a Service (PaaS) ist die erste Version von Microsofts Azure zu sehen – wobei sich dieses Angebot schon massiv verändert hat (siehe Beitrag „Windows Server 2012 im Azure-Abo“, erschienen im E-Paper März 2013). Andere Unternehmen gehen noch weiter und bieten Software as a Service (SaaS) – dazu gehört zum Beispielmicrosofts Office 365 (siehe Beitrag „Office 265 – zehn Argumente dafür und zehn dagegen“, erschienen im E-Paper März 2013) oder die CRM-Lösung von Salesforce – aber auch ERP-Systeme wie SAPs Business By Design fallen unter diese Rubrik.

In Bezug auf die AWS-Angebote herrschen einige Missverständnisse vor: Viele IT-Verantwortliche sind der Meinung, dass es sich bei den AWS lediglich um eine Entwickler-Technologie handelt und dass dabei nur VMs mit Linux als Gastbetriebssystem zum Einsatz kommen können, um den gewünschten Service zu erbringen. Zudem kommt noch die Nomenklatur von AWS ins Spiel – sie macht die Angelegenheit auch nicht unbedingt einfacher: Was zum Beispiel ist EBS (Elastic Block Storage) oder EC2 (Elastic Compute Cloud)?

Doch gottseidank ist das Erstellen eines AWS-Kontos und das Laufenlassen einer VM mit Windows Server als Gastbetriebssystem sowie das Verbinden mit der VM über das RDP (Remote Desktop Protocol von Microsoft) eine recht einfache Angelegenheit, wie es dieser Beitrag belegen soll.

Erst den Vertrag abschließen, dann anmelden

Um mit den AWS arbeiten zu können, ist zunächst ein AWS-Konto nötig. Um dieses Konto anzulegen, muss man eine Kreditkarte besitzen und zudem über das Telefon erreichbar sein. Wer nur die freie Variante der AWS-Angebots (das gilt für das erste Jahr) nutzen möchte, der hat nichts zu befürchten: Amazon bucht nichts von der Kreditkarte ab. Wer mehr in Anspruch nimmt, der wird dann aber über diese Zahlungsmethode belastet.
Das Anmelden erfolgt für die kostenlose Variante über die AWS-Seite.

Hier finden sich auch alle Angebote, die in der kostenlosen Variante zur Verfügung stehen. Es geht in diesem Test um das EC2-Angebot. Hier steht eine „Micro-Instanz“ für Windows zur Verfügung.

Das Anmelden geht über die Mail-Adresse, man muss sich als neuer Benutzer registrieren und dazu ein Passwort angeben. Dabei handelt es sich sozusagen um das „Stammkonto“ für die eigene Präsenz. Später lassen sich mit Hilfe von IAM-Funktionen (Identity Access Management) auch untergeordnete Konten – in der Regel mit reduzierten Berechtigungen, wie etwa „Read-Only“ – noch festlegen.

Dann sind die persönlichen Daten für das Konto einzutragen und der obligatorische Hinweis auf die Kundenvereinbarungen liegt vor. Die muss man bestätigen und dann wird im nächsten Schritt die Kreditkarte abgefragt. Dann lassen sich noch die Rechnungsadresse ändern und die Umsatzsteuer-ID kann angegeben werden.

Für die Verifizierung der Identität hat der Anwender noch die eigene Teefonnummer anzugeben. Danach erfolgt ein automatischer Anruf an diese Telefonnummer, in dem eine vierstellige PIN angesagt wird. Diese PIN muss man dann auch wieder am Browser eingeben – und damit ist die Verifizierung der Identität für das AWS-Konto erfolgt.

Danach wird eine Mail an die angegebene Adresse gesendet und zudem wird von Amazon getestet, ob die Kreditkarte auch korrekt funktioniert. Dazu zieht Amazon einen Dollar ein und überweist ihn dann wieder zurück. Sind diese „Formalitäten“ abgeschlossen, ist das Konto endgültig aktiviert. Im Test hat das etwa 20 Minuten gedauert. Nach dieser Zeit kann der Benutzer sich erneut bei AWS anmelden und über sein Konto die gewünschten Aktionen ausführen.

Routine im Anmelden kommt schnell

Dazu muss man sich erneut anmelden und dann im Startdialog (siehe Bild 1) oben auf Konto/AWS Konsole klicken. Nach einer erneuten Anmeldung an der AWS-Konsole (wieder dasselbe Kennwort und denselben Kontennamen) stehen dann die Dienst von AWS bereit – allerdings derzeit alles in englischer Sprache (Bild 3).

Im konkreten Fall geht es um das Erstellen einer Windows-Server-Instanz, daher ist EC2 unter der Kategorie „Computer & Networking“ der Dienst der Wahl. Dann erscheint ein Dialog, wie er in Bild 3 zu sehen ist.

Hier ist nun die Region anzugeben – also in welchen Rechenzentrums-Cluster die virtuelle Maschine später laufen soll. Für europäische Anwender empfiehlt sich die europäische Region (genauer Irland). Amazon verspricht dabei auch, dass keine Daten aus einer Region in eine andere verschoben werden. Somit bleiben die Daten in der EU – solange nicht ein Zugriff seitens der US-Regierung auf die Daten erfolgt, die bei US-Unternehmen wie Amazon letztendlich den „legalen“ Durchgriff haben.

Assistenten vereinfachen das Erzeugen der Instanz

Das Erstellen einer Instanz geht über den blau hinterlegten Punkt „Launch Instance“. Dabei helfen einem die Assistenten weiter: Ein Classic Wizard, ein Quick Launch Wizard und ein AWS Marketplace Wizard stehen dazu bereit (siehe Bild 4). Hier ist in dieser Testsituation der klassische Assistent die beste Wahl, denn es soll ja eine Windows-Server-Instanz erstellt werden. Wer vorgefertigte Software vom Marketplace beziehen möchte, kann das aber über den anderen Assistenten machen.

Die Basis-Images für die Instanzen tragen bei Amazon den Namen AMIs (Amazon Machine Images). Für den Start sollte man möglichst auf geprüfte AMIs zurückgreifen – also auf AMIs, die von Amazon selbst bereitgestellt werden. Wer Images von anderen Kunden verwenden möchte, sollte sich bewusst sein, dass diese Images unter Umständen nicht komplett getestet worden sind und daher womöglich nicht besonders zuverlässig sind.

Mit der Wahl aus der Kategorie „Quickstart“ ist man gut beraten, hier stehen vielzählige AMIs bereit. Dazu gehört auch der Microsoft Windows Server 2012 Base (eine Standard Edition in englischer Sprache), der hier im Test gewählt wird. Der gelbe Stern verdeutlicht, dass diese VM auch im Rahmen des kostenlosen Angebotes bereit steht, wenn man eine „Micro Instanz“ einsetzt. Als Größe für das Root Device gibt Amazon hier mit 30 GByte an – eine Minimalvorgabe, die für kleinere lasten ausreicht, aber für ein Produktivsystem eher selten geeignet ist.

Nach dem Klick auf „Select“ bei Windows Server 2012 erschein ein weiterer Dialog. Hier lassen sich noch verschiedene VM-Typen spezifizieren. Als T1 wird die Micro-Instanz bezeichnet, die im ersten Jahr kostenlos zur Verfügung steht. In Bild 6 sind weitere Optionen aufgeführt, die für die VM gelten könnten – dann aber entsprechende Kosten nach sich ziehen.

Bei der Availability Zone kann man innerhalb einer Region die komplette Trennung der Ressourcen angeben – Sinn macht das aber beim Erstellen einer einzigen Instanz nicht und wird daher hier auf „No Preference“ belassen.

Im nächsten Schritt kann man weitere Details angeben. Unter anderem ist ein Monitoring machbar – doch das kostet zusätzlich, bleibt hier im Test daher nicht aktiviert. Im Feld User Data kann man – bei Windows-Instanzen – Powershell-Skripte eintragen (als Text oder als Datei). Zudem ist anzugeben, was beim Herunterfahren (Shutdown) der VM passieren soll.

Als Voreinstellung ist „Stop“ eingetragen, sprich die VM wird angehalten, doch der Speicherplatz für die VM bleibt belegt. Bei „Terminate“ wird die Instanz komplett gelöscht. Beim Punkt IAM-Rollen lassen sich dann auch spezielle Zuweisungen machen. Die sind hier im Test allerdings nicht nötig.

Kostenloses Root Device darf 30 GByte groß sein

Im nächsten Dialog ist noch die Größe des Root Devices anzugeben. Standardmäßig sind das bei einer Windows-Server-Instanz die bereits kommentierten 30 GByte – das Maximum im kostenlosen Angebot. Im folgenden Dialog kann der Anwender noch Bezeichnungen vergeben. Das sind die sogenannten „Tags“. Mit ihrer Hilfe kann er die einzelnen VMs dann zu seinen eigene Projekten zuordnen, so dass er später bei der Abrechnung weiß, was jede VM gekostet hat und zu welchen internen Projekt er sie verrechnen muss.

Dann kommt ein wichtiger Dialog: Es geht um das Key Pair. Mit diesem Schlüsselpaar hat der Anwender die Möglichkeit, sich auf seiner Instanz einzuloggen. Im Normalfall ist daher diese Information unbedingt nötig. Nur wer die Instanz komplett automatisch – also über Skripte gesteuert – verwenden will, der braucht das Schlüsselpaar nicht.

Dabei muss man zuerst einen Namen eingeben und dann die entsprechende Datei herunterladen. Diese Datei (Format: .pem) sollte der Anwender sicher verwahren, denn nur mit diesen Infos gelingt das Anmelden an der Instanz. Auch der Support von AWS hat keinen Zugriff, wenn man ihm nicht diesen Schlüssel geben kann.

Der nächste Schritt ist das Erstellen einer Sicherheitsgruppe (Bild 10). Das entspricht einer Firewall, die auf der Ebene von AWS (nicht auf der Betriebssystemebene in der VM) nur die nötigen Ports freigibt. Hier ist ein Name zu vergeben und eine aussagekräftige Beschreibung. Standardmäßig schlägt das System bei Windows-VMs vor, dass 3389 für RDP geöffnet wird, alle anderen Ports sind dicht.

Bei der Quell-Adresse kann man hier auch IP-Adressen eingeben, damit man zum Beispiel nur den Zugriff aus der eigenen Firma auf die VM erlaubt. Es lassen sich auch weitere Ports öffnen, wenn man zum Beispiel einen Webserver betreiben möchte, kann man noch die http-Ports aufmachen. Im Test ist hier nur RDP nötig. Im nächsten Dialog zeigt das System den Anwender nochmals alle gemachten Einstellungen für die zu erstellende Instanz. Mit einem Klick auf „Launch“ legt das System los und erstellt die Windows-2012-Instanz.

Das wird einige Minuten dauern, das zeigt zumindest der nächste Dialog. In der Zwischenzeit kann der Anwender auch die Alarme überprüfen, die beim Erstellen der Instanz anfallen. In Bild 13 ist dann in der Konsole der Zustand der Instanz zu sehen. Im Test hat das Initialisieren der Instanz etwa vier Minuten gedauert. Mit einem Klick auf den Refresh-Button (oben rechts in der Konsole) wird dann der neue Zustand angezeigt.

Verbinden mit der neuen Instanz

Die Verbindungsaufnahme mit der frisch angelegten Instanz erfolgt bei Windows-VMs mit dem RDP (Remote Desktop Protocol). Hier muss der private Key verwendet werden, um das Admin-Kennwort zu entschlüsseln. Die Verbindungsaufnahme über ein anderes System und via RDP (im Test war das einmal ein MacBook Air mit installiertem RDP sowie ein Windows-7-PC mit RDP) benötigt einige Vorarbeiten.

Zuerst muss der Anwender in der Management-Konsole auf die laufende Instanz gehen und dort mit einem rechten Mausklick das Kontextmenü öffnen. Hier ist dann der Punkt Connect anzugeben. Dann erscheint ein Dialog, wie er in Bild 14 zu sehen ist. Hier muss man dann auf den Link „Retrieve Password“ klicken. Dann ist die Datei mit dem Private Key anzugeben (die .pem-Datei zuvor heruntergeladen wurde).

Dann ist auf „Decrypt Password“ zu klicken (Bild 15). Danach ist dann das Kennwort für das Administrator-Konto zu sehen. Diese Informationen zusammen mit dem DNS-Namen für die VM sind dann für das Etablieren der RDP-Session nötig.

Anschließend "mosert" RDP zwar, weil ein falsches Zertifikat angegeben wurde, doch das kann man vernachlässigen und dann wird die Verbindung zur Windows Server 2012 Instanz hergestellt. Anschließend lässt sich zum Beispiel der Servermanager starten. Damit kann der Administrator den Server wie gewünscht konfigurieren. Wichtig ist hier vor allem, dass man die ausstehenden Updates für das Server-Image einspielt.

Danach ist der Test abgeschlossen und die VM kann beendet werden. Beim normalen Stop wird sie nur angehalten, nur das „Terminated“ würde dazu führen, dass sie komplett „zerstört“ wird. Die kostenlose Micro-Variante darf man ruhig nur anhalten – Kosten fallen nicht an. So zumindest das Versprechen von Amazon.

Vergleich mit Azure

Im Vergleich zu den bereits getesteten Arbeiten mit Microsofts Azure und einem Start einer Instanz mit Windows Server 2012 ist festzustellen: Bei Azure ist eine deutsche Version des Servers in der VM machbar – bei Amazon habe ich kein entsprechendes Image gefunden. In Bezug auf die Sicherheit und das Anlegen eines Kontos für AWS sind bei Amazon mehr Hürden zu überwinden – ob das zu mehr Sicherheit führt sei dahingestellt.

Rainer Huttenloher