几个说明：
1. 这里只讨论最普通的费用，即北弗吉尼亚，linux机型。AW大多产品根据所在区域，运行系统不一样，如linux、windows等，每种的价格都会有差异；基本上了解清楚一种，其他都可以类推。
2. AWS的计费价格、计费内容会一直随着时间改变，比如推出新的产品、优惠、降价。基本上价格都在逐年递减。这里引用的价格均以成文日期的价格为准。
3. 所涉金额单位均为 $。
4. 本文仅仅是个人使用过程中的一个简单总结，因AWS本身十分庞大复杂，肯定会大量的遗留、错误和自言自语。看看就算了，千万别当真。落实到具体的问题还是根据最新数据逐个去推算比较准确。
为叙述清楚起见，按照AWS收费对象的不同，我们可以划分为如下三种收费类型：（AWS中各种服务最终的计费大多都是几种计费类型经过叠加形成的）
一、资源占用费
该收费的主要依据就是在一段时间内占用了一定的AWS系统资源。根据占用资源类型的不同，又可分为计算资源占用、存储资源占用两类。
1. 计算资源占用
这个类别里面最典型也是最复杂的就是EC2，其他像RDS、EMR、ElastiCache等基本就是在这个基础上派生出来的变种。如在价格上做一定差异或附加一个额外的收费等。另外CloudWatch（实例）、Route53（托管区域）、ELB等也会有些资源占用型收费内容，不过都比较简单直观，不用过多解释。
EC2在收费方式上，按客户使用方式上的需要，又提供了三种选择：
1) 按需实例：这个是最简单的方式，就是用多少时间算多少钱。定价按每个实例从启动到终止或停止使用的时间计算。运行未满一小时的实例，将按一小时计费。
这里要注意的是，从EBS启动的实例提供了停止的功能，停止了之后，计算资源是不收费了，但EBS这个存储资源还是需要继续收费的。非EBS启动实例没有停止功能，只能终止。
目前一个大型实例的价格为每小时 $0.240，每年的费用为$2102。这里的大型实例是指 m1.large实例，包含7.5 GiB 内存，4 个 EC2 计算单位（2 个虚拟内核，各含 2 个 EC2 计算单位），850 GB 本地实例存储，64 位平台，下同。
2) 预留实例：其实个人觉得这个叫折扣实例更合适，就是先出一部分钱，然后在一个时间段里给你一个折扣价，不过这个折扣价也是论个卖的。几个实例需要打折，就需要买几个预留实例。
预留实例可以按1年期买，也可以按3年期买。当然3年期平均算起来更划算。不过也要考虑到AWS经常会小降点价格，更主要的是要考虑自己的业务做不做得到3年 :)
在预留实例里面还可以根据使用率不同，分为低使用率预留实例、中使用率预留实例、高使用率预留实例，方便用户以有效的小时价格平衡预付款金额。这里的使用率可以看做你的服务器的开机时间。下面的表格就是一个大型实例在各种使用率下的价格计算。
根据上表内容，我们可以推算的出来如下使用规则：
* 全年开机时间97天（约2336小时）之内，按需付费比较划算（当然，这种零时性使用最划算的还是竞价实例）
* 全年开机时间大于97天，小于250天（约5980小时）之内，使用低使用率比较划算
* 大于250天，高使用率比较划算。
这里有个疑问，不知道中使用率的使用场景是什么，怎么算都不是价格最低的。可能在其他类型实例里面会便宜吧。
使用预留实例过程中经常会引起误解，需要牢记的主要有：
* 预留实例不是年付方式。而是预付一定费用，然后得到一个折扣的模式。这种付费模式可能国内不常见。比如一个大型实例，预付$243，那么在接下来的一年时间里就可以享受这种类型的一个实例每小时 $0.136的折扣，相对于按需付费便宜了些。
* 预付费是一次性支付的，不会因为实例关机而停止计费，但每小时 $0.136这个费用是关机就停止计算的。也就是说，如果你花了$243购买了一个预付实例，但接下来的一年，你一个该类实例都没开，那这个$243也就打水漂了。
* 购买了预留实例之后不是跟一个具体的实例绑定，而是根据当前有的所有实例进行动态映射的。比如你在某个AZ里购买了一个预留实例之后，随时可以在该AZ关、停、重建该实例。但如果在该实例运行过程中，又创建了一个同类实例，那新实例就会采用按需价，因为该预留实例已经被第一个实例使用了。
* 预留实例的类型必须是匹配的，购买了某个AZ的大型实例，就只适用该AZ中的大型实例，不同AZ之间是不能混用的。在2013-9-11号之前，已预留实例还不支持在一个区域不同AZ之间切换，不过现在支持了，至少提供了一定的自由度，不会因系统架构的调整造成预留实例的浪费。不过不同区域之间目前还是无法切换的。因此购买预留实例之前，需要有最基本的规划。
* 预留实例不仅仅可以用于自己创建的实例，也可用于EMR、AutoScale等系统自动创建的实例。这些实例的运行很可能不是连续的，所以就需要估算实例在线时间区间购买相应的预留实例。
* 预留实例在购买之后，价格就定了，前期费用、每小时费用都不会受AWS降价影响。
* 预留实例在某些AZ有可能买不到，这个在做系统架构前要心里有数，甚至不同账号情况都不一样。我出现过一个账号在某个AZ无法购买，但另一个账号却可以购买的情况。AWS解释是说AZ是一种逻辑上的zone，然后映射到不同的实体zone，所以账号之间可能不同。
* 有些3rd Party的价格可能比AWS提供的更优惠，不过买前最好算清楚。比如刚才看到一个27月的预留实例前期费用才630，不过每小时费用是0.052（小心算这个价差哦）。另外3rd Party购买的预留实例的费用在账单上是单独一栏的，这个看账单的时候要注意一下。
3) 竞价实例：
按Amazon的说法是投标未使用的 Amazon EC2 容量，所以竞价的价格可能会很低，比如目前大型实例的最低竞价价格为 $0.026 每小时，折算下来一个月才$18，远低于按需实例、预留实例的价格。不过这是一种竞价的方式，因此，这个价格可能会波动的很厉害。比如下图，这是当前的一个竞价历史价格图。
从图上可以看的出来，在某些时段，竞价价格可能会飙升的很厉害，比如9月17日，1c的价格就超过了$3，远远大于按需实例。不过总得来说，大多数时候，竞价价格还是很低的，而且就算某几个AZ价格高，也可以在其他AZ，其他区域找到便宜的实例。
在竞价的时候，可以设定一个自己可接受的最高价，启用、终止时间、实例信息等信息即可。不过在一次竞价之后是无法再次修改价格的，一旦AWS的价格高出竞价时设定的标价，实例就有可能被终止。因此，竞价实例是不稳定的。
当然，为了尽量不使实例被停止，也可以设置一个高出很多的价格，但这就要自己承担部分时间段的高价格。看看竞价实例历史价格就可以知道，那是个没有啥规律和理性的东西。
在使用竞价实例的时候，需要注意Persistent Request这个选项，不勾选时创建的竞价是一次性的，就是说，一旦系统价格高出你的出价，实例会终止，同时该竞价也会变成close状态。勾选之后，一旦系统高出你的出价，实例也会终止，但系统还会进一步检测之后的价格是否会回落，一旦回落到你的出价范围，将会重新启动一个实例为你服务。
因此，竞价实例的使用对应用的要求是比较高的，上面跑的应用需要做好随时被关机，重新加载的防范措施。
竞价实例除了单独启动加载之外，也非常适合在Auto Scaling、EMR等服务里面出现，通过两者的捆绑，可以用很廉价的方式解决访问高峰、批量计算等问题。
2. 存储资源占用
Amazon针对存储类别的不同，提供了一系列存储，合理的配置方案可以节省很多成本。在AWS账单中，经常会见到的存储有Glacier、S3、EBS、Snapshot等，其中在账单上Glacier被归到了S3里面，snapshot也算在了EBS里面，不过他们的价格都是不一样的。
1) Glacier
Glacier是目前AWS上最便宜的存储，不过从Glacier提取文件会有个等待时间，因此适合不怎么使用的存档数据。它的价格是$0.01/G/月左右，不论存储多少数据都是这个价格，还算便宜。
Glacier做的做好的地方是跟S3的配合，通过lifecycle的配置，基本可以跟S3无缝对接，使用者几乎感觉不到Glacier的存在。
2) S3
S3这个几乎是人尽皆知的东西了。1T之内的价格是$0.1/G/月左右，按49T、450T、500T、4000T、5000T这样有个阶梯价差（没参详明白为什么是这个阶梯划分法）。S3在不同的区域价格有微小差异，去冗余存储也会有价格差异。一般经常使用的数据存放S3，长时间不用的数据存放Glacier。
3) EBS
接下来的EBS就比较坑了。EBS跟S3，Glacier不同，EBS是根据申请块大小的计费，而后者是根据使用量计费的，这个在使用时要牢记。EBS的价格也是$0.1/G/月。在账单上，它的价格是按天折算的，所以虽然EBS用量一个月内没变化，账单上也在每天变。
仅从存储使用上来看，EBS的收费还算合理，但如果算上后面讲到的流量费、IO计次费就非常非常坑了。如果应用不优化的话，EBS的整体费用会出乎你的想象。
AWS还推出了预配置的 IOPS 卷，好吧，这应该是专门为高富帅准备的。曾经申请了100G做点测试，20来天就吃掉了$100。要清楚理解$0.10 每月预配置的 IOPS这个概念，这个是额外的收费。下面是AWS网站上对预配置的 IOPS收费的案例解释：
“例如，如果您预配置了含 1 000 个 IOPS 的卷，并在 30 天的月份中保留该卷 15 天，如在弗吉尼亚地区，您需要为预配置的 IOPS 支付 50 USD（每个预配置的 IOPS/月 0.10 USD * 预配置的 1 000 个 IOPS * 15 天/30）。 ”
4) Snapshot
按照AWS的解释，快照是通过增量压缩的方式存储到S3的。但收费上，不是跟S3列在一起的，不过两者的价格差不多。snapshot是一种很方便的系统备份方法，可以随时或用程序定时进行快照备份。
在使用存储资源的时候，需要注意：
* 分析数据类型，合理利用各不同存储，尽可能价格最优化
* 不要将实例配置的Ephemeral存储视而不见，优化程序尽可能多使用它
* 实在没办法，才去使用EBS
* 如果是备份类的数据，最好先压缩一下
资源占用型的服务还有ELB、EIP等会收点小钱，需要注意的是EIP在空闲时是要收费的，绑定到实例上才不收费。
二、流量费
资源占用型的收费还是比较合理的收费，毕竟用了人家的东西就要交钱，这很正常。流量上的收费就开始有点坑了。下面我们就来看看AWS在流量上收了哪些费用。
1. CDN（CloudFront）流量
CDN流量主要是指流出流量，每个区域价格也不尽想用，欧美10T内$0.12/G，其他地方接近$0.2/G。另外，从S3到CloudFront的流量也会收费，当然，也是小钱。不过CloudFront不算是一个很好的CDN选择。
2. 数据传输
数据传输主要是指流入、流出AWS，各个服务之间、区域间的数据流。
1) 流入流量，现在应该还是免费的。
2) 流出流量，10T之内$0.12/G。如果业务繁忙、跟其他服务器交互频繁，或需要经常备份出AWS，这个部分价格会迅速上涨。（这个不包括CDN）
3) EC2之间的流量，$0.01/G。别小看这一分钱，如果你的程序不好好控制的话，一个月几个T、十几个T是很简单的事。比如管理员为了数据安全，做了几份数据同步。
4) 区域之间的传输费用，$0.02/G。这里需要注意的是from不收费，to收费，但账单上都会列出，仅仅部分标0，所以这部分账单看看一大片，其实没啥内容。而且在这里，CloudFront也是当做一个区域来处理的，也就是说每个区域传到CloudFront的流量在这里收费。
另外像ELB流量、SES的附件流量也需要意思意思。反正基本上能想得到的流量AWS都帮你想到了，你还能想得到更多吗？
在流量使用上需要注意的是：
* 在备份的时候Snapshot是一个很好的选择，控制的好的话，可以很省存储空间，而且不会造成什么流量。
* 要保证数据安全的话，尽量用S3，S3还是比较稳定的。现在成熟的备份工具很多，而且也不会有啥流量产生。
* 优化程序，尽量减少不必要的数据传输
三、计次费
AWS还有很多需要计次的服务，比如SQS、SNS、SES等，这些都很正常，也很可以理解。但AWS还有个比较坑的计次，就是EBS类服务的IO计次费！
1. SQS、SNS、SES等计次费用
SQS、SNS这些经常会出现在AWS一些比较高级的服务中，比如SES中的Bounce mail就可以使用SNS进行通知，AutoScaling也利用了SNS。
SQS的收费是每 100 万个请求$0.50。要注意的是，它的请求数据量是有限制的。例如，1 次负载为 256 KB 的 API 调用将以 4 次请求计费。
SNS需要注意的是它有个API费用，同时有个通知费用，根据通知目标不同，收费也不同。比如现在每 100 万个 Amazon SNS API 请求是 $0.50（前100万免费），不过要是通知到mail的话，需要每 100 000 个 通知 收费$2.00，通知到SMS更贵。
SES更简单，每 1000 封$0.10。不过每天都有2000封的免费额度，不发垃圾信的话够用了。使用SES要注意的是，AWS刚开始分配的额度可能会比较低，它会慢慢给你加的。另外，还有个Max Send Rate的限定，超过发不出去的，写程序的时候要注意。
2. CDN计次费用
CloudFront除了流量要收费之外，还有个请求次数的收费。比如每10,000 HTTPS $0.01，每10,000 HTTP$0.0075。每个区域都会有不同（一般都比这高）。赶紧把那些小图片合到一个文件去吧。
3. EBS、RDS等 的 IO费用
这是一个很坑的地方，特别是把EBS当主硬盘使用的时候，天知道做了多少次IO啊。目前EBS上是每百万I/O请求 $0.10，看起来不多吧。等月底你看着数十亿，上百亿次请求的时候你就知道它的厉害了。当然，要是你用了RDS，你就会有更清醒的认识。而且你根本没法讲理，你算过你的MySQL这个月用了多少次IO么？
AWS除了提供上述应用之外，还有很多更高级的服务，不过从计费上看，基本都是在这些基础上的一些叠加、累计。有兴趣的可以自己去摸索、体会，会很有趣。理解清楚AWS的计费内容是我们用好AWS的一个前提条件，在业务发展的前期，EC2等资源占用费用会占主要比率，业务发展起来以后，后面两种计费将会迅速上涨。
几个合理利用AWS的小建议：
* 深入理解业务特性，合理选择专用主机、云计算，尽可能将动态的、变化的、瞬时的业务放在云上，而将稳定的、持续的业务放在专用主机上。
* 深入了解需要使用的每个服务的特性，局限和限制，将各种服务合理组合起来使用。
* 业务应用一定要要针对云计算的特性做优化，如果不优化，可能还不如专用主机来的划算。
* 多看看账单，分析理解其中每一项，确定优化目标。
总之，AWS不便宜，AWS网站上也明确说明云计算是“根据业务发展来扩展的较低可变成本来替代前期资本基础设施费用”，好好体会这句话。
Posts
