Amazon EC2 gets two new types of instances, large and extra large EC2 instances. Basically a large instance that has 4 times the capacity (CPU, RAM, HDD) of the old, now default small instance type while the extra large instance type has 8 times the capacity.
Small Instance (default)
1.7 GB memory 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit) 160 GB instance storage (150 GB plus 10 GB root partition) 32-bit platform I/O Performance: Moderate Price: $0.10 per instance hour
Large Instance
7.5 GB memory 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each) 850 GB instance storage (2 x 420 GB plus 10 GB root partition) 64-bit platform I/O Performance: High Price: $0.40 per instance hour
Extra Large Instance
15 GB memory 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each) 1,690 GB instance storage (4 x 420 GB plus 10 GB root partition) 64-bit platform I/O Performance: High Price: $0.80 per instance hour
The idea is that you specify the instance type in the RunInstances API call. All old tools that do not specify this parameter start a default instance type.
Very nice to see this so fast after the recent S3 SLAs.
If they would now allow to run EC2 instances in Europe there are no excuses left not to run nearly all applications on EC2.

EC2 instances are virtual and thus when they crash, you lose your virtual harddrive. If you back up every hour, then you’d need to be happy possibly losing 0-60mins of data.
Those prices look great. For bandwidth, though, I’ve yet to find a better service than 1&1. Amazon charge about £100 to transfer 1Tb, whereas you can get a dedicated European server with 100mbit connectivity (for first 1Tb of transfer per month, then down to 10mbit), 1Gb RAM, 2×160Gb Raid 1 HDD, a 2.2Ghz Athlon 64 3500+ all for £58/month (including VAT). You also get an external hardware firewall. Perhaps one of these as a file server combined with EC2 for the application + database server would be ideal.
@Dr Nic:
We use master-slave/multi-master setups in order to avoid data loss. The problem is that without being able to specify in which AWS data centers a new node should come up we could end up with the two DB instances running on the same physical machine…
That’s why we do frequent backups and do not use EC2 DB instances for applications where a couple of minutes of data loss mean a lot.
@Nick:
The advantage of EC2 is the easy management and setup of nodes. At the moment combining EC2 nodes with local data centers is not so much fun in Europe because of the latency between your local, European network and the EC2 nodes in the US. We heavily use EC2 app servers for excess capacity handling but the latency (especially with VPN on top) is very high.
...with regard to backing up data from the stateless EC2 to AS3 data stores
—- data transfers between EC2 and AS3 are 100% FREE, correct?Also wondering for a data point in my own research, since you guys have experience with this… quantitatively how often is “frequent” for you guys?
Many thanks for sharing the info on Rails on EC2, it’s a great topic.
@Mark:
Normally we do not use EC2 instances as DB masters. EC2 app nodes have no backup besides the EC2 image. EC2 DB slaves backup to S3 every 30 minutes in our typical setups.
I wish they will introduce extra small nodes! :)