EC2を使い始めてからずっと「とりあえずt3.small」みたいな選び方をしていたんですが、最近ちゃんとインスタンスタイプを理解しておかないとコスト面でも損してるなと感じてきました。AWS EC2のインスタンスタイプ比較をちゃんと調べ直す機会があったので、自分なりに整理してみます。
種類が多くて最初はとっつきにくいんですが、読み方のルールを知ると意外とスッキリするので、同じように悩んでいる方の参考になれば。
- インスタンスタイプの命名規則（読み方）がわかる
- 主要なインスタンスファミリー（T/M/C/R系など）の違いがわかる
- 2026年2月現在の最新動向（Graviton4がGA・Graviton5プレビュー）の概要がわかる
- ユースケース別の選び方の目安がわかる
- コスト面での考え方（サイズとの関係）が整理できる
まず「インスタンスタイプ」って何？
EC2インスタンスを起動するとき、「t3.micro」とか「m7g.large」とか指定しますよね。これがインスタンスタイプです。
Amazon EC2のインスタンスタイプとは、いわば「パソコンの性能カタログ」みたいなもので、CPUやメモリ容量、ストレージ、ネットワーク性能といった構成があらかじめテンプレートとして定義されています。ユーザーはその中から必要なものを選ぶだけで仮想マシンを立ち上げられます。
あまり極端なもの、例えば「CPUは2コアで、メモリが256GB」みたいな構成はラインナップされていません。ただ用途に合った組み合わせはだいたい揃っているので、実際に困ることは少ないです。
命名規則を読み解く
インスタンスタイプは [ファミリー][世代](追加機能).[サイズ] という形式で表現されています。最初にこれを知っておくだけで、初見のインスタンスタイプでもある程度内容が推測できるようになります。(docs.aws.amazon.com)
① インスタンスファミリー（最初の英字）
EC2インスタンスファミリーは、主に以下のようなカテゴリーに分類されます（ざっくり）。
- 汎用（T, M系など）：CPU・メモリ・ネットワークのバランスが取れた万能型
- コンピューティング最適化（C系）：CPUパワー重視
- メモリ最適化（R, X系など）：大量のメモリが必要なワークロード向け
- ストレージ最適化（I, D系など）：高I/OやローカルSSD重視
- 高速コンピューティング（P, G系など）：GPUなどを搭載した用途向け
② インスタンス世代（ファミリーの後の数字）
世代は大きいほど新しい傾向があります。新しい方が、性能の良いハードウェアを使用している、コストパフォーマンスが改善しているなどのメリットが期待できます。原則として最新世代を選ぶのが無難です。
なお「m4やc4＝Xen、m5以降＝Nitro」みたいに世代番号だけでスパッと区切れるわけではないので、移行時はインスタンスタイプごとのドキュメント（対応ドライバ、ENA/NVMeなど）を見て判断するのが安全です。ここ、昔の記憶だけで決めるとハマりがちです…（自戒）。
③ 追加機能（オプション文字）
世代の後に英字が追加されることがあります。代表的なものは以下です。(docs.aws.amazon.com)
- g：AWS Graviton（Armベースの自社プロセッサ）搭載
- a：AMDプロセッサ搭載
- d：内蔵のインスタンスストア（NVMe SSD）付き
- n：ネットワーク/EBS最適化
- i：Intelプロセッサ搭載（明示的に指定）
例えば「m7g.large」なら「M系ファミリー・第7世代・Graviton搭載・largeサイズ」という意味になります。
複数の追加機能がついている場合は「c7gn.xlarge」みたいに連なることもあります（m8gn みたいな表記もこのパターンです）。(docs.aws.amazon.com)
④ インスタンスサイズ（ドット以降）
インスタンスサイズは各インスタンスのvCPUやメモリサイズの規模を表しています。nano→micro→small→medium→large→xlarge→2xlarge→…の順でスペックが上がります。
ただし「1段上がると必ずvCPUとメモリがほぼ倍」かというと、ファミリーや世代・サイズ帯によって例外もあるので、最終的には公式のスペック表を見て確認するのが確実です（ここは自分も毎回見に行ってます）。
主要なインスタンスファミリーを比較
T系（バースト可能な汎用）
バースト可能なパフォーマンスを提供する低コストのインスタンスで、トラフィックがスパイクするウェブサイトや開発環境に適しています。CPUクレジットという仕組みがあって、普段は低めのCPU使用率で動かしておき、必要なときだけ一時的にバーストして高い処理能力を発揮できます。(aws.amazon.com)
T系インスタンスについてはベースライン（基準CPU使用率）が定義されています。Standardモードだと、クレジットを使い切るとベースライン相当まで落ちます。一方でT3/T4gはデフォルトがUnlimitedモードで、ベースラインを超えた状態を「維持」すると追加課金（サープラスクレジット課金）が発生します。なので「一定量を超えるとベースライン以下になる or 追加課金」という理解が近いです。(docs.aws.amazon.com)
余談ですが、最初に触るEC2として「t3.micro」や「t4g.small」を選ぶ人が多いと思うので、このバースト動作は早めに理解しておいた方がいいです。自分もしばらく知らずに使ってました。
M系（汎用）
汎用インスタンスは、CPU、メモリ、ネットワークリソースのバランスが取れており、ウェブサーバー、開発環境、中小規模データベースなど、幅広いワークロードに適しています。迷ったらM系、という感じの万能選手です。現行世代の主なラインナップは以下：
- M7g：AWS Graviton3搭載
- M7i：Intel Xeon Scalable（第4世代）搭載
- M7a：AMD EPYC搭載
- M8g：AWS Graviton4搭載（後述）
C系（コンピューティング最適化）
コンピューティング最適化インスタンス（Cシリーズ）は、アプリケーションがCPUを大量に消費するが、大量のメモリが必要ない場合に選ぶべきインスタンスです。計算集約型のタスク、リアルタイム処理、並列コンピューティングのワークロードに最適です。バッチ処理や動画エンコード、ゲームサーバーなどにも向いています。
R系（メモリ最適化）
メモリ最適化インスタンスは、メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されています。インメモリデータベース（Redis、Memcachedなど）、大規模なRDBMS、ビッグデータ処理、リアルタイム分析といったワークロードに向いています。「RAM」の頭文字が「R」なので覚えやすいです。
2026年2月現在のEC2インスタンスタイプ最新動向：Graviton4がGA、Graviton5はプレビュー
Graviton4はすでに一般提供（GA）済みで最新クラスの主力、一方で Graviton5は2025年12月4日にM9gとしてプレビュー公開という状況です（2026年2月時点）。(aws.amazon.com)
「今すぐ普通に使える最新のGraviton世代」という意味ならGraviton4、将来含めて最先端の世代という意味ならGraviton5も視野、という整理がよさそうです。
Graviton4世代（GA）の主なインスタンス
- M8g（汎用）
- R8g（メモリ最適化）
- M8gd / C8gd / R8gd（Graviton4 + インスタンスストアNVMe付き）
特にR8gは2024年7月9日にGAになっていて、性能向上の数字（Web最大30%/DB最大40%/Java最大45%）もAWS公式の案内に載っています。(aws.amazon.com)
（マイクロアーキテクチャの細かい仕様数値はAWS公式のGraviton4プロセッサ紹介ページに一次情報があるので、正確な数字が必要な場合はそちらを参照してください。）
ネットワーク帯域600Gbpsクラス（Graviton4 + “n”系）
M8gnは2025年12月17日にGAになっていて、最大600Gbpsネットワーク帯域（加えてEBS最大60Gbps）と明記されています。(aws.amazon.com)
同じくGraviton4のネットワーク最適化としてC8gnも2025年6月30日にGAで、こちらも最大600Gbpsです。(aws.amazon.com)
- M8gn：最大600Gbps（GA: 2025年12月17日）
- C8gn：最大600Gbps（GA: 2025年6月30日）
ついでに「M8gb」も同日GAで、こちらはネットワークというよりEBS帯域（最大150Gbps）寄りの派生です。(aws.amazon.com)
オンデマンド料金について（注意）
EC2のオンデマンド料金はリージョン・OS・サイズで変わるので、一般論として断定するのは危ないです。公式の料金ページで都度確認するのが確実です。(aws.amazon.com)
個人的な体感としては「性能が上がった分、同じコストでより速い（または同じ性能をより小さいサイズで満たせる）ケースがある」ので、単価だけじゃなくて”必要な性能を満たす最小サイズ”で比較するのが良いかなと。
GravitonはArmアーキテクチャ：移行前に確認を
GravitonはArmアーキテクチャなので、x86（Intel/AMD）向けにコンパイルされたバイナリはそのままでは動きません。Dockerイメージもarm64対応のものが必要です。PythonやLinuxの主要パッケージはArmに対応済みなことが多いので思ったより対応コストは低いですが、事前の動作確認は必須です。
ユースケース別のEC2インスタンスタイプ選び方
実際にインスタンスを選ぶときの大まかな基準をまとめます。迷ったときの参考程度に。
ケース別チートシート
- 個人開発・検証環境：T系（t4g.small、t3.microなど）でコスト最小に
- 汎用Webアプリ・APIサーバー：M系（m7g、m8gなど）が無難
- CPUを多用するバッチ処理・HPC：C系（c7g、c8gnなど）でCPU効率を重視
- インメモリDB・大規模RDB：R系（r7g、r8gなど）でメモリをたっぷり確保
- ML推論・GPU処理：P系・G系（p4d、g5など）
- 高頻度I/OやローカルSSD必須：I系（i4i、i4gなど）
コストとサイズの関係
EC2の料金体系で地味に重要なのが「サイズを上げるとコストも増える」という点です。largeよりxlargeの方がスペックが上がって料金も上がるんですが、きれいに”常に倍”とは限らないので、ここも念のため料金表での確認推奨です。
例えば、1つのxlargeを使うか2つのlargeを使うかはケースによります。スケールアップよりも水平スケールアウトが向くワークロードもあるので、Lambdaと組み合わせたり、ECSでコンテナを複数動かしたりする設計も検討の余地があります。
ArmベースのT4gはコスパが良い選択肢になりやすいので、開発環境や軽量なサービスには積極的に使っていきたいです（ただしArm対応チェックは忘れずに）。
まとめ
ここまでをざっくり整理します。
- インスタンスタイプは [ファミリー][世代](追加機能).[サイズ] の構造になっている（docs.aws.amazon.com）
- ファミリーは汎用（T/M）、コンピューティング最適化（C）、メモリ最適化（R/X）、ストレージ最適化（I/D）、高速コンピューティング（P/G）などに分かれる
- 世代は大きいほど新しい傾向があり、基本的に最新世代を選ぶのが無難
- Graviton4（M8g/R8gなど）はGA済みの最新主力で、Graviton3比の性能向上（Web最大30%/DB最大40%/Java最大45%など）が公表されている（aws.amazon.com）
- Graviton5はM9gとして2025年12月4日にプレビュー公開（2026年2月時点では”次世代”枠）（aws.amazon.com）
- GravitonはArmアーキテクチャのため、x86向けバイナリやDockerイメージとの互換性を事前に確認が必要
- 迷ったときはM系から始めて、CPUやメモリのボトルネックを確認してから調整するのがおすすめ
インスタンスタイプは一度選んで終わりではなく、CloudWatchでCPU/メモリの使用状況を見ながら定期的に見直すのが理想です。「なんとなくm5.large」のままにしてるのが一番もったいないので、少しずつ最適化してみてください。参考になれば！
関連記事
参考になったらクリックしてもらえると嬉しいです!
