Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am setting up a Rails app on AWS that: 1) all traffic must be ssl encrypted 2) will highly fluctuate in the amount of traffic on a weekly basis 3) will by maintained by someone that is a stronger coder than sysadmin

I am thinking that SSL termination on an elastic load balancer backed by small ec2 instances running nginx and unicorn

A small subset of the requests will take longer than 10s, because of this I am also debating using 'thin' instead of 'unicorn'.

My question is this: Is this sane? Am I stepping into a quagmire of cost, maintainability, security or performance problems?

share|improve this question

More than it is sane or not, if you are not a sysadmin and will take care of it, you will become a sysadmin, real fast. Are you up to it? :) I might be missing the point here, but let me tell a bit of my experience being a ruby dude playing as sysadmin on amazon:

There is a lot of tricks that you need to do to run on amazon: - The ELB (Elastic load balancer) on amazon is only a CNAME record, so you cant make point to the ELB, so you will need to have one webserver with a elastic ip to have a .htaccess or reflection or whatever is the rewrite thing on nginx or unicorn. Plan for it so it doesnt bit you back.

As far as thin vs unicorn, it is a design strategy beyond amazon in this case. I never used thin but heard good thinks for long pooling connections comet style. Amazon should be just fine for long lived connections, IMHO. If you even want to go safer, you can use the sticky cookies to make sure the client browser sticks to only one server.

"Am I stepping into a quagmire of cost?"

Yes, it gets expensive fast on amazon.

"Am I stepping into a quagmire of maintainability?"

Yes and no. I was used to having the machines "with a few miles" where i could go and hit reset or replace a harddrive. On amazon, you need to be prepared to have one of your machines go stale, and you will have to reboot it. So you need to plan to either have a strong image and keep it updated or go for a chef or puppet thing to manage your servers (and go crazy, that is so hard to get it setup, took me a month, but I did learn from 0 )

"Am I stepping into a quagmire of performance?"

Remember that the disk io is far from ideal, so DB for writes gets slow if your database does a lot of writing, definitely do simple trial to make sure the speed is good enough. And also, you will have to use EBS for database files.

The processor speed and memory are pretty good. I wouldn't worry.

And also, I would go bigger instances before going horizontal on many small instances, unless you plan to run out of ports because of those long pooling connections. If you want to have better performance, it is cheaper to scale vertically until you hit xlarge, instead of spinning tons of machines.

"Am I stepping into a quagmire of maintainability?" --- again

If you have a ton of small machines you want to elastic bring machines up and down, and it is a hassle to do it.

If you want developer friendly, i would go with EngineYard and check if you can deploy with their service. It is worth it.

Please feel free to ask questions!

share|improve this answer
Thank you for the time and thought you put into your answer. EngineYard is a great suggestion, but I don't want to spend that kind of money on hosting. I fear I did a poor job of framing the question. (This is a rather opinionated question to begin with.) 1. That being said, I have been maintaining a 100 node amazon cluster for the last 2 years. 2. I am aware of the cname restriction and want to use cnames exclusively. 3. I plan on sharding the database and mounting it on a raided ebs volume. Again ... Thank you for your thoughts – Aaron Scruggs Dec 29 '10 at 16:28
Not a problem! :) – rafamvc Dec 29 '10 at 17:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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