Bisher gab es bei Amazon’s EC2 den Nachteil, dass jede Server-Instanz eine dynamisch zugewiesene öffentliche IP (“EC2 Public IP Address”) erhalten hat. Es konnte also nicht sichergestellt werden, dass man bei EC2 immer unter der selben IP erreichbar ist und musste DNS Updates machen oder über eine externe statische IP ein Reverse-Proxy in die EC2-Cloud machen um diesen Nachteil zu umgehen.
Amazon hat nun die sog. Elastic IP eingeführt, die genau diesen Nachteil aufhebt.

Man kann sich mit ec2-allocate-address bis zu fünf statische Elastic IPs auf sein EC2-Konto buchen lassen (mehr sind auf Anfrage bei Amazon möglich) und diese an beliebige eigene Instanzen knüpfen. Hierzu sind die aktuellen EC2 Command-Line Tools erforderlich, denn ältere Versionen vor 1.3-19403 2008-02-01 kennen die erforderlichen Befehle zum Verwalten der Elastic IP noch nicht. Testen welche Version installiert ist, kann man mit ec2ver.

Mit ec2-describe-addresses kann man sich anzeigen lassen welche Elastic IPs man bezitzt und welche Elastc IPs an welche Instance gebunden sind. Mit ec2-associate-address kann man eine Elastic IP an eine bestimmte Instanz binden. Somit ist es dann z.B. auch ganz einfach möglich eine ausgefallene Instanz durch eine neue Instanz zu ersetzen (die entweder zuvor paralell mitgelaufen ist oder erst neu hochgefahren wird) ohne dass nach aussen der Wechsel einer IP kommuniziert werden muss. Auch zwischen laufenden Instanzen können so einfach die Elastic IPs ausgetauscht werden. Z.b. wenn man einen Loadbalancer auf einer Small Instance betreibt und diesen nahtlos auf eine Large Instance umziehen lassen möchte. Über die EC2 API oder die Command-Line Tools lässt sich das alles auch wunderbar automatisieren.

Elastic IPs die an eine Instanz gebunden sind, verursachen keine Mehrkosten. Lediglich reservierte aber nicht genutzte Elastic IPs kosten derzeit pro Stunde 1 Cent um einem Horten der knappe IPs vorzubeugen. Die ersten 100 Remaps einer Elastic IP je Monat sind kostenfrei; weitere Remaps werden mit je 10 Cent berechnet. Also eine tolle und faire Erweiterung für EC2.

Wie genau das ganze mit den Elastic IPs geht wird ausführlich in diesem Feature Guide besprochen.

Brainstorming in eigener Sache: Der einzige Nachteil den ich bisher für meinen Anwendungshorizont ausmachen konnte betrifft Nutzer, die wie ich bereits Instanzen betreiben, die vor der Einführung der Elastic IPs über die “EC2 Public IP Address” nach aussen verfügbar/bekannt gemacht wurden. Ich habe die “EC2 Public IP Address” in mein Zonenfile eingetragen und wenn ich nun auf eine Elastic IP umstellen möchte um künftig immer mit der selben IP erreichbar zu sein (unabhängig von der Instanz, und um künftige DNS Updates zu sparen), so verliere ich beim Zuweisen der neuen Elastic IP sofort die “EC2 Public IP Address” unter der die Instanz bisher erreichbar ist. Da es nicht möglich ist, sich eine Elastic IP zu reservieren die bisher als EC2 Public IP Address auf eine eigene Instanz gebunden ist, bleibt einem nichts anderes übrig als für die Dauer des DNS Updates unerreichbar zu bleiben.
Soll eine temporäre Unerreichbarkeit vermieden werden, so müsste man sich dadurch behelfen, dass man vorübergehend mit einer zweiten (neuen) Instanz arbeitet und ersteinmal darauf die neue Elastic IP bindet. Die alte Instanz würde zunächst unter der bereits bekannt gemachten EC2 Public IP weiterhin erreichbar bleiben. Auf der neuen Instanz kann man dann mit einem Reverseproxy (z.B. pound) auf die alte Instanz durchgreifen lassen. Der Reverseproxy der Hilfs-Instanz greift über die EC2 Private IP Address auf die erste Instanz zu, damit keine zusätzlichen Traffickosten entstehen (Traffic innerhalb EC2 ist kostenfrei, wenn er über die privaten IPs abgewickelt wird). Wenn das soweit eingerichtet ist, führen sowohl die alte IP als auch die neue Elastic IP zum WWW-Server der ersten Instanz. Somit kann nun das DNS-Update erfolgen, wobei die neue Elastic IP (die sich künftig nicht mehr ändern wird) die alte EC2 Public IP ersetzt. Ist das DNS-Update rum, erfolgen alle Requests über den Reverseproxy der zweiten (Hilfs-)Instanz. Jetzt kann die Elastic IP auf die erste Instanz gemappt werden. Dabei fällt die bisherige EC2 Public IP der ersten Instanz unwiederruflich weg, was nun aber nicht mehr schlimm ist, da sie nicht mehr im Zonenfile steht und somit nicht mehr verwendet wird. Nun gehen wieder alle Requests direkt auf die erste Instanz und die zweite Hilfs-Instanz mit dem Reverseproxy wird nicht mehr benötigt und kann heruntergefahren werden.

1)
Instance A = EC2 Public IP (not static) (=what I have)

2)
Instance A = EC2 Public IP
Instance B = EC2 Elastic IP (Instance B running reverse proxy -> Instance A)

3)
DNS Update EC2 Elastic IP and wait until no further requests via EC2 Public IP

4)
Remap EC2 Elastic IP to Instance A:
Instance A = EC2 Elastic IP (static) (=what I want)
Shutdown Instance B