Cloud Service
Amazon EC2
必要な時に必要なだけ起動できる仮想サーバー。AWSで最も基本的なコンピューティングサービス。
基礎CLF-C02SAA-C03SOA-C02DVA-C02信頼性パフォーマンス効率コスト最適化セキュリティ
最終更新: 2026-05-31公式ドキュメント ↗
TL;DR要点だけ先に
- 1.物理サーバーを買わず、仮想サーバーを数分で起動・停止・破棄。
- 2.使った分だけ課金。Auto Scaling で台数を自動増減し冗長化。
- 3.コスト最適化の鍵は購入オプションの使い分け(スポットで最大9割引)。

解決する課題
従来はサーバーを買い、データセンターに設置し、OSを入れて…と数週間かかっていました。EC2なら:
- 数分でサーバーが立ち上がる
- 負荷に応じて台数を増減できる(スケールアウト/イン)
- ハード故障やキャパシティ計画をAWSに任せられる
主要概念と用語
- インスタンス: 起動した1台の仮想サーバー
- AMI(Amazonマシンイメージ): OSやソフトを含む「起動テンプレート」
- インスタンスタイプ:
t3.microm5.largeなどのスペック区分(用途×サイズ) - EBS: インスタンスにアタッチする永続ブロックストレージ(=仮想ディスク)
- セキュリティグループ: インスタンス単位の仮想ファイアウォール(ステートフル)
- キーペア: SSH/RDP 接続用の鍵
仕様・制限・クォータ
- リージョン×AZ(アベイラビリティゾーン)に配置。AZ=物理的に分離されたデータセンター群
- 課金は秒単位(Linux/オンデマンドは最低60秒)または時間単位
- 1アカウントあたりの起動上限(vCPUクォータ)があり、引き上げ申請が可能
- インスタンスファミリー: 汎用(t/m)、コンピュート最適化(c)、メモリ最適化(r/x)、高速計算(p/g) など
内部の仕組み
EC2インスタンスは、AWSが管理する物理ホスト上で Nitro System(専用ハードウェア+軽量ハイパーバイザ)によって仮想化されています。Nitroによりネットワーク/ストレージI/Oを専用チップにオフロードし、ほぼベアメタルに近い性能とセキュリティを実現しています。
- ルートボリュームは通常 EBS(ネットワーク越しのブロックストレージ)。インスタンスを止めてもデータは残る
- 一部タイプは インスタンスストア(物理ホスト直結の一時ディスク)を持つ。停止で消える点に注意
EBS と インスタンスストアの違い
インスタンスストアは高速だが揮発性(停止/終了で消失)。永続化が必要なデータは必ず EBS か S3 へ。
設計パターン / ベストプラクティス
- ステートレス設計: セッションやファイルをインスタンス外(DynamoDB/ElastiCache/S3)へ逃がし、台数を自由に増減
- Auto Scaling + ELB: 複数AZにまたがって冗長化し、負荷に応じ自動増減
- Launch Template + AMI で起動を標準化、Immutableに入れ替える
運用・監視・トラブルシュート
- CloudWatch で
CPUUtilizationStatusCheckFailed等を監視 - ステータスチェック: システム(AWS側) と インスタンス(OS側) の2種類
- Systems Manager (SSM) Session Manager を使えば、SSH鍵や踏み台なしで安全に接続・運用できる
コスト
購入オプションを使い分けるのがコスト最適化の肝です。
| 購入オプション | 割引 | 向いている用途 |
|---|---|---|
| オンデマンド | なし(定価) | 短期・予測不能・検証 |
| Savings Plans / RI | 最大〜72% | 1年以上の定常稼働 |
| スポット | 最大〜90% | 中断許容のバッチ/CI/ステートレス |
| Dedicated Host | ライセンス都合 | BYOL・コンプライアンス要件 |
セキュリティ
- IAM ロールをインスタンスにアタッチし、アクセスキーのハードコードを避ける
- セキュリティグループは許可ルールのみ・ステートフル(戻り通信は自動許可)
- 保存データは EBS暗号化、転送は TLS。鍵は KMS で管理
アンチパターン
ルートユーザーやアクセスキーをインスタンス内に置くのはNG。IAMロールを使えばキーの管理・漏洩リスクを排除できます。
Well-Architected の観点
- 信頼性: 複数AZ + Auto Scaling で単一障害点を排除
- パフォーマンス効率: 用途に合うインスタンスタイプ選定、必要なら専用ハードウェア(高速計算)
- コスト最適化: 購入オプションの使い分け、不要インスタンスの停止/right-sizing
- セキュリティ: 最小権限のIAMロール、SG、暗号化
試験で問われるポイント
頻出
- 「中断OKで最安」→ スポット、「長期定常で割引」→ Savings Plans / RI
- 「キーをどう渡す?」→ IAMロール(ハードコード厳禁)
- EBS(永続)と インスタンスストア(揮発)の違い
📝 EC2 ミニ確認テスト第 1 問 / 全 3 問
中断されても問題ないバッチ処理を、できるだけ安く大量に回したい。最適な購入オプションは?
関連サービス・比較
サーバーレスの Lambda とよく比較されます。
| 観点 | EC2 | Lambda |
|---|---|---|
| 課金単位 | 起動時間(秒/時間) | 実行時間(ms)×メモリ |
| サーバー管理 | OS/パッチを自分で管理 | 不要(フルマネージド) |
| 常時稼働 | 得意 | 不向き(イベント駆動向け) |
| 起動の速さ | 数十秒〜 | ミリ秒(コールドスタートあり) |
ハンズオン / CLI例
# 最新の Amazon Linux 2023 でインスタンスを1台起動
aws ec2 run-instances \
--image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
--instance-type t3.micro \
--key-name my-key \
--security-group-ids sg-0123456789abcdef0 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=demo}]'
# 起動中インスタンスの一覧
aws ec2 describe-instances \
--filters "Name=instance-state-name,Values=running" \
--query "Reservations[].Instances[].{ID:InstanceId,Type:InstanceType}"
AWS Service
Amazon EC2を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
コンピューティング
比較で見る軸
クラウド: AWS / カテゴリ: コンピューティング / 難易度: basic
導入後に効く点
使った分だけ課金。Auto Scaling で台数を自動増減し冗長化。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- AWS
- カテゴリ
- コンピューティング
- 難易度
- basic
- 関連資格
- CLF-C02 / SAA-C03 / SOA-C02 / DVA-C02
- 設計柱
- reliability / performance / cost / security
判断チェックリスト
- 自社の用途が「コンピューティング / reliability」に近いか確認する。
- 強みである「物理サーバーを買わず、仮想サーバーを数分で起動・停止・破棄。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
他クラウドの同等サービス
役割が近いサービスです。設計の置き換えや比較検討の参考に。