Amazon EC2は「クラウド上の仮想マシン」と説明されることが多いですが、実際のシステム運用においては、それだけでは十分ではありません。EC2は多様なインスタンスタイプと料金モデルを提供しており、これらの選択はパフォーマンス・可用性・コストに直接影響します。AWS上で本番ワークロードを稼働させる前に、それぞれの要素がどのように組み合わさるのかを理解することが重要です。

1. クラウドコンピューティングにおけるAmazon EC2の位置づけ

1.1 EC2とは何か

Amazon EC2（Elastic Compute Cloud）はAmazon Web Servicesの中核となるコンピュートサービスであり、クラウド上で構成可能な仮想サーバーを提供します。CPU、メモリ、ストレージ、ネットワークといったリソースをオンデマンドでプロビジョニングでき、利用者が直接コントロールできます。

EC2は単一の「標準的な仮想マシン」を提供するのではなく、ワークロード要件に応じて柔軟に設計できる仕組みとして提供されています。そのため、多くの上位AWSサービスやカスタムクラウドアーキテクチャの基盤となっています。

代表的なEC2の利用例：

• Webアプリケーションおよびバックエンドサービス
• MySQL、PostgreSQL、MongoDBなどのデータベースサーバー
• プロキシサーバーやロードバランシングコンポーネント
• 開発・テスト・ステージング環境
• バッチ処理や科学技術計算
• ゲームサーバーやメディア処理アプリケーション

EC2の価値は「何を動かせるか」ではなく、「ワークロード特性にどれだけ正確に合わせられるか」にあります。

1.2 EC2のコアコンポーネント

EC2環境は主に3つの構成要素から成り立っています。

• AMI（Amazon Machine Image）
• EBSボリューム
• セキュリティグループ

これらは意図的に疎結合で設計されています。コンピュート、ストレージ、ネットワークポリシーを個別に進化させることができ、単一のサーバー構成に固定されません。

• AMI：インスタンスの作成・再現方法を定義
• EBS：インスタンス交換後も保持される永続ストレージ
• セキュリティグループ：インスタンス再起動なしでネットワーク制御

この構造により、EC2環境は「使い捨て可能」「再現可能」「自動化しやすい」という特性を持ち、クラウドにおけるスケーラビリティと安定運用を実現します。

1.3 AWSインフラ内でのEC2

EC2はAWSリージョン内で稼働し、各リージョンは複数のアベイラビリティゾーン（AZ）を持ちます。AZは電源・ネットワーク・物理ハードウェアが独立したインフラ単位です。

• EC2インスタンスとEBSは単一AZに配置
• 高可用性は複数AZへの分散配置で実現
• AMIはリージョン間で複製可能（災害対策）
• Auto Scaling Groupで自動的に容量維持

EC2は「単一サーバーの信頼性」に依存するのではなく、「冗長化と自動復旧」によって障害耐性を実現する設計思想です。

2. EC2インスタンスタイプの理解と選び方

2.1 インスタンス命名規則

EC2のインスタンスタイプは、CPU・メモリ・ネットワーク帯域・ディスク性能の固定組み合わせを示します。名称そのものに技術的仕様が組み込まれています。

例：
c7gn.2xlarge

││││ └─ Instance size (nano, micro, small, medium, large, xlarge, 2xlarge, ...)

│││└────── Feature options (n = network optimized, d = NVMe SSD)

││└──────── Processor option (g = Graviton, a = AMD)

│└───────── Generation

└────────── Instance family (c = compute, m = general, r = memory, ...)

名称の各要素は、性能の優劣を示すものではなく、それぞれが特定の技術的選択を表しています。

例：

• c7gn.2xlarge：第7世代Gravitonベースのcompute最適化
• m6i.large：第6世代Intelベースの汎用型
• r5d.xlarge：ローカルNVMe付きメモリ最適化

2.2 インスタンスの基本設計軸

EC2に多くのインスタンスタイプが存在する理由は、ワークロードごとに要求リソースが異なるためです。

主な設計軸：

• CPUアーキテクチャと性能特性
• メモリ容量およびvCPU比率
• ストレージモデル（EBSまたはローカル）
• ネットワーク帯域と性能

インスタンスファミリーは「より強いマシン」ではなく、「特定の特性を強調した設計」です。

3. インスタンスカテゴリとワークロード適合

3.1 汎用インスタンス（General Purpose）

リソースが均等に使用されるワークロード向けです。

Mシリーズ（M5, M6i, M7iなど）

• CPU・メモリ・ネットワークのバランス型
• Webサーバー、バックエンド、小規模DBなど

Tシリーズ（T3, T4g）

• クレジットモデルによるバーストCPU
• 開発環境、低トラフィックサイト向け
• 持続的CPU負荷が不要な場合にコスト効率良

3.2 Compute最適化（Cシリーズ）

CPUがボトルネックのワークロード向けです。

• 高負荷Webサーバー（Nginx、Apache）
• 科学計算（モンテカルロなど）
• 大規模バッチ処理
• リアルタイムゲームサーバー
• メディアトランスコード

特徴：

• 最大192 vCPU（例：c7i.48xlarge）
• 高メモリ帯域
• 最大200Gbpsネットワーク
• 一部でNVMeローカルSSD対応

3.3 メモリ最適化（Rシリーズ・Xシリーズ）

メモリ容量がボトルネックの場合に使用します。

Rシリーズ

• 最大1:32のメモリ比率
• Redis、Memcached
• Spark、Elasticsearch
• SAP HANA、Cassandra

Xシリーズ

• 最大1:128の超高メモリ比率
• 大規模エンタープライズ用途

3.4 GPU・アクセラレーテッドインスタンス

GPUによる並列処理向けです。

Pシリーズ

• 機械学習トレーニング
• LLMやCNNの学習
• 分子動力学、気候モデリング

Gシリーズ

• グラフィックス処理
• リアルタイムレンダリング
• CAD・3Dモデリング

生成AI（画像生成、音声認識など）にも活用されます。

3.5 ストレージ最適化

ディスクI/Oがボトルネックの場合です。

Iシリーズ

• NVMe SSDによる高ランダムI/O
• Cassandra、MongoDB
• 書き込み負荷の高いElasticsearch

Dシリーズ

• 高密度HDD
• HDFS
• 大規模データ処理
   

3.6 HPC最適化

科学技術・金融モデリングなど特化用途です。

Hpcシリーズ

• EFA対応
• 低レイテンシ
• MPI最適化

4. EC2料金モデルとコスト最適化

4.1 On-Demand

• 初期費用なし
• Linuxは秒単位課金
• 柔軟性高いが単価高い

用途：

• 開発環境
• 短期バッチ処理
• 需要が読めないシステム

4.2 Spot Instances

• 最大90%割引
• 中断可能性あり（2分通知）

適合：

• CI/CD
• データクロール
• 再実行可能処理

4.3 Savings Plans / Reserved Instances

長期利用前提の割引モデルです。

• Savings Plans：利用額ベース
• Reserved Instances：特定タイプ固定

割引率：

• 最大75%

4.4 モデル比較