Moving Away from the Amazon Cloud

I wrote quite a few posts about Amazon Web Services and I hosted my blog there too for a while, but after some time I decided to switch back to a cheaper hosting provider and leave Amazon for the big projects inside our company. This turned out to be quite tricky.

Moving away from the Amazon cloud has some pitfalls you should watch out for. So this post is not only a note to myself about how to do it right next time, but also a note for you readers on how to hopefully save some time and money. Due to lack of experience and not reading everything carefuly the first time, it took me two months and around $35 just to move away from the cloud. Now that’s the kind of money I’d spend to buy a new book, but certainly not just to make Amazon $35 richer ;)

I made a rough checklist below of stuff to watch out for, and Amazon’s prices according to October 2010:

  • When terminating all instances in the cloud, make sure you check every region (US East, US West, Ireland and Singapore) – pricing start at around $0.10/hr
  • Clear your S3 buckets, and remove them – Amazon charges $0.15 per GB-month for S3 storage
  • Remove your EBS shots, from all regions – $0.11-0.18 for storage/shapshots per GB-month
  • Elastic IP addresses – Amazon charges $0.01 for non-attached IP addresses per hour, that’s $14 per month!

And please, do double check if there’s anything else in your AWS Management Console, especially if you get a notification from your bank next month. Make sure you scan all available regions! Another way to terminate your AWS account is to instruct your bank not to pay to Amazon at all ;)

If there’s anything else you would add to the list above, make sure to leave a comment below or poke me on Twitter (@kovshenin). To stay tuned and never miss a post, subscribe to my RSS feed.┬áCheers!

Amazon Web Services: EC2 in North California

January is going crazy for me down here in Moscow, lot’s of stuff happening, loads of work. No time to tweet, not time to blog. As I mentioned in my earlier post, I quit my job at GSL and now working at a new local startup. I’ll make sure to announce it as soon as the website is alright, so stay tuned ;) Anyways, as I wrote back in December, I’m moving all my stuff to the new EC2 in the Northern California region, and I guess I can say that I’m finally done.

The process is not too different from simply moving to a new dedicated hosting or to a new EC2 instance in the same region, though there are a few nuances. I was surprised to note that the S3 Fox plugin for Firefox haven’t yet added the new region (Europe is present though). I thought it might not work for some reason (S3 and EC2 being in different regions), but hopefully it does. I also considered using the good old mod_php for Apache instead of running mod_suphp which gave me a tiny boost in performance. All the configurations were straightforward, copy from one EC2, paste into the other. Not without a few changes of course.

I also had a change in the Elastic IP address, but hey that was whitelisted by Twitter! So I guess I’ll have to write to them again for the new whitelisting. Oh well.. One more interesting thing is that I’m now running on an EBS-backed instance, which was introduced by Amazon not so long ago. I wouldn’t have to worry about getting my stuff lost on a terminate or a rebooted machine as the whole drive is being dumped into an EBS. So backups are now completely instant via the AWS Management Console, they’re called Snapshots, takes one click and a few minutes ;) Now if I’d like to terminate one EC2 instance and start the whole thing over on another one, I’d just restore from EBS or Snapshot! Unless, of course, I decide to move to another region. I believe EBS blocks and Snapshots are restricted to regions, furthermore, EBS and EC2 compatibility are restricted to a certain zone in one region, which is obvious. I wouldn’t like to run an EC2 instanced in one data center, backed by a hard drive located in a different one.

Another good question would be Amazon CloudFront. Well, since the S3 buckets haven’t changed, CloudFront should work the way it used to despiting the move. Or at least I hope so ;)

Amazon Web Services: Moving to a New Region

I wrote about Optimizing Your Amazon Web Services Costs back in November, where I mentioned some of the upsides of Reserved Instances at Amazon, but haven’t mentioned any downsides, and here we are. Two weeks later Amazon announced the Northern California Region opening. I thought it wouldn’t differ from the Virginia data center, but still decided to give it a shot for a few hours.

I didn’t do much benchmarking but hey, I’m running a Twitter app.., remember? This means that access times to the Twitter API are crucial, so I started off with some basic pinging, and the pings from California seemed to be a few times faster than the ones from Virginia. Next, I ran Xdebug and analyzed the cache grind sheets for a few requests to different profile pages. Sweet to know that 95% of the time taken to load a page is curl accessing the Twitter API ;) this means that my code is well optimized. The overall results in the California region was ~40% better than Virginia, so I thought of moving there. The problem was that I already had a 1 year contract with Amazon for an instance in the Virginia region.

I wrote to Amazon via their contact form and asked about reservation transfers from one region to another, of course with additional charges (the California region is slightly more expensive) and soon got a negative reply. They mentioned that reserved instances are not transferrable from one region to another but I can always cancel my reservation in one region and open up a new one in the other. They didn’t mention any refunds so I decided to ask, but soon, scrolling through their FAQ I found this:

Q: Can I move a Reserved Instance from one Region or Availability Zone to another?
A: No. Each Reserved Instance is associated with a specific Region and Availability Zone, which is fixed for the lifetime of the Reserved Instance and cannot be changed.

Q: Can I cancel a Reserved Instance?
A: The one-time payment for a Reserved Instances is not refundable. However, you can choose not to run or entirely stop using your Reserved Instance at any time, at which point you will not incur any further usage charges.

So I asked myself, why the heck would anybody want to cancel a reserved instance if they don’t get refunded? The conversation kept going on Twitter. Friends mentioned that I could purchase an additional reserved instance in the California region and then sell computing time on the one I have in Virginia, but that sounded too sarcastic. I felt unlucky and sad, and thought I thought should stick to the instance I had in Virginia. If only I had waited a few more weeks before making the purchase…

This morning I received another email from Amazon, stating that although they don’t usually do this sort of stuff, they got approval to process the cancellation with a refund just this one time, so now I’m free to reserve an instance in Northern California, happy holidays! Well, on Christmas Eve, this feels like a gift and I’m very excited about launching all my stuff in the new region, hopefully in January. So, thank you Amazon and Happy Holidays to all of you.

Optimizing Your Amazon Web Services Costs

I’ve been with Amazon for quite a long time now and you must have heard that their web hosting services aren’t very cheap. The average total of one instance per month (including EBS, S3 and all the others) was around $120 at the start. That was back in July 2009 when I had no idea about how all this stuff works. With a lot of experimenting I managed to drop my instance per month costs down by around 40%. Below are a few tips that can help you lower your Amazon Web Services charges:

  • Use reserved EC2 Instances where possible. Amazon charges $0.085 per hour for an m1.small Linux instance in the US, that’s around $61 per month and $734 per year. A reserved instance costs me $227 for one year, plus $0.03 per running hour, that makes it around $490 per year for an m1.small instance. Use reserved instances only if you’re sure that you’ll be using it for a whole year. You can save even more if you purchase a reserved instance for three years.
  • Storage: EBS vs EC2. Pick EC2! That’s right, EC2! EBS charges you for provisioned storage, IO requests and snapshots. These may rise pretty quickly if you’re running MySQL on an EBS block – very risky! Run your MySQL on EC2. The php files and everything else should preferably be on EC2 aswell. You can use your EBS block for tiny backups of core PHP files if you’re running more than one EC2 instance.
  • EBS is cheaper than S3. S3 should only be used in cases where you have to serve your static content from different servers (perhaps through CloudFront), and maybe store some backups there too (don’t forget to remove the old ones!), but EBS is cheaper, even with snapshots.
  • CloudFront is okay. It does speed up your website, but you have to know that it’s more expensive for requests to Japan and Hong Kong

There you go. With these tips you should be able to get the Amazon hosting services for around $90/month, unless of course you have a 3 million visitors per day website ;) Also, for those of you wondering.. I haven’t used RackSpace, but I did compare their prices to Amazon’s and they’re more expensive.

Working With Amazon EC2: Tips & Tricks

It’s been a while now since I’ve been hosting on Amazon Web Services and I’d just like to point out some issues I had and quick ways of solving them. We’re gonna talk about setting up a server that would serve not only you, but your clients too, cause $100/mo is quite expensive, isn’t it? So let’s begin and keep this as straightforward as possible. If you don’t understand something, it’s probably because you haven’t read the official EC2 docs and haven’t searched the forums. This is not a tutorial, it’s just a set of rules you may want to follow to make things right.

Once you start a new instance from an Amazon predefined AMI (Fedora Core 8 for example) I suggest you start building your structure right straight away. Attach an EBS volume to you instance (I mount it to /ebs) and start creating your users with their home directories in /ebs/home/kovshenin not the regular /home/kovshenin. Also point your MySQL server to keep your database files in /ebs/mysql. There are plenty tutorials out there on how to do that.

Now, edit your httpd.conf, add your vhosts, point them to the right users dirs, install an ftp server and make sure you chroot the users to their home directories. That way they won’t be able to mess up with eachothers files and folders, peek passwords etc. You might want to change the root user’s home directory to / instead of /root in case you’ll want to use ftp via your root user (which is quite dangerous).

Now comes the fun part. The HTTP server runs under the apache user by default in FC8 and I recommend you don’t touch this. Damn it took me quite some time to figure out how the heck can the apache user execute and write to files not belonging to apache. I messed up big time with the groups, adding apache to all my client’s users groups, but thank god I found mod_suphp in the end. Install that one and make sure you use it and there’s no need to change the users umasks anymore.

Note: There’s a little issue with the mod_suphp in Fedora as far as I know, which doesn’t let you use the suPHP_UserGroup directive in the httpd.conf yelling that it does not exist. Most of the man pages on the net say you have to use that directive, but I’m good without it. It seems that suphp can figure out what user to run on its own, look closely at the config files, and also make sure you’re running php-cgi, not the CLI version. By the way, this is the part where WordPress stops asking you your FTP credentials on plugins/themes update, install, remove and core upgrade too. Speeds up the whole process ;)

I used the following code to test how mod_suphp works (or doesnt):

<?php echo system("id"); ?>

Which should output what’s the current user. Make sure you check everything works before going public, and do not set your min_uid and min_gid in suphp lower than 50. It’s safer to chown -R files and folders than to let suphp run your scripts via root or some other powerful user.

Backing up your EC2 and EBS

This is very important. Once you have everything set up and running, DO backup. Backing up the EBS is quite simple, just create a snapshot from the Amazon EC2 Management Console. Backing up the running AMI (instance) is a little bit mroe complex. You have to use the ec2 command line tools to bundle a new volume, upload it to an Amazon S3 bucket and register the AMI. There are plenty tutorials on the net on how to do that. Shouldn’t take you more than half an hour to figure it out.

Just make sure you have copies of all the major config files (httpd.conf, crontab, fstab, ..) backed up on your /ebs/config for instance. You might need them in the future (when you loose everything, haha ;) Restoring a backed up AMI instance is simple. Launch a new instance using the AMI you generated, attach the Amazon Elastic IP address to it and voila. Way too simple.

About the EBS, there are quite a few things you should be able to do with it before continuing. Restoring a backed up Snapshot: Create Volume from Snapshot, umount /ebs, deattach old volume, attach new volume, mount /ebs. Cool? Be careful when you’re resizing your EBS. The xfs filesystem automatically grows as far as I know, but in my case I use the ext3 filesystem. So if you need to grow your ext3 EBS you’ll go:

  1. Create a Snapshot
  2. Create a new EBS Volume from that Snapshot you created (say 10 GB if you were running 5 GB)
  3. Attach it to your Instance, say /dev/sdg
  4. Use the resize2fs command to resize the partition to 10GB
  5. Mount it to /ebs2 or whatever
  6. Check to see if everything’s in place
  7. Unmount /ebs2, deattach /ebs2, unmount /ebs, deattach /ebs
  8. Attach the 10GB volume to where /ebs was attached (/dev/sdf)
  9. Mount /ebs and start your services

There you go, back to work, server. By the way, when working with Amazon AWS, note that you should be working in the same region where your AMI is (us, eu, east, 1c, …) otherwise some of the options (when attaching, etc) might just not come up. Beware of that.

Well, I guess those are pretty much all the basics. Don’t forget to read the Amazon S3 tutorials and API, pretty sweet stuff! Good luck.