Okay, I'm more of a coder, and not as familiar when it comes to things like system setup, though I try my best. I'm currently using Slicehost (stats below) to run a personal website that gets an okay amount of traffic.

  • Linux (Ubuntu 8.04.2)
  • 512MB RAM
  • Avg. xfer = 4.85GB (0.68 in / 4.17 out)
  • Automatic backups

I pay $48/month ($38 for hosting, $10 for backups).

I'm in the process of a site redesign, and with it, I'd like to move to AWS (EC2 & S3). I'm trying to figure out a similar (probably a little better in terms of RAM since I've consistently had high root & swap IO usage) setup, and how much that'll cost me.

Amazon offers a simple monthly calendar, but I'm not sure I'm entering the right info both in terms of finding a comparable setup, as well as what the price is coming out to be.

Relevant info about the new version of my website:

  • Ruby (REE 1.8.7) / Rails 3.1
  • PostgreSQL 9.0.4
  • SearchSphinx (2.0) is required to be running in the background
  • Various other cron jobs and rake tasks will be added as the app matures
  • App allows users to upload images as part of their profiles, which I'm planning on storing in S3

For comparison, the current version of my website running on Slicehost:

  • PHP5
  • PostgreSQL 8.3
  • Apache, DB, and files (images) all stored on same system

I guess my questions come down to:

  1. Do I want an on-demand instance, or a reserved instance? I assume reserved, but that made the price jump into the thousands for just 1 instance.
  2. According to the AWS instance types, I can probably settle for a Micro (613MB RAM) or Small (1.7GB RAM) instance. Does that sound right?
  3. I have no clue what numbers I want numbers to put into the EBS volumes part of the calculator, if anything. Do I even need an EBS volume, or will my EC2 instance have space that will be sufficient? (Keep in mind I'm offloading my user-uploaded photos to S3.)

I guess that's about it. When I try to make some rough estimates of what I assume is about right, it comes out to $63/month with a $350 setup fee. (This also doesn't include any of the S3 expenses.) I'm assuming the additional cost will be well worth the pain it will solve me in the long run, but I'm not even sure I'm putting the "right" numbers in the calculator in the first place.

  • "I'd like to move to AWS" -- why? What percieved benefits will you get from the move? – womble Jul 30 '11 at 0:29

While I love Amazon AWS, I would question whether it's right for you. AWS specializes in cloud computing; i.e. much of their value add lies "between" the server VMs -- management tools, extremely scalable data stores, traffic routing, etc. But you just need a single but larger server VM.

Have a look at Linode, they have a great reputation in the self-service segment, and fair prices for VPS's with more RAM. Or, given that you're no sysadmin, perhaps look for a managed VPS from vendors like ServInt, WiredTree etc.

Assuming you pick Amazon anyway:

Do I want an on-demand instance, or a reserved instance?

Reserved is substantially cheaper in the long run.

I can probably settle for a Micro (613MB RAM) or Small (1.7GB RAM) instance.

You'll need to measure your appstack + application RAM use. I would guess a Small 1.7 GB RAM instance is minimum.

Do I even need an EBS volume

You strictly need EBS; the 'local' instance storage (called ephemeral) is destroyed when the VM crashes / is shut down. All persistent data needs to be on EBS, S3, etc. But don't worry too much about EBS costs, for a small database it's usually not much of the overall cost.

Keep in mind I'm offloading my user-uploaded photos to S3.

Good idea -- which you can also do from Slicehost, Linode etc.

  • Thanks for the feedback. I'll check out Linode and see how that measures up with Slicehost and some other similar options. – Matt Huggins Jul 30 '11 at 3:14
  • Yes. ^^ This. 100%. AWS will cost you more, for a limited return for your use case. – Tom O'Connor Jul 30 '11 at 8:14

Unless there's something fundamental missing in your question, I'd say AWS would be a terrible move for you. Even before you factor in traffic and EBS (which you'll definitely need to store your PgSQL and SearchSphinx databases) it's double the cost, and for what? Your use case doesn't appear to include any of the things that AWS is actually good at (handling very peaky loads, particularly those that can be handled by background processing; or dealing with rapid growth and an incompetent IT staff that can't do capacity planning), so you'll be paying the "instant scaling" tax without getting anything back for it.

To answer your specific questions:

  1. "Do I want an on-demand instance?" -- maybe. Think of a reserved instance as being like buying a server outright and upfront. If you'd be willing to do that for your service, then you get a reserved instance. If you don't know if you'll need the server in 6 months or a year, then you probably shouldn't. And if you don't have the up-front cash to pay for it, then obviously you can't.
  2. Instance sizing -- as Jesper said, analyse your service's memory footprint and make your own decision. If you're running hot now on 512MB, my guess is that a micro wouldn't do you much good.
  3. Yes you need EBS. Where is your PgSQL and Sphinx index going to live otherwise? I suspect you may not have realised that EC2 is fundamentally different from other hosting providers. When you boot an instance, you don't get back what you had when it shut down. When you boot an instance, you get what is in the AMI you booted. That means that every time you do security updates or change anything in the OS you want to be persisted, you're going to have to re-roll that AMI, and anything that naturally changes during execution has to go on an EBS (and they don't perform at all well, in my experience).

Again, I don't think you're a good fit for using AWS. Stick with a traditional VPS service.

  • Thanks for the answer, that definitely helps clarify where I had some questions and confusion. I'll look into some of the other VPS solutions available for now in conjunction with S3 storage. – Matt Huggins Jul 30 '11 at 3:14

I'm going to offer an alternate perspective on this, since my situation is somewhat different (not quite mission critical), and gives me a bit more leeway.

One of my servers is run on AWS - it is mostly for some small sites for me and a few friends, about 10 sites, total data transfer 2GB/mo. All are PHP/MySQL running some CMS.

My monthly cost is $12+/-2: $5 for instance costs, $2.5 for snapshots, $3.5 for EBS (and the remainder is for 'miscellaneous items' ($0.5 for S3, $0.2 for bandwidth, $0.08 for Cloudfront, etc). I could add another server for about $8/mo (which I plan to do sometime).

My t1.micro runs PHP in FastCGI mode, with Apache, nginx, postfix, dovecot, vsftp, and mysql - uses 250 MB of memory, and loads a Wordpress blog in under 2s.

The reason my costs are so low (other than the obvious - small sites and micro instance) is because I go with the spot price. I have noticed that the fluctuation is minimal, typically the same as the reserved instance cost. So I have overbid significantly (something like $0.5 for the $0.007 instance) and I am essentially guaranteed that the instance will not be terminated. I doubt you will find a VPS solution for under $5/mo with root access.

Certainly, the premise is useless for something mission critical, but implement a bit of failover and you could easily have something viable. For me, it is the perfect platform to experiment and test things at the lowest possible cost.

My answers to your questions:

  1. Overbid spot instance (otherwise, you have to go reserved)
  2. The server depends on your specific needs - I would suggest PHP-FPM and use nginx as a reverse proxy for static files - it will drop your memory usage significantly. If you can get by with a micro instance go for it - keep in mind that you can always upgrade later - that is the advantage of AWS.
  3. You must use EBS volumes - remember to make them persistent (EBS root volumes are not persistent by default).

AWS can be very inexpensive in certain circumstances, and extremely expensive in others - be creative and keep your options open, and you will find what is best for you.


If you focus on costs, you could try cloudorado, which will calculate price of a server at multiple providers. It won't calculate backups though, but server and transfer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.