以前一直有个特殊的实例类型t1.micro，说是计算单元为1ECU，但是能burst到2ECU，说是适合平时使用率较低、偶尔使用率高的场景。昨天AWS发布了3款t2类型的新实例，将这种能burst的特性发挥到变态的极致。
| Type | vCPUs | Baseline Performance | RAM(GiB) | CPU Credits / Hour | monthly cost | 对应旧款类型 | 对应旧款月费用 |
| t2.micro | 1 | 10% | 1 | 6 | $9.50 | t1.micro | $ 14.64 |
| t2.small | 1 | 20% | 2 | 12 | $19.00 | m1.small | $ 32.21 |
| t2.medium | 2 | 40% | 4 | 24 | $38.00 | m1.medium | $ 63.69 |
Baseline Performance，是指平时低使用率时虚拟CPU核心所拥有整个实体CPU核心计算能力的百分比，例如t2.medium，40%是说在不burst的时候，一个vCPU最高拥有底层一个实体CPU核心计算能力的40%。当这些计算资源不够用的时候，CPU能burst到更强的计算能力，不再继续需要更强的计算能力时，它会自动降会到原来的Baseline performance，而且这种降级是逐渐的降，以最大程度减小对业务的影响（15分钟小降一次，直到降会Baseline）。
RAM，这一代的实例，内存终于是整数了，不再是坑爹的3.75G或者620MB了，而且t1.micro内存慷慨的给到了1GiB，注意GiB是1024进制的，而GB是坑爹的1000进制。
Network Performance，创建实例的时候，就会发现，这三个新类型的网络性能都是low to moderate，burst的时候跟m3.medium一个级别，t2.micro也不再是t1.micro那种坑爹的very low了。
CPU Credits / Hour，是指每小时低使用率时所积攒的CPU绩点，1个绩点允许你拥有整个底层实体CPU计算能力的1分钟时间，这样的话，t2.micro平时CPU使用率没超过100%时（没超过按照底层实体CPU一个核心计算能力10%预留给你的计算能力时），它每小时就能积攒6个绩点，这样10个小时后，这个实例就能有机会独占1个实体CPU核心跑一个小时了。注意Credit不使用的话，最多只能保留24小时，这样不同级别实例能保留的Credits数也有上限（CPU Credits per Hour * 24 hours）。还有个特点需要注意，该实例关机后再开机，之前积累的Credit也没了，terminate之后同样也肯定没了。但是重启还在。
实例在创建之初，AWS就给了一些CPU Credits，使你在开机的时候做初始化的时候，CPU能力是最强的。这点从CloudWatch上能看到，我稍后展示。
价格，对比对应的旧款，便宜了40%左右，注意新款t2实例不能使用instance storage，只能使用EBS，包括新款的SSD的EBS。
其他变化，在实例的monitoring里多了两个metrics, CPU Credit Usage实例已经使用了的CPU绩点、和CPU Credit Balance实例积累的CPU绩点。我们在CloudWatch中把这两个Metrics放在一个图中看。
蓝线是实例积累的CPU credits，橙线是使用了的CPU Credits
注意看最开始的时间，也就是实例创建的时间，蓝线不是从0开始的，它初始就有30个CPU Credits的样子，不过我没怎么用。之后后来编译几个软件的时候才开始消耗CPU Credits，编译完之后，CPU Credits又开始积累了。
使用场景：
这类实例的特点就是可以将平时空闲的CPU资源积累到需要的时候使用，比较适合平时使用率较低，有时候又需要较多的计算资源的场景。如果你发现自己的实例几乎剩不下什么CPU Credits，那说明该升级实例配置了。反之，如果CPU Credits一直处于没机会使用的状态，那该考虑降级实例了。比较适合开发、测试、以及业务量平时很小但偶尔有突发的场景
注意事项：
这类实例都是只支持HVM虚拟化方式的，之前PV虚拟化的AMI都用不了了，例如本网站，从t1.micro迁移到t2.micro，就得完全重搭。建议将业务AMI都更换成HVM的，毕竟HVM支持所有新出的实例类型，而PV只支持部分旧款的类型。
这类实例不支持Instance Storage。