EC2のインスタンスタイプは数百種類あり、コンソールの一覧を上から眺めて決めようとすると必ず手が止まります。実際の選定は、名前の文法を読んで候補の母集団を作り、CLIでスペック条件を当てて数個に絞り、稼働後は実測値で当て直す、という3段階の作業です。この記事では、AWS公式ドキュメントの定義に沿って命名規則を分解したうえで、describe-instance-typesでの候補抽出、Compute Optimizerの推奨の読み方、稼働中インスタンスの変更手順と引っかかりやすい互換性条件、Price List APIでの単価取得までをコマンド付きで示します。受託開発の現場で使っている採用条件と見送り条件も最後にまとめました。
まとめ：EC2インスタンスタイプを選ぶ手順と判断基準を先に示す
インスタンスタイプの選定は、用途からファミリー（系列）を決め、必要メモリ量からサイズを決め、プロセッサのオプション文字でコストと互換性を調整する、という順序で進めると迷いません。名前は「系列＋世代＋オプション．サイズ」という文法で書かれているため、m7i.largeとc7gn.xlargeの差はスペック表を開かなくても読み取れます。候補が10種類以上残るときは、コンソールではなくCLIのフィルタで機械的に絞り込むほうが速く、抜け漏れもありません。
そして、初回の選定は仮置きで構いません。EC2は停止すればタイプを変更できるため、2週間ほど動かしてCompute Optimizerの推奨とCloudWatchの使用率を見てから当て直すのが、コストと性能の両方で外さない進め方です。ただしアーキテクチャ（x86とArm）やドライバの都合で変更できない組み合わせがあり、ここを踏むと「停止したのに起動できない」という事故になります。互換性条件は後半の章で具体的に示します。
インスタンスタイプ名を分解して読む：c7gn.xlargeの構成要素
選定の速度は、名前をどれだけ正確に読めるかでほぼ決まります。AWSは命名規則を公式ドキュメントで定義しており、位置ごとに意味が固定されています。
インスタンスタイプ名の系列・世代・オプション・サイズの4区画の読み方
インスタンスタイプ名は、ピリオドの前がインスタンスファミリー、後ろがインスタンスサイズです。ファミリー側は1文字目が系列、2文字目が世代、3文字目以降がオプションを表します。AWS公式の命名規則ドキュメントの例に従えば、c7gn.xlargeは「計算特化（C）の第7世代（7）でGravitonプロセッサ（g）かつネットワーク強化（n）、サイズはxlarge」という読み方です。系列はM（汎用）・C（計算特化）・R（メモリ特化）・T（バースト）・I（ストレージ特化）・P/G（GPU）・Inf（Inferentia）・Trn（Trainium）・X/Z（大容量メモリ）などが定義されており、この1文字で用途の見当が付きます。
同じ系列・世代のオプション文字が示すプロセッサとストレージの違い
3文字目以降のオプションは、同じ系列・同じ世代の中で何が違うかを示す部分です。プロセッサ系ではg（AWS Graviton）・i（Intel）・a（AMD）が並び、付いていない場合はその世代の既定プロセッサになります。周辺機能ではd（インスタンスストア付き）・n（ネットワークとEBSの強化）・e（追加のメモリまたはストレージ）・z（高クロック）が使われ、flexが付くものはFlexインスタンスとして定義されています。m7iとm7i-flexのように末尾だけが異なる組み合わせを見たときは、まずこの表に当てて差分を確認してください。世代番号は数字が大きいほど新しく、同じサイズなら価格性能が改善している傾向にあります。
| 区画 | 例（c7gn.xlarge） | 意味 |
|---|---|---|
| 系列 | c | 計算特化（Compute） |
| 世代 | 7 | 第7世代 |
| オプション | gn | Graviton＋ネットワーク強化 |
| サイズ | xlarge | vCPUとメモリの規模 |
用途からファミリーを当てる：汎用・計算特化・メモリ特化の使い分け
系列が読めたら、次はワークロードから候補を数系列に絞ります。AWSのインスタンスタイプ紹介ページでは5つのカテゴリに整理されており、実務でもこの粒度で当てれば十分です。
用途別の5カテゴリと代表ファミリーの対応表とワークロードの判断軸
汎用はvCPUとメモリの比率が1対4前後で、WebサーバーやAPI、中小規模のデータベースに向きます。計算特化は1対2前後でCPU比率が高く、バッチ処理や動画エンコード、推論処理に使います。メモリ特化は1対8以上で、インメモリキャッシュや大きめのリレーショナルデータベースが対象です。ストレージ特化はローカルNVMeを大量に積み、分散ストレージや高IOのデータベースに割り当てます。GPUなどのアクセラレータを積む高速コンピューティングは、学習や生成AIの推論で使う系列です。
| カテゴリ | 代表系列 | vCPU対メモリ | 向くワークロード |
|---|---|---|---|
| 汎用 | M・T | 1対4 | Web・API・中小DB |
| 計算特化 | C | 1対2 | バッチ・推論・エンコード |
| メモリ特化 | R・X・Z | 1対8以上 | キャッシュ・大規模DB |
| ストレージ特化 | I・D | 1対4前後 | 高IO DB・分散ストレージ |
| 高速コンピューティング | P・G・Inf・Trn | 用途依存 | 学習・生成AI・映像処理 |
アプリ・OS・ミドルウェアの必要メモリ量を起点にしたサイズ選びの手順
サイズはlarge・xlarge・2xlarge…と上がるごとにvCPUとメモリがおおむね倍になります。ここで先にvCPU数から決めようとすると、メモリが足りずに1段上げ、結果としてCPUが余る、という無駄が生まれがちです。実務では「アプリのヒープとOSとミドルウェアの合計メモリ」を先に見積もり、それを満たす最小サイズを当て、そのうえでCPU使用率が張り付くならC系へ、余るならT系やFlexへ振り替えます。JVMやNode.jsのようにメモリ設定が性能を左右するランタイムでは、この順序のほうが結果的に安く収まります。EC2そのものの構成要素や料金モデルの全体像は、Amazon EC2の仕組みと採用判断を整理した記事で確認してください。
バースト型のT系を選ぶ条件：CPUクレジットとベースラインの実務
T系は単価が低く検証環境や小規模Webでよく選ばれますが、CPUの性能モデルが他系列と根本的に違います。ここを理解しないまま本番に置くと、負荷が上がった瞬間に遅くなるか、請求が想定外に伸びます。
T系の採用判断に必要なCPUクレジットとベースライン使用率の関係
AWS公式のバースト可能パフォーマンスインスタンスのドキュメントによれば、現行世代はT4g・T3a・T3の3種類で、T2は前世代の扱いです。T系はサイズごとにベースラインのCPU性能が決まっており、それを下回って動いている間にCPUクレジットを貯め、スパイク時にそのクレジットを使ってベースライン以上の性能を出します。平均CPU使用率が低く、たまに跳ねるだけのワークロード、たとえば社内向けの管理画面、開発・検証環境、小規模なコードリポジトリなどが本来の適用先です。常時50%以上のCPU使用率が続くワークロードは、クレジットが枯渇するかコストが積み上がるため、M系やC系に置いたほうが安定します。
unlimitedとstandardの選び分けとスポットでの注意
T4g・T3a・T3は既定でunlimitedモードとして起動します。unlimitedでは、24時間のローリング平均がベースラインを超えるとサープラスクレジットとして追加課金が発生する仕組みで、超過分はvCPU時間あたりの定額で請求されます。一方standardモードは、クレジットが尽きた時点でベースライン性能に張り付き、追加課金は発生しません。unlimitedモードのドキュメントでは、クレジットを貯める余裕のない短命なスポットインスタンスについてはstandardでの起動を推奨しています。また、Dedicated Host上のT3はstandardが既定で、unlimitedはサポートされません。請求の予測可能性を優先する環境ではstandardへ切り替える判断も有効です。
AWS CLIで候補を絞り込む：describe-instance-typesの実行手順
コンソールの一覧は種類が多すぎて比較に向きません。スペック条件が決まっているなら、describe-instance-typesにフィルタを渡して候補を機械的に列挙するほうが確実です。AWS CLIリファレンスにフィルタ名の一覧が定義されています。
vCPUとメモリの条件を指定した東京リージョンの現行世代候補の抽出
まずは条件を直接指定して、東京リージョンで使える現行世代の候補を出します。メモリはMiB単位で指定するため、16GiBなら16384と書きます。現行世代だけに絞るcurrent-generationと、アーキテクチャを指定するprocessor-info.supported-architectureを併用すると、旧世代が混ざりません。
# 現行世代・x86_64・vCPU 4・メモリ16GiB の候補を東京リージョンで列挙する
aws ec2 describe-instance-types \
--filters "Name=current-generation,Values=true" \
"Name=processor-info.supported-architecture,Values=x86_64" \
"Name=vcpu-info.default-vcpus,Values=4" \
"Name=memory-info.size-in-mib,Values=16384" \
--query "InstanceTypes[].InstanceType" \
--output text --region ap-northeast-1Graviton候補に絞ったvCPU・メモリ・ネットワーク性能の比較
コスト圧縮を狙うなら、同条件でArm（Graviton）側も出して突き合わせます。--queryで必要な項目だけ抜き出し、--output tableにすると比較表として読めます。バースト型を除外したいときはburstable-performance-supportedをfalseで指定してください。無料利用枠の対象だけ見たい場合はfree-tier-eligible、休止機能を使う予定があるならhibernation-supportedが使えます。
# Arm(Graviton)・バースト非対応・現行世代の候補をvCPUとメモリ付きで表示する
aws ec2 describe-instance-types \
--filters "Name=current-generation,Values=true" \
"Name=processor-info.supported-architecture,Values=arm64" \
"Name=burstable-performance-supported,Values=false" \
"Name=vcpu-info.default-vcpus,Values=4" \
--query "InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB,NetworkInfo.NetworkPerformance]" \
--output table --region ap-northeast-1Compute Optimizerの推奨で選び直す：findingsと参照期間の読み方
初回の選定は見積もりに過ぎないため、稼働後の実測で当て直します。AWS Compute Optimizerは稼働中インスタンスのメトリクスを分析し、サイズの過不足と推奨タイプを返してくれる機能です。
3つのfinding分類と参照期間・パフォーマンスリスクを踏まえた推奨の読み方
EC2インスタンスの推奨事項のドキュメントによると、findingはUnder-provisioned（不足）・Over-provisioned（過剰）・Optimizedの3分類です。推奨は日次で更新され、直近14日間のメトリクスを分析して生成されます。拡張インフラストラクチャメトリクスという有料機能を有効にすると、より長い期間（コンソールのグラフでは3か月）を対象にすることが可能です。詳細ページでは1インスタンスあたり最大3件の候補が、パフォーマンスリスクと時間単価付きで並びます。パフォーマンスリスクはAPIとCLI上では0（very low）から4（very high）の数値で返るため、自動化に組み込む場合はこの値で足切りするとよいでしょう。なお、メモリ使用率はCloudWatchエージェントを入れていないインスタンスでは分析対象になりません。この前提を外すと「CPUだけ見て縮めてメモリで詰まる」という失敗に直結します。使用率の計装はAWSのオブザーバビリティ実装をまとめた記事の手順が参考になります。
CLIによる過剰サイズのインスタンス抽出と現行・推奨タイプの比較
コンソールを開かずに棚卸ししたい場合は、get-ec2-instance-recommendationsでfindingを絞り込みます。過剰サイズのものだけを現行タイプ・推奨タイプ・パフォーマンスリスクの3列で並べると、そのまま変更計画の素材になります。
# 過剰サイズ判定のインスタンスを、現行タイプと第1推奨タイプの対で一覧する
aws compute-optimizer get-ec2-instance-recommendations \
--filters "name=Finding,values=Overprovisioned" \
--query "instanceRecommendations[].[instanceName,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].performanceRisk]" \
--output table --region ap-northeast-1稼働中のEC2インスタンスのタイプ変更手順と互換性の事前確認事項
EC2はタイプを後から変更できます。ただし無条件ではなく、ルートボリュームの種類と互換性の判定が前提になります。
EBSルートのインスタンスを停止してタイプを変更し再起動する手順
インスタンスタイプの変更ドキュメントでは、ルートボリュームがEBSで互換性がある場合は「インスタンスタイプの変更」、互換性がない場合とインスタンスストアルートの場合は「新しいインスタンスへの移行」と手順が分かれています。EBSルートの変更は、停止してからタイプ属性を書き換え、再度起動するという3ステップです。停止と起動を挟むためパブリックIPは（Elastic IPを割り当てていなければ）変わり、インスタンスストア上のデータは失われます。変更後は新しいタイプの料金が即座に適用されます。
# 停止 → 停止完了を待機 → タイプ変更 → 起動 の順に実行する
aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 \
--instance-type "{\"Value\": \"m7i.large\"}"
aws ec2 start-instances --instance-ids i-0123456789abcdef0タイプ変更前に確認するAMI・ドライバ・EBSボリューム数の互換性条件
互換性のドキュメントが挙げる判定軸は、仮想化タイプ（PVのAMIからHVM専用タイプへは変更不可）、アーキテクチャ（x86のAMIをArm系タイプへ変更することはできない）、ネットワークアダプタの変更、拡張ネットワーク（Nitro系はENAドライバ入りのEBS-backed AMIが前提、ENA Express有効時は変更先も対応している必要がある）、NVMe（未対応タイプから対応タイプへ移る際はドライバ導入とデバイス名の変更が伴い、/etc/fstabはUUIDまたはラベルでの記述が必要）、アタッチ済みEBSボリューム数の上限、NitroTPMの7点です。とくにx86からGravitonへの移行は、タイプ変更ではなくAMIの作り直しを伴う移行作業になる点を工数見積もりに入れてください。ボリューム数の制約も見落としやすく、公式ドキュメントでは32ボリュームを付けたm7i.4xlargeから上限27のm6i.4xlargeへ変更するとリクエストが失敗する例が示されています。
料金を自分で取得して比較する：Price List APIで単価を引く手順
タイプ候補が2〜3個に絞れたら、単価を突き合わせて最終決定します。料金ページを目視で拾うと転記ミスが起きるため、Price List APIで引いて比較するほうが確実です。オンデマンドの体系はEC2オンデマンド料金ページ、中断許容ワークロード向けの割引はスポットインスタンス料金ページが一次情報です。get-productsのCLIリファレンスに従い、リージョンコードとOS、テナンシーを指定して1時間あたりの単価を取り出します。Price List APIのエンドポイントは限られたリージョンにしかないため、--region us-east-1を明示して呼び出す点に注意してください。
# 東京リージョンの m7g.large（Linux・共有テナンシー）のオンデマンド単価を取得する
aws pricing get-products --region us-east-1 --service-code AmazonEC2 \
--filters "Type=TERM_MATCH,Field=instanceType,Value=m7g.large" \
"Type=TERM_MATCH,Field=regionCode,Value=ap-northeast-1" \
"Type=TERM_MATCH,Field=operatingSystem,Value=Linux" \
"Type=TERM_MATCH,Field=tenancy,Value=Shared" \
"Type=TERM_MATCH,Field=preInstalledSw,Value=NA" \
"Type=TERM_MATCH,Field=capacitystatus,Value=Used" \
--query "PriceList[0]" --output text \
| python -c "import sys,json;d=json.load(sys.stdin);print([x['pricePerUnit'] for t in d['terms']['OnDemand'].values() for x in t['priceDimensions'].values()])"取得した時間単価に月間稼働時間を掛ければ、候補間の差額が金額で出ます。定常稼働する土台にはSavings Plansを重ね、中断しても再実行できるバッチ処理はスポットへ寄せる、という二層構成にすると総額を下げることが可能です。vCPU数やスレッド数を絞って計算リソースを減らしたい場合は、CPUオプションの指定でコア数とコアあたりスレッド数を起動時に変更する方法もあります。ライセンスがコア数課金の商用ソフトを載せるときは、この指定が効きます。
受託開発の現場でのインスタンスタイプ選定：採用と見送りの判断基準
ここまでの手順を、実際の案件でどう適用しているかを条件付きで示します。判断が割れる場面は、たいてい「安さ」と「変更容易性」のどちらを取るかに集約されます。
常時稼働や特定ハードウェアが必要な場面での選定手順と初期構成の置き方
本記事の手順が効くのは、常時稼働するWeb・APIサーバーやデータベースをEC2に置く場合、既存システムをそのままクラウドへ持ち上げる場合、そしてGPUなど特定ハードウェアが要る場合です。初期構成は、汎用のM系かFlexで一段大きめに置いて2週間動かし、Compute Optimizerの推奨とCloudWatchの実測値で縮める進め方が標準です。新規構築でランタイムがArm対応済み（Go・Node.js・Python・Javaなど）ならGraviton系を第一候補にし、商用ミドルウェアやネイティブ拡張の対応状況に不安がある場合だけx86系を選びます。この判断とコスト設計を含めたAWS上の構成づくりは、クラウドインフラ構築の相談窓口で要件から詰められます。
稼働がまばらな処理で選定に時間をかけるべきでない場面と失敗パターン
逆に、タイプ選定そのものを詰めるべきでない場面もあります。稼働がまばらなイベント処理は、どのタイプを選んでも常時課金が無駄になるため、AWS Lambdaの料金体系と採用判断を整理した記事のとおりサーバーレスへ寄せたほうが低コストです。コンテナ化済みでサーバー管理を減らしたいなら、FargateとEC2の違いを解説した記事で示した分岐に従い、タスク単位のリソース指定に切り替えるほうが運用が軽くなります。失敗として多いのは、検証時の負荷でT系を選んで本番の定常負荷でクレジットが枯渇するパターン、そして「余裕を持たせる」名目で2段階大きいサイズを置いたまま誰も縮めないパターンの2つです。前者はベースライン使用率を先に計算すれば避けられ、後者は変更手順を運用フローに組み込んでおけば防げます。
よくある質問
EC2のインスタンスタイプ選定で実装者から挙がる質問を、公式ドキュメントの定義に沿って整理します。
インスタンスタイプの一覧はどこで確認できますか？
公式サイトのインスタンスタイプページでカテゴリ別の一覧を確認できますが、自分のリージョンで実際に使えるものを知りたい場合はdescribe-instance-typesを実行してください。コンソールの一覧と違い、フィルタでvCPU数やメモリ量、アーキテクチャを指定して抽出できるため、候補の比較が短時間で終わります。リージョンによって提供されないタイプがある点も、CLIで引けばそのまま反映されます。
インスタンスタイプは後から変更できますか？
ルートボリュームがEBSで互換性の条件を満たしていれば、インスタンスを停止してタイプを変更し、再起動する手順で切り替えられます。互換性がない組み合わせやインスタンスストアがルートの場合は、新しいインスタンスを起動して移行する形です。停止中はインスタンスストアのデータが失われ、Elastic IPを割り当てていなければパブリックIPも変わるため、切り替え時間を含めた計画が要ります。
T系インスタンスを本番環境で使っても問題ありませんか？
平均CPU使用率がベースラインを下回り、スパイクが短時間に限られるワークロードであれば本番でも使えます。ただしT4g・T3a・T3は既定でunlimitedモードのため、24時間平均がベースラインを超え続けるとサープラスクレジットの課金が積み上がります。定常的にCPUを使う処理はM系やC系へ移し、請求を固定したい環境ではstandardモードへ切り替える運用が現実的です。
GravitonとIntel・AMDはどう選び分けますか？
アプリケーションがArmで動くなら、価格性能の点でGraviton（名前にgが付くタイプ）を第一候補にできます。判断材料は、使用しているランタイムとライブラリのArm対応状況、コンテナイメージのマルチアーキテクチャ対応、商用ミドルウェアのサポート範囲です。x86からArmへはタイプ変更では移れずAMIの作り直しが必要なので、切り替えるなら新規構築か更改のタイミングを選んでください。
Compute Optimizerの推奨はそのまま適用してよいですか？
推奨は直近14日のメトリクスに基づくため、月次バッチや季節性のあるワークロードでは参照期間から負荷の山が外れている可能性があります。またメモリ使用率はCloudWatchエージェントを導入したインスタンスしか分析対象になりません。パフォーマンスリスクの値とfinding reasonを確認し、負荷の周期が長いシステムでは拡張インフラストラクチャメトリクスで期間を延ばしてから適用を判断してください。
関連記事
- Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を解説：本記事の前提になるEC2の構成要素と5つの料金モデルを整理した上位記事
- AWS Fargateとは？EC2との違い・料金をわかりやすく解説：インスタンスタイプを選ばずコンテナを動かす選択肢との比較
- AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断：常時稼働を避けたい処理をサーバーレスへ寄せる判断軸
- AWSのオブザーバビリティ実装：メトリクス・ログ・トレースの設計：ライトサイジングの前提になる使用率の計装手順
