Какая конфигурация Amazon Web Service (AWS) для веб-службы RESTful является наиболее масштабируемой и высокопроизводительной?

Я создаю асинхронную веб-службу RESTful и пытаюсь выяснить, какое решение является наиболее масштабируемым и высокопроизводительным. Изначально я планировал использовать конфигурацию FriendFeed, используя одну машину с nginx для размещения статического контента, действия балансировщика нагрузки и обратного прокси для четырех машин, на которых запущен веб-сервер Tornado для динамического контента. Это' Рекомендуется запускать nginx на четырехъядерном компьютере и каждый сервер Tornado на одноядерном компьютере. Amazon Web Services (AWS) кажется наиболее экономичным и гибким хостинг-провайдером, поэтому вот мои вопросы:

1a.) На AWS я могу найти только типы инстансов c1.medium (двухъядерный ЦП и 1,7 ГБ памяти). . Значит ли это, что у меня должен быть один экземпляр nginx, работающий на c1.medium, и два сервера Tornado на экземплярах m1.small (одноядерный ЦП и 1,7 ГБ памяти)?

1b.) Если мне нужно масштабировать, как я могу связать эти три экземпляра с другими тремя экземплярами в той же конфигурации?

2a.) Имеет смысл размещать статический контент в корзине S3. Будет ли nginx по-прежнему размещать эти файлы?

2b.) Если нет, снизится ли производительность из-за того, что nginx не будет их размещать?

2c.) Если nginx не будет размещать статический контент, он ' на самом деле действует только как балансировщик нагрузки. Здесь есть отличный документ , в котором сравнивается производительность различных облачных конфигураций и говорится о балансировщиках нагрузки: «И HaProxy, и Nginx перенаправляют трафик на уровне 7, поэтому они менее масштабируемы из-за завершения SSL и повторного согласования SSL. . Для сравнения, Rock перенаправляет трафик на уровне 4 без накладных расходов на обработку SSL ». Вы бы порекомендовали заменить nginx в качестве балансировщика нагрузки на тот, который работает на уровне 4, или достаточно ли высокопроизводительный Amazon Elastic Load Balancer?