aws ec2时间_AWS成本优化实践

我所在的部门研发的主要产品是桌面云（Desktop Cloud），又称为桌面即服务（Desktop as a service）。我所在的组主要工作是提供桌面云提供面向管理员和运营人员的监控服务。

这个监控服务本身也是构建在云上的，在AWS全球多个区域中都有部署，每天接收并处理高达4.4亿条来自桌面云的监控事件。

服务自上线以来一直稳定运行，在AWS上的花费也随着业务的持续增长而水涨船高。从今年年初开始，由于新冠的流行，越来越多的公司为了员工的健康与安全，把远程在家工作当作首选项。因此桌面云的业务在一二季度出现了爆发性的增长。与之而来，监控服务的流量也汹涌而来。同时客户对监控系统也提出了更高的要求，想通过监控系统了解在桌面云上的投资是否帮助他们的员工高效的在家工作。

随着监控流量的持续汹涌而来，为了保证SLA，监控服务也进行了相应的扩容，于是在AWS上花费也出现了好几倍的增长。第三季度的时候我花了点时间研究了一下怎样节约在AWS上的开销，在这里跟大家分享一下。

钱花在哪儿了

省钱的第一步要考虑的就是钱花在哪里了。这里我推荐使用AWS Cost Explorer查看和分析您的AWS成本和使用情况。 该工具提供默认报告，可帮助您直观地查看成本和使用情况（例如AWS账户，AWS服务）或资源级别（例如EC2实例ID）。 首先使用“关联帐户每月费用报表”来确定您的费用产生的主要帐户。 接下来，在这些帐户中找出构成费用的最重要服务。 您可以使用“按服务每月费用报表”来执行此操作，使用每小时和资源级别的粒度和标签来过滤和标识产生费用最多的资源。

钱花在哪里了这个问题有两个维度：一个维度是横比，找出最花钱的Top 6 AWS服务，一个维度是纵比，按月逐项比较开销，找出费用增长最快的Top 6 AWS服务。接下来把这两个维度得到的服务列表放在一起综合考虑，排出要重点调查费用的AWS服务的顺序。

我的做法是按照斐波那契数列（8，5，3，2，1，1）对两个维度的Top 6打分，然后对两个维度进行合并排序，从中选出了Top 5需要调查费用的AWS服务。（可怕的理工科量化思维！！！）

费用概况

在讨论我的Top5之前，我想给大家一个CMS费用使用的概况。我曾经问过一位某大厂高管朋友，他们云计算中心开销最大的三项是什么。我当时以为是CPU/内存，结果出乎我意料之外。云计算中心不算房租最大的三项开销是电费，网费和存储（也就是硬盘）。

CMS作为一个使用AWS的云服务，费用上也有类似的特征，大概是这么分布的

服务	网络传输	存储（EFS/EBS/S3）	计算（EC2）	监控（CloudWatch）	数据库	Kinesis	其他服务

分而治之

经过打分我的Top5是EFS(Elastic File System), 网络传输，监控（Cloudwatch），Kinesis，EC2（Elastic Cloud Computing）。接下来做进一步分析。

Top 1 - EFS

EFS的分析很简单，分析每个目录的大小，找出Top5的目录。很快就发现了原因 1）某个服务的运算数据中间结果放到了EFS上没有及时清除 2）某些服务的历史数据放到了EFS上。解决方法很简单，对1）进行定时清除，对2）定时把数据备份到S3上并进行清除。同样大小的数据，EFS的成本大概是S3的10到15倍。对于备份历史数据，S3已经足够好了。

通过以上调整，在生产环境中，EFS开销大约减少40%。

Top 2 - 数据传输（Data Transfer）

以下是Data Transfer的费用状况

其中NAT Gateway费用相当可观。

这是怎么回事呢？那就查文档吧，终于在NAT网关文档的某个隐秘角落看见了以下说明

向同一区域中的 Amazon S3 或 DynamoDB 发送流量时的最佳实践
为了避免在访问位于同一区域的 Amazon S3 和 DynamoDB 时产生 NAT 网关数据处理费用，请设置一个网关终端节点，并通过该网关终端节点而不是 NAT 网关路由流量。使用网关终端节点不会发生任何费用。有关更多信息，请参阅 网关 VPC 终端节点。

好像有点相关，那就先试试吧。现在测试环境上创建了S3的VPC终端节点，观察3天，发现效果不错，数据传输的成本下降不少。同时文档中还说可以为其他服务创建VPC终端节点，依葫芦画瓢，按照文档对其他几个有大规模数据传输的服务也创建了VPC。再观察了几天，发现网络传输费用进一步下降。

将以上步骤逐步应用到生产环境中，最终数据传输（Data Transfer）开销减少大约55%。

其中S3 VPC终端节点的流量时完全免费的，其他服务的VPC终端节点还会收取一部分费用，但是也比走NAT下降一半左右。

Top 3 - 监控（Cloudwatch）

对于Cloudwatch，初步怀疑是有某些服务写入了大量的日志。老套路，打开Cloudwatch面板看每个LogGroup的日志吞吐率指标。很快就发现某两个服务的日志吞吐率很高，一个达到了800k/s，另一个是300k/s。

打开日志文件并结合代码，调整并优化了对应的日志级别。

生产环境上线后，Cloudwatch成本节约65%。

EC2/Kinesis

EC2/Kinesis分析后没啥可以节约的，每月间的费用增长是正常的业务增长造成的。

结果

这几板斧下来，每月的AWS开销下降大约30%，数字还是相当可观的。

下一步

在CMS中，不少服务器用了RI，其实有不少一次性的低优先级任务可以考虑使用Spot Intance来完成，不过这需要对服务进行更深层次的改造，非一朝一夕能够完成。

另外这篇文章中也提了不少可以持续降低AWS开销的思路，[10 things you can do today to reduce AWS costs] (https://aws.amazon.com/cn/blogs/compute/10-things-you-can-do-today-to-reduce-aws-costs/), 希望对大家有所启发。

一点感想

• 买的没有卖的精
• 成本就象海绵里的水，只要去挤，总是会降下来的
• 多做成本分析，钱可能花在了你想不到的地方
• 勿以善小而不为，小改进可能节约大成本

版权声明

转载请标明出处。我的同事对本篇文章亦有很大贡献。