当我们的企业开始采用云服务时不仅仅面临的是技术革新，它还很有可能改变原组织的运作方式。当企业由原定期发生的投资IT资源，转变为价格与资源有效利用密切相关时，了解驱动云定价的因素和成本优化策略知识是非常值得的，它将会为我们的企业节省大量的成本支出。

目前虽然有很多企业已经上了云、在用云，但是重视AWS成本优化的企业目前可能并不多。我相信随着后续云计算的不断发展，更多的企业会使用云计算，且会有越来越多的企业和用户开始重视AWS使用成本，开始学习优化AWS的使用成本，我希望我们都是掌握成本优化的先行者，一起学习，一起进步。

好的，下面步入正题，《优化AWS使用成本》系列的第一部分介绍了：

优化AWS使用成本系列（一）思维模式转变与成本分配标签
优化AWS使用成本系列（二）AWS Organizations与成本优化文化建设

我们今天开始第二部分，正确配置实例规模。在使用AWS的过程中，如何正确配置实例大小/规模呢？首先在使用计算资源时，实例大小和规模要和业务匹配；其次，结合不同的业务场景，选择适合的实例的使用方式，这样才能最大化的优化AWS的使用成本。

-第二部分 正确配置实例规模-

–计算选型的一些简单原则–

在实例选型时，基本上的原则是只满足业务容量需求即可，不需要过度的配置，造成成本的浪费，因为实例配置可以随时进行调整，当配置不够时在调整即可。

那如何能够正确配置实例的大小呢，利用Amazon CloudWatch，或者一些类似的监控指标，观察业务利用率，确定缩减规模。

另外呢，如果需求实在太小，可考虑容器，AWS有对应容器的服务。

还有AWS主推的无服务器计算架构，AWS Lambda，不需要购买实例，直接在Lambda上传相应的脚本完成对应的功能，只收取很少的请求和持续时间等费用，省去了大笔实例费用。比如，可以上传一个脚本，功能为当用户上传到S3文件成功时执行对应的操作等等。这块的内容比较多，感兴趣的同学可以重点看下AWS Lambda服务的内容。

–计算实例典型使用方式–

计算资源选型，AWS将实例根据负载类型分为计算/内存/通用/存储/突发性能等等类型，不同实例系列，对应着不同的优化，以及CPU虚拟核心对应内存的比例等等，用户可以根据实际的计算需求进行选择。

以下是一些计算实例典型的使用方式：

对于一些稳定的需求，可以使用RI（预留实例），比如DB、账号服务器等等，这样能享受最高达75%的优惠折扣。

对于一些可变但可预测的需求，比如业务中一些前端WEB服务器，可能根据负载情况所需的服务器数量不同，可以用AUTO SCALING服务，当负载高的时候启用更多的实例来支撑业务负载，当负载下来时自动缩减实例数量达到既满足了业务承载，又节省了成本的目标。

另外对于一些DEV/TEST等内部环境，在不使用的时候可以随时关闭节省成本，因为开着就会计算成本，在需要时在开起来。

对于一些特别临时的需求，可以使用Spot实例，最高可以节省90%的成本，这部分后面在具体讨论。

在本文的最后，我想提供一个通过CloudWatch监控到计算资源浪费后调整实例类型节约成本的一个例子，帮助大家理解本文的主题，正确配置实例的大小/规模：

1. 配置资源时使用的是m4.4xlarge,1.72美元/小时
2. 业务上线后通过cloudwatch等监控指标，发现服务的负载非常低
3. 根据负载情况调整成m4.large实例，价格是0.215美元/小时
4. 再次对性能进行观测，如无异常完成此次调整
5. 最终成本节约87%

我们继续《优化AWS使用成本》系列的第一部分成本优化基础的剩下内容。

–使用有效的账户结构–

使用有效的账户结构，主要是指整合账户。整合账户这部分主要是针对企业有多个AWS账号的情况，尽早的对组织的账户规划对于成本的优化会非常有帮助。

整合账户是指通过AWS organizations服务进行AWS账户的管理，可以在服务中创建AWS账户也可以将现有账户加入组织，主要功能包括整合账单和账户管理功能：

• 整合账单，可以使用组织的主账户整合和支付所有成员账户。
• 账户管理功能，主账户可以限制成员账户访问AWS服务，进行权限方面的管理（这块不在本主题的讨论范围内，感兴趣单密吧）

与成本相关的主要是整合账单。

整合账户后，除了可以合并计费付费，几个比较容易忽视的对AWS成本优化有很大提升的部分是：

• 首先，不仅仅是合并付费，各成员账户的一些服务使用量也会合并计算，而一些AWS的服务如EC2和S3等服务，会随着用量增加而享受更低的价格，这就是整合账户对于成本优化的帮助之一；
  
• 其次，很重要的一点是，在整合账户的组织中的任何账户，都可以享受其他账户购买的RI小时成本优惠，这就意味着可以规划买一定比例的RI折扣放在主账户，其他账户的EC2等资源就直接享受可能高达75%的折扣。RI是指预留实例，这个在后面会具体介绍。

–使团队设计成本架构–

在业务架构设计初期，最好让熟知成本架构团队参与，在架构设计时就做好成本优化，避免造成资源的浪费，导致业务上线后在进行调整（虽然比传统数据中心方便）。

匹配的这些知识需要靠相关的培训来获得，使团队可以熟悉成本优化，AWS成本相关的服务，建立主动优化的意识等等。

在优化成本的过程中建立可视化过程及目标，定目标，看效果，不断优化不断调整，通过AWS提供服务，如预算工具等等进行跟踪，定期评估，优化。

AWS成本优化知识哪里来？下面的星球啊：）

–分配优化责任–

分配优化责任，就是明确成本的负责人以及目标,很多企业设立专门的云卓越中心负责成本跟踪和优化相关工作。

建立精益成本文化，不断的培训和传播相关知识，在业务各个阶段中选择满足需求的最优资源，以及不断的优化使用成本，让使用者在使用云时形成自然成本优化意识，形成文化。

很多组织在业务快速增长时没有重视成本优化方面的事情，殊不知省到既是赚到，可能关注优化知识几分钟能省下几百万。

整个第一部分结束。

(待续)

和群里的其他同学开始引导调查账单具体原因：

1. 先看了下4月的账单，发现账单的大部分的费用是NAT网关造成的，共1972小时，NAT网关是按照小时付费，不同区域价格不同，此账单区域每小时0.059美元，故116.35美金。（如图）

2. 用成本管理器看了下详细信息，确认确实在5月初NAT网关导致的扣费。（如图）

3. 1972小时，约82天，所以可判断NAT数量肯定不是一个，故引导查看了下CloudTrail,发现在4月是创建了3个NAT网关，5月份删除了，所以82天除以3月约27天，所以这部分也确认是正常的。（如图）

4. 最后对于该同学提出1，2天内被扣费100多美金，是因为AWS是月账单，一般是在月初的几天扣除上个月的使用费用，故账单的问题全部解除。

以上，往往我们在用AWS时，在资源可清退时只记得把EC2、S3这些比较明显的资源删除，而确忽视了EBS、NAT网关、ELB，很多资源都是按小时付费，最终导致金钱受到损失。

所以要养成定期跟踪账单情况的习惯，设置好账单告警，及时清退所有无用资源。