A few hours ago, Amazon AWS announced that all EC2 instance types can now run 64-bit AMIs.
Though t1.micro, m1.small, and c1.medium will continue to also support 32-bit AMIs, it is my opinion that there is virtually no reason to use 32-bit instances on EC2 any more.
This is fantastic news!
Sticking with 64-bit instances everywhere all the time gives you the most flexibility to switch the instance type of your running instances, reduces the choices and work necessary when building your own AMIs, and just makes life simpler.
In fact, to celebrate this occasion, I have dropped my listing of 32-bit Ubuntu AMI ids at the top of Alestic.com. The new simplified AMI id table listing only 64-bit Ubuntu AMIs now fits into the right sidebar.
Simply pick an EC2 region in the pulldown in the right sidebar, and you’ll get a clean listing of current available Ubuntu AMIs. Click on the orange arrow to the right of the AMI id to launch an instance of Ubuntu in your AWS console.
Note that reserved instances only specify an instance type not an architecture, so if you have already purchased reserved instances for m1.small or c1.medium, you can switch from 32-bit to 64-bit and still have your new instance be covered by the reserved instance pricing.
Do you have reasons why you might still need to run 32-bit instances on EC2? How much work is it going to take you to convert your existing instances and AMIs from 32-bit to 64-bit?
Follow Eric Hammond on Twitter
The micro instance hasn't got enough memory to handle the 64-bit architecture. From small onwards I don't see any reason either.
vasile.zaremba:
The t1.micro doesn't have enough memory to handle much of anything but something trivial, but your point is taken that there is slightly less available with 64-bit than 32-bit. It still seems to me that it's worth trying 64-bit first on t1.micro to see if it works for your application. A quick test using Ubuntu 11.10 Oneiric shows only 4% less free memory with 64-bit in fresh t1.micro instances
At first I tried the default Amazon distro, based on CentOS, with the 64 bit. Sometimes I could't even run an update with yum because of the lack of memory. Now with Ubuntu on 32 bit it runs smoothly. The memory usage dropped around 40%.
vasile.zaremba:
Sounds like 64 -> 32 bit was not your only change. You also switched Amazon Linux -> Ubuntu at the same time.
For building software that needs to run on 32-bit machines (yes there are some). While one can build these on a 64-bit machine, it takes extra steps.
Yes, +1 for Ubuntu :)
I thought that the Amazon Linux was optimised for EC2, but it didn't work for me. I wanted to be safe and went for the 32-bit.
This doesn't work for spot instances, i.e., requesting an m1.small instance type with a 64-bit AMI.
luipugs:
Thanks for the tip. I'd imagine this is something that the spot team would be eager to get working soon.
It looks like there is a small mistake in the list for us-west-2. The "Ubuntu 10.04 LTS Lucid instance-store" is listed as "ami-e60b86d6". However, "ami-e60b86d6" is EBS-backed.
phylae:
I'm not sure where you're getting your AMI information, but ami-e60b86d6 in region us-east-1 is clearly instance-store according to ec2-desribe-images. Since there is no way to change an AMI once created, it has always been instance-store.
The AMI ids are obtained from the API of AMIs published by Canonical, e.g., http://cloud-images.ubuntu.com/query/lucid/server/released.current.txt
FYI: Well I use 32bit instances for two reasons.
The first is that I use EC2 to test build procedures on various OS'es and flavors. We have users running both 32 bit and 64 bit. The majority of our users are still on 32 bit; we will see if that balance changes as 12.04 is adopted more.
The second is that I have had some pretty big issues running 64 bit distros on a small memory machine. It seems there are heuristics built into the software itself that tunes itself to more memory hungry methods & configs when building for 64 bit architectures. I can definitely see packagers assuming the minimum memory for a 64 bit machine would be => 4GB.
To get specific I was running git hosting on a 512MB machine. We had all kinds of issues when running the stock 64 bit distro that came with that VM solution. I switched user space to 32 bits and it got a whole lot better. (This was before we moved our solution to EC2.)
wm.a.mills:
Thanks for the input. I'd love to hear if you find problems with git on 64-bit EC2 Ubuntu 12.04 instances as I'm providing this on the AWS Marketplace in 64-bit only: https://aws.amazon.com/marketplace/pp/B007I98IH8
Redis uses memory more efficiently on 32-bit systems; if your application uses lists and sets extensively, 32-bit allows greater storage on EC2 than 64-bit. See http://redis.io/topics/faq
AItOawl27t7_X2PRqlK_NYYfZTlf_tOD01xthcM:
Sure, any application that uses an excessive number of pointers (addresses of objects in memory) will use more memory as the pointers are larger on 64-bit. The questions that you must face, however, are: exactly how much more your particular application uses, whether or not that causes a problem, and how much trouble it is going to be to replace your 32-bit server with a 64-bit server when you decide to grow beyond a c1.medium in the future.
In pretty much all of the situations I deal with personally and where others seek my advice, it generally pays to keep the architecture simple, reduce developer/sysadmin time, and just stick with 64-bit. If Amazon had started with 64-bit everywhere, all the time, I doubt there would be a large percentage of customers complaining and asking for 32-bit.
Just forget that 32-bit is available on fraction of the instance types and life will be simpler.