I have made a rough comparison for the classic “on demand” small instance against the new reserved instance:

On Demand Instance:
$0 + (365*24*$0,10) = $876/year = $73/month

Reserved Instance 1year:
$325 + (365*24*$0,03) = $588/year = $50/month
Saves you $288/year or $24/month.

Reserved Instance 3years:
$500 + (3*365*24*$0,03) = $1288/3years = $430/year = $36/month
Saves you 446 $/year or 37$/month.

Here’s the offical FAQ on using Reserved Instances. And here’s a funny but critically blog post about the “single commandline that can costs you losts of money“. I think Marc Musings is right and I wish that Amazon would improve this because I had the same bad emotions with this “new API feature”. It would basically a good idea to have alerts and/or limits for charges, instances and traffic.

Can’t wait for reserved Instances to be available for the EU region… “in the near future” as Amazon promised… Happy emotions when spending big money with ec2-purchase-reserved-instances-offering!

UPDATE 09-08-21: New Lower Prices for Amazon EC2 Reserved Instances and I’m also happy to see that one of my EC2 instance hit the 500 days uptime mark.

I really enjoyed listening to Dr. Werner Vogels. Dr. Vogels is Vice President & Chief Technology Officer at Amazon.com where he is responsible for driving the company’s technology vision, which is to continuously enhance the innovation on behalf of Amazon’s customers at a global scale.
This vision is why I have moved to EC2/S3 in 2007. I guess, I’ve finally become an Amazon AWS fan boy.

Even if audio is a bit out of sync, it’s worth to listening this long session.
As a developer from the bottom of my heart I like especially this quote: “There is no value in being a system administrator. You do not build a better product by being a better server maintainer.” This is so true, but I wonder how EC2 can free me from typical administration tasks. I still have to maintain my virtual server instances with the whole LAMP stack. Plus I have to think about how to scale horizontally (what to do when I need more virtual server instances).
In contradiction to Amzon’s EC2, Google’s AppEngine promises to free me from doing the admin tasks (no OS/LAMP Stack to maintain) and to solve the scale problem (no Database Replication to set up). AppEngine scales out of the box – the downside is, that it offers a very limited runtime just for you app.
True, a single EC2 instance doesn’t scale out of the box but it also doesn’t limit you in doing what you want to do on your virtual server. With EC2 I have to solve the scaling on my own. For this price I got more freedom.
I’m exited to use and learn about EC2/S3/Storefront each day but I also hope that Google’s AppEngine will offer a wider range of runtime environments in the future. t’s an interesting Cloud-Year 2009! #buzzword

Mit CloudFront kann ich nun vor meinen öffentlichen S3 noch ein Content Delivery Network vorschalten, dass automatisch meine Inhalte über alle verfügbaren Standorte synchronisert und bei Requests auf meine Inhalte immer die schnellste Verbindung auswählt. Mehr Details zur neuen CloudFront, dem Content Delivery Network von Amazon gibt’s unter aws.amazon.com/cloudfront/ und im original Wortlaut des Developer-Newsletters.

Dear AWS Customer,

Today, we’re excited to announce the public beta of Amazon CloudFront, a new web service for content delivery. With CloudFront, you can distribute content using a worldwide network of edge locations that provide low latency and high data transfer speeds. CloudFront works seamlessly with other AWS services such as Amazon S3, and like all AWS services, is self-service with no up-front commitments, no long-term contracts and pay-as-you-go pricing. You can sign up for CloudFront – and begin using it today – at aws.amazon.com/cloudfront.

The initial release lets developers and businesses deliver popular, publicly readable content worldwide. CloudFront has a number of exciting features that differ from many traditional methods of content delivery. It:

lets you get started easily there’s no need to contact a sales person or negotiate a contract. Anyone can get started in just minutes with only a credit card.
works seamlessly with Amazon S3 – you can start delivering your files stored in Amazon S3 through CloudFront edge locations in a matter of minutes.
is simple and easy to use – a single API call is all that’s needed to get started delivering your content.
lets you pay only for what you use there are no minimum fees and no long-term commitments.
To Use Amazon CloudFront, all you need to do is store your objects in Amazon S3 (make sure they are publicly readable), then, make a simple API call to register your bucket with CloudFront. This API call will return a new domain name for you to include in your web pages or application. When clients request an object using this domain name, they will be automatically routed to the nearest edge location used by Amazon CloudFront for fast delivery of your content. No negotiations, no upfront fees, and no volume commitments. It’s that simple.

You can learn more about Amazon CloudFront and get started using the service at aws.amazon.com/cloudfront.

Sincerely,
The Amazon CloudFront Team

http://vmware.com/download/fusion/

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

Es entlastet mich als Entwickler von all diesen adminstrativen Tasks die ich überlicherweise beim LAMP Stack habe. Es macht quasi den Administrator in mir arbeitslos und schenkt dem Entwickler in mir die frei gewordene Zeit um mich auf die Anwendung zu konzentrieren.

Teil 1 – Vorstellung der Google App Engine Preview:

Ab 2:50 stellt Kevin Gibbs die Vorteile der App Engine gegenüber dem klassischen LAMP Stack vor. Ich frage mich aber, ob die App Engine mir auch die Flexibelität des LAMP Stacks gibt – aber das kann zZ nicht beurteilt werden, da die App Engine ja zZ. nur ein Preview ist.

Mit Google App Engine kann ich die selbe Infrastruktur nutzen wie Google. Das ist analog wie bei Amazon mit S3, EC2 und SimpleDataService. Bei Amazon nutze ich jedoch virtuelle Server-Images mit EC2 und bin daher viel Flexibler als mit der Google App Engine (die als Sandbox doch sehr restriktiv ist). Ich habe bei EC2 aber halt auch den Mehraufwand, dass ich meine virtuellen Serverinstanzen selbst aufbauen (linux, apache, mysql, php order anderes) warten muss und ausgefallene Instanzen erkennen und ersetzten muss – ich muss dort Lösungen entwicklen für persistente Filesysteme (via integration von S3) und Lösungen entwicklen für persistene Datenbanken (SimpleDataService). All das ist bei Googles App Engine deutlich einfacher weil bereits in einem Gesamtframework integriert. Bei Amazon habe ich zwar mehr Freiheiten (mit meinen virtuellen Server Instanzen kann ich quasi alles anstellen und bin nicht nur auf das Hosting von WebApps beschränkt) – komme aber, wenn ich eine vergleichbare Skallierbarkeit mein Web App wie bei Google App Engine entwicklen möchte, zu den gleichen Restriktionen die die App Engine hat (kein Schreiben in lokales Filesystem, keine relationale Datenbank wie mySQL etc.).
Google App Engine erscheint also als idealer “out of the box” Hoster für Django Apps. Sicher wird die App Engine auch bald für Ruby on Rails verfügbar sein, da die Frameworks sehr ähnlich sind und sich RoR für Googles App Engine geradezu aufdrängt.

Teil 2 – eine einfache Demo.
Die Original-Demo von Campfire ist wegen der geringen Auflösung nicht zu gebrauchen. Hier eine bessere Version mit dem gleichen Inhalt:

Teil 3 – Betrachtung der 5 Komponenten des App Engine Stacks:

1) scalable serving infrastructure
2) python runtime and libraries
3) SDK
4) web-based admin console
5) scalable datastore

Interessant ist hier der Teil wo erklärt wird, wie die Skallierbarkeit umgesetzt wird. Man braucht eine Alternative zu klassischen relationalen Datenbanken (wie z.B. mySQL) die es erlaubt besser zu skallieren. Googles Big-Table und GQL sind die Komponenten, die für die App Engine den DataStore übernehen und so die Skallierbarkeit “out of the box” mit sich bringen.

Bei EC2 von Amazon kann ich natürlich auch weiterhin eigene mySQL Server einsetzen – aber wenn ich wirklich gross skalieren will, brauche ich auch etwas, das besser skalliert als mySQL. Hierfür stellt mir Amazon via SimpleDB eine vergleichbare Technologie breit. Aber ich muss das bei Amazon alles irgendwie erst unter einen Hut bringen und selbst managen (EC2, S3, SimpleDB, Integration RoR, Skallierung via virtueller Instanzen in Abhängigkeit der Last usw.) . All das gebe ich bei Google App Engine an Google ab – und zahle dafür natürlich den Preis, dass ich nicht so flexibel bin wie bei EC2.

Die Umstellung von relationalen Datenbank auf BigTable/GQL bzw. SimpeDB bei Amazon sehe ich zZ. als die größte Hürde für Apps die bereits mit Django oder RoR entwickelt wurden.

Teil 4 – Python Entwickler und Google Software Engineer Guido van Rossum spricht über Goolge App Engine:

Als Entwickler teile ich seine Begeisterung für das Projekt – und als Sprache wünsche ich mir neben Python natürlich Ruby.

Teil 5 – Google Product Manager Pete Koomen demonstriert App Engine’s web-basierte admin console:

Hier muss sich zeigen, ob man die gleiche Flexibelität bekommen, die man hat, wenn man seine Logs selbst vorliegen hat (die kann ich per AWStats, SawMill usw. auswerten). Aber auch hier gibt es natürlich vereinfachungen: Wenn ich meinen eigenen Cluster von WWW-Servern fahre muss ich die Logs zusammenführen bevor ich sie auswerten kann.
Auch fällt mir zZ die Vorstellung schwer, dass ich meinen Web-Server nicht mehr selbst konfigurieren kann.
Als lokale Datensicherung für den DataStore (BigTable oder SimpleDB) wird es sicher auch ein Dump und eine Restore-Möglichkeit geben – denn irgendwie möchte man seine Daten ja auch lokal gesichert wissen. All das sind Punkte die man erst in der Praxis kennen lernen muss – aber von den Möglichkeiten, die Google mir mit der App Engine in die Hand legt bin ich total begeistert. Ich wünsche ich hätte ein 48-Stunden Tag, damit ich mich (neben meiner normalen Arbeit) damit beschäftigen könnte…

Teil 6 – Google Product Manager Paul McDonald zeigt einige Demo Anwendungen:

Last but not least habe ich noch dieses Video gefunden:
Dion Almaer von Google bringt es auf den Punkt, wenn er App Engine mit Amazon EC2, S3 und SimpleDB vergleicht. Ausserdem macht er grosse Hoffnung auf ein rasches Erscheinen von RoR via App Engine, da er selbst ein RoR Fan ist. Absolut sehenswert dieses Interview:

On the train ride between Brussels and London, I got the chance to interview Dion Almaer, of Google, regarding the recently announced Google App Engine cloud computing product.

Einen leicht verständlichen Artikel zu Google App Engine und die möglichen Strategien von Goolge habe ich bei taz.de gefunden.

Brian Berliner beschreibt es in seinem Blog ganz treffend:

Amazon Web Services gives you the logs and asks you to build yourself a cabin. Amazon Web Services lets you change that cabin into a chateaux or a lodge, but you’ve got to wield the hammer.
Google App Engine gives you a log cabin and asks you to move in, invite your friends, and start to party. When the party gets too big, Google App Engine builds you a bigger cabin, chateaux, or lodge. You keep partying.

I believe the simplest approach wins.

Nach dem Konvertieren findet die VM unter VMWare Server nicht mehr das Netzwerk. /etc/network/interfaces ist unter Fusion mit eth0 gelaufen. Unter VMWareServer zeigt die VM mit “ifconfig -a” nur ein eth1 an. Ich habe die also in /etc/interfaces das primary network interface von eth0 auf eht1 geändert. Danach “/etc/ini.d/network restart” und nun läuft es wieder. Muss ich bei Gelegenheit mal genauer schauen, was da schief gelaufen ist – muss wohl irgendwas mit dem vmxnet networking driver sein.

Update: Die VM wurde “geklont” dabei wurde eine neue MAC-Adresse angelegt. Bei Debian ist in der “/etc/udev/rules.d/z25_persistent-net.rules” die alte MAC-Adresse eingetragen. Ich habe die “/etc/udev/rules.d/z25_persistent-net.rules” gelöscht und rebootet. Danach war das interface wieder als eth0 zu verwenden.

Auch andere haben schon vor dem Problem gestanden und versucht die 25 seitige Dokumentation “Timekeeping in VMware Virtual Machines” irgendwie auf das wesentliche zusammenzufassen.

Nach dem Tipp eines befreundeten Admins (Danke Dirk) in die Knowledgebase bei RedHat zu schauen, finde ich dort nur den Weg, den ich zuvor schon versucht hatte. Grob zusammengefasst:

1. Im Gast OS die VMWare-Tools installieren.

2. In der *.vmx Datei den Eintrag
tools.syncTime = “TRUE”
setzen.

3. ntpd im Gast nicht erforderlich aber für den Host empfohlen.

Damit hatte es aber noch nicht geklappt (Gast Uhr läuft extrem hinterher) und ohne den Eintrag “host.useFastClock = FALSE” werde ich mit “rtc: lost some interrupts” im Syslog zugeschmissen.

Also ist eine rasch zu ergoogelnde Lösung nicht in Sicht und ich muss nochmal genauer in die VMWare-Bibel der Zeitsynchronierung schauen. Dort finde ich auf Seite 22 bei Punkt 3, Unterpunkt 3 eine Lösung die für meine Konfiguration (Host = 2.6.18-6-686 #1 SMP mit VMWare Server1.x) funktioniert:

Linux kernel 2.6 guests normally request 1000 PIT 0 timer interrupts per second, plus, in
some cases, 1000 local APIC timer interrupts on each virtual CPU. For single processor guests, you can usually eliminate the unneeded APIC timer interrupts by including the kernel command line flags noapic nolapic nosmp. (All three flags may not be needed, depending on your exact kernel version, but it should be harmless to give all three.)

Aktuelle fahre ich also folgende Kernel Flags für die VM in der grub/menu.lst:
kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda1 ro noapic nolapic nosmp clock=pmtmr
und habe damit eine synchrone Zeit zwischen Host und VM und keinerlei “rtc: lost some interrupts” Meldungen im Syslog mehr.

Wie schön dass es noch immer einen Schalter mehr gibt, den man noch ausprobieren kann… Oder wie schreibt VMWare so schön auf Seite 25: “Conclusion: Timekeeping in virtual machines is a complex subject.”

Zu groß sei die Nachfrage nach dem erst kürzlich gestartetem Beta-Programm welches ideal die bereits mit großem Erfolg gestarteten Dienste S3 und EC3 ergänzt. So ist es zumindest in dem Developer Connections Newsletter#33 von heute zu lesen:

In late December, we announced Amazon SimpleDB, which is available in limited beta. Amazon SimpleDB is a web service for running queries on structured data in real time. This service works in close conjunction with Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Compute Cloud (Amazon EC2), collectively providing the ability to store, process and query data sets in the cloud. Traditionally, this type of functionality has been accomplished with a clustered relational database that requires a sizable upfront investment, brings more complexity than is typically needed, and often requires a DBA to maintain and administer. In contrast, Amazon SimpleDB is easy to use and provides the core functionality of a database – real-time lookup and simple querying of structured data – without the operational complexity.

We’re very excited about the strong interest our community has shown in the beta program. At this stage, we have limited spots available, and ask for your patience as we work to enable additional developers. In the meantime, you can read more about the service, and sign up to be notified when a spot becomes available for you.

So wie Rails für Ruby eine Killeranwendung ist, so wird SimpleDB für Rails und ähnliche Frameworks eine Killeranwendung werden. Also warte ich voller ungeduld, dass ich einen Slot zum SimpleDB Service bekomme und dass Rails einen Database-Adapter für SimpleDB bekommt.

Nitin Borwankar beschreibt in seinem Blog warum SimpleDB ein wichtiger Baustein zu skalierbaren Web-Anwendungen sein wird und warum SimpleDB ein Schlüssel-Feature für kommende Web-Anwendungen sein wird. Nitin kommt auch zu dem Schluss:

Existing web technologies such as Ruby on Rails, Django and Hibernate all have an Object Relational Mapper (ORM), which maps language objects to relational database tables.
If designers of these ORMs want to stay in the scalable apps game, they should take a serious look at using SimpleDB as a data store. Better yet, they should build ORMs from the ground up to integrate with SimpleDB.

Man darf also gespannt sein, ob RoR in gewohnt eleganter Weise einen Database-Adapter für SimpleDB bereitstellen kann. Denn auch wenn mit ActiveRecord eine Abstraktionslayer zu SQL eingezogen ist, so ist diese Aktraktionsstufe doch noch sehr an das Paradrigma von Relationalen Datenbanken angelehnt. SimpleDB ist aber nicht einfach nur eine altbekannte relationale DB die nun virtualisiert wurde sondern es bringt auch gleich ein neues Paradigma mit das vielleicht eher mit persistenten Hashes zu erfassen ist. Ich bin gespannt, ob man als RoR Entwickler von alledem ewas mitbekommen wird oder ob RoR die Internas verstecken wird so dass man weiterhin an der gewohnten Denkweise wird festhalten könnnen (wie es etwas das aws-simpledb Projekt in Aussicht stellt).

Für Nitin Borwanka jedenfalls ist mit SimpleDB der Startschus für Data 2.0 gefallen:

More than two years ago I wrote that Web 2.0 needs Data 2.0. The combination of EC2, S3 and SimpleDB is a toolkit for assembling massively scalable REST addressable web databases. Data 2.0 is now officially here. May the fun and games begin.

Further reading on Wikipedia: SimpleDB, CouchDB

Dear AWS Developers,

This is a short note to let a subset of our most active developers know about an upcoming limited beta of our newest web service: Amazon SimpleDB, which is a web service for running queries on structured data in real time. This service works in close conjunction with Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Compute Cloud (Amazon EC2), collectively providing the ability to store, process and query data sets in the cloud.

Traditionally, this type of functionality has been accomplished with a clustered relational database that requires a sizable upfront investment, brings more complexity than is typically needed, and often requires a DBA to maintain and administer. In contrast, Amazon SimpleDB is easy to use and provides the core functionality of a database – real-time lookup and simple querying of structured data – without the operational complexity.

Were excited about this upcoming service and wanted to let you know about it as soon as possible. We anticipate beginning the limited beta in the next few weeks.

Seite zum Beta-Projekt bei Amazon: Amazon SimpleDB und Developer Guide.
AWS-Blog: A Place for Everything – Amazon SimpleDB