Amazon EC2は、AWS上で仮想サーバーを必要なときに起動し、構成や台数を調整できるサービスです。
ただし、仮想マシンを一台起動しただけでは、可用性、セキュリティ、バックアップ、監視は整いません。
実務では、サーバーの性能表から選び始めるのではなく、止められる時間、守るデータ、管理方法、予算の順に要件を決めます。
本記事では、Amazon EC2の設計をGoogle Compute EngineとAzure Virtual Machines（Azure VM）に対応づけ、特定のクラウドを一律に優劣評価せず、用途に合う選び方を整理します。
Amazon EC2を理解するための基本用語
IaaSは、仮想サーバー、ネットワーク、ストレージなどの基盤をクラウド上で利用する形態です。
利用者は物理機器を保有せずに済みますが、OSやアプリケーションの設定、更新、監視は構成に応じて利用者側の作業として残ります。
| 用語 | 役割 | 設計時の確認点 |
|---|---|---|
| AMI | OSや初期構成を含む起動イメージ | 更新方法と世代管理を決める |
| インスタンスタイプ | CPU、メモリ、ネットワーク、ストレージ能力の組み合わせ | 測定結果に基づいて選ぶ |
| EBS | EC2から利用する永続ブロックストレージ | 容量、性能、暗号化、削除設定、バックアップを決める |
| セキュリティグループ | インスタンスの受信通信と送信通信を制御する仮想ファイアウォール | 必要な通信元、宛先、ポートだけを許可する |
| Launch Template | AMIやインスタンスタイプなどの起動設定をまとめるテンプレート | 変更を版として管理する |
| Auto Scaling Group | 指定した範囲でインスタンス台数と状態を管理する仕組み | 最小、希望、最大台数とヘルスチェックを決める |
| Availability Zone | 一つのリージョン内にある独立した拠点区分 | 障害範囲を考え、必要なら複数のZoneへ分散する |
各機能の定義は、Amazon EC2の公式概要でも確認できます。
仮想サーバー設計を始める順番
設計の起点はインスタンスタイプではなく、業務上の制約です。
- 停止許容時間を決める：単一インスタンスでよいのか、複数のAvailability Zoneに分散すべきかを判断します。
- データの置き場所を決める：インスタンスを交換しても残すデータを、EBS、共有ファイル、データベース、オブジェクトストレージなどへ分離します。
- 通信経路を決める：公開入口、内部通信、外向き通信、運用接続を分けます。
- 再現方法を決める：Launch Template、イメージ、ユーザーデータ、IaCで同じ構成を作り直せるようにします。
- 測定方法を決める：性能、エラー、遅延、容量、費用を継続して確認できる状態にします。
この順番なら、「安いインスタンスを選んだが停止できない」「自動増減できるがデータが一台に残っている」といった設計の食い違いを早い段階で見つけられます。
インスタンスとストレージの選び方
インスタンスタイプは用途と測定結果で絞る
EC2のインスタンスタイプは、計算、メモリ、ストレージ、アクセラレーターなどの特性別に分類されています。
最初から細かな型番を固定せず、アプリケーションのCPU使用率、メモリ使用量、ディスク入出力、ネットワーク量を測り、必要な余裕を含めて候補を絞ります。
性能不足だけでなく、余剰なサイズを長期間使うことも費用の増加につながるため、負荷試験と本番監視の結果から定期的に見直します。
EBSとインスタンスストアを混同しない
EBSは、インスタンスとは別に管理されるブロックストレージです。
終了時に残すか削除するかはボリュームの設定に左右されるため、バックアップと復元だけでなく、削除設定も確認します。
インスタンスストアは、ホストに接続された一時ストレージです。
通常の再起動ではデータが保持されますが、停止、休止、終了などでは失われるため、キャッシュや再作成できる作業領域に限って使います。
複数台から同じファイルを参照する要件がある場合は、Amazon EFS、Google Cloud Filestore、Azure Filesの比較も参照してください。
ネットワークと管理アクセスの設計
Webシステムでは、ロードバランサーだけを公開し、アプリケーション用インスタンスをプライベート側に置く構成が候補になります。
ただし、外部公開の要否や通信経路はシステムごとに異なるため、インターネットへの入口と出口、管理接続、サービス間通信を図にして確認します。
VPC、サブネット、ルート、各クラウドのファイアウォール機能の対応は、Amazon VPC、Google Cloud VPC、Azure VNetの比較で詳しく整理しています。
- 通信許可：セキュリティグループには、業務で必要な通信元、宛先、プロトコル、ポートだけを登録します。
- アプリケーションの権限：固定のアクセスキーをサーバーへ保存せず、AWSではIAMロール、Google Cloudではサービスアカウント、AzureではマネージドIDを使います。
- インスタンスメタデータ：EC2ではIMDSv2を要求する設定を検討し、利用しない場合はアクセス自体を制限します。
- 管理接続：AWS Systems Manager Session Managerを使う構成では、管理対象の設定、IAM権限、エージェント、サービスへの通信経路を確認します。
Session Managerは、管理対象への受信ポートを開かずに接続でき、ブラウザーやCLIからのシェル接続ではSSH鍵を使わない運用も可能です。
ただし、SSHをSession Managerでトンネルする方式ではSSH鍵が必要であり、SSHやポート転送のセッション内容は記録できないという違いがあります。
可用性とAuto Scalingの考え方
Auto Scaling Groupは、Launch Templateを使ってインスタンスを起動し、指定した台数を維持します。
需要に応じて台数を変える場合は、CPU使用率やロードバランサーのリクエスト数など、台数との関係を説明できる指標を選びます。
起動に時間がかかるアプリケーションでは、ウォームアップ中のインスタンスを評価へ含める時期も設計します。
「Auto Scaling Groupに入れれば高可用になる」を意味するわけではありません。
希望台数が一台なら、障害インスタンスを置き換える間に停止が生じます。
データセンター障害への備えが必要なら、複数のAvailability Zoneにサブネットを用意し、同時稼働台数、ロードバランサー、データ層まで含めて分散させます。
Elastic Load Balancingのヘルスチェック結果で置換したい場合は、Auto Scaling Group側でそのヘルスチェックを有効にします。
EC2、Compute Engine、Azure VMの対応関係
三つのクラウドには似た役割の機能がありますが、設定範囲、料金、利用できるリージョン、運用手順まで同一ではありません。
名称の対応表は、移行や比較を始めるための索引として使います。
| 比較項目 | AWS | Google Cloud | Azure |
|---|---|---|---|
| 仮想マシン | Amazon EC2 | Compute Engine | Azure Virtual Machines |
| 構成テンプレート | Launch Template | Instance Template | VMSSのモデルとイメージ |
| グループ管理と自動増減 | Auto Scaling Group | Managed Instance Group | Virtual Machine Scale Sets |
| 負荷分散 | Elastic Load Balancing | Cloud Load Balancing | Azure Load BalancerまたはApplication Gateway |
| ワークロードのID | IAMロール | サービスアカウント | マネージドID |
| 永続ブロックストレージ | Amazon EBS | Persistent DiskまたはHyperdisk | Managed Disks |
| 一時ローカルストレージ | インスタンスストア | Local SSD | 一時ディスク |
既存環境との接続から選ぶ
AWSのアカウント管理、監視、ネットワークがすでに標準化されている組織では、EC2を採用すると既存の手順を再利用しやすくなります。
同じ理由で、Google CloudやMicrosoft Entra IDを中心に運用している組織では、それぞれの仮想マシンサービスが自然な候補になります。
必要な構成を実際に比較する
Google Compute Engineは、一部のマシンシリーズでvCPU数とメモリ量を指定するカスタムマシンタイプを利用できます。
Azure VM Scale Setsにはオーケストレーションモードなどの選択があり、作成後に変更できない項目もあります。
サービス名だけで決めず、対象リージョンで必要なマシン、ディスク、可用性構成、割引条件を組み合わせ、見積額と運用作業を比較します。
コストを比べるときの注意点
仮想マシンの時間単価だけでは、システム全体の費用は比較できません。
- 常時稼働する最小台数とピーク時の台数
- ブロックストレージ、スナップショット、共有ファイルの容量と性能
- ロードバランサー、NAT、外向きデータ転送
- ログの取り込み、保存期間、検索量
- バックアップ、待機系、災害復旧環境
- 監視、パッチ、問い合わせ対応にかかる作業時間
利用量が読めない段階では柔軟な料金モデルで測定し、継続利用が見込める範囲だけをSavings Plansや各クラウドのコミットメント型割引の候補にします。
Spot系の仮想マシンは中断される前提で、再実行、チェックポイント、通常料金の処理系への切り替えを設計できる処理に使います。
監視と復旧を運用開始前に決める
監視はCPU使用率だけでは不十分です。
利用者が受ける影響を把握するため、成功率、応答時間、処理待ち、ストレージ容量など、サービスの状態を説明できる指標を選びます。
AWS、Google Cloud、Azureの監視サービスの役割は、Amazon CloudWatch、Cloud Monitoring、Azure Monitorの比較で確認できます。
障害対応では、検知、影響確認、一時緩和、原因切り分け、復旧、再発防止の順をRunbookに記載します。
スナップショットを作るだけでなく、別環境へ復元できるかを定期的に試し、復旧時間と復旧地点の要件を満たすか確認します。
代表的な三つの構成
ステートレスなWebアプリケーション
ロードバランサーの背後に複数の仮想マシンを置き、セッションやアップロードファイル、データベースをインスタンス外へ分離します。
データベースをマネージドサービスへ分ける場合は、Amazon RDS、Cloud SQL、Azureのマネージドデータベースの比較が選定の参考になります。
中断を許容できるバッチ処理
ジョブをキューへ置き、処理途中の状態を永続ストレージへ保存できるなら、Spot系の仮想マシンを選択肢にできます。
一回しか実行できない処理や、再開位置を記録できない長時間処理には向きません。
既存サーバーの段階移行
最初は単一インスタンスへ移す場合でも、その構成を高可用と呼ばず、停止時の連絡、復旧手順、バックアップ、監視を先に決めます。
移行後に状態を外部へ分け、複数台化と自動置換へ進むと、変更範囲を限定しながら運用を改善できます。
導入時の確認チェックリスト
- 許容停止時間、復旧時間、失ってよいデータの範囲が決まっている
- 対象リージョンとAvailability Zoneの構成が決まっている
- インスタンスタイプを選んだ測定根拠がある
- 永続データと一時データを分離している
- 受信通信と送信通信を必要最小限にしている
- 固定の資格情報をインスタンスへ保存していない
- 同じ構成をテンプレートまたはIaCで再作成できる
- ヘルスチェックがアプリケーションの利用可否を判定できる
- ログ、メトリクス、監査証跡の保存先と期間が決まっている
- バックアップからの復元を試している
- 通常時と障害時のRunbookに担当者と判断条件がある
- 割引適用前に、実際の利用量と変更予定を確認している
公式ドキュメントで確認する項目
クラウドの仕様や料金、利用可能な構成は変わるため、実装時には対象リージョンの公式情報を確認してください。
EC2設計の結論
EC2を安定して運用するには、仮想マシン単体ではなく、ネットワーク、ID、ストレージ、負荷分散、自動置換、監視、復旧を一つの設計として扱います。
Compute EngineやAzure VMと比較するときも、サービス数や印象による順位ではなく、同じ要件と構成図を使って費用と運用負荷を確かめると判断しやすくなります。
まず停止許容時間とデータの置き場所を決め、最小構成を再作成できる状態にしてから、負荷試験と監視結果に基づいて台数とサイズを調整してください。
この記事に関連する株式会社greedenの取り組み
仮想サーバーは、製品名の比較だけでなく、要件整理と保守運用まで含めて設計する必要があります。株式会社greedenは、要件定義からリリース後の保守運用まで、Webシステム開発を一気通貫で支援します。