TL

Cloud Service

Amazon EC2

必要な時に必要なだけ起動できる仮想サーバー。AWSで最も基本的なコンピューティングサービス。

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

解決する課題

従来はサーバーを買い、データセンターに設置し、OSを入れて…と数週間かかっていました。EC2なら:

  • 数分でサーバーが立ち上がる
  • 負荷に応じて台数を増減できる(スケールアウト/イン)
  • ハード故障やキャパシティ計画をAWSに任せられる

主要概念と用語

  • インスタンス: 起動した1台の仮想サーバー
  • AMI(Amazonマシンイメージ): OSやソフトを含む「起動テンプレート」
  • インスタンスタイプ: t3.micro m5.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に入れ替える

運用・監視・トラブルシュート

  • CloudWatchCPUUtilization StatusCheckFailed 等を監視
  • ステータスチェック: システム(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 とよく比較されます。

観点EC2Lambda
課金単位起動時間(秒/時間)実行時間(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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

コンピューティングreliabilityperformancecostsecurity

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。