EC2 インスタンスファミリーの選択基準 — t・m・c・r 比較
EC2 のインスタンスタイプは 800 種を超えますが、選択は二つの段階に絞られます。「どのファミリーか」と「どのサイズか」です。この記事は最初の段階であるファミリーの選択基準を整理します。結論を先に書くと、基本は最新世代の m 系で、CPU かメモリのどちらかに偏った実測の根拠があるときだけ c や r に移ります。 t は安く見えますが、条件が合うときだけ安いタイプです。スペック表記の読み方の一般論は ハードウェア基礎 #9 で扱ったので、ここでは AWS 側の選択基準に集中します。料金は us-east-1 のオンデマンド基準です。
名前の読み方 — ファミリー、世代、属性 #
m8g.large は三つの部分に分かれます。先頭の文字 m がファミリー(用途)、数字の 8 が世代、後ろに付く文字が属性です。属性の文字は少し覚えるだけで大半が読めるようになります。
g: AWS Graviton(ARM)プロセッサです。m8g、c8g、r8g が現行世代です。i: Intel です。m8i、c8i(Xeon 6)が最新で、m7i が広く定着した世代です。a: AMD EPYC です。同世代の Intel より約 10% 安く設定されています。d: ローカル NVMe SSD が付いています。インスタンスを停止するとデータが消える一時ディスクです。n: ネットワーク帯域の強化版です。-flex: 同世代の標準型より約 5% 安く、常時フル性能が不要なワークロード向けです。
世代の数字は大きいほど新しく、同じファミリーなら世代を上げるだけで料金が同じか下がりつつ性能が上がる場合がほとんどです。 m5 から m7i や m8g への移行は、実質的に比較検討が要らないアップグレードです。
t ファミリー — バーストモデルが合う条件 #
t4g と t3 は CPU をベースラインの分だけ常時保証し、それ以上はクレジットで使うモデルです。ベースラインはサイズごとに異なります。t3.micro は vCPU の 10%、t3.small と t3.medium は 20%、t3.large は 30% です。アイドル時間にクレジットが貯まり、忙しいときに消費する構造なので、平均使用率がベースラインを下回るワークロードでだけ表示料金が実際の料金になります。
合う場所は明確です。開発・ステージングサーバー、トラフィックの少ない社内ツール、待ち時間の長いバッチです。t4g.micro は 1 時間あたり約 $0.008 で、同サイズの t3(約 $0.010)より安くなります。
合わない場所も明確です。CPU がベースラインを常時超えるサービスです。クレジットが尽きると性能がベースラインまで絞られ、デフォルトで有効な unlimited モードでは絞られる代わりに超過課金が付きます。超過課金が続くと、同サイズの m 系より高くなります。 「数日は問題なかったのに急に遅くなった」が EBS では gp2 のクレジット枯渇だったように(gp3 vs io2 参照)、EC2 では t のクレジット枯渇です。CPUCreditBalance の指標が底を這うグラフが見えたら、t 系から移行するタイミングです。
m・c・r — vCPU 対メモリの比率が基準です #
m、c、r は同じサイズなら vCPU 数が同じで、メモリだけが異なります。比率がそのまま用途です。
| タイプ | vCPU | メモリ | 比率 | 時間あたり料金 | プロファイル |
|---|---|---|---|---|---|
| c8g.large | 2 | 4GiB | 1:2 | 約 $0.080 | 演算中心 |
| m8g.large | 2 | 8GiB | 1:4 | 約 $0.090 | 汎用 |
| r8g.large | 2 | 16GiB | 1:8 | 約 $0.118 | メモリ中心 |
読む方向は料金表ではなく実測です。CPU 使用率は高いのにメモリが半分以上遊んでいれば c へ、メモリは埋まるのに CPU が遊んでいれば r へ移ります。c は Web・API サーバー、ビルド・CI、エンコード、ゲームサーバーが該当し、r はインメモリキャッシュ(Redis、Memcached)、大きな JVM ヒープ、分析ワークロードが該当します。どちらか確信がなければ m から始めて実測で判定します。同じメモリを基準に見ると差がより鮮明です。16GiB が必要なとき、r8g.large(2vCPU)は約 $0.118、m8g.xlarge(4vCPU)は約 $0.180 です。CPU が遊んでいるなら、r は同じメモリを 3 分の 2 の料金で提供します。
一つ注意すべき点は、サイズを決めるときに CPU とメモリだけを見てはいけないことです。インスタンスサイズにはネットワーク帯域と EBS 帯域・IOPS の上限が一緒に結び付いています。小さいインスタンスに高性能な gp3 を付けても、インスタンス側の上限で頭打ちになる問題は gp3 vs io2 で扱いました。
アーキテクチャの軸 — Graviton、Intel、AMD #
ファミリーとは別にアーキテクチャの軸があります。同じ m8 世代では Graviton(m8g)が Intel(m7i・m8i)に比べて時間あたり料金が約 10% 低く、世代ごとの性能向上まで重なると、価格性能比の差はさらに開きます。m8g.large が約 $0.090、m7i.large が約 $0.101 です。AMD(a)は Intel と同じ x86 なのでバイナリ互換のまま約 10% 安い、中間の選択肢です。
Graviton は ARM なので、移行前に確認が必要です。インタープリタ言語(Python、Node.js、Ruby)と JVM はおおむねそのまま移せますが、ネイティブバイナリとコンテナイメージは ARM ビルドがあるかを確認する必要があります。削減幅の見積もりと移行チェックリストは EC2 Graviton 移行 にまとめました。新規ワークロードなら Graviton を先に検討し、依存関係で詰まったときに x86 に戻る順序が料金面で有利です。
残りのファミリーは必要が明確なときだけ #
t・m・c・r 以外のファミリーは io2 と同じ性格です。必要条件が明確なときだけ選びます。
- x、u(ハイメモリ): 比率が 1:16 以上で、SAP HANA のような大型インメモリ DB 向けです。r では足りないという実測が先です。
- i、d(ストレージ): ローカル NVMe・HDD の密度が高い系列で、分散 DB や検索エンジンのようにローカルディスクの IOPS がボトルネックになる場合です。大半のワークロードは EBS で足ります。
- p、g、inf、trn(アクセラレーテッド): GPU・AI アクセラレータの系列です。どれが必要かは 学習サーバーと推論サーバー、GPU サーバーは何が違うのか で扱いました。
選択の手順 — 実測が先です #
- 現在の消費量を測ります: CloudWatch の
CPUUtilizationで CPU プロファイルを見て、メモリはデフォルトの指標にないので CloudWatch Agent を付けて測ります。t ならCPUCreditBalanceも一緒に見ます。 - Compute Optimizer を有効にします: 無料で、実測ベースの過大・過小プロビジョニングと推奨タイプをアカウント単位で出してくれます。遊んでいるインスタンスの整理は 常時点検リスト と重なる作業です。
- ファミリーを決めます: 平均 CPU がベースラインを下回る間欠的な負荷なら t、バランス型なら m、実測が片方に偏っていれば c か r です。
- アーキテクチャと世代を決めます: Graviton が使えるかを先に確認し、世代は特別な理由がなければ最新を選びます。
- サイズは小さく始めて上げます: サイズ変更は再起動 1 回で済むので、大きめに取って減らせないより、小さく取って上げるほうが安くつきます。長期運用が確定したら Savings Plans のコミットでオンデマンド比の料金をさらに下げます。
まとめ #
- タイプ名はファミリー(用途)、世代、属性(g=Graviton、i=Intel、a=AMD、d=ローカル NVMe)として読みます。同じファミリーなら最新世代が基本です。
- t は平均使用率がベースラインを下回るときだけ安いタイプです。クレジット枯渇と unlimited の超過課金が見えたら m に移ります。
- m・c・r は vCPU 対メモリの比率(1:4、1:2、1:8)が基準です。実測で CPU とメモリのどちらがボトルネックかを見てから移ります。
- 同じ世代では Graviton が x86 より約 10% 安くなります。新規ワークロードは Graviton を先に検討するのが料金面で有利です。
- サイズは CloudWatch と Compute Optimizer の実測で決め、小さく始めて上げます。CPU とメモリのほかに、ネットワークと EBS の上限もサイズに結び付いている点を覚えておきます。