AWS 目前是世界上市场份额最大的云服务商，在国内的市场比例因为各种原因远远比不上阿里云，但是在国际市场上，尤其是IaaS 这一块，AWS，Microsoft和 Google 几乎是三分天下。
云是否便宜？
这是一个相对有争议性的话题，我抛砖引玉说说自己的看法。一般说起云服务，很多用户的第一反应就是便宜。从成本考虑的话，因人而异，我不认为云服务就一定会比线下的服务器更便宜。豆子的部门需要对集团旗下140多个大大小小的子公司进行IT的运维，经常有用户会问我们，如果我的服务器迁移到AWS上，大概一个月多少钱？上云之前，一般都会进行简单的成本计算进行对比，包括硬件成本，软件成本，人工成本以及各种维护的成本，包括机房的备份，UPS，空调等等。从效率上来说，IaaS的优越性在于可以让管理员完全忽略掉底层的存储，网络，主机，以及机房的相关配套设备，仅仅关注自己需要的服务上面，从人工的工时上节约了大量的时间和金钱；个人认为，对于一些大的公司而言，基础的机房建设投资不菲，上云肯定能节省大量的金钱和精力；但是对于某些小的客户而言，高可用的存储主机网络本来就不是他们关注的重点，一个普通的服务器足够满足所有的需求了，因为他们的IT的预算本来就很低，那么上云并不会节约太多开支。
AWS云服务和相关费用考虑
对于AWS来说，上云之前需要考虑哪些服务和费用呢？如果忽略掉潜在的重要开支，往往会发现预算和和实际开支相差甚远的情况。
AWS提供了一个网站来估算开支，但是提供的选项特别复杂
https://calculator.s3.amazonaws.com/index.html
AWS有一套超级复杂的计费系统，他的上百个服务有不同的计费方式，但是他最核心服务就是EC2，S3， VPC。不论规模大小，基本上所有的AWS用户都或多或少的会使用这些服务，而绝大部分开支也出自这些服务上。所以不考虑特殊情况，我一般泛泛地估算开支就是看这几个核心服务的使用情况。
EC2: （吃钱大户）
EC2是AWS最早推出的虚拟机服务，用户可以根据自己的需求选择合适的EC2 类型。EC2本身针对CPU，内存，带宽等需求对CPU和内存进行特殊优化，分为了A1, E2, E3 等8大类型，每个类型又根据性能划分了不同的级别。不同级别收费区别极大，一般说来，刚开始都是根据当前的需求选择一个类似的服务器，试运行一下，然后再逐渐提高性能级别。
除了类型的选择，我们知道EC2 Instance的收费是根据时间来的，用户需要考虑是否24X7的全天候运行。如果可以晚上关机的话，可以节约近乎一半的开支。Auto scaling这里暂不计入考虑。
EC2的硬盘存储都是EBS类型。EBS也是根据IOP的速度分了三大类 （Magnetic，Provisioned IOPS (SSD) and General Purpose (SSD)）。基本标准是容量空间越大，速度越快。对于大部分应用来说，通用类型足矣。通用性的计算标准是3IOPS / G。用户可以计算一下需要的存储空间有多大。基本上这部分的开支是固定的和可以预见的。
EBS的备份一般是通过Snapshot来实现的，这一块的开支比较难以精确估算，他的收费主要还是根据流量和存储空间来计算的。Snapshot在做了第一个之后，之后都是incremental backup，用户可以估算每天改变的文件大小以及总共保留的快照个数来估算开支。
S3：
S3是另外一个吃钱的大户。S3一般是用来保存备份的文件，用户可以通过脚本或者第三方的软件备份文件到S3 bucket里面，但是S3本身也根据可用性和可靠性划分了多个级别，比如S3 standard，S3 IA, Glacier 等等。用户需要规划如何有效地利用不同的级别，比如不用的归档文件可以备份到 Glacier，需要经常访问到S3 standard，他们的价格也是相差数倍以上。
VPC：
VPC的收费主要取决于流量和***服务，这部分的开支基本都是固定的。以***为例，一个连接每个月的开支大概是30刀左右。
理想 VS 现实
给用户估算了价格，用户觉得省事省钱了，很开心，然后月底的时候看账单，往往会有意外的惊喜（惊吓？！）很多时候人算不如天算，总有意外破财的时候。AWS的计费系统超级复杂，因此定期管理账单是非常重要的。需要强调的一点是， AWS的 Billing系统不是实时的，有1-2天的滞后性，当天的消费情况并不会立刻出现在账单上。
Billing系统里面，大部分时候我们都是在 Cost Explorer里面查看账单，通过不同的group我们可以看见不同的视图。比如说我的一个测试账号里面，我意外发现我上个月比起之前多花了几块钱，这是花在哪里了？
Group by 从 Service切换到 Usage Type, 我发现原来是Elastic IP的开支。 EIP默认是免费服务，但是如果我关掉EC2 实例之后，忘记dissociate 掉关联的EIP, 他就会开始收费。惊不惊喜，意不意外？
这种小惊喜的陷阱还很多，为了避免月底给老板带来心脏病的刺激,我们需要更好地管理和监控自己的服务以及开支。
对于AWS的管理员而言，首先需要做的是设置一个 Bill Alarm。当开支超过我们的心理底线的时候，需要他给我们及时发通知，可以及时止损。设置的方法很容易，可以参考这个链接
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html
除了警报以外，Billing管理器另外一个非常有用的功能是根据TAG 分类 。
Billing默认的显示是根据服务类型来列出的，如果所有的服务都是一个部门使用，那当然okay，但是如果涉及到多个部门的话，我们可以对不同的服务进行tag标记是哪个部门使用的，然后通过标记进行分类。
默认通过服务类型来显示
根据tag分类之后的账单，我可以清楚地看见不同的诊所的开支，月底就可以挨个收费了
第三点 我们知道AWS的服务都是通过计时算钱的。对于开支大头EC2 Instance而言，如果我们可以在晚上自动关机，早上自动开机，我们关机时段是不需要付费的，这样可以有效地减少不必要的开支。AWS官方提供了一个自动化的解决方案叫做 instance scheduler，链接如下
https://aws.amazon.com/solutions/instance-scheduler/
通过CloudFormation配置之后就可以通过tag设定自动开机，关机时间了。
第四点 定期检查备份开支。备份的开支在初期很容易被忽略，但是如果不留意的话，他的增长会呈线性增长。这个原因是由于EC2的snapshot, AMI 和 旧的Volume很容易累积，如果没有好的规范及时删除，可能几个月的时间就会意外地累积出一大堆额外的开支。
对于snapshot的快照，AWS同样提供了官方的自动化方案，他可以通过tag来自动备份和删除旧的备份，这个stack方案叫做 ops Automator，具体可以参考这个博文进行配置
https://blog.51cto.com/beanxyz/2454327。
出于同样的原因S3里面的数据可能也会越积越多 因此我们需要配置S3 的lifecycle，对于旧的数据需要及时清除。如果经常需要创建新的bucket, 我们可以通过CloudWatch和Lambda来自动添加对应的Lifecycle。
另外一个省钱的有效方式是 Reserved Instance 或者 spot instance。Reserved instance可以通过预付的方式，相比起on demand的方式而已，节省几乎一倍的费用。这种方式很适合那种24X7 连续运转的服务器。不过需要注意的是，如果需要改变服务器的类型（升级或者降级），那么之前预付的钱就白费了。好在AWS也知道这种需求改变难免发生，因此用户可以在Reserved Instance Marketplaces 上出售没有用完的时间。
例如，Billing 系统里面可以查看reserved instance替你省了多少钱，这个例子里面我并未使用预付的方式，因此打折力度大概28%左右
Spot instance 则是你投标去购买其他人暂时不用的资源，当然这个价格比起on demand来说会优惠很多。不过缺点是一旦资源耗尽，随时可能中断服务，因此不适合需要长期稳定的需求，往往作为一个辅助，临时分担运算压力等等。
收费的方式
AWS 默认就两种方式，信用卡或者银行转账。如果公司的财务流程需要出示账单再付款的话，AWS也可以发送对应的账单，然后再由公司的财务付款也是可以的。
如果发生某些意外，比如信用卡过期了，AWS会自动给root账号发送警告信告知欠款，如果超过3个月都没人理会那个邮件的话，他会发个最终通牒，然后切断登录，随机关闭一些EC2的服务。不过他仍然保留你登录 support账号的权限，这样你才能给他们联系，赶快交钱赎人。当然如果态度比较好的话，乖乖认错，服务还是很快就能恢复的~
总结
AWS的云服务提供了大量的服务，每个服务都有其自身的计费方法。这里我主要针对他的几个核心服务简单的讨论了一下他们的开支，以及如何最大力度去节约这些开支。限于经验和水平，难免有疏忽和不足，欢迎指出和讨论。