- 最新
- 投票最多
- 评论最多
【以下的回答经过翻译处理】 这里有很多东西需要搞清楚,答案并不简单,因为改变一件事会影响另一件事。我强烈建议您联系当地的 AWS 解决方案架构团队,以便您可以就这些事情进行互动对话。
也就是说,一些(相对)快速的答案:
我们始终建议您运行多个实例。高可用性是关键,使用负载均衡器和自动缩放组可以很容易地做到这一点。在一个实例变得不健康的情况下,这会给你更高的生存能力;如果更多用户访问您的网站,还可以让您扩大规模。
但是,这确实会导致您必须跨多个实例分发静态文件的情况。您是否创建了一个包含正确文件的图像以便在发布时准备就绪?您是否有定期运行的更新过程?您应该使用 EFS 将文件放在共享文件系统上吗?所有这些都是有效的答案,取决于很多因素——因此我建议就此进行对话。
您还需要考虑 RDS 数据库的可伸缩性。
对于备份,(同样)有几种方法可以解决这个问题,但我将从 AWS Backup 开始。请注意,如果您有一个从其他来源构建您的实例(或 AMI)的自动化过程,那么您不需要备份它们。如果您在 S3 中进行版本控制,则不需要对其进行备份 - 除非您希望区域间的生存能力,在这种情况下,跨区域存储桶复制是一个很好的解决方案 - 但具有该要求也会带来数据库复制方面的复杂性和实例维护。
根据我的其他回答,这个 re:Invent 视频 绝对值得一看,其中涵盖了很多此类主题。
顺便说一句,始终选择“更高”的实例编号(例如 t3 而不是 t2)- 较新的实例类型(具有更高的编号)通常更便宜和/或提供更好的性能。此外,“t”系列实例在所有 AWS 实例类型中是独一无二的,因为它们使用 CPU 积分以降低成本;但对于高性能,它们可能不适合您。它们可能是,但除非您[监控您的 CPU 积分](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits。 html) 随着时间的推移。
相关内容
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前