我是一个试图评估将现有物理数据中心迁移到AWS（6个应用程序服务器和2个复制的MySQL服务器）成本的独立IT人员。 Amazon提供的成本计算器基于带宽需求和3种尺寸的服务器实例。 我知道我们的带宽需求是什么，但是我很难知道EC2服务实例的大小是否与我们的特定硬件/负载相对应。 我们的负载按时间表差异很大，所以我预计在高峰时段至less有一个“按需”情况。 我可以使用哪些工具/策略将我们的物理设置映射到相应的（负载优化的）AWS设置？
我发现成本计算器对我个人来说是不够的。 我目前有一个部署3 x m1.small，2 x m1.large，1 x m1.xlarge和1 x c1.xlarge服务器实例的部署。 我们从传统数据中心的3台物理服务器扩展到了9个月前的这一点。
计算最简单的部分是小时实例成本。 由于定价scheme的原因，我大部分时间发现我的S3成本是微不足道的。 EBS卷和快照实际上比S3成本要高，而且计算起来相当容易，但是我会build议高估I / O请求，因为我发现我们的实际使用量比我们原先估计的要高。
带宽是棘手的，缺乏服务器实例本身，可能是成本的第二大成本考虑。我认为我们有一个带宽使用模式的想法，但在AWS下的实际使用已经certificate，这些初步估计不正确。 有几件事要记住，你有公共入站和出站带宽，但也有区域间带宽。 如果您的实例在同一区域运行，但在不同的可用区域（AZ）中，您将收取带宽费用。 当您考虑EBS卷以及在给定的AZ中完成时，这也是很重要的。 实际上我们已经看到，由于实例本身之间的通信，区域间带宽高于我们的公共带宽使用。
我创build了自己的电子表格，在为预算目的提供估算值时，为我执行大部分计算。 我目前正在通过电子表格来获取新预算的修订更新。 但是这一次我能够利用Amazon提供的一些使用历史logging，所以我可以给出一个更好的估计。
至于哪个实例映射是最好的猜测工作。 您可以尝试根据服务器主要用途的CPU和内存强度进行匹配。 实际上，我们使用AWS比使用物理服务器更多地分离我们的基础架构，所以我们可以更好地匹配各个部分的需求并提供额外的可扩展性。