同じ4vCPU・16GiBの仮想サーバーでも、AWSではm7i.xlarge、AzureではStandard_D4s_v5、Google Cloudではn2-standard-4と、名前の付け方が三者三様です。インスタンスタイプは「CPU・メモリ・ストレージ・ネットワークの組み合わせをあらかじめ定義した型番」のことで、AzureではVMサイズ、Google Cloudではマシンタイプと呼ばれます。この記事では3クラウドそれぞれの公式ドキュメントの定義に沿って命名規則を1文字ずつ分解し、CLIで候補一覧を取り出すコマンド、同等構成を突き合わせるときにずれるvCPUの定義やバースト型の扱いまでを、移行見積りの実務で使う手順としてまとめた記事です。AWS単独の選定作業に絞った手順は別記事で扱っているため、ここでは横断の対応関係を中心に置きます。
まとめ：3クラウドのインスタンスタイプを突き合わせる手順と判断の順序
インスタンスタイプの選定は、用途からファミリーを決め、必要メモリ量からサイズを決め、プロセッサやストレージを示す文字で微調整する、という順序で進みます。この順序は3クラウドで共通です。違うのは名前の書き方だけで、AWSは「ファミリー＋世代＋オプション文字．サイズ」、Azureは「ファミリ＋vCPU数＋付加機能＋バージョン」、Google Cloudは「シリーズ－リソース比率－vCPU数」という文法を持ちます。
移行や相見積りで3クラウドを並べるときは、名前の対応表だけで済ませないでください。vCPUがスレッド単位かコア単位かは名前から読めず、ここを取り違えると同じ「4vCPU」でも実効性能が2倍近く離れます。ローカルディスクの有無、バースト型かどうかも同様に名前の一部にしか現れません。突き合わせの精度を上げる実務的な近道は、各クラウドのCLIでスペックを機械的に出力し、同じ列で比較することです。本文ではそのコマンドを3クラウド分そのまま載せます。
インスタンスタイプの定義とAWS・Azure・Google Cloudでの呼び名の対応
まず用語を揃えます。呼び名が違うだけで指しているものは同じですが、社内の資料で混在すると見積りの粒度がぶれます。
AWSのインスタンスタイプ・AzureのVMサイズ・GCPのマシンタイプの対応
AWSのEC2では「インスタンスタイプ」、AzureのVirtual Machinesでは「VMサイズ」、Google CloudのCompute Engineでは「マシンタイプ」と呼びます。いずれもvCPU数・メモリ容量・ストレージ構成・ネットワーク帯域の組み合わせを型番として提供する仕組みで、利用者が仮想サーバーを起動するときに指定するのが、この型番です。Oracle Cloudでは「シェイプ」という別の呼称も使われます。
仮想サーバーそのものを指す「インスタンス」と、その型番である「インスタンスタイプ」は別物です。インスタンスという語はデータベースやオブジェクト指向でも使われ、文脈で意味が変わります。用語の整理はインスタンスとは？クラウドの仮想サーバーからオブジェクト指向・DBまで領域別に解説で領域別にまとめています。
| クラウド | サービス名 | 型番の呼称 | 表記例 |
|---|---|---|---|
| AWS | Amazon EC2 | インスタンスタイプ | m7i.xlarge |
| Azure | Virtual Machines | VMサイズ | Standard_D4s_v5 |
| Google Cloud | Compute Engine | マシンタイプ | n2-standard-4 |
型を選ぶ作業がvCPU・メモリ・ストレージ・ネットワークの4要素に分かれる理由
型番が数百種類に膨らむのは、4つの要素の比率を変えた組み合わせを用意しているからです。vCPUとメモリの比率が1対4前後なら汎用、1対2前後なら計算特化、1対8以上ならメモリ特化に分類されます。ストレージは物理サーバー直結のローカルディスクを持つかどうか、ネットワークは帯域を上積みしたモデルがあるかどうかで枝分かれします。
この4要素のうち、後から変えにくいのはCPUアーキテクチャです。x86_64とArm64の間ではバイナリ互換がなく、コンテナイメージやコンパイル済みの依存ライブラリを作り直す必要があります。メモリとvCPUは停止して型番を変えれば増減できるため、初期構成では厳密に当てにいかず、稼働後の実測で当て直す前提で決めて構いません。
命名規則を1文字ずつ分解する手順：c7gn.xlargeとE96bds_v5の読み方
名前を読めるかどうかで選定速度が変わります。3クラウドとも命名規則を公式ドキュメントで定義しており、位置ごとの意味は固定されています。
EC2の系列・世代・プロセッサ文字・サイズの4区画とc7gn.xlargeの読み方
EC2のインスタンスタイプ名は、ピリオドの前がファミリー、後ろがサイズです。AWS公式のインスタンスタイプの命名規則では、1文字目にファミリー名、2文字目に世代、続いてプロセッサ文字と追加機能のオプション文字が並ぶと定義されています。c7gn.xlargeなら「計算特化（C）の第7世代（7）、AWS Gravitonプロセッサ（g）、ネットワークとEBSの強化（n）、サイズはxlarge」と読みます。
ファミリー名はM（汎用）・C（計算特化）・R（メモリ特化）・T（バースト可能）・I（ストレージ特化）・P／G（GPU）・Inf（Inferentia）・Trn（Trainium）・X／Z（ハイメモリ）など20種類近くが定義されています。プロセッサ文字はa（AMD）・g（Graviton）・i（Intel）の3つで、付いていない場合はその世代の既定プロセッサです。AWS単独でのファミリー選定やCLIでの絞り込み、稼働中インスタンスのタイプ変更手順はEC2インスタンスタイプの選び方：命名規則の読み方とCLI絞り込み・変更手順で詳しく扱っています。
Azure VMサイズのファミリ・付加機能文字・バージョンとE96bds_v5の読み方
Azureの構成はAWSより区画が多く、Microsoft Learnの名前付け規則では「［ファミリ］＋［サブファミリー］＋［vCPUの数］＋［制約付きvCPU］＋［付加機能］＋［アクセラレータの種類］＋［メモリ容量］＋［バージョン］」と定義されています。AWSと決定的に違うのは、vCPU数が名前の中に数字でそのまま入る点です。D4s_v5は4vCPU、E96bds_v5は96vCPUだと、スペック表を開かずに分かります。
付加機能の小文字は種類が多く、a（AMDプロセッサ）・d（ローカル一時ディスクを含む）・s（Premium SSDと互換）・p（ARMベース）・m（メモリ集中型）・l（メモリ比率が低い）・n（ネットワーク強化）・i（分離サイズ）などが定義されています。公式ドキュメントの例に従えばE96bds_v5は「ファミリEb・96vCPU・b（メモリ帯域）・d（ローカル一時ディスク）・s（Premium Storage対応）・第5世代」です。M8-2ms_v2のようにハイフンを挟む表記は制約付きvCPUを示し、8vCPUのハードウェア上で2vCPUに制限してライセンス費用を抑える用途に使います。Azure側の構成要素と料金モデルはAzure Virtual Machinesとは？仕組み・VMシリーズ・料金モデルと可用性設計にまとめています。
GCPのマシンシリーズとリソース比率・n2-standard-4の読み方
Google Cloudのマシンタイプ名は3区画のハイフン区切りで、最も読みやすい形式です。マシンファミリーのリソースと比較ガイドの定義では、n2-standard-4は「第2世代の汎用シリーズ（n2）、vCPU当たり4GBメモリのリソース比率（standard）、4vCPU」を表します。リソース比率の部分はstandardのほかhighcpu（CPU寄り）・highmem（メモリ寄り）があり、c4-highcpu-16やm3-highmem-64のように使われます。
シリーズ名の末尾文字がプロセッサの系統を示すのもAWSとは違う点です。公式ガイドではIntel系がN4・C4・X4・M4・A4、AMD系がC4D・N4D・G4・H4D、Arm系がN4A・C4A・A4Xと整理されています。第2世代ではN2に対するN2D（AMD）、T2Dに対するT2A（Arm）が同じ対応関係の例です。末尾にDが付けばAMD、Aが付けばArmという読み方を覚えておくと、シリーズ名だけでアーキテクチャの当たりが付きます。
| 観点 | AWS | Azure | Google Cloud |
|---|---|---|---|
| vCPU数の表記 | サイズ名（xlarge等） | 名前の中の数字 | 末尾の数字 |
| Armの示し方 | g（Graviton） | p（ARMベース） | シリーズ末尾のA |
| AMDの示し方 | a | a | シリーズ末尾のD |
| ローカルディスク | d | d | 別リソースで付与 |
| 世代の示し方 | 2文字目の数字 | 末尾のv5等 | シリーズ名の数字 |
3クラウドのCLIで候補一覧を取得してvCPUとメモリで絞り込む手順
候補が10種類を超えたら、コンソールの一覧を目で追うのはやめてCLIに切り替えます。同じ列で出力を揃えれば、そのまま比較表になります。
describe-instance-typesでvCPUとメモリ条件から候補を絞る手順
AWSではdescribe-instance-typesにフィルタを渡します。AWS CLI 2.37.0のコマンドリファレンスで定義されているフィルタ名のうち、選定で使うのはcurrent-generation（現行世代か）・vcpu-info.default-vcpus（vCPU数）・memory-info.size-in-mib（メモリ量）・processor-info.supported-architecture（アーキテクチャ）の4つです。東京リージョンで4vCPUのArm系現行世代を抽出するなら次のようになります。
aws ec2 describe-instance-types \
--region ap-northeast-1 \
--filters Name=current-generation,Values=true \
Name=vcpu-info.default-vcpus,Values=4 \
Name=processor-info.supported-architecture,Values=arm64 \
--query 'InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,VCpuInfo.DefaultThreadsPerCore,MemoryInfo.SizeInMiB]' \
--output tableDefaultThreadsPerCoreを出力に含めているのは意図的です。この値が1なら物理コアとvCPUが1対1、2ならハイパースレッドを1vCPUとして数えている型番だと判別でき、後述する突き合わせのずれを事前に潰せます。
az vm list-skusで対象リージョンのサイズを取得する手順と非推奨コマンド
Azureで最初に引っかかるのがコマンドの世代交代です。解説記事でよく見るaz vm list-sizesは、Azure CLIの公式リファレンスに「非推奨。このコマンドは非推奨となり、今後のリリースで削除される予定です。代わりに ‘az vm list-skus’ を使用してください」と明記されています。新しく手順書を書くならlist-skusを使ってください。
az vm list-skus \
--location japaneast \
--resource-type virtualMachines \
--query "[?starts_with(name,'Standard_D')].{Name:name, vCPU:capabilities[?name=='vCPUs'].value|[0], MemoryGB:capabilities[?name=='MemoryGB'].value|[0]}" \
--output tablelist-skusはサイズ一覧に加えてリージョンごとの提供状況や制限事項も返します。--locationで東京リージョン（japaneast）を指定すれば、そのリージョンに存在しないシリーズを最初から候補から外せます。移行先の設計では、この「そのリージョンに無い」が頻出の落とし穴です。
machine-types listでゾーン内のマシンタイプとvCPU数を列挙する手順
Google Cloudのマシンタイプはゾーン単位で提供されます。gcloud compute machine-types listに--zonesと--filterを渡し、--formatで列を指定すれば、AWS・Azureと同じ並びの表が得られます。
gcloud compute machine-types list \
--zones asia-northeast1-a \
--filter="guestCpus=4 AND name ~ ^n2-" \
--format="table(name, zone, guestCpus, memoryMb)"3クラウドとも出力列をvCPU数とメモリ量に揃えておくと、そのままスプレッドシートに貼って突き合わせられます。ここまでを1回作っておけば、次の案件では--regionや--zonesを差し替えるだけで再利用できます。
同等構成を突き合わせるときにずれる4観点とvCPU定義差の補正
対応表を作ると、そこで作業を終えたくなります。ただし名前の対応だけで見積りを出すと、あとから性能とコストの両方で外します。ずれが出る観点は4つあり、いずれも名前からは読み取れません。
vCPUがスレッド単位かコア単位かを名前から読めない問題と確認コマンド
同じ「4vCPU」でも、物理コア4つぶんの型番と、物理コア2つをハイパースレッドで4スレッドに見せている型番があります。CPUバウンドなバッチ処理では、この差がそのまま処理時間の差になります。名前には現れないため、前述のVCpuInfo.DefaultThreadsPerCoreのようなAPI上の値で確認するしかありません。
実務での補正はシンプルです。移行前後でスレッド数の前提が変わる可能性があるときは、vCPU数を揃えるのではなく、処理時間を実測して揃えます。ベンチマークを回す余裕がない案件では、CPUバウンドな処理に限って移行先を1段階大きい型番から始め、稼働後の使用率で落としていく進め方が安全です。
ローカルディスクの有無が名前の文字に現れる位置と見落とした場合の影響
AWSはd、Azureもdでローカルディスクの有無を示しますが、Google Cloudの汎用シリーズではローカルSSDを別リソースとして付与します。名前を突き合わせただけだと、移行先でローカルディスクが消え、一時ファイルの書き込み先がネットワーク越しのブロックストレージに変わります。
この見落としが効いてくるのは、データベースの一時表領域、ビルドキャッシュ、動画処理の中間ファイルなど、I/Oが処理時間を支配する場面です。移行前の構成でローカルディスクを使っているかどうかは、型番ではなくマウント状況で確認してください。使っていれば、移行先ではローカルディスク付きの型番を選ぶか、ブロックストレージのIOPSを明示的に積み増す必要があります。
バースト型のT系・B系・共有コアを同等扱いしたときの性能の落ち方
3クラウドとも、CPUを常時フル稼働させない前提の安価な型番を用意しています。AWSのT系、AzureのB系、Google Cloudのe2-microなど共有コアのマシンタイプがこれに該当する型番の例です。いずれもベースラインを超えて使い続けると、蓄積したクレジットを消費し尽くした時点で性能が頭打ちになります。
開発環境や社内向けの管理画面なら妥当な選択です。一方で、日次のバッチが数十分CPUを使い切るワークロードにバースト型を当てると、月末など負荷が集中した日だけ処理が終わらないという形で顕在化します。名前の上では同じ「2vCPU・8GiB」でも、バースト型と通常型を同じ行に並べないでください。突き合わせ表を作るときは、バースト型かどうかの列を必ず1本立てます。
受託開発でクラウドを横断して構成を決めるときの採用条件と見送り条件
ここからは判断です。3クラウドの対応表は便利ですが、作るコストに見合わない場面もあります。
名前の対応表だけで移行見積りを出してよい場面と実測が要る場面の線引き
対応表だけで進めてよいのは、Webサーバーやアプリケーションサーバーのように、CPU使用率が平均30%を下回り、ピークもオートスケールで吸収できる構成です。この層は多少の性能差が応答時間に出にくく、稼働後に型番を変えれば済みます。相見積りの段階で工数をかける価値は薄いと考えています。
実測が必要なのは、データベース、バッチ処理、機械学習の学習・推論の3つです。いずれもCPUかI/Oが処理時間を直接決めるため、型番の差が費用の差ではなく業務の締め切りに跳ね返ります。この3つを含む案件では、見積り段階で移行先の候補を2つに絞り、実データの一部で処理時間を測ってから構成を確定させる手順です。クラウド移行全体の進め方と費用試算の組み立てはクラウド移行の進め方｜7Rの選び方から費用試算・切り替えまでの手順で発注者視点から整理しています。
3クラウド比較を持ち込むべきでない場面とAWS単独に絞る判断の条件
既にどれか1つのクラウドで本番が動いており、運用チームのスキルもそこに寄っている場合、3クラウド比較は持ち込みません。型番の差で浮く月額数万円より、監視・バックアップ・IAM設計を2系統覚える負担のほうが確実に高くつきます。社内に運用担当が1人しかいない体制なら、比較検討そのものを見送ってよい場面です。
逆に、親会社の方針でAzureが指定されている、GPUの在庫状況で候補を分散させたい、といった制約があるときは、最初から3クラウドの型番を並べて設計します。私たちがインフラ構築の案件で使っているのも、ここまでに示したCLI出力を揃えて比較表にする手順です。クラウドをまたぐ構成設計や移行の実装で手が足りない場合は、AWS・Google Cloud・Azureのインフラ構築支援で要件整理から対応しています。
よくある質問
インスタンスタイプの選定でつまずきやすい点を5つにまとめました。
インスタンスタイプとインスタンスは何が違いますか？
インスタンスは起動した仮想サーバーそのもの、インスタンスタイプはその仮想サーバーのスペックを定義した型番です。1つのインスタンスタイプから何台でもインスタンスを起動できます。なお「インスタンス」という語はデータベース製品やオブジェクト指向プログラミングでも使われ、それぞれ意味が異なります。クラウドの文脈では仮想サーバー1台を指すと考えてください。
AWSのt3.mediumはAzureとGoogle Cloudでは何に相当しますか？
vCPU数とメモリ量だけで機械的に対応させるなら、2vCPU・4GiBのバースト型という条件が近いものになります。ただし各社のバースト方式は蓄積の単位も上限も異なるため、公式に「同等」と定義された対応表は存在しません。本番で使う場合は、vCPUとメモリの数値を合わせるだけでなく、バースト型かどうかとベースライン性能を個別に確認してください。
インスタンスタイプの一覧は各クラウドのどこで確認できますか？
AWSはaws ec2 describe-instance-types、Azureはaz vm list-skus、Google Cloudはgcloud compute machine-types listで、それぞれリージョンやゾーンを指定して取得できます。コンソールの一覧画面でも確認できますが、リージョンごとの提供有無やvCPU数で絞り込むならCLIのほうが速く、条件の取りこぼしもありません。
Arm系のインスタンスタイプに変えるとコストは下がりますか？
AWSのGraviton、Azureのp付きサイズ、Google CloudのArm系シリーズは、同等スペックのx86系より単価が低く設定されている型番が多くあります。ただしx86_64向けにビルドしたバイナリやコンテナイメージはそのまま動きません。マルチアーキテクチャ対応のイメージを作り直す工数と、依存ライブラリがArm64に対応しているかの調査を先に見積もってください。移行のコストを回収できるのは、常時稼働させる規模の大きい環境です。
3クラウドで同じ構成を組むと料金も同等になりますか？
同じvCPU数・メモリ量でも料金は一致しません。単価そのものに差があるうえ、長期利用の割引制度（AWSのSavings Plans、Azureの予約インスタンス、Google Cloudの確約利用割引など）の条件や割引率がそれぞれ違うためです。比較するときはオンデマンド単価だけを並べず、想定する稼働時間と契約期間を決めたうえで、各社の料金ページで実額を取得して突き合わせてください。
関連記事
- EC2インスタンスタイプの選び方：命名規則の読み方とCLI絞り込み・変更手順：AWS単独でのファミリー選定・Compute Optimizerの読み方・稼働中のタイプ変更手順
- Azure Virtual Machinesとは？仕組み・VMシリーズ・料金モデルと可用性設計：Azure側のVMサイズと可用性ゾーン設計をまとめた記事
- Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断：EC2そのものの構成要素と5つの料金モデル
- インスタンスとは？クラウドの仮想サーバーからオブジェクト指向・DBまで領域別に解説：用語としての「インスタンス」を領域別に整理
- クラウド移行の進め方｜7Rの選び方から費用試算・切り替えまでの手順：移行全体の進め方と費用試算の組み立て
