EC2インスタンスタイプの選び方 — 世代・ファミリー・Gravitonの実務判断

EC2のインスタンスタイプは数百種類あり、真面目に全部比較しようとすると設計が止まります。実務で必要なのは全種類の知識ではなく、「型番を読めること」「ファミリーの使い分け」「3つの落とし穴」の3点だけです。順に整理します。

01型番の読み方 — m7g.xlarge を分解する

型番は「ファミリー・世代・属性・サイズ」の4要素です。m7g.xlargeなら、m＝汎用ファミリー、7＝第7世代、g＝Graviton（Arm系CPU）、xlarge＝サイズ。属性の文字は他に、i＝Intel、a＝AMD、d＝ローカルNVMeストレージ付き、n＝ネットワーク強化などがあります。

サイズは基本的に倍々で、汎用mファミリーならlarge＝2vCPU/8GiB、xlarge＝4vCPU/16GiB、2xlarge＝8vCPU/32GiB…と増えます。vCPUとメモリの比率はファミリーで決まっているので、まずファミリーを選び、次にサイズを選ぶ、が正しい順番です。

02ファミリーの使い分けは「vCPU:メモリ比」で覚える

• m（汎用）1:4 — 迷ったらここから。Webアプリ、APIサーバ、小中規模DB
• c（コンピューティング最適化）1:2 — CPUを使い切る処理。バッチ、アプリケーションサーバ、エンコード
• r（メモリ最適化）1:8 — メモリを食う処理。DB、キャッシュ、インメモリ処理。「mでメモリだけ足りない」ならr
• t（バースト型） — 常時は低負荷で、たまに跳ねる用途。検証環境、社内ツール、小規模サイト。後述の罠あり
• そのほか、i（ストレージI/O特化）、g/p（GPU）などは用途が明確なときだけ

実測してから移る前提なら、最初の1台は「最新世代のm、サイズは見積もりの一段小さめ」で十分です。AWSはサイズ変更が数分でできるので、オンプレ時代のような「大は小を兼ねる」の先買いは損しかありません。

03落とし穴①：T系のCPUクレジット枯渇

t3/t4gは安く見えますが、それは「ベースライン性能」しか常時保証されていないからです。例えばt3.mediumのベースラインはvCPUあたり20%。それを超えるCPU利用はクレジットを消費し、クレジットが尽きた瞬間、性能はベースラインまで強制的に絞られます。

怖いのは枯渇のタイミングで、アクセス集中や重いバッチなど「一番CPUが必要な瞬間」に尽きます。unlimitedモードにすれば絞られない代わりに超過分が従量課金され、恒常的に超過するなら「安いはずのt3がm系より高くつく」逆転が起きます。

04落とし穴②：旧世代のまま放置

同じ「m系のlarge」でも、世代が上がるほど速くなりながら同等以下の単価になるのがEC2の基本傾向です。m4やm5で塩漬けになっている環境は、最新世代に乗り換えるだけで性能向上とコスト削減が同時に手に入ります。作業もAMIの互換性さえ確認すれば、停止→タイプ変更→起動の数分です。

「動いているものは触らない」という運用方針のもとでは、この塩漬けが起きやすく、棚卸しの費用対効果が高いポイントです。無料のAWS Compute Optimizerを有効化すれば、実測メトリクスに基づく推奨タイプを一覧で出してくれます。

05落とし穴③：インスタンスの上限がストレージやネットワークを縛る

インスタンスサイズはCPU・メモリだけでなく、EBS帯域とネットワーク帯域の上限も決めています。小さいインスタンスでは帯域が「バースト値」表記で、ベースラインはずっと低い点に注意してください。「ディスクが遅い」の原因がインスタンスサイズだった、はよくある話です。詳しくはEBS選定の記事で解説しています。

06Graviton（Arm）に移るべきか

同世代のIntel/AMD比で最大2割程度安いのがGraviton（末尾g）です。判断はワークロードの中身次第です。

• 移行しやすい — OSSミドルウェア（nginx、PostgreSQL、Redis等）、Java/Python/Go等の自社アプリ、コンテナ。arm64ビルドを用意すれば大半はそのまま動きます
• 要確認 — 商用パッケージ・エージェント類（監視、ウイルス対策、バックアップ）。ベンダーのarm64対応表を先に確認
• 見送り — x86前提のレガシーバイナリ、ベンダーサポートが取れないもの

進め方は「検証環境の1台をg系に切り替えて2週間動かす」から。うまく動けば、同じ構成のまま2割の恒久的なコスト削減です。

07サイズより「台数」を先に考える

最後に設計の順番の話です。1台を大きくする（スケールアップ）前に、2台に分ける（スケールアウト）を検討してください。2台をAZに分けて並べれば、性能だけでなく可用性が段違いになります——単一インスタンスのSLAは99.5%、マルチAZ構成なら99.99%です。この差が業務にとってどれだけ大きいかは、構成SLA計算ツールで確かめられます。

—まとめ：選定の型

①ファミリーをvCPU:メモリ比で選ぶ（迷ったらm）。②世代は常に最新から。③サイズは一段小さめで始めて実測で調整。④T系はクレジットを理解した用途だけ。⑤EBS・ネットワーク帯域の上限もインスタンスが決めることを忘れない。⑥OSS中心ならGravitonで2割取る。⑦大きくする前に、分けることを考える。——この7つで、インスタンス選定の迷いはほぼなくなります。