随着上云的企业越来越多，上云成本问题也受到越来越多的关注。

在上云之后，很多人觉得IT支出不但没有减少，还比以前花的更多了，这到底是什么原因呢？

企业如何通过成本优化，来降低上云的费用？

 

 

 

1 上云的成本

 

 

上云的成本包括：计算的成本、存储的成本、网络的成本、应用和管理成本。

 

 

 

首先我们要注意一点，成本的管理并不是在方案实施以后才需要关注的，而是在设计方案的时候就应该考虑了。

和迁移到云端一样，成本控制和优化需要事先规划，事中分析，并且做好事后评估，然后不断地改进。

任何方案都不是完美的，需要一直进行回顾，并且不断地，与时俱进的提高。

 

 

2 计算成本优化

 

 

EC2 ：实例大小+使用时间

Lambda：请求数量+持续时间

ECS：

EC2模式：实例大小+使用时间

Fargate模式：vCPU+内存资源

EC2的计费模式主要是4种，首先是最常见的按需模式OnDemand，然后是预留实例模式Reserved Instance，

也就是签约拿折扣的模式，1年或者3年。还有一种Spot模式，也就是投标模式，谁出的钱多就给谁，但是极不稳定。

目前还推出了一个新的模式，叫Saving Plans，也就是不再按照固定的大小和时长来决定，而是更加灵活的按照使用费用来决定，很多地方都比预留实例模式更加灵活。

EC2的计费模式是按照实例使用时间x实例类型的单价x折扣率来决定的。

Lambda相对于EC2而言，简单很多，计费方式是由请求的数量还有持续的时间来决定的。

当然，由于Lambda有一些免费的额度，使用的量里面可以事先扣除这一部分，只收额外的使用量的费用。

 

 

 

 

上图表格列举出了不同的EC2模式的适用范围，适用模型还有折扣度。

按照AWS过去的知识体系，Spot是最便宜的，但是极不稳定，只适合在无状态的应用下使用，也就是随时可以开始或者终止的应用。标准的RI折扣度可以高达75%，

但是非常的不灵活，基本不能调整，可变RI可以修改大小，但是折扣度掉到了最高62%。这里我比较推荐最新的Saving Plans，

既可对签约的实例进行一部分修改，也可以享受最高72%的折扣。Saving Plans也分2种模式。

 

计算成本优化建议：

 

1. 做好设计，选择合适的实例类型和大小

2. 实时监控计算使用率

3. 对可预测的实例购买长约

4. 使用Auto Scaling

5. 少量计算可以使用lambda，无服务的计算尽量使用spot

6. 尽量使用container，充分利用所有资源

7. 充分利用免费的资源

 

 

 

3 存储成本优化

 

 

S3分为5种，分别是：1. S3标准2. S3智能分层3. S3-IA4. S3 Glacier5. S3 Glacier Deep Archive S3并不是只是简单的按照数据用量来收费。

不同的类型有不同的价格，并且在数据使用费之外，还有别的费用，比如数据请求费和检索费。

从1-5，数据存储费越来越便宜，但是请求和数据检索的费用却越来越贵。所以S3的使用总费用是数据存储费+请求检索费+传输费用。

 

 

 

 

相对而言，EBS就简单很多了，EBS分4种模式：1. 预置的 IOPS SSD(io1) 卷2. 通用型 SSD (gp2) 卷3.

吞吐量优化型 HDD (st1)卷4. Cold HDD (sc1) 卷 数据存储费和IOPS依次降低，其中1.2为IOPS优化，

3.4为吞吐量优化。费用计算也很简单，用量x类型单价

 

 

 

 

 

最后看一下EFS，虽然EFS也分为好几种，但是我们基本上用的都是第一种，标准类的。其他几种大家关注一下就行。

特别是第5项，不频繁访问请求，这个有点类似S3的检索费。

 

 

 

下面用最常用的S3做了一个列表，大家可以对比一下各种费用。可以看到这里的存储费依次降低，

但是检索费和其他的费用则呈现增长趋势。所以我们在做选择的时候，不光要考虑费用，还需要考虑具体用途。

 

 

 

 

 

存储成本优化建议：

 

1. 选择合适的存储容量和类型

2. 尽量减少跨AZ数据复制

3. 配置合理的生命周期

4. 定期清理磁盘，删除不用的内容

5. 使用数据压缩

6. 监控存储数据用量

7. 释放不用的资源

 

 

 

4 网络成本优化

 

 

跨AZ，跨VPC访问：跨越类型+数据量

ELB：数据传输量+数据位置

NAT网关：数据处理+时间

 

 

这里通过一个例子来说明。从上图可以看出，网络费用分布在传输的各个环节。虽然都是小钱，加起来数字就会很可观了。

所以说，企业在上云之后，除了存储费和计算费以外，网络费用占相当大的一个比例，对于某些企业来说，网络的成本甚至高于计算的成本。

 

网络成本优化建议：

 

1. 尽量选用私有IP

2. 尽量减少跨AZ数据复制

3. 尽量使用VPC-peering和TransitGateway

4. 尽量使用Endpoint Gateway，将流量尽量留在内网。

5. 仅在必须的时候使用NAT Gateway

6. 仅在必须的时候使用S3 Cross-region replication，上面有说过，S3的数据传输是要收费的，主要就是这里，
除了数据传输费用以外，还有网络传输的费用。

7. 使用数据压缩，在可能的情况下，尽量压缩数据，以减少传输的时间和费用。

8. 监控网络流量的使用，实时监控网络的流量和费用，防止突发的人为或者意外的大规模数据传输而导致成本飙升。

9. 释放不用的资源，比如弹性IP，减少浪费。

 

 

 

5 应用和管理成本优化

 

 

系统类型的选择：Linux vs Windows

应用架构的选择：分层架构 vs 微服务

服务模式的选择：Server vs Serverless

 

 

 

 

上图的表格，列举出了AWS对应的服务模式，On-premises就是传统的机房，服务器模式，

这种模式的成本最低，但是灵活性最差，部署起来通常需要数周时间。相对而言，EC2是分钟级别，ECS是秒级，

最夸张的Lambda则是毫秒级，非常适合对计算有严格要求的方案。但是事情总有两面，得到了最高的灵活度，

同时也要付出最高的代价。毫秒级的灵活度需要的成本最高。所以，我们在设计方案的时候，

需要将客户具体需求加入进来，而不是简单地建几个EC2，将本地虚拟机变成云端虚拟机就行了的。

管理成本

我们需要有一些趁手的工具来对成本进行监控和管理。AWS为我们提供了几个方案，

比如Tagging用来对资源成本进行控制，AWS organization用来对账户的成本进行控制，

AWS Budgets则用来控制成本的总量。CloudWatch是大家熟悉的监控工具，也可以用来监控使用成本。

 

 

Tagging：资源成本控制

AWS Organization：账户成本控制

AWS Budgets：控制成本总量

CloudWatch：监控成本

 

 

Tagging就是用来对资源分配进行标记，比如这台EC2是IT部门的，那台是会计部门的，

这样可以对不同的资源进行成本监控，知道哪个部门甚至哪个人用了多少。

如果公司有很多不同的账户，比如北京分公司，上海分公司，每个公司都有自己的AWS账户，

那么AWS Organization就可以不同的管理策略来监控不同账户的使用，从而实现对成本的管控。

而AWS Budgets，则是用来对服务进行一个预算设定和监控，看看资源的使用是否超过了成本，比如这张图，

我们可以看到AWS Budgets列出了一系列详细的成本统计和使用趋势，从而可以对总体的成本进行监控和微调。

 

 

6 综述

 

 

 

综上，关于AWS的成本优化，我们需要注意以下几点：

• 选择合适的架构设计
• 减少不必要的服务
• 减少不必要的服务
• 制定合适的资源生命周期
• 定期回顾现有设计并提出改革方案
• 参考官方成本优化文档和成本优化工具
• 关注AWS最新的更新

 

这里推荐一些成本计算工具，和成本优化的参考资料，大家可以参考。

 

AWS总体拥有成本（TCO）计算器：http://aws.amazon.com/tco-calculator

AWS月度计算器：https://calculator.s3.amazonaws.com/index.html

 

 

 

没有完美的设计，云上的架构和成本优化都是需要不断更新、调整的；成本优化不是消灭成本。

 

 

 

 

 

 

 

 

原文出处：[https://zhuanlan.zhihu.com/p/113940698](https://zhuanlan.zhihu.com/p/113940698)

作者：ozjacky