Mit US West (Oregon) steht nun die dritte Region in den USA und damit die sechste Region weltweit auf der Landkarte der Amazon Web Services. Oregon befindet sich im Pazifischen Nordwesten der Vereinigten Staaten. Die neue Region soll damit einen günstigeren Zugriff und eine geringere Latenz aus dem Westen der USA auf die Services von Amazon gewährleisten.

Die Kosten für die neue Region betragen dieselben wie für die Region US East (Northern Virginia).

Folgende Services stehen in der Region US West (Oregon) zur Verfügung:

• Amazon Elastic Compute Cloud (EC2) und die damit verbundenen Services (Elastic Block Store, Virtual Private Cloud, Elastic Load Balancing und Auto Scaling).
• Amazon Simple Storage Service (S3).
• Amazon SimpleDB.
• Amazon Relational Database Service (RDS).
• Amazon Simple Queue Service (SQS).
• Amazon Simple Notification Service (SNS).
• Amazon Elastic MapReduce.
• AWS CloudFormation.
• Amazon CloudWatch.

Neben der Middleware WebMethods hat die Software AG ebenfalls sein Tool für die Prozessmodellierung Aris zertifizieren lassen, so dass beide Anwendungen nun auf Amazon EC2 sowie VMware betrieben werden können. Durch die Portierung auf EC2 sollen bestehende Kunde die Utility-Services Möglichkeiten der Cloud nutzen können. Nach Aussage der Software AG nutzen einige Kunden sogar bereits Lösungen auf VMware Basis, wodurch die jetzige Zertifizierung ihnen nur ein weiteres Maß an Sicherheit gewährleisten soll.

Um WebMethods bzw. Aris auf Amazon EC2 zu nutzen, müssen die Kunden einen separaten Vertrag mit Amazon eingehen. Die Lizenzen würden hingegen von Seiten der Software AG geliefert. Dazu sind die CPU-Lizenzen der Software AG kompatible mit den Virtual Core Lizenzen von Amazon. Was bedeutet, dass ein Kunde seine bestehenden Lizenzen zu Amazon umziehen kann.

Unternehmen können die Amazon Cloud somit für die Entwicklung, Test und Produktion nutzen. Die Software AG erwartet hingegen die meiste Nutzung in den beiden erstgenannten Bereichen.

Development-as-a-Service

Das Hauptziel der Software AG besteht jedoch im Aufbau eines umfangreichen Platform-as-a-Service Angebots. Die PaaS Umgebung wird dazu neben einem Java Application Server (WebMethods) ebenfalls einen In-Memory Cache (Terracotta) beinhalten. Darüber hinaus soll dem PaaS eine IDE (Integrated Development Environment) einverleibt werden, was aus dem Platform-as-a-Service im Grunde genommen ein Development-as-a-Service macht.

Hinzu kommt eine Kollaborationsschicht, die es virtuellen Teams ermöglichen soll gemeinsam, in Echtzeit und ortsunabhängig miteinander zu arbeiten.

Wann der PaaS erscheint steht derzeit noch nicht fest, jedoch befindet sich das nächste Major Release für WebMethods in den Startlöchern.

MFA erweitert die Nutzung der Amazon Web Services um eine weitere Sicherheitsfunktion. So kann sich ein Benutzer neben seinem Benutzernamen und einem Passwort zusätzlich mit einem Authentifizierungscode ausweisen, bevor er sich letztendlich anmeldet.

Bisher standen Administratoren Hardware Tokens zur Verfügung, mit denen Sie ad-hoc Authentifizierungscodes erstellen konnten. Mit der neuen Option können nun auch Smartphones, Tablets oder normale Computer verwendet werden, auf der eine Anwendung betrieben werden kann, welche den offenen OATH TOTP (Open Authentication Time-Based One-Time Password) Standard unterstützt, um darüber die Codes zu generieren.

Die Nutzung der Software ist deutlich günstiger, bequemer und flexibler als der 13 Dollar teure Hardware Token.

Die AWS Virtual MFA Application steht im Amazon Appstore bzw. dem Android Market zum Download bereit. Amazon stellt auf seiner Webseite darüber hinaus eine Liste mit alternativen Anwendungen für iPhone und Blackberry Nutzern bereit.

Hierfür hat Amazon eine Webseite geschaffen, auf der Whitepapers zum Download bereitstehen, die dabei helfen, fehlertolerante Anwendungen zu entwickeln und Cloud Architekturen zu verstehen.

An dieser Stelle ist es sehr interessant zu sehen, dass die Whitepapers bereits im Jahr 2010 bzw. im Januar 2011 erstellt oder aktualisiert wurden.

AWS Cloud Architecture Best Practices Whitepaper – Read

Dieses Whitepaper gibt einen technischen Überblick aller AWS Services und verschiedener Best Practice Ansätze für die architektonische Gestaltung, um damit effiziente und skalierbare Architekturen zu entwerfen.

Building Fault-Tolerant Applications on AWS Whitepaper – Read

In diesem Whitepaper werden Funktionen für die Erhöhung der Fehlertoleranz vorgestellt, die dazu dienen, um hoch zuverlässige und hochverfügbare Anwendungen innerhalb der AWS Cloud zu entwickeln.

Web Hosting Best Practices Whitepaper – Read

Dieses Whitepaper überprüft detailliert Lösungen für das Web Application Hosting. Dazu gehört unter anderem, wie jeder AWS Service genutzt werden kann, um eine hochverfügbare und skalierbare Webanwendung zu entwerfen.

Leveraging Different Storage Options in the AWS Cloud Whitepaper – Read

Dieses Whitepaper dient dazu, einen Überblick über die Speichermöglichkeiten in der AWS Cloud zu geben und darüber hinaus Szenarien vorzustellen, um eine effektive Nutzung zu erzielen.

AWS Security Best Practices Whitepaper – Read

In diesem Whitepaper werden bestimmte Tools, Funktionen und Richtlinien beschrieben, um zu verstehen, wie Cloud Anwendungen innerhalb der AWS Infrastruktur von Grund auf geschützt werden können.

Source: http://aws.amazon.com/architecture

Aus diesem Grund ist es nicht nachvollziehbar, dass diese Unternehmen mit dem Finger auf Amazon zeigen und sagen: “Uns trifft keine Schuld, Amazon ist down!”. Es wäre interessant zu wissen, wer zur Rechenschaft gezogen worden wäre, hätten diese Anbieter keinen Public Cloud Service genutzt, sondern betrieben ein eigenes Rechenzentrum. Denn eines ist klar, (solche) Probleme können in jedem Rechenzentrum auftreten und hätten dann bedeutend schwerwiegendere Probleme. Und wenn die Cloud richtig genutzt worden wäre, wären auch die Probleme bei Amazon in der Form nicht sichtbar geworden.

Was ist passiert?

Hintergrund
Die Amazon Cloud besteht aus mehreren Regionen, verteilt über mehrere Kontinente, in denen sich wiederum mehrere sogenannte Availability Zones befinden. Availability Zones sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Availability Zones nicht betroffen sind.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Availability Zones ausgeführt werden.

Wie das Konzept genau funktioniert, kann unter Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen nachgelesen werden.

Das Problem
Um 1:41 AM PDT begann das Problem mit Latenzen und Fehlerraten innerhalb der EBS Volumes und Verbindungsproblemen zu den EC2 Instanzen in mehreren Availability Zones der Region US-EAST-1.

Das führte dazu, dass die Webseiten bzw. Webanwendungen, die auf den EC2 Instanzen betrieben werden, nicht mehr erreichbar waren.

Design For Failure

Zunächst muss eines klar sein. Amazon stellt “nur” virtuelle Ressourcen zum Aufbau einer eigenen virtuellen Infrastruktur bereit. Amazon ist NICHT für die Anwendung und deren Funktionalität zuständig, sondern stellt nur die Infrastruktur bereit, auf der die Anwendungen ausgeführt werden.

“Everything fails, all the time” Werner Vogels, CTO Amazon.com

Aus diesem Grund rät Amazon: “Design for failure!” und gibt Tipps, dieses umzusetzen:

• Avoid single points of failure
• Assume everything fails, and design backwards
• Goal: Applications should continue to function even if the underlying physical hardware fails or is removed or replaced.

Und nennt Möglichkeiten für die Realisierung des Designs:

• Use Elastic IP addresses for consistent and re-mappable routes
• Use multiple Amazon EC2 Availability Zones (AZs)
• Create multiple database slaves across AZs
• Use Amazon Elastic Block Store (EBS) for persistent file systems

Design for failure! Ist im Prinzip nichts Neues. Im Grunde sollte das ebenfalls bei jedem anderen nicht Cloud Anbieter und im eigenen Rechenzentrum beachtet werden. Der Entwickler sollte immer in der Pflicht stehen, seine Anwendung gegen Hardware oder sonstige Ausfälle abzusichern und die Verfügbarkeit sicherzustellen.

Hootsuite und Mobypicture bspw. haben den Fehler gemacht, sich nur auf eine AWS Region zu konzentrieren, anstatt ihren Service über die gesamte Amazon Cloud hinweg zu verteilen. Speziell bei Mobypicture, als einen europäischen Anbieter mit Sitz in Holland, ist genau dies ein wenig verwunderlich. Die deutsche Seite von Foursquare hingegen war bspw. erreichbar und lief stabil, ebenso die von Reddit.

Nicht alles auf eine Karte setzen

Für jedes Unternehmen, das seinen Service über die Cloud anbietet, gilt es daher: “Nutze die gesamte Cloud eines Anbieters und verlasse Dich nicht nur auf einen einzigen Anbieter!”

Durch die Verteilung einer Anwendung über mehrere Regionen und Availability Zones bei einem Anbieter wird die Verfügbarkeit der Anwendung drastisch erhöht. Zudem ist eine MultiVendor Strategie zwingend erforderlich. Außerdem müssen bereits von Beginn an Fallback Szenarien entwickelt werden, um gegen einen plötzlichen Ausfall vorbereitet zu sein.

Es geht also bspw. darum, Systeme aufzubauen, die im Fehlerfall automatisch eine gespiegelte Infrastruktur bei einem anderen Anbieter aufbauen. Besser wäre es, mehrere Anbieter parallel zu nutzen und die Services über mehrere Anbieter hinweg zu verteilen. Dazu gehört z.B.: Instanzen von unterschiedlichen Anbietern parallel produktiv einzusetzen, um damit das Risiko zu streuen.

Denn: Cloud Computing löst nicht alle Probleme automatisch…

Für die Zukunft

Amazon darf auf keinen Fall von einer Schuld freigesprochen werden, dazu werben sie viel zu deutlich mit der eigenen Verfügbarkeit. Dennoch, beim Cloud Computing handelt es sich um bedeutend mehr als nur das Nutzen von ein paar virtuellen Ressourcen und jeder Nutzer der Cloud ist für die Verfügbarkeit seiner Anwendung selber verantwortlich. Dafür stehen ihm ausreichend Mittel und Wege auf Grund der Cloud zur Verfügung!

IBMs “Smart Business Clouds” (SmartCloud) bestehen aus den eigenen vorkonfigurierten x64-basierten CloudBurst Stacks und werden in einer Vielzahl von Cloud Rechenzentren überall auf der Welt betrieben. IBM unterscheidet seine SmartCloud in den Angeboten Enterprise und Enterprise+, die von den IBM’s Global Technology Services vertrieben werden.

Die bereits verfügbare “SmartCloud Enterprise” Infrastruktur umfasst ausschließlich x64-basierte Server und bietet ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,5%. Weiterhin unterstützt IBM auf seinen virtuellen Maschinen 32-bit und 64-bit Betriebssysteme wie Microsoft Windows 2003 und 2008, Red Hat Enterprise Linux 5.4 und 5.5 und Novell SUSE Linux Enterprise 11

Die “SmartCloud Enterprise+” Infrastruktur wird in der zweiten Jahreshälfte von 2011 erwartet. Kunden erhalten hier die Möglichkeit, x64 basierte oder Power Server zu kaufen, auf denen sie ihre Anwendungen betreiben können. Hier erhöht IBM zudem seine SLAs auf 99,9% Verfügbarkeit

Im Gegensatz zu seinem Angebot “Smart Business Development and Test on the IBM Cloud”, bei dem IBM als Hypervisor auf eine RedHat/ KVM Kombination setzt, nutzen die “SmartClouds” den VMware ESXi Hypervisor. Um auch Kunden zu bedienen, die auf andere Hypervisor setzen als den von VMware, wird IBM dazu übergehen müssen, ebenfalls KVM und Microsofts Hyper-V zu unterstützen. Auf den Power Servern in der “SmartCloud Enterprise+” setzt IBM auf seinen eigenen PowerVM Hypervisor und unterstützt hier die Betriebssysteme AIX Unix, Red Hat Enterprise Linux, sowie den SUSE Linux Enterprise Server.

Die Abrechnung der SmartClouds erfolgt pro VM pro Stunde. Zudem steht ein Softwarekatalog bereit, aus dem sich Kunden IBM spezifische Anwendungen wie Middleware, Groupware und Datenbanken, sowie Anwendungen von Drittanbietern wie die Cloud Management Software von Kaavo oder Plattformen zur Entwicklung von Webanwendungen wie von Aviarc, beziehen können.

Die Preise für die SmartClouds sind ebenfalls öffentlich. Vergleichbar mit Amazons EC2 rechnet IBM auch hier on-Demand ab und bietet seinen Kunden Optionen auf reservierte Kapazitäten. Das “SmartCloud Enterprise+” Angebot hingegen wird nicht stündlich on-Demand abgerechnet. Hier muss sich der Kunde entweder für eine monatliche Abrechnung oder einen festen Vertrag mit Laufzeit entscheiden. Jedoch stehen ihm hier weitere Managed Services, sowie mehrere Sicherheitsstufen zur Verfügung.

Wie ebenfalls von Amazon EC2 bekannt, kann ein Kunde auch bei den “SmartClouds” zwischen unterschiedlichen Konfigurationen von virtuellen Maschinen wählen. Je nach Leistungsstufe wird hier von Copper bis Platinum unterschieden.

Für eine 32-bit Konfiguration kann je nach Leistungsstufe zwischen 1 bis 4 virtuellen CPUs mit 1,25 GHz, zwischen 2GB bis 4GB virtuellen RAM und zwischen 60GB und 350GB virtuellen Instanzspeicher gewählt werden. Für einen Red Hat Enterprise Linux Server und einer Copper Konfiguration berechnet IBM 15.4 Dollar(cent) pro Stunde.

Für eine 64-bit Konfiguration kann je nach Leistungsstufe zwischen 2 bis 16 virtuellen CPUs mit 1,25 GHz, zwischen 4GB bis 16GB virtuellen RAM und zwischen 60GB und 2TB virtuellen Instanzspeicher gewählt werden.

Im Vergleich zu Amazon EC2 ist die IBM SmartCloud erheblich teurer, was aber daran liegt, das IBM mit seinem Angebot gezielt nur Unternehmen anspricht. So kostet die kleinste 32-bit Copper Instanz mit einem SUSE Enterprise Linux Server 11.0 0,095 Dollar pro Stunde und eine 64-bit Platinum Instanz mit einem Red Hat Linux Enterprise Server 5.4 und 5.5 1,84 Dollar pro Stunde. (Jeweils für nicht reservierte Kapazitäten.)

Das sich das Angebot an Unternehmen richtet, wird bei der Registrierung deutlich. Hier kann zwischen weiteren “Optional Premium Services” wie “On-boarding support” (Remote on-boarding support | Einmalig 3.000 Dollar), “Virtual Private Network service” (Network isolation of your instances through a virtual private network on the IBM Cloud | Einmalig 1.000 Dollar plus 300 Dollar monatlich) oder weiterem “Support” unterschieden in “Premium support” für 5% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 75$ pro Monat) und “Advanced Premium support” für 10% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 1000$ pro Monat), gewählt werden.

Die SmartCloud Enterprise Infrastruktur befindet sich in unterschiedlichen Cloud Rechenzentren überall auf der Welt. Kunden aus den USA beziehen die Services aus Raleigh in North Carolina und Boulder in Colorado. Kanadische Kunden werden aus Toronto in Ontario bedient. Für Europa, den mittleren Osten und Afrika werden die Services über ein Rechenzentrum aus Ehningen in Deutschland bereitgestellt, sowie für asiatische Kunden über ein Rechenzentrum in Singapur und Tokio.

Fazit

Für Unternehmenskunden sind die IBM “SmartCloud Enterprise Services” auf Grund ihrer umfangreichen Serviceleistungen ein attraktives wenn auch teures Angebot. Ob IBM damit tatsächlich den Kampf mit Amazon aufnehmen kann und möchte bleibt fraglich. Denn einen entscheidenen und attraktiven Vorteil hat Amazon gegenüber IBM. Die AWS Cloud ist ein echtes Public Cloud Angebot und ist für jedermann zugänglich. So haben auch Entwickler oder “normale Menschen” mit einer Idee die Möglichkeit die Services von Amazon zu nutzen. IBM hingegen richtet sich gezielt an Unternehmenskunden und hat nicht den Bedarf auf die Wünsche einfacher Benutzer einzugehen.

Aus eigener Sicht betrachtet, muss IBM sich darauf auch nicht einlassen, da die Dienstleistungen seit jeher Unternehmen adressierten. Spannend bleibt, ob und wie Amazon darauf reagiert. Wie bereits oben erwähnt, kann sich Amazon jedoch darauf berufen, die “Cloud für jedermann” zu sein. Vor allem Startups, Entwickler mit innovativen Ideen und Fachabteilungen die “nur mal etwas ausprobieren wollen”, werden weiterhin auf Grund des unkomplizierten Ressourcenbezugs und der einfachen und kostengünstigen Abrechnung auf die AWS Cloud zurückgreifen.

Route 53 löst DNS Anfragen mit einer geringen Latenz auf, indem ein globales Netzwerk von DNS Servern genutzt wird. Anfragen an eine Domain werden automatisch an den nächstgelegenen DNS Server weitergleitet und damit mit der best möglichen Performanz beantwortet. Route 53 stellt eine Web Service Schnittstelle bereit, über die Public DNS Einträge erstellt und verwaltet werden können und ist vollständig in alle bereits vorhandenen Amazon Web Services integriert. Zum Beispiel kann durch die Nutzung des AWS Identity and Access Management (IAM) in Kombination mit Route 53 bestimmt werden, wer Änderungen an den DNS Einträgen vornehmen kann.

Für die Nutzung von Route 53 müssen, wie bei alle anderen Amazon Web Services, keine langen Vertragslaufzeiten eingegangen oder Mindestumsätze generiert werden. Die Abrechnung erfolgt pro Domain, die mit dem Service verwaltet wird und pro Abfrage, die von Route 53 beantwortet wird.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Verfügbarkeitszonen ausgeführt werden.

Die folgende Graphik zeigt eine Darstellung der Amazon EC2 Regionen und Verfügbarkeitszonen. Jede Region ist völlig unabhängig. Jede Verfügbarkeitszone ist vollständig isoliert, aber durch Netzwerkverbindungen mit einer geringen Latenz mit anderen Verfügbarkeitszonen verbunden.

Regionen

Amazon EC2 verfügt über mehrere Regionen, wodurch EC2 Instanzen an den Standorten ausgeführt werden können, die den eigenen Anforderungen entsprechen. Um z.B. als nicht europäisches Unternehmen Kunden in Europa Dienstleistungen anzubieten und zudem den dort gesetzlichen Anforderungen gerecht zu werden, können die EC2 Instanzen in einer Verfügbarkeitszone der Region Europa ausgeführt werden.

Jede Amazon EC2 Region ist so konstruiert, dass sie vollständig isoliert von allen anderen Amazon EC2 Regionen betrieben wird. Damit wird die größtmögliche Unabhängigkeit und Stabilität erzielt und macht den Ort einer jeden EC2 Ressource eindeutig.

Um Instanzen zu starten oder mit diesen zu arbeiten, muss zunächst die korrekte URL eines Endpunkts einer Region definiert werden. Soll z.B. eine Instanz in der Region US-East (Standard Region) betrieben werden, wird als Endpunkt URL ec2.us-east-1.amazonaws.com verwendet.

In der folgenden Tabelle sind alle Regionen mit ihren zugehörigen Endpunkten dargestellt.

Verfügbarkeitszonen

Fehler können auftreten, die Auswirkungen auf die Verfügbarkeit von Instanzen haben, die sich an dem gleichen Standort befinden. Auch wenn das ziemlich selten vorkommt – wenn alle Amazon EC2 Instanzen an einem einzigen Standort gehostet werden, der von einer Störung betroffen ist, sind diese Instanzen nicht mehr verfügbar.

Sind z.B. Instanzen über drei Verfügbarkeitszonen verteilt und eine dieser Instanzen fällt aus, kann eine Anwendung zu konzipiert werden, dass die Instanzen in den übrigen Verfügbarkeitszonen die Anfragen automatisch entgegennehmen und verarbeiten.

Quelle

• Region and Availability Zone Concepts

Ein AWS Account ist auf 100 EBS Volumes oder in der Summe auf eine Volume Gesamtspeichergröße von 20 Terrabyte begrenzt. Dabei beträgt die maximale Größe eines Volumes 1 Terrabyte. Jedes EBS Volume kann jeder EC2 Instanz innerhalb derselben Verfügbarkeitszone hinzugefügt werden.

Mit Amazon EBS können Snapshots (Backups) der EBS Volumes erstellt und auf Amazon S3 gespeichert werden. Diese Snapshots können als Ausgangspunkt für neue EBS Volumes genutzt werden und schützen die Daten langfristig. Weiterhin können Snapshots mit bestimmten Benutzern geteilt oder öffentlich verfügbar gemacht werden.

Amazon EBS Volumes verfügen über folgende Eigenschaften:

• Speichern ausserhalb der Instanz
• Persistenz jenseits der Lebensdauer von Instanzen
• Hohe Verfügbarkeit und Zuverlässigkeit
• Hinzufügen und Entfernen der Volumes für bereits ausgeführte Instanzen
• Darstellung als ein eigenes Gerät innerhalb der Instanz

Amazon EBS Snapshots verfügen über folgende Eigenschaften:

• Erfassung des aktuellen Zustands eines Volumes
• Datensicherung
• Instanziierung neuer Volumes, die den exakten Inhalt eines Snapshots beinhalten

Amazon EBS Anwendungsfälle

---

Fehlertoleranz

Amazon EBS ist so konstruiert, dass jede Instanz zu einem Speichervolumen hinzugefügt werden kann. Fällt eine Instanz auf Grund eines Fehlers aus, löst sich das EBS Volume automatisch mit den intakten Daten von der Instanz. Anschließend kann das Volume zu einer neuen Instanz hinzugefügt werden und der Wiederherstellungprozess beginnen.

Erklärung

• 1. Eine Amazon EC2 Instanz ist mit einem EBS Volume verbunden. Die Instanz fällt aus, bzw. Probleme treten auf.
• 2. Zur Wiederherstellung muss das EBS Volume nun von der Instanz gelöst werden. Das kann auch automatisch durch das EBS Volume erfolgen. Anschließend wird eine neue Instanz gestartet und das Volume dieser neuen Instanz hinzugefügt.
• 3. Für denn Fall das ein Amazon EBS Volume ausfällt, kann eines neues EBS Volume auf Basis des jüngsten Snapshots des Volumes erstellen, dass ausgefallen ist.

Neue Volumes auf Basis von Snapshots erstellen

Amazon EBS Snapshots ermöglichen den schnellen Einsatz neuer Volumes, indem ein bereits vorhandener Snapshot als Ausgangspunkt für diese neuen Volumes dient.

Erklärung

• 1. Es wird ein Web-Service mit einer großen Datenmenge verwendet.
• 2. Wenn die Daten fertig sind, kann ein Snapshot des Volumes in Amazon S3 zur langfristigen Datensicherung gespeichert werden.
• 3. Wenn der Datenverkehr und Ressourcenverbrauch ansteigt, kann aus dem Snapshot ein neues Volume erstellt, eine neue Instanz gestartet und anschließend dieser neuen Instanz das neue Volume hinzugefügt werden.
• 4. Wenn sich der Datenverkehr wieder verringert, können eine oder mehrere Amazon EC2 Instanzen heruntergefahren und ihre EBS Volumes gelöscht werden.

Datenpersistenz

EBS Volumes existieren unabhängig von den aktuell vorhandenen Instanzen und bleiben solange vorhanden, bis sie explizit gelöscht werden. Das ermöglicht das Speichern von Daten, ohne dass eine Instanz gestartet sein muss.

Erklärung

• 1. In regelmäßigen Abständen wird eine Instanz zur Batchverarbeitung von großen und wachsenden Datenmengen ausgeführt.
• 2. Am Ende der Verarbeitung wird die EC2 Instanz beendet. Das EBS Volume wird aber weiterhin ausgeführt.
• 3. Werden die Daten das nächste Mal verarbeitet, wird eine neue EC2 Instanz gestartet und dem bereits vorhandenen EBS Volume hinzugefügt.

Auf Basis dieses Vorgehens können die Daten nur mit den Ressourcen auf unbestimmte Zeit verarbeitet und gespeichert werden, die auch tatsächlich benötigt werden.

Root Partition

EBS Volumes können als Root Device (Partition) für Linux und Windows Instanzen verwendet werden. Dadurch besteht die Möglichkeit Root Partitionen mit der Größe von bis zu 1 Terrabyte zu nutzen.

Weiterhin kann das EBS Volume (als Root Partition) von einer anderen Instanz gemounted werden, falls eine Instanz ausfällt.

Die Größe der Partition kann während des Startvorgangs mittels Block Device Mapping geändert werden.

Erklärung

• 1. Ein vorhandenes AMI ist in Amazon EBS gespeichert. Es Änderungen daran vorgenommen und ein neues AMI erstellt.
• 2. Falls die Größe der Root Partition nicht mehr ausreicht, wird die Instanz gestoppt und mit einem größeren EBS Volume neu gestartet.
• 3. Falls eine Instanz ausfallen sollte, wird eine neue Instanz gestartet und die Root Partition (EBS Volume) der ausgefallenen Instanz gemounted.

Große Datenmengen

Amazon EBS bietet größere Volumes als Amazon EC2 Instanzen. Jedes EBS Volume kann bis zu einem Terrabyte groß sein.

Quelle

• Amazon Elastic Block Store

Alle Amazon EC2 Instanzen erhalten während des Starts zwei IP Adressen zugewiesen. Eine private Adresse (RFC 1918) und eine öffentliche Adresse (public), die mittels Network Address Translation (NAT) direkt aufeinander abgebildet werden. Private Adressen sind nur innerhalb des Amazon EC2 Netzwerks erreichbar. Öffentliche Adressen hingegen sind aus dem Internet erreichbar.

Weiterhin stellt Amazon EC2 einen internen, sowie einen öffentlichen DNS Namen zur Verfügung, der jeweils der privaten bzw. öffentlichen IP-Adresse zugewiesen wird. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der öffentliche DNS Name hingegen löst die öffentliche IP-Adresse außerhalb des Amazon EC2 Netzwerks und die private IP-Adresse innerhalb des EC2 Netzwerks auf.

Private Adressen (RFC 1918)

Alle Amazon EC2-Instanzen erhalten eine private Adresse per DHCP zugewiesen. Die Adressbereiche sind in RFC 1918 definiert und können nur innerhalb des Amazon EC2 Netzwerks gerouted werden. Die privaten IP-Adressen werden für die Kommunikation zwischen den jeweiligen Instanzen verwendet.

Die private Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird. Anschließend wird die Adresse wieder an Amazon EC2 zurückgegeben und kann dann erneut an eine andere Instanz vergeben werden.

Es sollte darauf geachtet werden, dass immer die internen Adressen verwendet werden, wenn zwischen Amazon EC2 Instanzen kommuniziert wird. Damit ist sichergestellt, dass der Datenverkehr immer mit der höchsten Bandbreite übertragen wird und die Latenz innerhalb des Amazon EC2 Netzwerks so gering wie möglich ist.

Interner DNS Name

Jede Instanz verfügt über einen internen DNS Namen, der zu der entsprechenden privaten IP-Adresse der Instanz innerhalb des Amazon EC2 Netzwerks aufgelöst wird. Der interne DNS Name wird nicht ausserhalb von Amazon EC2 aufgelöst.

Öffentliche Adressen

Während des Starts wird eine öffentliche Adresse einer EC2 Instanz mittels Network Address Translation (NAT) zugewiesen. Die öffentliche Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird oder durch eine Elastic IP-Address ausgetauscht wird.

Kommunizieren Instanzen mit anderen Instanzen über ihre öffentliche IP Adresse entstehen zusätzliche Kosten, basierend auf regionalen oder dem Internet Datenverkehr, je nachdem ob sich die Instanzen in der selben Region befinden.

Öffentlicher DNS Name

Jede Instanz verfügt über einen externen DNS Namen, der zu der entsprechenden öffentlichen IP-Adresse der Instanz ausserhalb des Amazon EC2 Netzwerks und von innerhalb des EC2 Netzwerks aufgelöst wird.

Quelle

• Instance Addressing Concepts