以前一直有個特殊的實例類型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。