Azure VM は、単に仮想マシンを作成するだけのサービスではありません。 作成元、VM サイズ、性能上限、ディスク、ファイル共有、冗長化、バックアップ、災害対策を組み合わせて設計することで、安全で高可用なシステムを構成できます。 このページでは、Azure VM の設計で重要な考え方を 12 枚の図で整理します。
Azure VM 設計の要点を 12 の図で解説します。気になる項目からジャンプできます。
Azure VM は、コンピューティング（VM本体）、ディスク、ネットワーク、ストレージ、可用性、保護（バックアップ／DR）といった複数の要素を組み合わせて成立します。まずは「VM単体」ではなく「システム全体」として捉えることが設計の出発点です。
設計時の注意点：いきなりVMサイズから決めると、後段のディスク性能・冗長化・バックアップと整合が取れなくなります。全体像を先に固定してください。
Azure VM は、Marketplace イメージ、独自のカスタムイメージ（マネージドイメージ／Azure Compute Gallery）、スナップショットや専用ディスクなど、複数の「作成元」から起動できます。作成元の選び方が、展開スピードと標準化のしやすさを左右します。
設計時の注意点：使い捨てのマネージドイメージだけで運用すると、世代管理やリージョン跨ぎの配布で破綻しがちです。継続運用は Compute Gallery を検討してください。
VMサイズ（SKU）は vCPU とメモリだけでなく、最大 IOPS・最大スループット・NIC数・データディスク本数・アクセラレーテッドネットワーク対応などの「上限」も同時に決めます。ディスクをいくら速くしても、VMサイズ側の上限で頭打ちになります。
設計時の注意点：VM側の上限 < ディスク側の性能、という組み合わせだと投資が無駄になります。VMサイズとディスク性能は必ずセットで確認してください。
Azure VM は用途特性ごとにシリーズが分かれています。まず「どの特性が必要か」でシリーズを選び、その中でサイズ（vCPU／メモリ）を決めるのが失敗しない手順です。
| シリーズ | 分類 | CPU:メモリ | 主な用途 | 代表例 |
|---|---|---|---|---|
| B | バースト可能 | 可変 | CPUを常時は使い切らない用途向け。普段は低負荷で、時々スパイクする小規模Web・開発／テスト・検証環境に最適。CPUクレジットを貯めて必要時にバーストします。 | B2s, B4ms |
| D | 汎用 | 1 : 4 | CPUとメモリのバランス型。多くの本番ワークロードの標準選択。Webサーバー、アプリケーションサーバー、中小規模データベース、業務システム全般に向きます。 | D4s_v5, D8s_v5 |
| E | メモリ最適化 | 1 : 8 | CPUに対しメモリが多い構成。大規模データベース、インメモリキャッシュ、SAP、メモリを多く消費する分析・集計処理に向きます。 | E8s_v5, E16s_v5 |
| F | コンピューティング最適化 | 1 : 2 | メモリに対しCPUが強い構成。バッチ処理、Web／アプリサーバー、ゲームサーバー、アプリケーションビルドなどCPU負荷の高い処理に向きます。 | F8s_v2, F16s_v2 |
| L | ストレージ最適化 | 高IOPS | ローカルNVMeによる大容量・高IOPS・低レイテンシI/O。NoSQL（Cassandra／MongoDB）、大規模トランザクションDB、データウェアハウス、ビッグデータに向きます。 | L8s_v3, L16s_v3 |
| M | 大容量メモリ | 超大容量 | 数TB級の超大容量メモリを搭載。大規模SAP HANA、超大規模インメモリデータベースなど、極端にメモリを要するミッションクリティカル用途向けです。 | M64s, M128s |
| N | GPU | GPU搭載 | GPUアクセラレーション用。NC＝AI学習・数値計算、ND＝大規模ディープラーニング、NV＝可視化・仮想デスクトップ・レンダリングと、目的別にサブシリーズを選びます。 | NC, ND, NV |
| H | HPC（高性能計算） | 高性能 | 科学技術計算向けの高性能コンピューティング。流体解析、数値シミュレーション、分子モデリング、気象・地震解析など大規模並列計算に向きます。 | HB, HC |
設計時の注意点：シリーズ名の末尾の s は Premium SSD 対応、v3/v5 などは世代を表します。まず用途でシリーズを決め、次に世代は原則新しいものを選ぶとコスト効率と性能のバランスが取りやすくなります。
VMが扱うストレージは、OS/データディスク（ブロック）、共有ファイル（Azure Files / Azure NetApp Files）、オブジェクト（Blob）など役割が分かれます。「誰が」「どのプロトコルで」「どの性能で」アクセスするかで最適な選択肢が変わります。
設計時の注意点：何でもデータディスクに載せると、共有・スケール・コストで詰まります。共有要件があるならファイルサービスを最初から検討してください。
VMには、OSディスク、データディスク、そして一時ディスク（テンポラリ）があります。一時ディスクは高速ですが、再起動・再配置で内容が消える揮発性ストレージです。永続化が必要なデータを置いてはいけません。
設計時の注意点：一時ディスクにデータやページファイル依存の重要データを置くと、メンテナンス再配置で消失します。永続データは必ずデータディスクへ。
Managed Disk は Ultra Disk / Premium SSD v2 / Premium SSD / Standard SSD / Standard HDD などの種類があり、IOPS・スループット・レイテンシ・コストが異なります。ワークロードのI/O特性に合わせて種類とサイズを選びます。
設計時の注意点：コスト優先で Standard HDD を本番DBに使うと、レイテンシで性能問題が顕在化します。I/O要件から逆算して種類を決めてください。
ストレージの冗長化は、単一データセンター内で3重化する LRS と、複数の可用性ゾーンにまたがって冗長化する ZRS が基本です。ゾーン障害まで耐えたいなら ZRS を選び、可用性設計と合わせて考えます。
設計時の注意点：「冗長化=バックアップ」ではありません。LRS/ZRSはインフラ多重化であり、誤削除・ランサム対策にはBackup/Snapshotが別途必要です。
複数VMからの共有には Azure Files（SMB/NFS のフルマネージド共有）と Azure NetApp Files（高性能・低レイテンシなエンタープライズNAS）があります。性能・レイテンシ・機能要件が高いほど ANF が候補になります。
設計時の注意点：基幹の高IOPS共有をAzure Files標準ティアで組むとレイテンシが不足することがあります。要件が厳しい場合はANFを早期評価してください。
ストレージはアクセス方式で性格が変わります。Block（Managed Disk）は単一VMが占有する低レイテンシI/O、SMB は Windows 系の共有、NFS は Linux 系の共有に向きます。用途とOSに合ったプロトコルを選ぶことが重要です。
設計時の注意点：Blockディスクを複数VMで共有しようとする（Shared Disk以外で）と破損リスクがあります。共有目的なら最初からSMB/NFSを選んでください。
共有の実現手段は複数あります。Shared Disk（同一ディスクを複数VMで共有し、クラスタソフトで制御）、Azure Files、Azure NetApp Files。それぞれ前提条件と得意領域が異なるため、共有の目的から選定します。
設計時の注意点：Shared Disk はクラスタリング機構（SCSI PR対応）とセットの技術です。単なるファイル共有目的で選ぶとオーバースペック／設計過多になります。
可用性は「VMを2台置く」だけでは不十分です。入口のロードバランサー／ゲートウェイ、可用性ゾーン配置、複数インスタンス、データ層の冗長化までを一気通貫で設計して初めて、単一障害点のない構成になります。
設計時の注意点：アプリVMだけ2重化してもDBやファイル共有が単一だと、そこが単一障害点になります。全レイヤーで冗長化を揃えてください。
データ保護は目的で使い分けます。Snapshot は特定時点の複製（素早い復元）、Azure Backup は世代管理された定期バックアップ（誤削除・長期保持）、Azure Site Recovery(ASR) はリージョン障害に備えたレプリケーションと切替（DR）です。
設計時の注意点：Snapshotだけを“バックアップ”と誤解すると、世代管理や地理冗長が不足しDR要件を満たせません。目的別に3つを組み合わせて設計してください。
Azure VM は、VMサイズ、ディスク、ストレージ、冗長化、バックアップ、DRを一体で設計することで、安全で高可用なシステムになります。 新規構築、オンプレミスからの移行、性能・コスト最適化、バックアップ設計、可用性ゾーンを使った冗長化設計、ASR による災害対策まで、幅広くご相談いただけます。