Mit Cloud-Computing lässt sich eine Infrastruktur in Form von virtuellen Servern oder Load Balancern digital zur Verfügung stellen (Infrastructure-as-a-Service). Zudem können Plattformen zur Entwicklung und zum Betrieb von Applikationen (Platform-as-a-Service) sowie Applikationen, die direkt „on the fly“ in und aus der Cloud genutzt werden können (Application-as-a-Service), bezogen werden.

Nicht selten werden Public Clouds jedoch als Rettungsanker für fehlende Innovation, veraltete Systeme und die Auslagerung von IT-Know-how gesehen. IT-Entscheider sollten sich daher der Vor- und Nachteile eines Wechsels in eine Public Cloud bewusst sein. Während die meisten Vergleiche nur auf technische Aspekte abzielen, analysiert dieser Artikel die Services der drei großen Cloud-Anbieter Amazon Web Services, Google Cloud und Microsoft Azure aus Management-Sicht.

Unterschieden werden diverse Cloud-Modelle. In einer Public Cloud teilen sich mehrere Nutzer die gleichen (Rechen-)Ressourcen. Public-Cloud-Angebote umfassen meist standardisierte Dienste, die günstiger sind als Dienste und Server mit hohem Individualisierungsgrad, und deren Rechenpower nur jeweils einem Nutzer dediziert zur Verfügung steht.

Die Gründe für einen Wechsel in eine Public-Cloud-Umgebung können vielfältig sein. Unternehmen führen in der Praxis häufig eines oder mehrere der folgenden fünf Argumente für einen Wechsel auf:

1. 1. Kostenersparnis
   2. Erhöhte unternehmerische Agilität und Skalierbarkeit
   3. Hohe Verfügbarkeit
   4. Auslagerung von Verantwortung
   5. Einkauf von Know-how in Form von professionellen Cloud-Services

Oft spielt auch eine Rolle, dass IT-Entscheider den Zug des Cloud-Zeitalters nicht verpassen wollen. Um eine objektive Entscheidung für die Zukunft der Unternehmens-IT zu treffen, ist es daher umso wichtiger, diesbezüglich alle Vor- und Nachteile zu kennen.

Amazon Web Services (AWS): Amazon startete 2002 mit einem ersten Public-Cloud-Angebot. Dazu gehörte unter anderem ein Datenspeicher. Seit 2006 bietet Amazon mit der Elastic Compute Cloud (EC2) die Möglichkeit, Cloud Server anzumieten.

Microsoft Azure: Microsoft bietet seit 2010 Clouddienste mit einer Vielzahl an Microsoft-Produkten an. Analog zu AWS lassen sich auch in der Microsoft-Cloud Server mit Linux-Betriebssystem betreiben.

Google Cloud: Das erste Cloud-Angebot von Google ist seit 2008 verfügbar und ermöglichte in der initialen Version die Ausführung von Python- und Java-Applikationen in der Cloud. Seit 2013 lassen sich Cloudserver mit diversen Betriebssystemen anmieten.

Alle Anbieter offerieren ein breites Portfolio mit einer Vielzahl an Services, die sich miteinander kombinieren lassen. Von Cloud-Servern, Datenbanken sowie Daten- und Langzeitspeichern über Content-Delivery-Networks, Load-Balancer bis hin zu Big-Data-Analysetools. Sämtliche Features sind für IT-Administratoren komfortabel zu bedienen, sodass schwarze Konsolenfenster und kryptische Zeichenketten zumindest zum Teil der Vergangenheit angehören. Es ist daher kein Wunder, dass das Thema Cloud in der Unternehmensstrategie immer häufiger nicht primär durch das Management angetrieben, sondern durch IT-Abteilungen beziehungsweise die zugehörigen Mitarbeiter selbst ins Leben gerufen wird, weil diese im privaten Umfeld oder in Projekten bereits mit Cloud-Diensten arbeiten.

Die Migration bestehender Anwendungen ist je nach deren Alter und Programmierung mit wenig Freude verbunden. Bei einem Wechsel der Betriebsumgebung fallen immer Migrationsaufwand und Kosten an. Ein Umzug in eine Public Cloud der drei Anbieter bedingt meist etwas höhere Migrationskosten als bei einer individuell angepassten Umgebung, da unter anderem die Anwendungen auf ein Set an die standardisierten Services angepasst werden müssen. Die Applikationen lassen sich zwar in der Regel in der Public Cloud wie zuvor betreiben, Vorteile wie Skalierbarkeit und automatisierte Deployments gehen dann allerdings verloren. Daher ist eine Anpassung der Applikationen ratsam.

Die Berechnung der voraussichtlichen Kosten zum Betrieb der eigenen IT-Infrastruktur bei AWS, Google Cloud oder Microsoft Azure stellt keine einfache Aufgabe dar. Alle Anbieter haben ein komplexes Preismodell, das oft Staffelungen und viele unterschiedliche Positionen beinhaltet. So unterscheiden Microsoft und Google bei den Datentransfer-Preisen nach Destination. Bei Amazon werden Load Balancer nicht nur pro Stunde, sondern auch nach verbrauchten Load Balancer Capacity Units berechnet. Eine Vorhersage über die Kosten ohne ein technisches Konzept und voraussichtliche Verbrauchswerte ist meist nur eingeschränkt möglich. Ein detaillierter Ressourcenplan verbunden mit der passenden Cloud-Strategie zur Auswahl der richtigen Komponenten und Struktur stellt hingegen eine gute Basis für die Kalkulation der Cloud-Betriebskosten dar.

Kostenvorteile ergeben sich besonders dort, wo Server nur temporär gestartet werden, um Lastspitzen aufzufangen. Hier profitiert man von der stunden- (AWS und Azure) oder minuten-genauen Abrechnung (Google). Bei Umgebungen mit 24/7-Betrieb und geringer Nutzung der Skalierungsfunktionen werden die Kostenvorteile weitaus geringer ausfallen.

Die Personalkosten für das Management der Server und der sonstigen Infrastruktur ändern sich in den meisten Fällen nur geringfügig, da der zeitliche Aufwand etwa gleichbleibend ist. Auch in der Cloud mit allen Automatisierungsmöglichkeiten bedarf es Administratoren, die die Infrastruktur kennen, überwachen, warten und weiterentwickeln. Dieser Punkt wird bei der initialen Kostenkalkulation für den Cloud-Betrieb oft vergessen. Durch die Umstellung von Applikationen auf einen Cloud-Einsatz und die Etablierung eines hohen Automatisierungsgrads lassen sich bei großen Umgebungen jedoch langfristig Kosten sparen. Dies geht – sofern noch keine Umstellung erfolgt ist – mit einem Technologiewechsel und einem Umdenken in der IT einher. Kosten lassen sich immer dort sparen, wo Server nicht einzeln gepflegt werden müssen, sondern automatisiert mit neuer Konfiguration erstellt werden können. Dies erfordert jedoch die Unterstützung durch alle involvierten IT-Systeme.

Entscheidend bei der Beurteilung eines Hosting-Vertrags sind die Service Level Agreements (SLAs). Bei der Analyse der drei Anbieter gilt es speziell die folgenden Bedingungen zu beachten:

Preisanpassungen möglich: Amazon, Microsoft und Google stehen in einem starken Wettbewerb zueinander. Deshalb sind momentan keine großen Preissteigerungen zu erwarten. Alle Cloud-Anbieter halten sich jedoch das Recht vor, ihre Preise binnen dreißig Tagen frei zu ändern. Langfristig besteht daher das Risiko höherer Preise.

Deutsches Recht wird nicht angewendet: Bei keinem Anbieter gilt für die Vertragsbedingungen deutsches Recht. AWS nutzt das Recht des US-amerikanischen Bundesstaats Washington, Google Cloud das des Bundesstaats Kalifornien und Microsoft Azure agiert auf Basis von irischem Recht.

Unterschiedliche Verfügbarkeitszusagen: Branchenüblich weisen alle Anbieter für Cloud-Server SLAs mit Verfügbarkeitszusagen aus. Hier unterscheidet sich speziell die Erstattungssumme für ausgefallene Services:

Google Cloud

• 99,00 Prozent bis < 99,95 Prozent Verfügbarkeit – Erstattungssumme: 10 Prozent
• 95,00 Prozent bis< 99,00 Prozent Verfügbarkeit – Erstattungssumme: 25 Prozent
• weniger als 95,00 Prozent Verfügbarkeit – Erstattungssumme: 50 Prozent

AWS

• 99,95 Prozent bis 99,00 Prozent Verfügbarkeit – Erstattungssumme: 10 Prozent
• weniger als 99,00 Prozent Verfügbarkeit – Erstattungssumme: 30 Prozent

Azure

• weniger als 99,95 Prozent Verfügbarkeit – Erstattungssumme: 10 Prozent
• weniger als 99 Prozent Verfügbarkeit – Erstattungssumme: 25 Prozent
• weniger als 95 Prozent Verfügbarkeit – Erstattungssumme: 100 Prozent

Microsoft liegt mit einer Erstattung von bis zu einhundert Prozent deutlich vor der branchenüblichen Erstattung von maximal fünfzig Prozent, wie sie Google anbietet.

Die Verfügbarkeitszusage und mögliche Erstattungsansprüche finden nur Anwendung, wenn sehr spezielle Rahmenbedingungen eingehalten werden. Zudem muss bei allen Anbietern ein Ausfall unter Vorlage hinreichender Aufzeichnungen belegt werden. Aus juristischer Sicht ist daher ein eigenständiges Monitoring-System unerlässlich.

Bei der Betrachtung dieses beispielhaften Ausschnitts der Service Level Agreements wird bereits deutlich: Die SLAs sind deutlich zugunsten der Anbieter verfasst. Es gibt diverse Schlupflöcher, die sie sich offenhalten. Eine Erstattung bei einem Ausfall erscheint eher als ein Akt des guten Willens und der Kundenbindung. Sollte es sich um eine betriebskritische Infrastruktur handeln, deren Ausfall einen großen Einfluss auf das tägliche Business hat, wäre von der Nutzung einer der drei Public Clouds abzuraten. Insbesondere Microsoft zeigt daher Kooperationswillen und ermöglicht zumindest Kunden mit potenziell hohen Umsatzzahlen die Verhandlung individueller SLAs. Auch bei den anderen Providern ist davon auszugehen, dass sie zumindest ihren größten Kunden individuelle SLAs anbieten oder in Zukunft vermehrt anbieten werden. Kunden mit kleinen Umgebungen bleiben hingegen auf der Strecke.

Das Public-Cloud-Konzept der drei Anbieter und die günstigen Preise gehen mit einer Verlagerung der Verantwortung einher: Der Kunde trägt das Risiko für Ausfälle mit, indem er selbst eine Infrastruktur schaffen muss, die potenziellen Ausfällen standhält. Ob die Standard-SLAs ausreichend sind, hängt vom jeweiligen Projekt ab. Mit einem guten Cloud-Konzept, das eine Verteilung über mehrere Standorte vorsieht, kann dem Risiko entgegengewirkt werden.

Verfügbarkeitszusagen und Gutschriften (sogenannte Service Level Credits) sollten in keinem SLA fehlen, sie helfen allerdings im Moment des Ausfalls wenig. In den meisten großen Unternehmen ist ein Arbeiten ohne die technische Infrastruktur kaum noch möglich. Interne Systeme müssen immer verfügbar sein, sonst steht der Betrieb. Daher stellt sich die Frage, wie verlässlich die angebotenen Public Clouds tatsächlich sind.

Verschiedene Websites wie Cloudharmony von Gartner bieten die Möglichkeit, die Verfügbarkeiten der letzten Wochen oder Monate zu vergleichen. Studiert man die Statistiken der vergangenen Jahre, so lässt sich feststellen, dass alle Clouds relativ verlässliche Ergebnisse liefern, kurze Downtimes einzelner Standorte jedoch dazugehören (siehe https://cloudharmony.com/status), weswegen eine Infrastruktur auf mindestens zwei Availablity-Zones essenziell ist. Bei besonders kritischen Applikationen, wie Finanzportalen, bei denen schon ein kleiner Ausfall verheerende Folgen hat, ist der Aufbau einer vernetzten Infrastruktur unter Einbeziehung der Ressourcen von zwei Public-Cloud-Anbietern ratsam.

Zusammenfassend lässt sich sagen, dass aufgrund der Flexibilität und Kombinationsmöglichkeiten von Standorten und Cloud-Anbietern eine hohe Verfügbarkeit erreicht werden kann. Diese entsteht jedoch in der Hauptsache durch ein durchdachtes Konzept für die Gesamtinfrastruktur, das in Kundenhand liegt und final auch eine Budgetfrage ist. Beim Betrieb der eigenen Infrastruktur in zwei Availablity-Zones mit automatischem Failover ist im Normalfall mit branchenüblichen Verfügbarkeiten über achtundneunzig Prozent pro Monat zu rechnen. Bei einem Ausfall bedarf es eigener Administratoren, die die in der Cloud betriebenen Systeme 24/7 überwachen und im Fehlerfall sofort reagieren. Die Cloud-Provider werden bei einem Ausfall schnell aktiv, reparieren jedoch nur die eigene Cloud-Infrastruktur. Die Überwachung, ob alle Systeme automatisiert wieder hochfahren und sich wie gewünscht verhalten, bleibt dem Kunden überlassen.

Die Public Cloud ermöglicht es, flexibel auf neue Anforderungen zu reagieren. Bestands-Ressourcen können mit wenigen Einschränkungen beliebig erweitert und neue Ressourcen hinzugezogen werden. Gleichzeitig sind fast alle Leistungen flexibel zur nächsten vollen Stunde kündbar. In der Praxis werden neue Ressourcen meistens zum Abfangen von Lastspitzen (etwa durch eine Werbekampagne) temporär hinzugebucht. Entwickler können zudem kurzfristig benötigte Instanzen per Knopfdruck erzeugen und nach Abschluss des Entwicklungsschrittes wieder stoppen.

Durch die Optimierung und Anpassung der eigenen Software lässt sich ein Teil der Abhängigkeit vom jeweiligen Public-Cloud-Anbieter (Lockin-Effekt genannt) reduzieren, da die Anwendung nicht mehr von speziellen Komponenten abhängig ist und idealerweise in einem Container liegt, der auf jeder Plattform betrieben werden kann. Wurde dies konsequent umgesetzt, lässt sich die eigene Umgebung leichter auf einen anderen Provider portieren.

Zu bedenken ist, dass die Leistungen der Anbieter nicht zu einhundert Prozent identisch sind. Die detaillierten Konfigurationsmöglichkeiten von Load-Balancern, Speichermedien, Datenbanken und anderen Komponenten sowie die APIs (API gleich Application Programming Interface) zur Verwaltung unterscheiden sich an einigen Stellen. Zudem sind die Größen und Leistungsdaten der VMs nicht standardisiert. Es sollte daher genau geprüft werden, welcher Aufwand einem Plattformwechsel gegenübersteht. Aktuelle Studien zeigen, dass der Aufwand häufig unterschätzt wird und ein Lockin-Effekt aufgrund der proprietären Lösungen der Anbieter und fehlender Standards weiterhin besteht.

Die Anbieter streben jeweils eine Spezialisierung in eine bestimmte Richtung an: Google ist den beiden Konkurrenten im Bereich Big-Data-Analyse weit voraus, Amazon bietet das Portfolio mit den meisten Zusatzleistungen und Microsoft spezialisiert sich im Bereich Windows-Server und Windows-Anwendungen out of the box. Bei sehr spezifischen Leistungen kann es also gut sein, dass diese zumindest nicht im gewohnten Umfang bei der Konkurrenz angeboten werden. Ein Vergleich lohnt sich immer.

Gemäß diverser Studien stellt die Datensicherheit für Unternehmen eines der größten Argumente gegen die Public-Cloud-Nutzung dar. Als Hauptgründe werden die Ungewissheit über Sicherheitslücken, die möglichen Zugriffe Dritter sowie die Angst vor Datenverlusten genannt. Auch in der Wissenschaft ist Cloud-Sicherheit ein heiß diskutiertes Thema. Um hier Vertrauen zu bilden, investieren die Cloud-Anbieter viel Geld in die Entwicklung von Sicherheitsmechanismen. Bereits heute ist davon auszugehen, dass das Sicherheitsniveau der Clouds von Amazon, Google und Microsoft sehr hoch ist.

Ein viel größeres Risiko stellt eine Fehlkonfiguration durch den Nutzer oder Administrator dar. So gab es allein in diesem Jahr mehrere Vorfälle wie zum Beispiel der, über den Forbes berichtete, bei denen Kundendaten auf unerwünschte Weise zugänglich wurden. Administratoren müssen daher ein gutes Verständnis für die von den Cloud-Anbietern bereitgestellten Sicherheitsvorkehrungen haben, um einen angemessenen Schutz für die gespeicherten Daten zu etablieren.

Der Aufbau einer Infrastruktur, die der neuen EU-Datenschutz-Grundverordnung (EU-DSGVO) genügt, ist möglich, wobei es einige Aspekte zu beachten gilt und auch dort die Verantwortung für die korrekte Nutzung der Cloud beim Kunden liegt.

Cloud bedeutet ein Umdenken in der IT und bietet – je nach Projekt – diverse Vorzüge. Public-Cloud-Lösungen von AWS, Azure und Microsoft können den Zugang zu neuen Technologien erleichtern und Kosteneinsparungen ermöglichen. Voraussetzung ist eine vorausschauend geplante Architektur und ein fundiertes Management der Umgebung. Die Services der Anbieter stellen eine solide, sichere Basis für den Betrieb der eigenen Infrastruktur dar. Es bedarf – analog zu jeder anderen Hosting-Form – ebenfalls Administratoren mit dem notwendigen Know-how, um die Umgebung einzurichten und zu verwalten. Niedrige Infrastrukturkosten gehen mit dem Transfer der Verantwortung vom Anbieter zum Kunden einher, der die Redundanz und Datensicherheit fast vollständig selbst verantworten muss. Ein genauer Vergleich der Services von AWS, Microsoft und Google, individuell ausgehandelte SLAs sowie ein fundiertes Migrations-, Sicherheits- und Backup-Konzept sollten daher zwingender Teil jeder Cloud-Strategie sein.