您的任务是优化您的云基础设施。节约成本是必要的。您将注意力集中在您每月的最大开销上——一个EC2实例的舰队。您可以查看度量和搜索日志。

迹象很明确。实例没有被充分利用。您对订单和实例进行了调整，EC2实例的成本会立即下降。生活和预算是好的。

然后，报告开始出现。起初，社交媒体上有几次提过它。几位客户叫“帮助台”。他们在连接到您的网站时遇上了问题。

然后，指标开始突破阈值，警报被触发。购物车被丢弃了，订单也减少了！收入下滑！

这种情况比您想象的更为常见。对于许多人来说，云优化开始和结束时使用的是正确的AWS EC2实例。

这可以产生可接受的优化结果，特别是对于小型的基本工作负载（例如，您的web服务器机群）。但是对于许多人，尤其是那些工作更复杂、工作负载更多样的人来说，这种简单的方法是不充分的，并且会导致资源利用率低和成本效率降低。

在几乎所有的云优化工作中，正确大小的实例都是重要且必要的步骤，但这只是其中的一部分。它可能会让你在正确的范围内，但是为了获得最好的座位，还有更多的工作要做。

这里有5个可操作的步骤可以帮助您集中您的云优化目标，并确保您调整的努力保持在正确的轨道上。

1、问问自己是否是否合理精简是正确的优化技术

您可以通过重构或替换资源来更有效地利用时间和预算吗？

一个恰当的例子是，当您的任务是对一个自管理的数据库集群进行正确的调整，比如MySQL或在EC2实例上运行的PostresSQL。您能从调整中得到多少英里？或者，用Amazon关系型数据库服务代替EC2集群，让AWS管理细节，这是否更有意义呢？

使用关系数据库服务，您可以将日常管理任务卸载，例如补丁和备份到AWS，并使用您通常在这些活动上花费的时间来处理应用程序的功能需求。当然，您仍然需要对关系数据库服务实例进行适当的大小调整，但是这样您就不再需要处理数据库本身了。

同样的好处也可以通过其他的管理服务来实现，比如Amazon ElastiCache（对于像Redis和Memcached这样的内存商店）和AWS目录服务。当你考虑与他们的自我管理等价的所有权的总成本时，通过替换来优化是一个很有吸引力的选择。

这些类型的优化可以提升服务器资讯news.webhostingtalk.cn/，在云基础设施的生命周期中产生巨大的收益。

2、查明您的最终用户何时和如何使用您的应用程序

他们（实际用户或其他软件或服务）何时使用您的系统？他们遵循什么模式？

如果没有这种用法信息的正确大小，如果它使您没有准备好进行不定期的需求更改，则将是毫无意义的。

如果使用模式遵循一个典型的日模式，随着需求的逐渐减少和流量的变化，您可以依赖AWS自动伸缩来调整容量以满足需求。但是，如果这些日常模式包括突然的需求峰值（像大多数人那样），自动伸缩可能无法迅速补偿。轻微的过度供应，以增加足够的能力来应对需求的短期峰值，可能是最优的。

如果你所期望的市场营销或销售活动会在你的应用程序中产生突然的、极端的需求增长，那该怎么办呢？您可以预先准备资源，以确保这些事件能够提供足够的容量，然后在不再需要时将它们分解。

了解应用程序的使用模式可以确保您在需要时能够具备一定的能力。如果没有，那么任何大小的调整都不会节省您的时间。

3、理解应用程序的体系结构

使用应用程序架构的知识来指导您的云优化工作。您的设计和体系结构决定了您可以使用哪些优化技术，以及你调整的努力会有多大的效果。

例如，您用来优化有状态应用程序的调整方法与您在无状态应用程序中使用的方法有很大的不同。解耦和分布式的应用程序比它们的单片应用程序有更多的选择。（如果你不知道这些术语的含义，那么现在是学习的好时机）。

您的应用程序的体系结构最终决定了它是如何扩展的，以及您的应用程序是如何影响您的正确的策略的。

垂直扩展的应用程序（如数据库等有状态应用程序）通常需要更传统的、非云的方法来进行正确的调整。不能够利用AWS云的弹性和可伸缩性来弥补需求的变化，垂直扩展的应用程序需要您预测和提供未来的容量需求。

对垂直可伸缩应用程序进行适当调整，需要过度供应能力，以弥补短期需求的增加。额外产能的数量取决于需求增长的预期速度，以及何时再次调整规模。您的过量供应越多，您等待来调整的时间就越长，但在那之前，您会有更多的闲置产能。

水平可伸缩的应用程序通常比垂直伸缩的应用程序更容易、更灵活。自动伸缩、水平可伸缩的应用程序可以很容易地补偿正确调整的错误或基线的漂移。这就是您想要的。

您可能会发现最好的优化方法是重新构建您的应用程序，这样它就可以利用额外的AWS服务和特性。

4、使用AWS计费选项对您的优势

AWS率先为云基础设施提供按需付费的计费模式，在AWS云服务中选择资源时，提供了前所未有的灵活性和自由度。

按需计费可以让您及时做出决策，然后只支付您使用时所使用的费用。这是最常见的选择，但是如果成本优化是优先考虑的问题，那么还有更经济的选择。

保留的实例不同于随需应变，因为它们允许您长期（一、三年）提交您的资源需求。作为回报，AWS提供了很高的折扣，在某些情况下，最高可达75%。

但是，在考虑保留实例时要小心。根据所购买的类型，这些实例特定于EC2实例类型和大小、AWS区域和可用性区域。记住，您今天做出的承诺可能会限制您未来的选择和灵活性。

抵制在第一天购买预留的实例的冲动，仅仅是为了省钱。将决定推迟到以后的日期，以便能够仔细审查流量和性能指标，以支持该决策。然后，定期回顾这些决定，并根据需要进行调整。

底线-在提交给预留的实例之前做您的准备。如果你不这样做，那就有点像把车放在马前。

5、最后，您可以正确地对EC2实例进行大小调整，对吗？

差不多了！在此之前，您应该真正了解您的应用程序及其操作方式。

它使用CPU和内存的效率有多高？它有什么磁盘IO需求？每秒能处理多少次请求？它的优点和缺点是什么？

这些问题（以及您在上面的步骤中所做的工作）将引导您走向特定的EC2实例类型和大小。了解这些信息对于确保您能够对所选的EC2实例类型和可用的系统资源进行最有效和最优的使用是至关重要的。

正确的调整是困难的，但是如果您对您的应用程序、您的客户和您的选择有一个透彻的了解的话，您可以确定您正在向正确的方向前进。