Amazon EBS

解決する課題

• インスタンスを停止/再起動してもデータを残したい
• OSやDBのデータを置く高速なディスクが欲しい
• ディスクをバックアップ・複製したい

主要概念と用語

• ボリュームタイプ: gp3/gp2（汎用SSD）、io1/io2（高IOPS）、st1/sc1（HDD）
• スナップショット: 増分でS3に保存するバックアップ
• Elastic Volumes: 稼働中にサイズ/タイプ/IOPSを変更
• 暗号化: KMSで保存時暗号化

仕様・制限・クォータ

• 単一AZのリソース（別AZへはスナップショット経由でコピー）
• 原則1インスタンスにアタッチ（io1/io2はMulti-Attach対応）
• サイズ拡張は可、縮小は不可

内部の仕組み

EBSはネットワーク接続のブロックストレージで、物理ホストから独立しているためインスタンスを止めてもデータが残ります。対照的にインスタンスストアは物理ホスト直結で高速ですが揮発性（停止で消失）。スナップショットは増分でS3に保存され、別リージョンへのコピーやAMI作成の土台になります。

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

• 汎用はgp3（IOPS/スループットを独立設定でき割安）
• 定期スナップショット＋ライフサイクルで世代管理（Data Lifecycle Manager）
• 重要データは暗号化を有効化

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

• メトリクス: VolumeReadOps VolumeQueueLength BurstBalance
• 性能不足はタイプ変更（gp3/io2）やIOPS引き上げで対応
• スナップショットから別AZへ復元してAZ障害に備える

コスト

• プロビジョニングした容量＋（io系は）IOPSに課金。gp3でコスト最適化
• 不要ボリューム/古いスナップショットの削除

セキュリティ

• KMSで保存時暗号化（スナップショットも暗号化継承）
• IAMでボリューム操作を制御

Well-Architected の観点

• 信頼性: スナップショット・別AZ復元
• パフォーマンス効率: ワークロードに合うタイプ選定
• コスト最適化: gp3・不要資源の削除

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 暗号化したgp3ボリュームを作成してアタッチ
aws ec2 create-volume --availability-zone ap-northeast-1a \
  --size 20 --volume-type gp3 --encrypted

aws ec2 attach-volume --volume-id vol-xxxx \
  --instance-id i-xxxx --device /dev/sdf

# スナップショットでバックアップ
aws ec2 create-snapshot --volume-id vol-xxxx --description "daily backup"