我是 AWS 的新手，做了我的研究，但没有得到好的答案，因此问了一个简单的问题。
到目前为止我做了什么
所以事实上，如果你http://example-domain-name.com你将能够看到该应用程序并与之交互......
我的问题是，我现在完成了吗，我的应用程序部署正确吗？正如我听到的恐怖故事，包括 AWS AMI 崩溃等。
您能否分享您在这方面的专业知识。
根据您对问题的评论，所有可能的最佳案例是高度可用、多可用区、自动缩放的 Web 层，由复制的 mysql 数据库支持，或者，如果您负担得起，则支持 Amazon RDS 之类的东西。这是一个示例 CloudFormation 模板，在您填写几个变量后，它将或多或少地构建我刚刚在大约两次单击中描述的内容。
这有点矫枉过正......我想......但如果你担心亚马逊的无数故障模式，高可用性可以付出代价。该模板的默认实例（包括多可用区 RDS）每月 270 美元左右，24/7 正常运行时间。如果你真的致力于你的博客，并且可以保证你会在上面写很多年，那么使用保留实例可以节省相当多的钱。
这是很多钱，是的。但这也低于我在纽约的每月汽车保险费率。这比亚马逊的价格更能说明我可疑的保险公司或我的驾驶记录，但在某些个人应用程序中，高度可用的设计可能值得付出代价。你的时间对你来说价值多少？博客呢？
称之为黄金标准，因为你必须有一辆装满黄金的自卸卡车才能负担得起并且还能吃。当你开始出血时你会失去什么？
可用区：进行多可用区部署，您可能会面临可用区中断的风险。这种情况不会经常发生，但在 DC 地铁中也不会发生这种情况。不过不用担心，如果您围绕单个 AZ 进行设计，那么您就在某个庞大且可能出乎意料的公司中。
RDS / 复制 MySQL：丢失高可用数据解决方案，您就有丢失数据的风险。考虑到最好的设计，这是一种痛苦，即使它像偶尔的 EBS 快照一样简单。
多个网络服务器：就像 MySQL 数据库一样，如果你把你的网络层放在一台机器上，你就要求中断。如果您能负担得起替代方案，您可以围绕它进行设计。否则，您将需要一种简单的编程方式来构建您的网络服务器。
自动缩放：我不明白为什么有人在不使用CloudFormation或 CLI 工具的自动缩放的情况下设计 AWS 应用程序，即使实例的最小数量和最大数量正好是一个。AWS 定价的免费套餐包含大量 CloudWatch 指标，可以轻松进行实例监控，但这当然取决于......
配置管理：每个 AWS 设计的共同点是配置管理。无论您实际部署了多少台机器，它都是部署过程中最重要的组成部分。无论您是使用 CloudFormation、Chef、Puppet、其他服务还是它们的组合，您现在花在配置管理上的任何时间，当您对机器构建仍然记忆犹新时，都会在以后得到回报。
这些组件中的每一个都有助于您的应用程序的稳定性，并且所有这些组件都需要花费金钱或时间。这只是你想花什么，什么时候花的问题。
您可以通过 Amazon 的免费套餐部分实现黄金标准。它包括足够的时间在单个 AZ 中连续运行一个微实例、一个 ELB 和一个小型 RDS 实例。在撰写本文时，它还允许使用 10 个自定义 CloudWatch 指标。免费套餐仅适用于第一年使用的新客户。如果您将其产品与一些基本配置管理相结合，您可以合理地在 AWS 上运行一个小型博客，以避免许多停机情况。
重要的是要了解您的 AWS EC2 服务器“可能”随时出现故障......这是“设计使然”......他们向您收取廉价非冗余商品硬件的廉价租金......没有 SLA...... .
所以真正的问题是：您是否有充分记录（最好是脚本化）的过程来从头开始快速重建服务器和/或从 EBS 快照中恢复它？
如果这个问题的答案是：是的！然后我会说你“做对了”......
如果没有，您可能需要多花一点时间了解 AWS 土地上可能发生的坏事......（再次“按设计”）。
没有什么好办法。您至少需要一个负载均衡器和两个应用程序实例。另外，根据您的应用程序，您将需要一个容错的 RDS 实例和/或 S3。
AWS 对于简单的应用程序或博客来说是错误的解决方案。通过使用其他提供商的单个 VPS 或专用服务器，您可以以显着降低的成本获得更好的性能和耐用性。使用 AWS，您需要为快速扩展应用程序的能力支付额外费用。如果您不需要这样做，那不是正确的选择。90% 的使用 AWS 的人不理解这一点。