Schlagwort: Cloud

Kategorien
Management

Definition Public Cloud vs. Private Cloud

Nachdem mittlerweile davon abgesehen wird zu definieren, was Cloud Computing ist, wird nun versucht eine Definition bzgl. des Unterschieds zwischen einer Private und einer Public Cloud zu finden. Finde ich auf der einen Seite auch sehr gut, dass muss auch abgerenzt werden. Hört man dieses Thema allerdings während jedes Vortrags und jedes Panels wird es am Ende sehr zäh!

Dennoch möchte ich hier eine Definition wiedergeben, die den Kontext gut beschreibt.

Mit einer Private Cloud werden IT Ressourcen den internen Benutzern als Service automatisiert und unmittelbar bei Bedarf durch die eigene IT-Umgebung bereitgestellt.

Eine Private Cloud zeichnet sich also durch folgende Eigenschaften aus:

  • Self Service
  • Elastizität & Skalierbarkeit
  • Automatisierung
  • Virtualisierung
  • Eigene Rechenzentren
Kategorien
Kommentar

Cloud Computing ist der Sündenbock!

Wird Cloud Computing von dem Standpunkt der Sicherheit heraus mit einem einzigen Wort definiert, sind sich viele Protagonisten einig. Cloud Computing is a scapegoat, zu deutsch Sündenbock, Prügelknabe oder Buhmann.

Zurückzuführen ist diese Definition auf in vielen Fällen schlechte Medienberichte über vermeintliche Probleme aus dem Cloud Computing Bereich. Das Sidekick Disaster im vergangenen Jahr z.B. hat dem Cloud Computing damit einen Bärendienst erwiesen.

Allerdings sind wir uns alle einig, dass es sich bei dem Sidekick Disaster nicht um ein Cloud Computing Problem, sondern Probleme andersartiger Natur gehandelt hat. Aber wie die Medienlandschaft nun einmal funktioniert, geht es darum Leser zu erreichen, und viele Leser erhält man schließlich durch Überschriften die einen Thriller dahinter vermuten lassen. Ergo: Bevor man über Problematiken die mit Cloud Computing in Zusammenhang stehen könnten urteilt, sollte man sich über den tatsächlichen Hintergrund und über den Author und dessen Expertise informieren.

Sind wir mal ehrlich, sind Daten die sich in unserem Einflussbereich, wie z.B. dem eigenen Rechner oder dem Rechenzentrum wirklich sicherer als in der Cloud? Wissen IT Beauftragte tatsächlich, was sich auf den Firmen PCs/ Laptops lokal befindet? Dabei rede ich nicht von den Daten, sondern von der dort durch den Anwender installierten Software etc.. Und sind wir ehrlich, wie oft werden z.B. mobile Endgeräte gestohlen! Zählen wir allein diese Punkte – und es gibt noch wesentlich mehr – zusammen, sind traditionelle Systeme bzw. Lösungen nicht sicherer als Lösungen auf Basis von Cloud Computing!

Wie kann also Cloud Computing dem IT-Leiter bzw. IT-Sicherheitsbeauftragten dabei helfen ihre Umgebung hinsichtlich der Beschädigung von Daten, dem Diebstahl oder Verlust von sensiblen Daten, vor unberechtigtem Zugriff, der Compliance und der System-Verfügbarkeit schützen?

Zunächst sollte natürlich das Geschäftsmodell überprüft werden. Es macht keinen Sinn die Cloud zu adaptieren, wenn dadurch möglicherweise kein Nutzen entsteht. Bei Cloud Computing Technologien handelt es sich um moderne Architekturen, die den aktuellen Standards entsprechen und somit bzgl. den klassischen Sicherheitsproblemen sensibilisiert sind. Dennoch sollte die Sicherheit beim Aufbau oder der Adaption einer Cloud an erster Stelle stehen! Eine Cloud ist und sollte immer so konstruiert sein, dass sie u.a. den rechtlichen regionalen und globalen Rahmenbedinungen entspricht und weiterhin strategisch verteilt organisiert ist. Das bedeutet, dass die Daten nicht nur an einem einzigen Ort zentral gespeichert sind, sondern über mehrere Standorte hinweg repliziert werden.

Werden u.a. diese Eigenschaften beim Design einer eigenen Cloud bzw. bei der Entscheidung zur Adaption einer Cloud berücksichtigt, erhöht das Cloud Computing durch seine Zuverlässigkeit und Skalierbarkeit ganzheitlich die Sicherheit.

Kategorien
Analysen

Cloud Computing und seine finanziellen Vorteile

Neben den viel diskutierten technischen Vorteilen des Cloud Computing gegenüber eines traditionellen Rechenzentrums, stehen natürlich auch die finanziellen Vorzüge im Vordergrund.

Investitionskosten und die Art der Ausgaben
In einem klassischen Rechenzentrum muss ein Unternehmen bzgl. der Hard- und Software Anschaffungen in Vorleistung gehen und weiterhin die gesamten Kapitalaufwendungen und die Kosten für den Betriebsaufwand übernehmen. Ein Cloud Computing Anbieter hingegen investiert gezielt in seine Infrastruktur, um diese als Dienstleistung anzubieten. Die Kapitalaufwendungen werden hier somit vom Unternehmen an den Cloud Anbieter abgegeben. Das Unternehmen zahlt daher nur die Kosten für den Betriebsaufwand, wenn diese anfallen.

Cash Flow und Operative Kosten
Wie bereits oben beschrieben, muss ein Unternehmen seine Server und die Software im Voraus anschaffen. Werden die Dienstleistungen von einem Anbieter aus der Cloud bezogen, entstehen nur dann Kosten, wenn der Dienst auch tatächlich verwendet wird. Hinsichtlich der operativen Kosten versucht ein Unternehmen ständig die Kosten für die Entwicklung, Bereitstellung, Wartung, etc. zu verringern. Dieser Aufwand entfällt durch den Bezug der Leistungen von einem Cloud Anbieter. In diesem Fall ist der Anbieter für den Lebenszyklus der Hardware-und Softwarekomponenten zuständig.

Finanzielle Risiken
Investitionen in ein eigenes Rechenzentrum werden zunächst immer im Voraus getroffen, wodurch ein Unternehmen allein dafür ein enormes finanzielles Risiko eingehen muss, ohne die Gewissheit zu besitzen, dass ein ROI dabei herauskommt. Werden die Dienste von einem Cloud Anbieter bezogen, verringert sich das finanzielle Risiko auf einen Zeithorizont von einem Monat, wodurch auch der ROI ebenfalls sehr zeitnah gemessen werden kann.

Trotz der immer wiederkehrenden Diskussion, dass es sich bei dem Nutzen von Cloud Computing lediglich um das verringern der Kosten handelt (“Cloud Value is only about Cost.”), wird dieser Mythos mit dem Statement “Cloud Value is about Business Agility, Opportunities and Investment” entkräftet. Denn Cloud Computing bietet deutlich mehr Vorteile und Möglichkeiten, als nur das Variabilisieren der Kosten, sondern ermöglicht es ein Unternehmen sich deutlich flexibler und agiler aufzustellen.

Kategorien
Grundlagen Services

Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen

Amazon EC2 bietet die Möglichkeit, Instanzen über mehrere Standorte zu verteilen. Dabei sind die Standorte in Verfügbarkeitszonen (Availability Zones) und Regionen aufgeteilt. Die Regionen sind verstreut und befinden sich in getrennten geographischen Gebieten wie den USA und Europa. Verfügbarkeitszonen sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Verfügbarkeitszonen nicht betroffen sind. Dazu bieten sie eine kostengünstige Konnektivität mit einer geringen Netzwerklatenz zu anderen Verfügbarkeitszonen in der gleichen Region.

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.

Region Endpoint
US-East (Northern Virginia) Region ec2.us-east-1.amazonaws.com
US-West (Northern California) Region ec2.us-west-1.amazonaws.com
EU (Ireland) Region ec2.eu-west-1.amazonaws.com
Asia Pacific (Singapore) Region ec2.ap-southeast-1.amazonaws.com

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

Kategorien
Analysen

Wir brauchen eine transparente Cloud!

Stellen wir uns das folgende Szenario vor:

Wir haben unsere IT Infrastruktur erfolgreich in die Cloud eines Anbieters migriert. Alles bestens, wir sagen uns: „Super, alles funktioniert einwandfrei! Wir senken unsere Kosten. Unsere Infrastruktur ist nun so skalierbar, dass sie unseren Anforderungen immer gerecht wird. Uns stehen immer die aktuellen Software Versionen zur Verfügung und wir können von jedem Ort unabhängig von den lokalen Systemen miteinander kollaborieren.“

Was machen wir aber, falls wir uns nun doch dazu entscheiden wieder in das eigene Rechenzentrum zurückzukehren oder den Cloud Anbieter zu wechseln, weil dieser z.B. günstiger ist? Oder gehen wir noch einen Schritt weiter. Wie können wir unsere gesamten Geschäftsprozesse in der Cloud über mehrere Anbieter hinweg verteilt abbilden? Stellen wir uns vor, dass ein Anbieter den Prozess A verarbeitet, ein weiterer den Prozess B. Ein dritter Anbieter verarbeitet den Prozess C und nutzt dabei die Prozesse A und B. Oder wir verwenden eine Vielzahl voneinander unabhängiger Services von unterschiedlichen Anbietern und integrieren diese zu einem einzigen Service. Wir wir sehen, sind der Komplexität keine Grenzen gesetzt. Ein vermeintlich einfacheres Beispiel: Unsere Daten sind bei dem Anbieter A gespeichert und ein Anbieter B soll diese Daten verarbeiten.

Ist das möglich?

Ein weiterhin sehr kritischer Punkt des Cloud Computing ist das Fehlen von Standards. Jeder Anbieter verwendet unterschiedliche Technologien und kocht innerhalb seiner Infrastruktur seine eigene Suppe. Die meisten Anbieter versuchen in der Regel mittels des gefürchteten Vendor-Lockin ihre Kunden „an sich zu binden“. Denn leider haben es bisher die Wenigsten verstanden, Kunden über guten Service und weitere Dienstleistungen von sich abhängig zu machen.

Aus diesem Grund ist jede Beziehung zwischen einem Anbieter und seinem Kunden anders und eine anbieterübergreifende Zusammenarbeit – die für einen Kunden in vielen Fällen unerlässlich ist – kann nicht stattfinden.

Wir brauchen eine transparente Cloud!

Ein möglicher Ansatz wäre libcloud (http://libcloud.org). Dabei handelt es sich um eine Standard Bibliothek u.a. für Anbieter wie Amazon, Rackspace oder Slicehost, die eine einheitliche API bereitstellt. Sie ist in Python implementiert und kostenlos (Apache License 2.0) zu nutzen, um mit unterschiedlichen Cloud Anbietern zu kommunizieren.

libcloud

Allerdings ist die libcloud Bibliothek nur ein Ansatz. Wir müssen, wenn wir von Cloud Standards reden, uns auf eine noch wesentlich tieferer Ebene begeben. Was ich damit sagen will ist, dass ein Cloud Anbieter sich selber in die Pflicht nehmen muss und seine Schnittstellen so offen und sorgfältig zu dokumentieren, dass ein Wechsel oder eine Integration unterschiedlicher Services, Prozesse etc. zwischen verschiedenen Anbietern ohne weiteres möglich ist.

Ein Kunde muss mit einem guten Gefühl seine Daten, Prozesse etc. zu einem Cloud Anbieter auslagern, weil er sich sicher sein kann über diese frei zu verfügen und einen Wechsel sowie eine Integration sorgenfrei vornehmen zu können.

Kategorien
Grundlagen Services

Das Konzept des Amazon Elastic Block Store

Der Amazon Elastic Block Store (Amazon EBS) ist eine spezielle Speicherart, die speziell für Amazon EC2 Instanzen konstruiert wurde. Mit Amazon EBS können Volumes erstellt werden, die von Amazon EC2 Instanzen wie externe Geräte eingebunden (gemounted) werden können. Amazon EBS Volumes verhalten sich wie unformatierte externe Block-Devices. Sie können durch den Benutzer benamt werden und stellen eine Block-Device-Schnittstelle bereit. EBS Volumes können mit einem Dateisystem ausgestattet oder wie ein gewöhnliches Block-Device genutzt werden.

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

Kategorien
Analysen

Sind die Amazon Web Services der Standard der Cloud?

Nach dem Artikel Amazon ist das Mass aller Dinge im Cloud Computing Markt! stellt sich ebenfalls die Frage, ob Amazon mit seinen Amazon Web Services (AWS) auch die Standards in der Cloud setzt.

Die Amazon Web Services sind der aktuelle und unangefochtene Marktführer aus dem Bereich der Infrastruktur as a Service (IaaS) Anbieter und decken soweit alle Segmente und Möglichkeiten des Cloud Computing ab. Durch die langjährige Erfahrung verfügt Amazon über einen signifikanten Vorsprung vor allen anderen Anbietern in diesem Segment. Die Expertise entstand dabei durch den Aufbau einer Privat Cloud, um die Ansprüche an die eigene Infrastruktur (Skalierbarkeit des Webshops, etc.) zu erfüllen, woraus dann die Public Cloud Angebote (Amazon Web Services) entstanden sind.

Zunächst können wir natürlich aus einer Vielzahl von „Standards“ auswählen, da jeder Anbieter versucht, seine proprietäre Lösung als Standard am Markt zu positionieren. Daher kann nicht einfach davon ausgegangen werden, das die Amazon Web Services der Standard der Cloud sind. Zudem benötigt ein Standard einen gewissen Zeitraum, um sich als Standard zu etablieren.

Was sind also Anzeichen dafür, dass die Amazon Web Services bereits der Standard bzw. der kommende Standard des Cloud Computing sind?

Ein Blick auf die Angebote der Drittanbieter im Cloud Computing Markt verrät, AWS hat einen hohen Stellenwert. Vor allem Amazons Speicherdienst Amazon S3 ist dabei sehr beliebt. Mit JungleDisk, CloudBerry S3 Explorer, CloudBerry Backup oder Elephant Drive, stehen nur ein Paar Clients bereit, mit denen die Daten vom lokalen PC oder Server in die Amazon Cloud übertragen werden können. Zudem stehen mit S3 Curl, S3cmd oder S3 Sync weitere OpenSource Lösungen bereit, welche die Amazon S3 API zum Speichern von Daten nutzen.

Ein weiteres deutliches Indiz dafür, dass sich die Amazon Web Services als Cloud Computing Standard etablieren werden, ist das Angebot des deutschen Cloud Computing Anbieters ScaleUp Technologies, die mit ihrem eigenen Cloud Storage die Amazon S3 API vollständig adaptiert hat. Weiterhin stehen mit Eucalyptus bzw. der Ubuntu Enterprise Cloud „Klone“ der Amazon Elastic Compute Cloud (EC2) zur Verfügung, mit denen eine Private Cloud nach dem Vorbild von EC2 aufgebaut werden kann. Auch hier existiert mit den Euca2ools bereits eine EC2 API Adaption.

Schaut man sich zudem die Liste der AWS Solution Provider an, erkennt man, wie wichtig die Bedeutung von AWS mittlerweile geworden ist.

Nicht alle AWS Angebote haben derzeit das Potential als Standard bezeichnet zu werden. Dazu zähle ich wie bereits oben erwähnt nur die Amazon Simple Storage Service (Amazon S3) sowie die Amazon Elastic Compute Cloud (Amazon EC2), wobei S3 dabei deutlich Populärer ist als EC2.

Wie man anhand der Angebote und Adaptionen erkennt, ist vor allem S3 weit verbreitet und anerkannt und es ist davon auszugehen, dass weitere Drittanbieter auf diesen Zug aufspringen werden. Zudem werden die meisten Anbieter davon absehen, dass Rad neu zu erfinden. Amazon war der erste Anbieter im IaaS Cloud Computing Markt und hatte dadurch ausreichend Zeit, seine proprietären Standards bekannt zu machen. Zudem haben es die restlichen großen Anbieter verpasst schnell nachzuziehen und eigene Angebote zu präsentieren. Sollten sie noch länger warten, wird die Zeit zu Gunsten von Amazon entscheiden.

Amazon S3 ist derzeit der Defacto Standard im Bereich Cloud Storage. Amazon EC2 wird voraussichtlich in Kürze nachziehen und sich etablieren. Wann und ob es die restlichen AWS Angebote ebenfalls zu Defacto Standards schaffen, bleibt abzuwarten.

Kategorien
Grundlagen Services

Das Amazon EC2 Adressierungskonzept

Dieser Artikel beschreibt das Adressierungskonzept von Amazon EC2. Das beinhaltet die Arten von IP-Adressen, die für EC2 Instanzen zur Verfügung stehen.

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

Kategorien
Tutorials

Virtuelle Maschinen für Amazon EC2 mit dem VMBuilder erstellen

Dieses Tutorial beschreibt wie ein offizielles Amazon EC2 Image mit dem VMBuilder deployed wird.

Installation

Installation auf Karmic Koala (9.10) und späteren Versionen

Für alle Ubuntu Versionen ab Karmic Koala (9.10) sind fertige Pakete vorhanden.

Weiterlesen „Virtuelle Maschinen für Amazon EC2 mit dem VMBuilder erstellen“
Kategorien
Grundlagen Services

Der Amazon EC2 Instanzspeicher

Jede Instanz verfügt über eine festen Speicherplatz, auf dem Daten gespeichert werden können. Dieser wird im EC2 Kontext als Instanzspeicher bezeichnet und ist nicht als permanente Speicherlösung gedacht.

Wird eine Instanz neu gestartet, bleiben die Daten auf dem Instanzspeicher bestehen. Wird die Instanz higegen beendet, gestoppt oder ein Fehler tritt auf, dann sind die Daten verloren.

Für den Einsatz einer dauerhaften Speicherlösung empfiehlt Amazon daher Amazon Elastic Block Store.

Sollte Amazon EBS nicht eingesetzt werden, sollten wichtige Daten auf Amazon S3 gesichert werden.

Speicherort

Wo sich der Speicher auf den jeweiligen Instanz Typen befindet, kann der folgenden Tabelle entnommen werden.

Ort
Beschreibung
/dev/sda1 Auf allen Linux/Unix Instanz Typen als root (/) formatiert und gemounted. Auf allen Windows Instanz Typen als C: formatiert und gemounted.
/dev/sda2 oder xvdb (Windows) Auf allen m1.small und c1.medium Instanzen als /mnt formatiert und gemounted. Auf allen small Windows Instanzen formatiert und gemounted.
/dev/sda3 Auf allen m1.small und c1.medium Instanzen für Linux/Unix Instanz Typen als /swap formatiert und gemounted. Für Windows Instanzen nicht verfügbar.
/dev/sdb oderr xvdb (Windows) Auf allen m1.large, m1.xlarge, c1.xlarge, m2.xlarge, m2.2xlarge, und m2.4xlarge Instanzen für Linux/Unix Instanz Typen als /mnt formatiert und gemounted. Für alle m1.large, m1.xlarge, c1.xlarge, m2.xlarge, und m2.2xlarge Windows Instanzen formatiert und gemounted.
/dev/sdc oder xvdc (Windows) Verfügbar auf m1.large, m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.large, m1.xlarge, c1.xlarge und m2.4xlarge Windows Instanzen formatiert und gemounted.
/dev/sdd or xvdd (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/UNIX Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.
/dev/sde or xvde (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.

Quelle