Amazon EC2徹底解説：GCP Compute Engine・Azure VMとの実務比較で迷わない仮想サーバー設計

はじめに（要点サマリー）

本記事は、AWSのAmazon EC2を中心に、Google Compute Engine（GCE）とAzure Virtual Machines（Azure VM）の同等機能比較までをまとめた、現場でそのまま使える実務ガイドです。
先に結論：**可用性と拡張性の“王道IaaS”**はEC2を核に、Auto Scaling Group＋ELB＋Launch Templateで標準化するのが安定。**GCEはカスタムマシンタイプ（vCPU/メモリの細粒度指定）**が強み、AzureはAD/AADや仮想ネットワーク統合が自然で企業ガバナンスに馴染みます。
設計の肝は、インスタンス選定・ストレージ設計・ネットワーク/セキュリティ・スケーリング/可用性・運用自動化の5点。
いますぐ使えるCLIサンプル（EC2/GCE/Azure VMの3クラウド対比）、ユーザーデータ（cloud-init）、ASG/スケール設計の型、運用チェックリストを収録しました。
読者像：情報システム部門のクラウド移行担当、Web/業務アプリ開発者、SRE/インフラエンジニア、セキュリティ/ガバナンス担当、スタートアップの技術リーダー。オンプレVMのリフト＆シフトから、モダンなスケール設計までの全体像を素早く掴みたい方向けです。

1. Amazon EC2とは：IaaSの基本から“いま使うべき型”まで

Amazon Elastic Compute Cloud（EC2）は、仮想サーバー（IaaS）をオンデマンドで提供するサービスです。AMI（マシンイメージ）を元にインスタンスを起動し、VPC/サブネット/セキュリティグループでネットワーク境界を定義します。
近年のEC2はNitroベースの仮想化が一般化しており、安定した性能・セキュアな分離・柔軟なENA（高速ネットワーク）を前提に設計できます。可用性は複数AZ分散を基本とし、Auto Scaling Group（ASG）とElastic Load Balancing（ELB）を組み合わせることで、障害時の自己回復と需要変動への追従が容易になります。

実務では、Launch Templateで起動パラメータ（AMI/タイプ/ディスク/ユーザーデータ/ロール）を標準化し、ASGで最小・希望・最大の台数管理、ターゲット追跡スケーリングでCPUやリクエストレイテンシの目標値に合わせて自動変動させる構成が“定番”です。

2. 代表ユースケース（設計の型と比較観点）

Web/APIの可用性重視クラスター
- ASG＋ALB（HTTP/HTTPS）でスケール、複数AZへ分散。ストレージはEBSルート＋外部状態はRDS/ElastiCache/EFSへ。
- GCEならManaged Instance Group（MIG）＋HTTP(S) Load Balancing、AzureならVirtual Machine Scale Sets（VMSS）＋Application Gateway/Front Doorが同等の型です。
バッチ処理・ジョブ実行
- Spotインスタンスでコストを圧縮。中断に強いワークロード（MapReduce、動画変換）に最適。
- GCEのSpot VM、AzureのSpot VMも同発想。再実行戦略とチェックポイント設計が鍵。
HPC/機械学習
- 高帯域ネットワーク・GPU/高速ストレージが必要。Placement Groupや専用ホストでノイズ分離。
- GCPのA2/A3系やAzureのHB/HC/ND/NC系に相当。選定はネットワーク帯域・GPU世代・ストレージスループットを重視。
業務サーバーのリフト＆シフト
- まずは**単一AZ×ASG（最小1/最大1）で自己回復性を確保。OS/パッチ配布にSystems Manager（SSM）**を使うと運用が楽になります。
- GCEはOS Config、AzureはUpdate Management/Automationで同等の運用が可能。

3. インスタンス選定：迷わない5ステップ

目的に合うファミリーと適正サイズを選ぶと、性能とコストのバランスが整います。

ファミリー選定
- 汎用（General Purpose）：均衡型。多くのWeb/APIに適合。
- 計算最適化（Compute Optimized）：CPU集約処理。アプリサーバー/ゲームサーバーなど。
- メモリ最適化（Memory Optimized）：インメモリDB/キャッシュ/大規模解析。
- ストレージ最適化（Storage Optimized）：ローカルNVMeが必要なOLAP/ログ処理。
- アクセラレーテッド（GPU/FPGAなど）：AI学習/推論、GPUレンダリング。
ストレージ方式
- EBS（永続ブロック）か、インスタンスストア（高速・非永続）か。
- ルートはEBSを基本。一時ファイルやキャッシュのみインスタンスストアを検討。
ネットワーク性能
- 必要帯域/ppsに応じてENA対応サイズや拡張ネットワークを選定。
可用性要件
- 複数AZ前提でASGを組むか、専用ホスト/専有インスタンスでノイズ分離を優先するか。
料金モデル
- オンデマンドで検証→Savings Plans/RIで平常稼働を最適化→Spotでバーストやバッチを吸収。

GCE比較：カスタムマシンタイプでvCPU数/メモリGBを細かく指定可能。Azure比較：SKU（サイズ）の選択肢が豊富で、Proximity Placement Groupなどレイテンシ最適化の機能が充実。

4. ストレージ設計：EBS/インスタンスストア/EFS/FSxの使い分け

EBS（Elastic Block Store）
- 種別：汎用SSD（gp系）／プロビジョンドIOPS（io系）／スループット最適化（st）／**コールドHDD（sc）**など。
- ルート/データディスクに最適。スナップショットで世代管理。暗号化は基本オン。
インスタンスストア
- 物理的に直結された高速NVMe。非永続なので再起動/停止で消える。
- 一時領域・シャッフル・キャッシュに限定して利用。
EFS（NFS互換の共有ファイル）/FSx（Windows/Lustre/ONTAP等）
- アプリ間で共有が必要ならEFS/FSx。スループット/遅延要件で使い分け。

GCE：Persistent Disk（PD）にStandard/SSD/Extremeなど。Local SSDは超低遅延だが非永続。
Azure：Managed Disks（Standard HDD/SSD、Premium/Ultra）。Azure Filesで共有を提供。

5. ネットワーク＆セキュリティ：まず固める“4点セット”

VPC/サブネット
- プライベートサブネット＋NAT/プロキシで外部通信。パブリックサブネットは最小限。
セキュリティグループ（SG）
- ステートフルな仮想ファイアウォール。最小許可を貫く。NACLはCIDR単位の補助的コントロール。
アイデンティティ
- IAMロール（インスタンスプロファイル）で資格情報を埋め込まない。IMDSv2を強制。
運用アクセス
- SSM Session Managerで踏み台レスなシェル/ポートフォワード。鍵配布と踏み台の管理を廃止可能。

GCE：VPC/Firewall、サービスアカウントをインスタンスに付与。OS LoginでIAM連携が簡潔。
Azure：VNet/NSG/ASG、Managed Identityで資格情報を排除。Bastion/Just-In-Timeで安全接続。

6. 可用性・スケーリング：ASG＋ELBを“標準装備”に

Auto Scaling Group（ASG）
- ヘルスチェックで障害インスタンスを自動置換。スケジュール/ターゲット追跡/ステップなどのポリシー。
Elastic Load Balancing（ALB/NLB/GWLB）
- ALB：L7。HTTP/HTTPS、パス/ホストベースルーティング。
- NLB：L4。超低遅延・固定IP。gRPC/高スループットに強い。
マルチAZ/マルチリージョン
- AZ分散は必須。リージョン跨ぎはRoute 53/ヘルスチェックとデータレプリケーションの設計が鍵。

GCE：Managed Instance Group＋Cloud Load Balancing（グローバルHTTP(S)）。
Azure：VMSS＋Application Gateway/Load Balancer/Front Door。

7. 自動化・ブートストラップ：反復可能な“起動の儀”

Launch Template＋ユーザーデータ（cloud-init）で宣言的初期化。
AMIベイク（Packerなど）で時間のかかるセットアップを事前焼き込み、起動時間を短縮。
Systems Manager（State Manager/Run Command/Patch Manager）で構成・パッチの標準化。

GCE：Startup Script/Metadata、Instance Templates。
Azure：VM Extensions（Custom Script）、イメージギャラリー。

8. 監視・運用・トレーサビリティ

CloudWatch：メトリクス（CPU/ネットワーク/ディスク）とAgentでOSメトリクス/ログ収集。
CloudTrail：API操作の証跡。インスタンス/ネットワーク/鍵操作を追跡。
SSM：インベントリ/脆弱性/パッチ可視化。
アラート：SLO/SLIを先に決め、アラート閾値ではなくユーザ体験に結び付く指標（p95レイテンシ等）を重視。

GCE：Cloud Monitoring/Logging、Ops Agent。
Azure：Azure Monitor/Log Analytics、Diagnostic Settings。

9. コスト最適化：ブレない打ち手

権利サイズ最適化（Rightsizing）：CPU/メモリ/ディスク/ネットワーク使用率を計測し、ひと回り下に。
料金モデルの併用：
- オンデマンド…開発/実験。
- Savings Plans/Reserved Instances…常時稼働。
- Spot…バースト/バッチ。
スケジュール停止：夜間・休日は自動停止。
外部状態を外出し：インスタンスをステートレス化し、スケールダウンや置換を容易に。
ストレージ最適化：EBS種別の見直し、汎用SSDのIOPS調整、不要スナップショット削除。

GCE：Committed Use Discount＋Spot、Sustained Use Discount（長時間自動割引）。
Azure：Reserved VM Instances＋Spot、自動停止/スケジュールで同様に効きます。

10. 3クラウド対応での“言い換え”早見（運用の会話を滑らかに）

起動定義：Launch Template（EC2）／Instance Template（GCE）／VMSSのModel＋Image（Azure）
自動スケール：ASG（EC2）／MIG（GCE）／VMSS（Azure）
L7ロードバランサ：ALB（EC2）／HTTP(S) LB（GCE）／Application Gateway（Azure）
資格情報の受け渡し：IAMロール（EC2）／サービスアカウント（GCE）／Managed Identity（Azure）
踏み台レス接続：SSM Session Manager（EC2）／IAP+OS Login（GCE）／Bastion/Just-in-Time（Azure）

11. 実務サンプル（3クラウド対比で“手が動く”）

11.1 EC2 起動（最小構成・ユーザーデータ付き）

# 1) セキュリティグループ（80/22を例示。22はSSM運用なら省略推奨）
aws ec2 create-security-group \
  --group-name web-sg --description "web sg" --vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxx --protocol tcp --port 80 --cidr 0.0.0.0/0

# 2) キーペア（SSM運用なら作成不要）
aws ec2 create-key-pair --key-name web-key > web-key.pem && chmod 400 web-key.pem

# 3) 起動（Launch Templateを使わない最短例）
cat > user-data.sh <<'EOF'
#cloud-config
packages:
  - nginx
runcmd:
  - systemctl enable nginx
  - systemctl start nginx
EOF

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type t3.small \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx \
  --iam-instance-profile Name=ec2-app-role \
  --user-data file://user-data.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-1}]'

11.2 GCE（同等の最短デプロイ）

gcloud compute instances create web-1 \
  --zone=asia-northeast1-b \
  --machine-type=e2-small \
  --metadata=startup-script='#!/bin/bash
sudo apt -y update && sudo apt -y install nginx
sudo systemctl enable nginx && sudo systemctl start nginx' \
  --tags=http-server

11.3 Azure VM（同等の最短デプロイ）

az group create -n rg-web -l japaneast
az vm create -g rg-web -n web-1 \
  --image UbuntuLTS --size Standard_B1ms \
  --custom-data cloudinit.yaml \
  --admin-username azureuser --generate-ssh-keys
az vm open-port -g rg-web -n web-1 --port 80
# cloudinit.yaml は EC2のcloud-configとほぼ同等

11.4 Auto Scaling（EC2：Launch Template＋ASG＋ALB要点）

# Launch Template
aws ec2 create-launch-template \
  --launch-template-name web-lt \
  --launch-template-data '{
    "ImageId":"ami-xxxxxxxxxxxxxxxxx",
    "InstanceType":"t3.small",
    "IamInstanceProfile":{"Name":"ec2-app-role"},
    "SecurityGroupIds":["sg-xxxxxxxx"],
    "UserData":"'"$(base64 -w0 user-data.sh)"'"
  }'

# Auto Scaling Group（2AZ分散、ターゲット追跡でCPU50%）
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-lt \
  --min-size 2 --max-size 6 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-a,subnet-b"

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu50 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'

12. セキュリティと運用ガバナンス：実務の“標準ルール”

公開境界の明確化：ALBはパブリック、EC2はプライベート。直接のインターネット公開は避ける。
資格情報ゼロ：IAMロール/Managed Identity/サービスアカウントを必ず使用。環境変数やファイルにキーを置かない。
IMDSv2/メタデータ保護：SSRF対策として必須。GCE/Azureもメタデータアクセスの制御を行う。
パッチ運用：SSM Patch Manager等で定期スケジュール。緊急時はブルー/グリーンで段階適用。
ログの一元化：アプリログはCloudWatch Logs（またはGCE/Azureの相当）へ。構造化ログを前提に可観測性を高める。

13. 可用性設計の実践：3パターン

標準Web三層
- ALB→ASG（アプリ）→RDS/EFS/ElastiCache。スケールアウトが基本。
ステートレスAPI＋外部認証
- ALB＋Cognito/IdPで認証、ASGはイミュータブルデプロイで差分を残さない。
HPC/低レイテンシ
- Placement Group（Cluster/Spread/Partition）を選択。ストレージはインスタンスストア＋並列FS。

GCE/Azureでも、LB＋スケール群＋外部状態（DB/Cache）の分離という骨子は同じです。

14. よくある落とし穴と回避策

単一AZ運用のまま本番化：障害時に全停止。ASG＋複数AZを“最低ライン”に。
踏み台サーバーの長期放置：脆弱化の温床。SSM Session Manager/IAP/BastionのJITに移行。
インスタンスに秘密情報：環境変数やファイルに鍵。Parameter Store/Secrets Manager/Key Vault/Secret Managerへ移管。
ローカルに状態を持つ：スケール不可に。EBS/EFS/オブジェクトストレージ/外部DBへ分離。
スナップショット無計画：世代/保持期間/タグを決めて運用。不要分は定期削除。
監視の“後追い”：ローンチ前にSLO/SLI/アラートを先に定義。

15. 設計チェックリスト（初週で必ず固める）

目標：可用性（AZ分散）/性能（p95）/回復時間/運用境界を数値で定義。
インスタンス：ファミリー・サイズ・料金モデル、AMI管理、ユーザーデータ。
ストレージ：EBS種別/IOPS/スナップショット/暗号化、共有FS要否。
ネットワーク：VPC/CIDR/サブネット設計、SG/NACL/ルート、DNS/名前解決。
セキュリティ：IAMロール/IMDSv2/鍵管理、SSMで踏み台レス。
スケーリング：ASG台数・ポリシー、ヘルスチェック、デプロイ方式（Rolling/Blue-Green/Canary）。
監視：メトリクス/ログ収集/ダッシュボード/アラート、トレースの要否。
コスト：Rightsizing/停止スケジュール/Spot適用範囲、Savings Plans/RIの方針。
変更管理：IaC（例：Terraform/CloudFormation/Bicep/DM）とレビュー手順。
退出計画：AMI/スナップショット/データ移行、DNS/証明書/監視のクリーンアップ。

16. 運用Runbook（インシデント初動の型）

検知：アラート内容と影響範囲（AZ/ASG/ターゲット）を即確認。
自動復旧の確認：ASGの置換が進行しているか、LBの健全ターゲット数を確認。
一時緩和：スケールアウト閾値を一段下げ、追加キャパシティを投入。
原因切り分け：直近デプロイ/AMI/ユーザーデータ/外部依存（DB/Cache）を比較。
恒久対策：ヘルスチェックの改善、リソース制限（ulimit）、観測点追加を反映。
ふりかえり：ダッシュボード/Runbookに学びを記録し、タグ/命名/ポリシーを更新。

17. ケーススタディ（3例）

17.1 スタートアップのAPI基盤（短納期）

構成：ALB → ASG（t系汎用） → RDS（マネージド）→ CloudWatch。
ポイント：AMIベイク＋ユーザーデータで再現性。夜間停止でコスト最適化。
他クラウド：GCEはMIG＋HTTP(S) LB＋Cloud SQL、AzureはVMSS＋AppGW＋Azure Database。

17.2 画像処理バッチ（低コスト重視）

構成：SQS（キュー）→ Spotインスタンス群 → 処理結果はS3へ。
ポイント：中断ハンドリングとリトライ。チェックポイントをS3に保存。
他クラウド：GCE/AzureのSpot VM＋キュー（Pub/Sub／Storage Queue）で同様に実装。

17.3 社内基幹の段階移行（安全重視）

構成：ASG（最小1/最大1）で自己回復→負荷増に応じて段階的に複数AZ。
ポイント：SSMで踏み台レス、パッチ基準日を定義。監査ログは別アカウントに保管。
他クラウド：GCEのOS Config/Shielded VM、AzureのUpdate Management/Defender for Cloudで同水準を維持。

18. 3クラウド比較まとめ（実務の視点）

設計のわかりやすさ：GCE（カスタムタイプが明快） ≧ EC2（型が豊富） ≧ Azure（選択肢が広く設計力次第）
企業ガバナンス/ネットワーク親和性：Azure ＞ EC2 ≧ GCE
スケール自動化の成熟度：EC2（ASGの成熟＋豊富な実例） ≧ GCE（MIG簡潔） ≧ Azure（VMSS機能充実）
運用の一貫性（踏み台レス/証跡）：EC2（SSM/CloudTrail） ≧ Azure（JIT/Bastion/Activity） ≧ GCE（OS Login/IAP/Audit Logs）
コスト最適化の柔軟性：EC2（Savings Plans/Spotの組合せ） ≧ GCE（Committed/Sustained/Spot） ≧ Azure（Reserved/Spot）

19. 想定読者と到達ゴール（具体的に）

情報システム部門（オンプレVM移行）：EC2へ同等移行→自己回復化→監視/パッチ/証跡の標準化までを、ASG＋SSMの型で定着。
Web/業務アプリ開発者：ステートレスAPI＋外部状態分離の原則を身につけ、ローリング/カナリアで安全に出せる。
SRE/インフラエンジニア：VPC/SG/IMDSv2/ログ集約を前提に、SLOベースのアラートを組める。
セキュリティ/ガバナンス担当：鍵を置かない・踏み台レス・証跡保存のガードレールを組織標準として定義。
スタートアップ技術リーダー：最小構成→型化→IaCの順で、小さく始め広く伸びる基盤を短期間で構築。

20. まとめ：EC2は“型”で使うとブレない

Amazon EC2は、ASG＋ELB＋Launch Templateという再現性の高い型で運用することで、可用性・性能・コストのバランスが取りやすくなります。ストレージはEBS中心に、状態は外部へ退避、アクセスはSSMで踏み台レス。この原則を守るほど、障害時も置換して回復でき、デプロイとスケーリングが怖くなくなります。
マルチクラウドでも、MIG/VMSSに読み替えるだけで同じ設計思想を貫けます。まずは最小構成をIaC化し、計測→権利サイズ最適化→割引適用の順でコストを整えましょう。

付録A：cloud-init（最小Webサーバー）

#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /var/www/html/healthz.html
    content: "ok"
runcmd:
  - systemctl enable nginx
  - systemctl start nginx
  - printf "location /healthz { return 200 'ok'; add_header Content-Type text/plain; }" \
      > /etc/nginx/snippets/healthz.conf
  - 'sed -i "/server_name _;/a include snippets/healthz.conf;" /etc/nginx/sites-available/default'
  - systemctl reload nginx

付録B：セキュリティグループ（最小、ALB経由のみ）

# アプリSG：ALBのSGからの80/TCPのみ許可
APP_SG=$(aws ec2 create-security-group --group-name app-sg --description "app" --vpc-id vpc-xxx --query GroupId --output text)
ALB_SG=$(aws ec2 create-security-group --group-name alb-sg --description "alb" --vpc-id vpc-xxx --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $APP_SG --protocol tcp --port 80 --source-group $ALB_SG
aws ec2 authorize-security-group-ingress --group-id $ALB_SG --protocol tcp --port 80 --cidr 0.0.0.0/0

付録C：Rightsizingの簡易手順（週次）

CloudWatch/MonitoringでCPU/メモリ/ディスク/ネットワークを可視化（Agent導入）。
連続2週間でCPU p95 < 40%かつメモリp95 < 60%なら1サイズ縮小を候補化。
負荷テストで余裕を確認後に縮小。ASGのローリング更新で無停止適用。
3か月に1度、**割引モデル（Savings/RI/Committed/Reserved）**の適用率を棚卸し。

付録D：デプロイ戦略の雛形（Rolling/Blue-Green/Canary）

Rolling：ASGのMaxSurge相当を増やし順次置換。最小リスク。
Blue-Green：新ASGを別で用意→ターゲットグループ切替。ロールバック容易。
Canary：1台→少数→全体。メトリクス/ログ/トレースで段階判断。
共通：ヘルスチェックURL/DBマイグレーション順序/Feature FlagをRunbookに明記。

付録E：今日できる3ステップ

Launch Templateを作り、ユーザーデータにcloud-initを入れて再現可能な起動にする。
**ASG（最小1/最大1）**で自己回復だけ先に確保。ALBは次の段階で。
SSM Agent＋Session Managerを有効化し、踏み台と鍵配布を廃止。ログ収集も同時に整える。

――これで、EC2の“第二歩”は万全です。次回はAWS Lambdaを予定し、Cloud Functions/Azure Functionsまで横断で比較します。どうぞお楽しみに。