年中アイス

いろいろつらつら

t3.smallとt3.mediumのCPU creditが同じだった

t3インスタンスのCPU creditを使い切ってしまうことがあり、そういやt2より良くなったようなと思って、再度調べてみたら驚きの仕様が! ※2020/02/20 少し文章の構成を直しました。

インスタンスタイプ、サイズごとのCPU creditの回復量と蓄積可能量

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.htmldocs.aws.amazon.com

リンクにあるように、t3.small, t3.mediumは、creditの回復量24、蓄積可能576と同じだったのです。t2はクレジットの回復量と保持量はt3の半分です。t2ではサイズごとに倍々だったんですが、t3は何故かsmallとmediumは同じで、他は倍々です。ただし、t3はt2と異なり、起動時の初期クレジットがないので、起動直後にCPUを消費する場合は注意が必要です。他に明確に違うのはメモリサイズ。t3.small 2GB, t3.medium 4GBです。他も細かくは違うのかもしれませんが、目立つのはこれだけ。

向いてそうなユースケース

起動直後にCPUを大きく使わず、一定の時間を経て、時々バーストするようなケースだとt3の方が回復力があり、よりクレジットを使えます。CPUと比較してメモリの使用量が少ない場合は、t3.smallを水平スケールさせる方がコストパフォーマンスが良いです。

一部のECS clusterは、t3.mediumにしていたんですが、これを受けて同インスタンス数のt3.smallに下げました。動かしているコンテナにGoが多く、CPUは割り当てるものの、メモリはそこまででもなく余り気味でした。CPU creditが一緒であれば、同じ金額でsmallでインスタンス増やすほうが、CPUリソースが多く使え、同じインスタンス数なら金額は半分です。

参考