Herve Bizira's picture

Hi everyone, I'm very excited to try out turnkey hub on ec2 and I was wondering about  the best way to setup the following project. It's an existing project hosted on shared hosting account and I'd like to migrate it to use turnkey hub on ec2.

It has:

-a MySQL server to store user data

-stores uploaded images from users. Images need to be retrieved later on using a url to the specific image.

-a flash and php frontend using symfony 1.4

-git based source control

- developer specific subdomains (ex: developerName.theproject.com) that has a copy of the site for dev work.

-requires SSL endpoints for parts of the site


My initial thought was to put the DB on it's own dedicated instance. The flash and php frontend on web server instances and store the uploaded images in a seperate EBS volume that's universally accessible. I would use cloudwatch to spawn new instances of the web server images when necessary and a load balancer to distribute the traffic.


Any suggestions?


Thanks for your time


Alon Swartz's picture

Multi-tier setups (e.g., load-balancers, web-servers, backend database servers) are usually required for very large deployments, but from my experience you want to avoid reaching a setup like that if you don't need it.

Considering you're moving from a share-hosting environment, I'd recommend starting out with the simplest setup, and optimizing as needed. For example, you could start with a small EBS-backed TKL symphony server which handles everything.

When you reach its limits (and depending what they are), you could use TKLBAM to migrate to more powerful server (e.g. medium). Then, when you start reaching its limits, you can split out components to other servers. 

But, before you go for multi-tier, I'd look into optimizing the application itself as you might have a bottle neck that easily optimized.

Hope the above helps...

Herve Bizira's picture


Thanks for the reply Alon. Just a few more questions:


1- I've read over the documenation for the backup and migration system and am I right to presume that migrating to a more powerful system is a matter of minutes? I suspect that when my traffic starts spiking, that I'll need to be able to quickly scale up to more powerful instances.

2- If I choose to use an EBS backed volume for storage, can multiple instances access the same EBS volume? Are there any practical downsides to doing that...I don't anticipate my storage needs exceeding 20gigs for the first year.

3-What would be the monthly cost of setting up a small instance with 10gigs EBS that runs 24/7? Assuming traffic of about 100k users monthly? I tried using amazon's calculators but I couldn't predict some of the metrics they use to compute the final number (IO requests, etc..)

4-Is IO/bandwidth between the instance and EBS charged since it's not part of the local storage?

5-What kind of bottle necks were you refering to in a single tier design? And how would you optimize them? 

6-Do you have any example links showing scripts that auto onfigure new instances? Examples: setting up ssl on newly launched instances, mysql setup, etc...

I'm just trying to be as optimized (financially and setup wise) as possible before deploying.


Thanks for your time.

Herve Bizira's picture

one last question


7. The following article suggests using S3 backed instead of EBS backed instances:


However, you suggest using EBS backed? I was wondering why and also what happens when an instance fails on AWS, EBS or S3 backed, how do you recover?

Jeremy Davis's picture

I guess you'd recover from a 'failed' EC2 instance the same way you'd recover from a HDD failure in a physical server - with a backup! That's where TKLBAM comes in!

I have only just started using EBS backed instances and I definately find them more convienient for my purposes. But I don't have a server running constantly (I start-stop it as required). If you plan to run your server 24/7 then just from a financial perspective I would imagine that an EBS backed reserved instance would probably be the cheapest option - although I suggest you do the maths yourself to be sure.

Liraz Siri's picture

EBS-backed is equivalent to RAID in reliability, which is good but not perfect. Amazon have hundreds of thousands of these sub-systems so it's only natural that every once in a while some of them will fail.

That's the reason we recommend you always backup your servers with TKLBAM.

Liraz Siri's picture

  1. Yes, you can use TKLBAM to migrate automatically between pretty much any underlying deployment type, so you can start small and scale as needed.
  2. No. Multiple instances can not access an EBS volume directly. It works like a hard disk, not a network share. If you need network sharing, look into like NFS or Samba.
  3. It's very unusual for IO requests to be a significant factor in costs. It's usually a rounding error. I estimate the cost should be about $70-$80/month for a small instance running 24x7, depending on how much traffic you get. The range is for the bandwidth.
  4. No. They don't charge any extra for the bandwidth directly. EBS drives are connected to your instance on a separate fiber backplane from what I understand.
  5. Usually memory is the first thing you run out of if you're running a forked web server such as Apache. If that's an issue, you can get a lot of extra mileage by switching to another web server such as lighttpd or nginx
  6. Search the site's forums and documentation. These sort of issues may have been discussed before. In general you don't need to do much mysql tuning out of the box and replacing your SSL certificate is pretty simple too.

Add new comment