我是一名 IT 人员，正在尝试评估将我们现有的物理数据中心迁移到 AWS（6 个应用程序服务器和 2 个复制的 MySQL 服务器）的成本。Amazon 提供的成本计算器基于带宽需求和 3 种大小的服务器实例。我知道我们的带宽需求是多少，但我很难确定 EC2 服务实例大小与我们的特定硬件/负载相对应。我们的负载在计划上变化很大，因此我设想在高峰时段至少有一个“按需”实例。我可以使用哪些工具/策略将我们的物理设置映射到相应的（负载优化）AWS 设置？
答案1
我发现提供的成本计算器对我个人来说不够用。我目前的部署包括 3 x m1.small、2 x m1.large、1 x m1.xlarge 和 1 x c1.xlarge 服务器实例。我们在 9 个多月前从传统数据中心的 3 台物理服务器扩展到现在的这个规模。
计算中最容易确定的部分是每小时实例成本。我发现，由于定价方案，我的 S3 成本大部分都微不足道。EBS 卷和快照实际上比 S3 成本高，而且计算起来相当容易，不过我建议高估 I/O 请求，因为我发现我们的实际使用量高于我们最初的估计。
带宽是个棘手的问题，它少于服务器实例本身，可能是第二大成本因素。我以为我们对带宽使用模式有所了解，但 AWS 下的实际使用情况证明这些初步估计是错误的。需要记住的几件事是，您拥有公共入站和出站带宽，但也有区域间带宽。如果您的实例在同一区域但在不同的可用区 (AZ) 中运行，则需要为您支付带宽费用。当您考虑 EBS 卷时，这也算在内，因为它们是在给定的 AZ 中完成的。实际上，由于实例本身之间的通信，我们已经看到区域间带宽高于我们的公共带宽使用量。
我创建了自己的电子表格，在尝试为预算目的提供估算时，它可以帮我完成大部分计算。我目前正在检查电子表格以获取新预算的修订更新。不过这次我能够利用亚马逊提供的一些使用历史记录，以便提供更好的估算。
至于哪个实例映射，这已经是最佳猜测了。您可以尝试根据服务器主要用途的 CPU 和内存强度进行匹配。我们实际上使用 AWS 而不是物理服务器来拆分我们的基础设施，以便我们能够更好地满足各个部分的需求并允许额外的可扩展性。