我们的初创公司有一个应用程序，已投入生产近一年，并Rails/MySQL+MongoDB/Unicorn/Nginx在单个 Linode 盒上成功运行。
我们最近决定迁移到 AWS，原因如下：
- 成本- 我们获得了价值数千美元的 AWS 信用额度（通过我们参与的加速器计划），如果不使用它将是一种遗憾。
- 可扩展性- 我们最近开始收到很多媒体的关注，我们的用户数量也在增加。考虑到 Linode 盒子的成本以及我们得到的回报，它在近期不会有很好的扩展性。
- 能力- AWS 堆栈在功能和可用工具方面似乎令人印象深刻，并且我听到和阅读了很多好评（也有一些差评）的报道，说它可能是开始成长的好地方。
总体而言，成本和可扩展性问题对我们有利，因为免费可靠的托管很难被击败（好吧，直到我们的 AWS 信用额度用完）。我们尚未获得资金，因此所有 IT 成本都来自我自己的口袋（每月几百美元）。
所以基本上，我想将我们的应用程序迁移到 AWS，并且我一直在考虑以下堆栈：
Elastic-Load-Balancer
|
|
[1+ Rails App over Unicorn/Nginx]
|
|
[1+ DB Server (MySQL + MongoDB)]
应用或数据库服务器可以根据需要水平扩展。由于我们还没有真正突破断点，我考虑先从 1 个应用服务器、1 个数据库服务器（目前不是 RDS）和 ELB + Route53 开始，以管理 DNS 和负载平衡。
我从未使用过 AWS，也不是 DevOps 专家，所以我想就以下几件事征求一下反馈：
- 我应该如何管理 unicorn+nginx 设置中的 Web 服务器部分？到目前为止，它们都在同一台机器上，因此问题不大。我应该保留 nginx.conf 设置，只让 nginx 在每个 App 实例上监听端口 80/443 吗？
- 我希望能够通过根据需要添加更多实例 (AMI) 来扩展应用层。这在短期内可行吗？例如 - 直到我们有钱聘请 DevOps 人员或因贫困而关闭商店 :)
- 如果您能学到其他任何经验教训或者记住任何事，我们将不胜感激。
注意 - 由于各种原因，我暂时不想使用 OpsWorks：我们的应用服务器高度定制化，不支持 Mercurial，不太成熟，等等。
谢谢。
答案1
如果您需要，AWS 可以提供可扩展性 架构建议
- 使用 elb 作为第一层
- 使用两个或更多应用服务器（出于冗余原因）
- 如果可以的话，使用 rds
现在...如果 rds 不是一个选项，那么您最终将得到一个主数据库和一个从属数据库。对于数据库，我建议使用条带化的 ebs 卷。
配置管理可以是任何东西，只要你觉得它舒服就行。当然还有 chef、puppet 等。