EC2インスタンスタイプの命名規則と購入オプション—t3のunlimitedは既定で動く

t3.small と t3.medium は、CPUクレジットの獲得レートもベースラインも同じ値です。24クレジット/時、vCPUあたり20%。違うのはメモリ容量だけで、タイプ名からCPU性能の差は読み取れません。

c7gn.xlarge を4つに分解する

インスタンスタイプ名は記号の羅列ではなく、位置ごとに意味が決まっています。AWS公式の “Amazon EC2 instance type naming conventions” が定義しているのはこの4つ。

The first position of the instance family indicates the series, for example c. The second position indicates the generation, for example 7. The third position indicates the options, for example gn. After the period (.) is the instance size, such as small or 4xlarge, or metal for bare metal instances.

シリーズ文字が用途を決める

先頭の文字がワークロードの方向を決めます。ここを外すと、サイズを上げても単価あたりの性能は戻りません。CPUを食う処理にメモリ最適化のRを充てても、余ったメモリの分だけ払うことになるからです。

シリーズ	意味	典型的な用途
M	汎用	Webアプリ、小規模DB
C	コンピューティング最適化	バッチ、エンコード、ゲームサーバー
R / X / Z	メモリ最適化・メモリ集約・高クロック	インメモリキャッシュ、大規模DB
T	バースト可能	平常時の負荷が低い開発環境、踏み台
I / Im / Is / D	ストレージ最適化・高密度ストレージ	NoSQL、データウェアハウス
G / P / Inf / Trn	GPU・推論・学習アクセラレータ	機械学習、映像処理
Hpc / Mac / VT / U	HPC・macOS・映像トランスコード・大容量メモリ	シミュレーション、iOSビルド

オプション文字はプロセッサと機能の組み合わせ

3番目の位置は複数の文字が連なります。プロセッサ系が a(AMD)、g(Graviton)、i(Intel)。機能系が d(インスタンスストア)、n(ネットワークとEBSの最適化)、b(ブロックストレージ最適化)、z(高クロック)。e は付く相手で意味が変わり、ストレージ最適化なら追加ストレージ、メモリ最適化なら追加メモリを指します。

同じ世代・同じシリーズでも、オプション違いで別ファミリーが並びます。AWS CLIに同梱されたAPIモデルから c7 系だけ抜くとこうなります。

$ MODEL=/opt/homebrew/Cellar/awscli/2.35.11/libexec/lib/python3.14/site-packages/awscli/botocore/data/ec2/2016-11-15/service-2.json
$ python3 -c "
import json
e = json.load(open('$MODEL'))['shapes']['InstanceType']['enum']
print(sorted({t.split('.')[0] for t in e if t.startswith('c7')}))
"
['c7a', 'c7g', 'c7gd', 'c7gn', 'c7i', 'c7i-flex']

末尾の c7i-flex だけ形が違います。Flexインスタンスはピリオドより前にハイフンが入る形。ファミリー名を [a-z]+[0-9]+[a-z]* のような正規表現で切り出すと c7i-flex がマッチせず、ファミリー単位のコスト集計から丸ごと落ちます。

CLIのモデルには1212タイプ入っている

選択肢の総数は、認証情報なしでもローカルで数えられます。aws ec2 describe-instance-types はAPI呼び出しですが、タイプ名の列挙自体はCLIが持つサービスモデルに書かれているためです。

$ python3 -c "
import json, collections
e = json.load(open('$MODEL'))['shapes']['InstanceType']['enum']
f = collections.Counter(t.split('.')[0] for t in e)
print(f'instance types: {len(e)}')
print(f'families: {len(f)}')
"
instance types: 1212
families: 188

aws-cli/2.35.11 の時点で1212タイプ、188ファミリー。ただしこれはAPIモデルが知っている全量で、実際に起動できる顔ぶれはリージョンごとに違います。東京リージョンで使えるものだけ見るなら、認証情報を通したうえで aws ec2 describe-instance-type-offerings --location-type region --region ap-northeast-1 を叩きます。

T系のベースラインとCPUクレジットの収支

Tシリーズだけは、他のシリーズと課金の考え方が違います。公式の “Key concepts for burstable performance instances” はこう書いています。

Burstable performance instances are the only instance types that use credits for CPU usage.

ベースラインより低い使用率で動いている間はクレジットが貯まり、超えた間は貯めたぶんを取り崩す。残高が0になった時点で、性能が頭打ちになるか追加課金に回るかが分かれます。

ベースライン利用率は割り算で出る

ベースラインは暗記するものではなく、公式が計算式を示しています。

(number of credits earned/number of vCPUs)/60 minutes = % baseline utilization

t3.large は2 vCPUで36クレジット/時なので、(36 ÷ 2) ÷ 60 = 30%。CloudWatchの CPUUtilization はvCPUあたりの値で出るため、この30%をそのままメトリクスのしきい値に使えます。

インスタンス	vCPU	獲得クレジット/時	蓄積上限	ベースライン
t3.nano	2	6	144	5%
t3.micro	2	12	288	10%
t3.small	2	24	576	20%
t3.medium	2	24	576	20%
t3.large	2	36	864	30%
t3.xlarge	4	96	2304	40%
t3.2xlarge	8	192	4608	40%

冒頭に挙げた t3.small と t3.medium の同値がここに出ています。vCPU数もクレジットもベースラインも一致し、差はメモリの2GiBと4GiBだけ。CPU不足を理由に small から medium へ上げても、CPU側の上限は変わりません。上げるなら large 以上か、Tシリーズ以外へ移ります。

t3はunlimitedが既定で動く

クレジットが尽きた後の挙動は、standardとunlimitedのどちらで起動したかで変わります。standardならベースラインまで性能が落ち、unlimitedなら不足分を借りて処理を続けます。

問題は既定値です。T3・T3a・T4gはunlimitedが既定で、T2だけがstandard既定。つまり何も指定せずにt3を起動すると、クレジットが尽きた後もバーストが続きます。24時間の平均使用率がベースライン以下に収まっていれば追加請求は発生しません。超えた分は、AWSがvCPU時間あたりの定額で課金します。日次バッチで長時間CPUを張り付かせる用途をt3に置くと、インスタンス料金とは別の行が請求書に増える理由がこれです。

設定値の名前はAPIモデルにそのまま書かれています。

$ python3 -c "
import json
s = json.load(open('$MODEL'))['shapes']
print(s['CreditSpecification']['members']['CpuCredits']['documentation'])
"
<p>The credit option for CPU usage of a T instance.</p> <p>Valid values: <code>standard</code> | <code>unlimited</code> </p>

稼働中のインスタンスがどちらかは aws ec2 describe-instance-credit-specifications --instance-ids i-xxxxxxxx で読めます。切り替えは aws ec2 modify-instance-credit-specification で、停止せずに反映されます。もう一つ、Dedicated Host上のT3はunlimitedに対応しません。この構成だけstandard既定で起動します。

停止してもクレジットは7日残る

蓄積したクレジットの寿命は世代で違います。T3・T3a・T4gは停止後7日間保持され、7日を過ぎると消えます。T2は停止した瞬間に全部失う仕様。夜間停止する開発環境をt2からt3へ寄せる動機は、単価より先にここにあります。

蓄積には上限もあり、24時間ぶんを超えて貯まりません。t3.micro なら288クレジットで頭打ちで、それを超えて稼いだ分はEC2が捨てます。3日間アイドルさせても、蓄積量は1日分で止まります。

購入オプションは7つある

公式の “Amazon EC2 billing and purchasing options” が並べているのはこの顔ぶれ。割引率はいずれもオンデマンド比です。

オプション	コミット対象	割引の上限	キャパシティ確保
オンデマンド	なし（秒単位の従量）	なし	なし
Savings Plans	1年/3年、USD/時間の使用量	Compute 66% / EC2 Instance 72%	なし
リザーブドインスタンス	1年/3年、インスタンス構成	72%	ゾーンRIのみ
スポット	なし（EC2が需給で価格決定）	変動	なし
Dedicated Hosts	物理ホスト	ライセンス持ち込み分	ホスト単位で確保
Dedicated Instances	なし（時間単位）	なし	なし
キャパシティ予約	なし（AZ単位で予約）	なし	あり

スポットは中断の2分前に通知が来ます。その前段として、中断リスクが高まった時点で流れるのがリバランス推奨シグナル。中断時の挙動は terminate・stop・hibernate から選べます。

Savings PlansとRIは何を約束するかが違う

コミット対象が金額か構成か

検索候補に必ず並ぶ「リザーブドインスタンス savings plans 違い」の答えは、公式のRI概要ページに1文で書かれています。

With Reserved Instances, you make a commitment to a specific instance configuration, whereas with Savings Plans, you have the flexibility to use the instance configurations that best meet your needs.

RIは「m5.large をこのリージョンで1年」と構成を約束します。Savings Plansは「1時間あたり10ドル分を1年」と金額だけを約束し、中身は自由。Compute Savings Plansなら最大66%引きで、ファミリー・サイズ・リージョン・OS・テナンシーを問わず適用され、FargateとLambdaの使用量にも当たります。EC2 Instance Savings Plansは対象をリージョン内の1ファミリーに絞る代わりに最大72%。66%と72%の6ポイント差が、ファミリーとリージョンを固定する対価です。

AWS自身はRIよりSavings Plansを推奨する立場を取っていて、RIのドキュメント冒頭に “We recommend Savings Plans over Reserved Instances” と明記しています。

正規化係数でサイズをまたいで効く

RIを構成固定と書きましたが、地域RIにはサイズの融通が効きます。仕組みは正規化係数で、nanoが0.25、smallが1、largeが4、xlargeが8と倍々に増える単位です。

m3.2xlarge の地域RIは16単位ぶん。同じリージョンで m3.large（4単位）が2台と m3.xlarge（8単位）が2台動いていると、割引は小さいサイズから順に適用されます。large 2台に8単位を使い、残る8単位で xlarge 1台をカバー。もう1台の xlarge はオンデマンド料金のままです。

この融通には条件が付きます。地域RI限定で、Amazon Linux/UNIXかつデフォルトテナンシーのみ。WindowsやRHEL、SUSEは対象外で、G4dn・G5・P5・Inf1といったアクセラレータ系ファミリーも除外されます。

キャパシティを押さえるのはゾーンRIだけ

RIを買えば容量も確保される、という理解は誤りです。地域RIについて公式の比較表が書いているのは “A regional Reserved Instance does not reserve capacity.” の一文。容量まで押さえるのはAZを指定したゾーンRIか、キャパシティ予約です。

組み合わせの制約もあります。スポットはSavings Plansの対象外で、スポット利用額はCompute Savings Plansのコミットにも充当されません。Dedicated Instancesを1台でも動かしているリージョンには1時間あたり2ドルの専有料金がかかり、これもSavings Plansでは割り引かれません。

起動中インスタンスの購入オプションはAPIから読めない

「このインスタンスはRIが効いているのか」をEC2のAPIで確かめようとすると、答えは出ません。DescribeInstances が返す InstanceLifecycle の取りうる値を見ると理由が分かります。

$ python3 -c "
import json
s = json.load(open('$MODEL'))['shapes']
print(s['InstanceLifecycleType']['enum'])
print(s['Instance']['members']['InstanceLifecycle']['documentation'])
"
['spot', 'scheduled', 'capacity-block', 'interruptible-capacity-reservation']
<p>Indicates whether this is a Spot Instance or a Scheduled Instance.</p>

列挙にオンデマンドもRIもSavings Plansも入っていません。オンデマンドで起動した場合、このフィールドはレスポンスに現れないのが実装です。判別できるのはスポットやキャパシティブロックのような、起動方式そのものが違うものだけ。

RIが属性として出てこないのは仕様どおりで、公式はこう定義しています。

Reserved Instances are not physical instances, but rather a billing discount applied to the use of On-Demand Instances in your account.

RIもSavings Plansも請求側の割引であって、インスタンスの属性ではありません。適用状況を確認する先はEC2ではなくCost ExplorerとCost and Usage Report。aws ec2 describe-instances をいくら叩いても出てこないので、コスト集計スクリプトを書くときはデータソースを最初から分けておきます。

インスタンスタイプ変更が失敗する条件

選び直しは停止して modify-instance-attribute を叩くだけ、とは限りません。公式の “Compatibility for changing the instance type” は、互換性がなければ新規インスタンスを起動して移行するよう指示しています。

実際につまずくのは次の項目です。

• アーキテクチャ: Graviton（Arm）のAMIからIntel/AMD系タイプへは変更できない。c7g から c7i への横移動もこれに当たる
• ボリューム数の上限: 公式の例では、32本のボリュームを付けた m7i.4xlarge から上限27本の m6i.4xlarge への変更はリクエストごと失敗する
• NVMeとENAのドライバ: Nitro世代へ移るとEBSがNVMeブロックデバイスとして見え、デバイス名が /dev/nvme[0-26]n1 に変わる

3つ目は起動後に効いてきます。/etc/fstab をデバイス名で書いていると、タイプ変更後の再起動でマウントに失敗する。UUIDかLabelで書き直しておくのが前提条件です。

互換性がなく新しいインスタンスへ移行する場合は、セキュリティグループやサブネットの割り当てもやり直しになります。この2つの効き方の違いはセキュリティグループとネットワークACLの違い—戻り通信のハマりどころに整理しました。

まとめ

• タイプ名はシリーズ・世代・オプション・サイズの4分割で読む。c7i-flex のようにハイフンを含む例外がある
• T系のベースラインは (獲得クレジット ÷ vCPU数) ÷ 60 で出る。t3.small と t3.medium はCPU側が同性能
• t3はunlimitedが既定。24時間平均がベースラインを超えると、vCPU時間あたりの定額が別途かかる

• Savings Plansは金額を、RIは構成をコミットする。地域RIは容量を予約しない
• RIとSavings Plansの適用状況はEC2のAPIに出ない。確認先はCost ExplorerとCost and Usage Report