So I decided to take the plunge into moving my mailserver from Linode to EC2 considering it made more sense after doing some math. The reality is Linode is an excellent VPS host and I still have many machines with them (and highly recommend them), but the reality is at some point, it doesn’t become cost effective for me to run a VPS there.
This was the case with my mailserver. After moving to a Linode 1536, I did some math and realized it was costing me just a tad too much. So I pulled up a spreadsheet and did a comparison.
The linode solution offered me: 60 GB of storage with 1 GB of RAM and 600 GB of transfer. My problem was I kept on buying add-ons like extra RAM and storage because I host A LOT of mail.
Even with the transfer, I was only doing 10-20 GB a month and that would be a VERY BUSY month. So it ended up costing me $90.00 per month for a Linode with sufficient RAM and storage. Moving up to the next level was a bit too expensive so I just decided not to do it.
I started looking at reserved instances at Amazon’s cloud and realized that I could get an m1.medium for .032 per hour if I were willing to pay the heavy utilization fee of $390.00. The m1.medium reserved instance worked out to be outfitted as follows:
3.75 GB of memory, 2 EC2 Compute Units (1 virtual core with 2 EC2 Compute Units each), 410 GB of local instance storage, 32-bit or 64-bit platform.
So it would end up costing me the following per month (with the $390.00 factored in): $56.50 for the one year heavy utilization price.
This means that whether or not I’m running my instance, I’m still getting charged hourly, but with that much storage, who could possibly say no?
I’d be saving over $678.00 per year! That’s a hefty chunk of change. Now one would argue that Linode gives you CPU bursting and all that Jazz, but here’s the reality, I ran a mailserver on an old Pentium 100 for 5 years (a long time ago). It hosted about a dozen domains and it was really quite peppy.
So this would be more than fine. The problem with Instance Store devices and EC2 is if you use EBS storage, it costs money. You pay per GB of EBS storage. See the problem? You pay the hourly + EBS storage. Not exactly a win-win situation if you ask me. The other problem was with instance store devices, once you’ve made the changes you need and your reboot, they’re all lost.
So here’s how to solve it.
Once you’ve created and customized your instance store (S3 Backed Instance) and have it configured exactly the way you want it, create an AMI out of your fully configured instance. Here is the crux of the problem. How do you do it?
Well, a little creativity and you too can create your own instance while it’s running.
1. First things first, create an EBS volume in the Amazon console. I made mine 30GB
2. Attach it to your running instance and mount it to /mnt (formatted of course)
3. copy your private key and certificate files into it.
4. Execute the following statement: ec2-bundle-vol -d /mnt -k PRIVATE-KEY -c CERTIFICATE –u YOUR-AWS-ACCOUNT-NO -r (You have a choice i386 or x86_64) Choose widely young padmai! (Star Wars Humor)
5. Afterwards, you’ll see all these wonderful files in your /mnt directory. You can upload it now or detach the EBS volume for safe keeping. I chose to upload mine using the following command: ec2-upload-bundle -b YOUR-S3-BUCKET-PATH -m /mnt/image.manifest.xml -a YOUR-AWS-ACCESS-ID -s YOUR-AWS-ACCESS-KEY
6. Register the AMI in the bucket. Do it with one of two options: a. Through the console or b. ec2-register –K PRIVATE-KEY –C CERTIFICATE YOUR-S3-BUCKET/image.manifest.xml
You’re done. Just launch the AMI as a separate instance to check it out and make sure it’s exactly what you wanted.
If it is, you’re ok and ready to go.
Another option is to save all the files in the EBS Volume (download them) and not register it until you need it to save on the costs.
I keep the 30 GB EBS volume around for convenience with the keys already there and a little script that pretty much automates the whole process.
I mounted all that ephemeral storage (S3 Instance Backed Storage to /home) so I just excluded it. (I have a nightly backup run to an S3 bucket that does a backup and rotates them of course!).
Since I’m lucky enough to have VERY FAST Internet connection, I didn’t see the purpose of storing the ami after I registered it. I just kept the bucket around and just uploaded the files to the bucket prior to needing to launch it. I also have a script in my /root directory that basically formats and mounts the /home volume as well as automatically restores the last backup. Total time to restore? About 10 min. (Yes, I’m actually one of the VERY few people in the world that actually tests backups and solutions before putting them into production.. hey.. what a concept! LOL.
Keeping a 30GB EBS volume around with the keys in it and a few scripts always guarantees that you will have the space to build your AMIs really quickly. Just hot attach to /mnt and run your scripts!
How cool is that?
I’m writing a more detailed e-book that will include the scripts I use and how I have everything I suggest in the VERY NEAR future. It will be in the estore and I’ll probably take the plunge into the Amazon and Barnes and Noble ebook stores as well. Well, let’s not call them books. Just guides.