オンプレミス環境でVMware ESXiやHyper-Vを使って仮想化を運用してきたエンジニアが、クラウド移行を検討するとき、必ずといっていいほど直面する疑問があります。「コンテナってVMと何が違うの？DockerやKubernetesは使わないといけないの？」この記事では、仮想マシン（VM）とコンテナの違いをオンプレ経験者の視点からわかりやすく整理します。アーキテクチャの根本的な差から、AWS・AzureにおけるEC2・ECS・AKSの使い分けまで、現場で役立つ判断軸を体系的に解説します。
なぜ今「コンテナ」が注目されるのか
VMwareを使ってきた人であれば、仮想マシンの概念は直感的に理解できます。物理サーバーの上にハイパーバイザー（ESXiやHyper-V）を置き、その上でゲストOSを含む複数のVMを動かす。オンプレの現場ではこの構成が長年スタンダードでした。
コンテナが登場した背景には、VMが抱える「重さ」の問題があります。VMはゲストOSを完全に含むため、1台あたり数GB以上のメモリを消費し、起動にも数分かかることがあります。一方でマイクロサービスアーキテクチャのように「小さな機能を独立してデプロイしたい」というニーズが高まると、VMの重さは大きな障壁になります。
Dockerが2013年に登場してからコンテナ技術は急速に普及し、2017年以降のKubernetesの台頭で、クラウドの本番環境における「コンテナ前提の設計」が当たり前になってきました。AWS・Azure・GCPのマネージドKubernetesサービス（EKS・AKS・GKE）の充実がそれを後押ししています。
アーキテクチャの根本的な違い
VMとコンテナの違いを理解するには、スタックの構造を比較するのが一番わかりやすいです。
1. 仮想マシン（VM）のスタック
| レイヤー | 内容 |
|---|---|
| 物理サーバー / クラウドホスト | 実際のハードウェアまたはクラウドインフラ |
| ハイパーバイザー | VMware ESXi / Hyper-V / KVM |
| ゲストOS（VM単位） | 各VMに独立したOS（例: Ubuntu、Windows Server） |
| ミドルウェア・アプリ | Apache、Java、Pythonランタイムなど |
各VMは独立したOSカーネルを持ちます。これにより「ゲストOS同士が完全に隔離された環境で動く」という強固な分離が実現しますが、その分オーバーヘッドも大きくなります。
2. コンテナのスタック
| レイヤー | 内容 |
|---|---|
| 物理サーバー / クラウドホスト | 実際のハードウェアまたはクラウドインフラ |
| ホストOS（1つ） | 例: Linux（Ubuntu 22.04、Amazon Linux 2023） |
| コンテナランタイム | Docker Engine / containerd / CRI-O |
| コンテナ（アプリ単位） | Linuxのnamespace / cgroupで隔離された軽量プロセス |
コンテナはホストOSのカーネルを共有します。Linuxのnamespaceでプロセス・ネットワーク・ファイルシステムを隔離し、cgroupでCPU・メモリの使用量を制限する仕組みです。OSカーネルを共有するため、VMと比べて起動が圧倒的に速く（秒オーダー）、リソース消費も少なく済みます。
ポイント: コンテナは「OSを仮想化する」のではなく、「アプリの実行環境を隔離する」技術です。
VM vs コンテナ：主要項目の比較表
| 比較項目 | 仮想マシン（VM） | コンテナ |
|---|---|---|
| 起動時間 | 数十秒～数分 | 数秒以内（多くは1秒以下） |
| イメージサイズ | 数GB（OSを含む） | 数十MB～数百MB（軽量） |
| OS隔離 | 完全隔離（独立カーネル） | ホストOSカーネルを共有 |
| セキュリティ境界 | 強固（ハイパーバイザー分離） | namespaceで隔離（VM比でやや弱い） |
| ポータビリティ | OVAイメージ（サイズが大きい） | Dockerイメージ（軽量・高速転送） |
| 同一ホスト上の密度 | 数台～数十台程度 | 数百～数千コンテナが可能 |
| OSの選択 | Windows・Linux問わず自由 | 原則Linuxベース（Windows Containerも存在） |
| オーケストレーション | vSphere、AWS Auto Scaling Group | Kubernetes（EKS・AKS・GKE） |
クラウドにおける「VM = EC2」「コンテナ = ECS / EKS」の対応
AWSに置き換えると次のように整理できます。
1. Amazon EC2（クラウドのVM）
Amazon EC2は仮想マシンそのものです。オンプレのVMware上に立てたLinuxサーバーと、操作感はほぼ同じです。SSH接続して設定を行い、Apacheやnginxを手動でインストールする使い方ができます。
クラウド上のVMならではの強みは、インスタンスタイプを変更してCPU・メモリを即座にスケールアップできる点と、AMIを使ってVM丸ごとのバックアップ・複製が簡単にできる点です。
2. Amazon ECS（EC2上またはFargate上でコンテナを動かす）
Amazon ECS（Elastic Container Service）は、Dockerコンテナを管理するオーケストレーターです。「タスク定義」でコンテナの仕様（イメージ・CPU・メモリ）を定義し、「サービス」で何台起動するかを制御します。
バックエンドとしてEC2を使う場合とAWS Fargate（サーバーレスコンテナ）を使う場合の2択があります。Fargateを選ぶとEC2インスタンスの管理が不要になり、コンテナの実行時間と使用リソースだけで課金されます。
3. Amazon EKS / Azure AKS（Kubernetesによるコンテナ管理）
規模が大きくなる、またはKubernetesのエコシステムを活用したい場合はAmazon EKS（Elastic Kubernetes Service）やAzure AKS（Azure Kubernetes Service）を選びます。Kubernetesはコンテナのスケジューリング・ヘルスチェック・オートスケーリング・ローリングアップデートを宣言的に管理できるプラットフォームです。
Azureに対応させると、Azure Virtual MachinesがEC2相当、Azure Container Instances（ACI）がFargate相当、AKSがEKS相当です。
# AWS CLI: ECSタスク定義の一覧確認 aws ecs list-task-definitions --region ap-northeast-1 # ECSサービスの状態確認（東京リージョン） aws ecs describe-services \ --cluster my-cluster \ --services my-service \ --region ap-northeast-1 # EKSクラスターのノード一覧を確認 kubectl get nodes -o wide # Dockerイメージのサイズ一覧確認 docker image ls --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"
どちらを選ぶべきか：現場での判断軸
「コンテナを使うべきか、VMのままでいいか」はワークロードの性質によって変わります。
1. VMが適しているケース
・WindowsアプリをそのままEC2で動かしたい: レガシーな.NETアプリや社内業務システムはコンテナ化コストが高く、EC2やAzure Virtual Machinesで動かす方が現実的
・特定OSカーネルへの依存がある: カーネルモジュールやデバイスドライバを使うワークロード
・強固なセキュリティ隔離が必要: PCI-DSSやHIPAAなど厳格なコンプライアンス要件がある場合
・ステートフルなDBサーバー: Oracle DBやSQL Serverなど状態を持つDBはVM上で管理する方が安定
2. コンテナが適しているケース
・マイクロサービス化を進めている: 機能ごとに独立してデプロイ・スケールしたい
・デプロイ頻度が高い: CI/CDパイプラインとコンテナは相性がよく、イメージビルド→プッシュ→デプロイの自動化が容易
・環境差異（dev / stg / prod）をなくしたい: 「自分のPC（開発環境）では動いたのに本番で動かない」問題をDockerイメージで解消できる
・コスト効率を高めたい: 1台のEC2上に複数のコンテナを詰め込むことでリソース効率が向上する
3. VMとコンテナを組み合わせるハイブリッド構成
現実の現場では、VMとコンテナの二択ではなく組み合わせが主流です。たとえば「DBはAmazon RDS（マネージドVM相当）、APIサーバーはECS（コンテナ）」という構成は非常に一般的です。Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。コンテナ環境で動かすLinuxスキルと合わせて習得することで、クラウド移行の現場で即戦力になれます。
料金の考え方（2026年3月時点）
1. EC2（VM）のコスト構造
Amazon EC2はインスタンスが起動している時間に対して課金されます。東京リージョン（ap-northeast-1）でt3.medium（2vCPU / 4GB）をオンデマンドで使うと、約$0.0544/時間（2026年3月時点）です。24時間×30日で約$39/月になります。使用しない時間はインスタンスを停止することで課金を抑えられますが、Amazon EBSストレージ料金は停止中も発生します。
2. ECS / Fargate のコスト構造
AWS Fargateはコンテナが実際に動作している時間のvCPUとメモリに対して課金されます（東京リージョン、2026年3月時点）。
・vCPU: $0.04048 / vCPU時間
・メモリ: $0.004445 / GB時間
0.25vCPU / 0.5GBのコンテナを24時間稼働させると約$0.25/日です。小規模ワークロードでは手軽に始められますが、大規模になるとEC2 Savings Plansを組み合わせた方がトータルコストを抑えられるケースがあります。
3. EKS（Kubernetes）のクラスター費用
Amazon EKSはクラスターのコントロールプレーンに$0.10/時間（約$72/月）の固定費がかかります（2026年3月時点）。ノード（EC2またはFargate）は別途課金です。少量ワークロードには割高になるため、複数サービスを管理する規模になって初めてコストに見合う価値が出てきます。
よくあるトラブルと注意点
1. 「コンテナ化すれば万事解決」という誤解
コンテナはあくまでツールであり、設計の問題は解決しません。モノリシックなアプリをそのままDocker化しても、デプロイ速度やスケーラビリティは大きく改善しません。コンテナの恩恵を受けるには、アプリ側のステートレス設計が前提になります。
2. コンテナセキュリティの過小評価
コンテナはホストOSカーネルを共有するため、カーネルの脆弱性の影響を受けやすい側面があります。ホストOSのカーネルアップデートとコンテナイメージのベースイメージ更新を定期的に行う必要があります。Amazon InspectorはAmazon ECRイメージの脆弱性スキャンを自動化できるため、ECSやEKS環境では積極的に活用すべきです。
3. ステートフルな処理をコンテナ内部に持ち込むリスク
コンテナは「スケールアウト・スケールイン」を前提とした設計です。セッション情報や一時ファイルをコンテナ内部に持たせると、コンテナが再起動したときにデータが消えます。セッション管理はAmazon ElastiCacheに外出しし、ファイルはAmazon S3やAmazon EFSに保存する設計が基本です。
4. オンプレからの移行でOSの差異に注意
オンプレのRHEL系（CentOS、Rocky Linux）で動かしていたアプリをDebian / Ubuntu系のコンテナに乗せると、パッケージ名やサービス管理コマンドの差異でトラブルが起きることがあります。ベースイメージは本番環境のOSに揃えるか、alpine系など最小構成にする判断が必要です。
本記事のまとめ
・VMはOSレベルの完全隔離、コンテナはLinuxのnamespace / cgroupを使った軽量隔離という根本的な違いがある
・起動速度・リソース効率・ポータビリティでコンテナが優れ、セキュリティ隔離・Windowsアプリ対応・ステートフルDBではVMが有利
・AWSではAmazon EC2（VM）、Amazon ECS / Fargate（コンテナ）、Amazon EKS（Kubernetes）の3層を使い分ける
・現場ではVMとコンテナを組み合わせるハイブリッド構成が現実的
・コンテナ化の前提はアプリのステートレス設計——コンテナは道具であり、設計の代わりにはならない
VMからコンテナへの移行、どこから手をつければいいか迷っていませんか？
「理屈はわかったけど、実際の移行設計はどう進めるべき？」という疑問に、現場視点でお答えします。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
