EC2

1. 概要

Amazon EC2（Elastic Compute Cloud）は、AWS 上で仮想サーバ（インスタンス）を起動・管理できる IaaS（Infrastructure as a Service） サービス。

物理サーバの調達やセットアップを行うことなく、数分で仮想マシンを起動でき、不要になったらすぐに削除できる。これにより、従来はハードウェア調達に数週間〜数ヶ月かかっていた作業が、API やコンソールから即座に実行可能になる。

責任共有モデルにおける位置づけ

EC2 は IaaS に分類されるため、OS より上のレイヤーはユーザーの責任となる。具体的には、OS のパッチ適用、ミドルウェアのインストール・設定、アプリケーションのデプロイ、セキュリティ設定（ファイアウォール、ユーザー管理）はすべてユーザーが管理する。

一方、物理ホストのハードウェア、ハイパーバイザー、ネットワークインフラについては AWS が管理する。

この責任範囲を理解しておくことで、「何をAWSに任せられて、何を自分で対処しなければならないか」が明確になる。

2. ユースケース

EC2 は汎用性が高いサービスだが、特に以下のようなケースで選択されることが多い。

• 既存のオンプレミスアプリケーションをクラウドに移行したいとき — OS やミドルウェアの構成をそのまま維持できるため、アプリケーションの改修を最小限に抑えられる（リフト＆シフト）
• OS レベルでの細かいチューニングが必要なとき — カーネルパラメータの調整や特定バージョンのミドルウェアが必要な場合、Lambda や ECS では対応しづらい要件に応えられる
• GPU を使った機械学習や推論処理を実行したいとき — P 系・G 系インスタンスで NVIDIA GPU を利用でき、CUDA 環境を自由に構築できる
• 長時間動作するバッチ処理を実行したいとき — Lambda の 15 分制限を超えるような処理や、大量のメモリを必要とする処理に適している
• 開発・検証用の一時的な環境が必要なとき — スポットインスタンスを使えば低コストで検証環境を立ち上げられる

3. 基本概念

EC2 を理解するために押さえておくべき主要用語を以下にまとめる。

4. アーキテクチャ概要

代表構成（Web アプリケーション）

以下は、EC2 を使った Web アプリケーションの典型的な構成。ALB（Application Load Balancer）でリクエストを受け、Auto Scaling Group 内の複数の EC2 インスタンスに分散し、バックエンドのデータベースとして RDS を使用する。

[ユーザー]
   ↓ HTTPS
[ALB (Application Load Balancer)]
   ↓ HTTP (ポート80)
[EC2 × 2台以上 (Auto Scaling Group)]  ← 複数AZに分散
   ↓ TCP (ポート3306)
[RDS (Multi-AZ)]

構成図生成プロンプト: 上記構成をアーキテクチャ図として作成する場合、以下のプロンプトを画像生成 AI や draw.io 等で使用できる。 「AWS アーキテクチャ図。ユーザーからの HTTPS リクエストが ALB を経由し、2 つのアベイラビリティゾーンに分散された Auto Scaling Group 内の EC2 インスタンス群に振り分けられる。EC2 からは RDS（Multi-AZ 構成）に接続する。VPC 内にパブリックサブネット（ALB）とプライベートサブネット（EC2、RDS）を配置。」

設計ポイント

• EC2 をインターネットに直接公開しない — ALB や CloudFront を前段に置くことで、DDoS 対策やSSL 終端を一元管理できる
• 複数の AZ（アベイラビリティゾーン）に分散配置する — 1 つの AZ で障害が発生しても、別の AZ のインスタンスがリクエストを処理し続けられる
• ステートレスに設計する — セッション情報をインスタンス内に持たず、ElastiCache（Redis）や DynamoDB に外出しすることで、スケールイン・アウト時にセッションが失われない

5. 主要機能

インスタンスタイプ

インスタンスタイプは名前の先頭文字（ファミリー）で用途が分かれる。

世代の数字が大きいほど新しい。末尾の g は Graviton（ARM）プロセッサを示し、同スペックの x86 と比較して約 20% 安価。

AMI（Amazon Machine Image）

ストレージ（EBS）

購入オプション

本番環境には Savings Plans を優先的に検討し、開発・検証環境にはスポットインスタンスの活用を検討するのがコスト最適化の基本戦略。

6. 料金体系

EC2 の料金は複数の要素で構成されるため、「インスタンス料金だけ」を見ていると想定外のコストが発生しやすい。

主な課金要素

見落としがちなコスト

• 停止中インスタンスの EBS 料金 — インスタンスを停止しても EBS は課金され続ける。不要なら EBS ごと削除する
• 未使用の Elastic IP — 関連付けのない Elastic IP には料金が発生する。使わなくなったら即解放する
• AZ 間のデータ転送 — 同一リージョンでも AZ をまたぐ通信には課金される（$0.01/GB 程度）

7. 比較・選定指針

「EC2 を使うべきか」を判断するために、類似サービスと比較する。

EC2 を選ぶ判断基準

以下のいずれかに該当する場合は EC2 が適している。

• OS やカーネルの設定を直接変更する必要がある
• Lambda の実行時間制限（15 分）やメモリ制限（10 GB）を超える処理がある
• コンテナ化が難しいレガシーアプリケーションを移行する
• GPU インスタンスが必要（機械学習、動画処理など）

8. 運用・監視

主要メトリクス（CloudWatch）

注意: メモリ使用率とディスク使用率は CloudWatch の標準メトリクスに含まれない。これらを監視するには CloudWatch Agent をインストールしてカスタムメトリクスとして送信する必要がある。

ログ

CloudWatch Logs Agent を使って各ログを CloudWatch Logs に集約することを推奨する。インスタンスが終了してもログを保持できる。

運用ツール

• AWS Systems Manager（SSM） — SSH を使わずにインスタンスに接続できる Session Manager、パッチ適用の自動化（Patch Manager）、設定管理（State Manager）を提供
• CloudWatch Agent — メモリ・ディスク使用率のカスタムメトリクスを収集
• AWS Config — インスタンスの設定変更を追跡し、コンプライアンスチェックを自動化

9. トラブルシューティング

問題：SSH 接続できない

原因:

• セキュリティグループで TCP ポート 22 が許可されていない
• サブネットの NACL でインバウンド / アウトバウンドがブロックされている
• ルートテーブルにインターネットゲートウェイへのルートがない
• インスタンスにパブリック IP または Elastic IP が割り当てられていない
• OS 上の sshd が停止している

確認手順:

1. セキュリティグループのインバウンドルールを確認（ポート 22、接続元 IP）
2. サブネットの NACL でポート 22 のインバウンドと、エフェメラルポートのアウトバウンドが許可されているか確認
3. ルートテーブルに 0.0.0.0/0 → igw-xxxx のルートがあるか確認
4. インスタンスにパブリック IP が割り当てられているか確認
5. VPC Reachability Analyzer で接続経路を診断
6. どうしても接続できない場合は SSM Session Manager での接続を試みる

問題：CPU 使用率が高い

原因:

• アプリケーションの処理負荷が増大している
• メモリ不足により swap が発生し、CPU も圧迫されている
• バックグラウンドプロセス（ウイルススキャン、ログローテーション等）が重なっている

確認手順:

1. top または htop でプロセスごとの CPU 使用率を確認
2. 特定プロセスが占有している場合、そのプロセスの挙動を調査
3. メモリ使用率も併せて確認し、swap が発生していないか確認（free -m）
4. 一時的な負荷増なら Auto Scaling でスケールアウト、恒常的なら上位インスタンスタイプへの変更を検討

問題：ステータスチェックが失敗する

原因:

• System Status Check 失敗: AWS 基盤側の障害（ハードウェア故障、ネットワーク障害）
• Instance Status Check 失敗: OS レベルの問題（カーネルパニック、ファイルシステム破損、メモリ枯渇）

対応:

1. System Status Check 失敗 → インスタンスを停止・起動（再起動ではなく停止→起動で別の物理ホストに移動する）
2. Instance Status Check 失敗 → システムログ（コンソール出力）を確認し、OS レベルの問題を特定。復旧困難な場合は AMI から新しいインスタンスを起動

10. 実装例

AWS CLI

# インスタンスの起動
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --iam-instance-profile Name=MyEC2Role \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-server}]'

# インスタンスの停止
aws ec2 stop-instances --instance-ids i-0123456789abcdef0

# インスタンスの終了（削除）
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

Terraform

resource "aws_instance" "web" {
  ami                    = "ami-0abcdef1234567890"
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.private.id
  vpc_security_group_ids = [aws_security_group.web.id]
  iam_instance_profile   = aws_iam_instance_profile.ec2.name

  root_block_device {
    volume_type = "gp3"
    volume_size = 20
  }

  tags = {
    Name = "web-server"
  }
}

11. アンチパターン

12. 参考リンク

• EC2 公式ドキュメント
• EC2 API リファレンス
• AWS CLI EC2 リファレンス
• EC2 の料金
• AWS Black Belt - Amazon EC2