Amazon EC2

解決する課題

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

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

主要概念と用語

• インスタンス: 起動した1台の仮想サーバー
• AMI（Amazonマシンイメージ）: OSやソフトを含む「起動テンプレート」
• インスタンスタイプ: t3.micro m5.large などのスペック区分（用途×サイズ）
• EBS: インスタンスにアタッチする永続ブロックストレージ（＝仮想ディスク）
• セキュリティグループ: インスタンス単位の仮想ファイアウォール（ステートフル）
• キーペア: SSH/RDP 接続用の鍵

仕様・制限・クォータ

• リージョン×AZ（アベイラビリティゾーン）に配置。AZ＝物理的に分離されたデータセンター群
• 課金は秒単位（Linux/オンデマンドは最低60秒）または時間単位
• 1アカウントあたりの起動上限（vCPUクォータ）があり、引き上げ申請が可能

インスタンスタイプの読み方

m7g.xlarge のような名前は4つの部分に分解できます。ここを読めれば、 初めて見るタイプでも当たりがつきます。

m      7      g       .xlarge
│      │      │        └─ サイズ
│      │      └───────── 追加機能（省略されることが多い）
│      └──────────────── 世代（数字が大きいほど新しい）
└─────────────────────── ファミリー（用途）

ファミリー	用途	vCPU : メモリ の目安
t	バースト可能な汎用（開発・小規模）	1 : 2〜4
m	汎用	1 : 4
c	コンピュート最適化	1 : 2
r	メモリ最適化	1 : 8
x	大容量メモリ	1 : 16 以上
i / d	ストレージ最適化（インスタンスストア大容量）	—
p / g / inf	GPU・機械学習アクセラレータ	—

追加機能の文字も規則的です。g は AWS Graviton（Arm）、i は Intel、a は AMD、 d はインスタンスストア付き、n はネットワーク強化、e はメモリ/ストレージ追加、z は高クロック。

同じ世代なら Graviton（g）が価格性能で有利なことが多いですが、Arm なので ビルド済みバイナリや商用エージェントが対応しているかを先に確認します。

停止・休止・終了の違い

3つとも「止める」ですが、残るものが違います。取り違えるとデータを失います。

操作	メモリ	EBS	パブリックIP	課金
停止（stop）	消える	残る	解放される（Elastic IP は保持）	インスタンス停止／EBSは継続
休止（hibernate）	EBSルートに保存して復元	残る	解放される	同上＋保存領域
終了（terminate）	消える	DeleteOnTermination に従う	解放	停止

実務で効いてくるのは2点です。

• 停止するとパブリックIPが変わります。 IPを固定したいなら Elastic IP を関連付けるか、DNS名で参照します。
• 終了時にEBSが消えるかは属性次第。 ルートボリュームは既定で DeleteOnTermination: true、 後からアタッチしたボリュームは既定で false。「終了したらデータも消えた」「消したのにボリュームが残って課金され続けた」は どちらもこの属性の確認漏れです。

インスタンスストアを持つタイプでは、停止でインスタンスストアの中身が消えます。 再起動（reboot）では消えません。この違いも押さえておきます。

内部の仕組み

EC2インスタンスは、AWSが管理する物理ホスト上で Nitro System（専用ハードウェア＋軽量ハイパーバイザ）によって仮想化されています。Nitroによりネットワーク/ストレージI/Oを専用チップにオフロードし、ほぼベアメタルに近い性能とセキュリティを実現しています。

横にスクロール

• ルートボリュームは通常 EBS（ネットワーク越しのブロックストレージ）。インスタンスを止めてもデータは残る
• 一部タイプは インスタンスストア（物理ホスト直結の一時ディスク）を持つ。停止で消える点に注意

EBS のボリュームタイプを選ぶ

ルートボリュームを既定のまま使っていると、性能でも費用でも損をしていることがあります。

タイプ	種別	性能の決まり方	向き
gp3	汎用SSD	ベースライン 3,000 IOPS / 125 MB/s。容量と独立して追加設定できる	既定の選択。ほぼこれ
gp2	汎用SSD（旧）	容量に比例（3 IOPS/GiB）。小さいボリュームは遅い	新規で選ぶ理由は薄い
io2 Block Express	プロビジョンドIOPS SSD	IOPS を明示指定。最も高い	高IOPSのDB
st1	スループット最適化HDD	シーケンシャル向き。ランダムアクセスは苦手	ログ・ビッグデータ
sc1	Cold HDD	最安・最低速	アクセス頻度の低い保管

gp2 から gp3 への変更は、多くの場合そのまま得になります。 gp2 は容量に比例して IOPS が決まるため、 「性能を出すために容量を大きくする」という無駄が発生していました。gp3 なら容量は必要な分だけにして、 IOPS とスループットを別に設定できます。既存ボリュームは停止せずに変更できます。

設計パターン / ベストプラクティス

• ステートレス設計: セッションやファイルをインスタンス外（DynamoDB/ElastiCache/S3）へ逃がし、台数を自由に増減
• Auto Scaling + ELB: 複数AZにまたがって冗長化し、負荷に応じ自動増減
• Launch Template + AMI で起動を標準化、Immutableに入れ替える

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

• CloudWatch で CPUUtilization StatusCheckFailed 等を監視
• ステータスチェック: システム(AWS側) と インスタンス(OS側) の2種類
• Systems Manager (SSM) Session Manager を使えば、SSH鍵や踏み台なしで安全に接続・運用できる

コスト

購入オプションを使い分けるのがコスト最適化の肝です。

セキュリティ

• IAM ロールをインスタンスにアタッチし、アクセスキーのハードコードを避ける
• セキュリティグループは許可ルールのみ・ステートフル（戻り通信は自動許可）
• 保存データは EBS暗号化、転送は TLS。鍵は KMS で管理

Well-Architected の観点

• 信頼性: 複数AZ + Auto Scaling で単一障害点を排除
• パフォーマンス効率: 用途に合うインスタンスタイプ選定、必要なら専用ハードウェア(高速計算)
• コスト最適化: 購入オプションの使い分け、不要インスタンスの停止/right-sizing
• セキュリティ: 最小権限のIAMロール、SG、暗号化

試験で問われるポイント

関連サービス・比較

サーバーレスの Lambda とよく比較されます。

ハンズオン / 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}"