AWSのインスタンスタイプの選び方：EC2の命名規則・現行世代とCLI絞り込み、RDSとの違いまで実装者目線で解説

EC2のインスタンスタイプは数百種類あり、コンソールの一覧を上から眺めて決めようとすると必ず手が止まります。実際の選定は、名前の文法を読んで候補の母集団を作り、CLIでスペック条件を当てて数個に絞り、稼働後は実測値で当て直す、という3段階の作業です。この記事では、AWS公式ドキュメントの定義に沿って命名規則を分解したうえで、describe-instance-typesでの候補抽出、Compute Optimizerの推奨の読み方、稼働中インスタンスの変更手順と引っかかりやすい互換性条件、Price List APIでの単価取得までをコマンド付きで示します。受託開発の現場で使っている採用条件と見送り条件も最後にまとめました。

「AWSのインスタンスタイプ」と一口に言っても、EC2のほかにRDSやElastiCacheにも同じ文法の名前が付いています。たとえばdb.r8g.largeやcache.m7g.largeは、接頭辞を外すとEC2のr8g.large・m7g.largeと同じ読み方です。本記事はEC2を軸に説明しつつ、2026年9月時点の現行世代の一覧と、RDS・ElastiCacheで挙動が変わる箇所も後半の章で押さえます。

まとめ：EC2インスタンスタイプを選ぶ手順と判断基準を先に示す

インスタンスタイプの選定は、用途からファミリー（系列）を決め、必要メモリ量からサイズを決め、プロセッサのオプション文字でコストと互換性を調整する、という順序で進めると迷いません。名前は「系列＋世代＋オプション．サイズ」という文法で書かれているため、m7i.largeとc7gn.xlargeの差はスペック表を開かなくても読み取れます。候補が10種類以上残るときは、コンソールではなくCLIのフィルタで機械的に絞り込むほうが速く、抜け漏れもありません。

そして、初回の選定は仮置きで構いません。EC2は停止すればタイプを変更できるため、2週間ほど動かしてCompute Optimizerの推奨とCloudWatchの使用率を見てから当て直すのが、コストと性能の両方で外さない進め方です。ただしアーキテクチャ（x86とArm）やドライバの都合で変更できない組み合わせがあり、ここを踏むと「停止したのに起動できない」という事故になります。互換性条件は後半の章で具体的に示します。

世代は2026年9月時点で第8世代が主力になり、Graviton系では第9世代（M9g・C9g・R9g）も一覧に載っています。新規に選ぶなら、まず第7〜第8世代の中から候補を出し、第9世代は利用したいリージョンでの提供状況を確かめてから加える進め方が現実的です。RDSやElastiCacheでも同じ系列・世代の読み方が通用しますが、T系のクレジットの扱いはサービスごとに違うため、DBやキャッシュをT系で置くときは専用の章を確認してください。

インスタンスタイプ名を分解して読む：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文字で用途の見当が付きます。AzureのVMサイズ・Google Cloudのマシンタイプとの対応関係はインスタンスタイプとは？AWS・Azure・Google Cloudの命名規則と選定手順で横断的に整理しています。

同じ系列・世代のオプション文字が示すプロセッサとストレージの違い

3文字目以降のオプションは、同じ系列・同じ世代の中で何が違うかを示す部分です。プロセッサ系ではg（AWS Graviton）・i（Intel）・a（AMD）が並び、付いていない場合はその世代の既定プロセッサになります。周辺機能ではd（インスタンスストア付き）・n（ネットワークとEBSの強化）・e（追加のメモリまたはストレージ）・z（高クロック）が使われ、flexが付くものはFlexインスタンスとして定義されています。m7iとm7i-flexのように末尾だけが異なる組み合わせを見たときは、まずこの表に当てて差分を確認してください。世代番号は数字が大きいほど新しく、同じサイズなら価格性能が改善している傾向にあります。

2026年9月時点の現行世代一覧：第8世代・第9世代とプロセッサの対応

EC2インスタンスタイプの一覧ドキュメントでは、現行世代（Current generation）と前世代（Previous generation）が分けて掲載されています。2026年9月時点の汎用・計算特化・メモリ特化を世代とプロセッサで整理すると、次の表のようになります。M1〜M4、C1〜C4、R3・R4、T1などは前世代に分類されており、新規構築で選ぶ理由はほぼありません。

バースト型は現行世代としてT2・T3・T3a・T4gに加えてT8iが並んでいます。一方、バースト可能パフォーマンスインスタンスのドキュメントではT4g・T3a・T3を現行、T2を前世代として説明しており、ページによって整理の粒度が揃っていません。T系の世代選びで迷ったら、後述のCLIで東京リージョンの提供状況を引いて判断するのが確実です。なお、表の各タイプがどのリージョン・どのAZで使えるかは時期によって変わるため、この表は「候補の母集団」として使い、最終確認は必ずCLIで行ってください。

用途からファミリーを当てる：汎用・計算特化・メモリ特化の使い分け

系列が読めたら、次はワークロードから候補を数系列に絞ります。AWSのインスタンスタイプ紹介ページでは5つのカテゴリに整理されており、実務でもこの粒度で当てれば十分です。

用途別の5カテゴリと代表ファミリーの対応表とワークロードの判断軸

汎用はvCPUとメモリの比率が1対4前後で、WebサーバーやAPI、中小規模のデータベースに向きます。計算特化は1対2前後でCPU比率が高く、バッチ処理や動画エンコード、推論処理に使います。メモリ特化は1対8以上で、インメモリキャッシュや大きめのリレーショナルデータベースが対象です。ストレージ特化はローカルNVMeを大量に積み、分散ストレージや高IOのデータベースに割り当てます。GPUなどのアクセラレータを積む高速コンピューティングは、学習や生成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へ切り替える判断も有効です。t3.medium単体の東京の月額、平均CPU使用率ごとの追加課金、CloudWatchでの監視コマンドはt3.mediumのスペックと東京の料金｜CPUクレジットの計算とT8i・t4gとの比較で計算しています。

T系とFlexの違い：ベースライン40%で動くflex付きタイプの位置づけ

T系と似た「安くて普段は余裕がある」選択肢に、名前にflexが付くタイプ（M7i-flex・M8i-flex・C7i-flex・C8i-flex・R8i-flex）があります。EC2インスタンスタイプの一覧ドキュメントによれば、Flexはベースライン40%のCPU性能を確保し、24時間のうち95%の時間は最大100%まで性能を出せる設計です。T系のようにクレジット残高を監視する必要がなく、サープラスクレジットの追加課金もありません。ただし、ベースラインを長時間大きく超えて使い続けると最大バースト性能が段階的に下がる場合があると明記されています。

実務上の使い分けは、平均CPU使用率がおおむね20%を下回り、夜間はほぼ無負荷という管理画面や検証環境ならT系、平均が20〜40%程度で日中にまとまった負荷がかかるWeb・APIならFlex、40%を超えて張り付くなら通常のM系・C系、という3段で考えると判断がぶれません。この20%・40%という境目は、T系のベースラインとFlexのベースラインから逆算した目安であり、公式の閾値ではない点に注意してください。

AWS CLIで候補を絞り込む：describe-instance-typesの実行手順

コンソールの一覧は種類が多すぎて比較に向きません。スペック条件が決まっているなら、describe-instance-typesにフィルタを渡して候補を機械的に列挙するほうが確実です。AWS CLIリファレンスにフィルタ名の一覧が定義されています。

vCPUとメモリの条件を指定した東京リージョンの現行世代候補の抽出

まずは条件を直接指定して、東京リージョンで使える現行世代の候補を出します。メモリはMiB単位で指定するため、16GiBなら16384と書きます。現行世代だけに絞るcurrent-generationと、アーキテクチャを指定するprocessor-info.supported-architectureを併用すると、旧世代が混ざりません。

なお同じタイプでもAZによって提供状況が違います。東京リージョンのAZ構成とAZごとの提供確認はap-northeast-1とは｜東京リージョンのAZ構成と指定方法・大阪との使い分けにまとめました。

# 現行世代・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-1

Graviton候補に絞った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-1

必要なvCPUとメモリの範囲から候補を逆引きする属性ベースの抽出

describe-instance-typesのフィルタは値の完全一致が基本なので、「vCPUは4〜8、メモリは16GiB以上、現行世代、バースト型は除く」のような範囲指定は書きにくいという欠点があります。この用途にはget-instance-types-from-instance-requirementsがこの用途に適したコマンドです。条件をJSONで渡すと、それを満たすタイプ名が一覧で返り、インスタンスを起動せずに候補を確認できます。

# attributes.json：x86_64・現行世代・vCPU 4〜8・メモリ16GiB以上・バースト型を除外
{
  "ArchitectureTypes": ["x86_64"],
  "VirtualizationTypes": ["hvm"],
  "InstanceRequirements": {
    "VCpuCount": {"Min": 4, "Max": 8},
    "MemoryMiB": {"Min": 16384},
    "InstanceGenerations": ["current"],
    "BurstablePerformance": "excluded",
    "CpuManufacturers": ["intel", "amd"]
  }
}

# 条件を満たすタイプを東京リージョンで表形式に出す
aws ec2 get-instance-types-from-instance-requirements \
  --cli-input-json file://attributes.json \
  --output table --region ap-northeast-1

このコマンドが返すのは「条件に合うタイプ」であって、そのAZに空き容量があるかは考慮されません。また同じ条件の書き方は、Auto ScalingグループやEC2 Fleetの属性ベースのインスタンスタイプ選択でもそのまま使うことが可能です。属性ベースのインスタンスタイプ選択のドキュメントにあるとおり、タイプ名を固定せず条件で指定しておくと、スポットの空きに合わせて複数のタイプへ分散でき、新しい世代が出たときも設定を書き換えずに候補へ入ります。スポットを使うバッチ基盤では、1つのタイプ名に決め打ちするより条件で持つ構成のほうが中断に強くなります。

Compute 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へ変更するとリクエストが失敗する例が示されています。

EC2以外のAWSインスタンスタイプ：RDSとElastiCacheの接頭辞と選び方

AWSでインスタンスタイプを選ぶ場面はEC2だけではありません。マネージドDBやキャッシュでも、裏側ではEC2と同じ系列・世代のハードウェアが使われており、名前に接頭辞が付く形で表記されます。EC2の命名規則が読めれば、ほかのサービスの選定もほぼ同じ手順で進められます。

db.とcache.の接頭辞で読むRDS・ElastiCacheのクラス名とEC2の対応

RDSでは「インスタンスタイプ」ではなく「DBインスタンスクラス」という呼び方です。RDSのDBインスタンスクラスのドキュメントでは、db.r6gがクラス種別、db.r6g.2xlargeがクラス、2xlargeがサイズという関係で説明されています。ElastiCacheでは「ノードタイプ」と呼び、ElastiCacheのサポート対象ノードタイプにcache.m8g.largeやcache.r7g.largeが並びます。

接頭辞を外した部分の読み方はEC2と同じですが、提供されている組み合わせは大きく絞られています。RDSのDBインスタンスクラス種別のドキュメントによれば、2026年9月時点で汎用はdb.m9g（Graviton5）・db.m8g（Graviton4）・db.m8i（Intel Xeon 6）などが並び、メモリ特化はdb.r8g・db.r8iが新しい層です。一方で計算特化はdb.c6gdのみで、しかもマルチAZ DBクラスター専用と明記されています。EC2の感覚で「CPUが重いからC系」と考えても、RDSでは選べないという点を押さえておいてください。RDS全体の仕組みと料金モデルはAmazon RDSの仕組みと採用判断を整理した記事、キャッシュ側の構成はAmazon ElastiCacheの対応エンジンとServerlessの違いを解説した記事にまとめています。

RDSで選べるクラスをCLIで引く手順とT系クレジットの挙動差

RDSのクラスはエンジンとバージョンによって選べる範囲が変わるため、EC2のdescribe-instance-typesの結果はそのまま使えません。describe-orderable-db-instance-optionsにエンジン名を渡すと、そのリージョンで作成できるクラスが返ります。

# 東京リージョンのPostgreSQLで作成できるDBインスタンスクラスを重複なしで列挙する
aws rds describe-orderable-db-instance-options \
  --engine postgres \
  --query "OrderableDBInstanceOptions[].DBInstanceClass" \
  --output text --region ap-northeast-1 \
  | tr '\t' '\n' | sort -u

見落としやすいのがT系の扱いです。RDSのdb.t4g・db.t3はUnlimitedモードで構成されていると公式に記載があり、24時間平均でベースラインを超えると追加料金が発生します。EC2のようにstandardへ切り替える設定は用意されていません。反対にElastiCacheのT4g・T3ノードはstandardで構成されており、クレジットが減ると性能がベースラインまで徐々に下がります。同じ「t4g.medium」でも、RDSでは請求が伸び、ElastiCacheでは遅くなるという逆の症状が出るため、監視するメトリクス（CPUCreditBalanceとCPUSurplusCreditsCharged）もサービスごとに分けて設定してください。なお、db.t2はRDSでは2024年12月31日にサポート終了となっており、残っている場合はdb.t3以降への更新が必要です。エンジン別に選べるクラスの違いやdb.t4gとdb.m8gの損益分岐はRDSのインスタンスタイプの選び方で詳しく比較しています。RDSのクラスごとの東京リージョンの実額と単価の下げ方はAWS RDSの料金を東京リージョンの実額で計算した記事で試算しています。

料金を自分で取得して比較する：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を重ね、中断しても再実行できるバッチ処理はスポットへ寄せる、という二層構成にすると総額を下げることが可能です。タイプを固定して1年以上使う見込みが立った段階なら、リザーブドインスタンスの購入判断と適用条件をCLIで試算した記事の手順で、タイプの柔軟性と割引率を比べてから購入してください。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で引けばそのまま反映される仕組みです。RDSのDBインスタンスクラスはaws rds describe-orderable-db-instance-options、ElastiCacheのノードタイプは公式ドキュメントのサポート対象ノードタイプの表で確認します。

インスタンスタイプは後から変更できますか？

ルートボリュームが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・Azure・Google Cloudの命名規則と選定手順を横断解説：3クラウドの命名規則を横断で比べる上位記事
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説：DBインスタンスクラスを選ぶ前提になるRDSの全体像
• リザーブドインスタンスの購入判断と適用条件｜AWS CLIで割引を試算する手順：タイプが決まった後の割引の掛け方
• AWSのオブザーバビリティ実装：メトリクス・ログ・トレースの設計：ライトサイジングの前提になる使用率の計装手順