目次

Amazon EBS 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

本ガイドは以下を対象としています:

  • 初心者向け: EBS とは何か、なぜ EC2 に必要かを学びたい方
  • 開発者・SRE向け: ボリュームタイプ選定、スナップショット戦略、高IOPS設計を実装したい方
  • インフラエンジニア向け: gp3移行、io2 Block Express導入、Multi-Attach構成を検討する方
  • 意思決定者向け: gp2→gp3で60-87%コスト削減を実現したい方

2026年のEBSエコシステム

  • gp3がデフォルト: 2025年9月より、gp3は最大80,000 IOPS（前回は16,000）、2,000 MiB/s（1,000から倍増）に拡張。ほぼ全用途で推奨
  • io2 Block Express全リージョン対応: 256,000 IOPS、4,000 MiB/s、<500µs平均レイテンシで超高性能DB向け
  • Multi-Attach with I/O Fencing: io2が最大16インスタンス同時アタッチに対応、クラスターDB構成に最適
  • EBS Snapshots Archive: スナップショットアーカイブでコスト90%削減、長期保存に有利
  • Elastic Volumes: ダウンタイムなしにライブ変更、スケーリング柔軟性向上

概要

Amazon EBS（Elastic Block Store）は、EC2インスタンスにアタッチするマネージドブロックストレージサービス です。OS ディスク、高IOPS データベース、トランザクション処理の永続ストレージとして機能し、スナップショットによる増分バックアップ、暗号化、マルチAZ対応で Enterprise グレードの信頼性を提供します。

初心者向けメモ: EBS は EC2 インスタンスにアタッチして使います。S3 が「ファイルの倉庫」なら、EBS は「ハードディスク」です。

このサービスを選ぶ理由

課題 他の選択肢との比較 EBS での解決
OS・ブートボリューム S3 では FS 不可、EFS は NFS で遅延大 ブロックレベルで EC2 に直接マウント、ms単位レイテンシ
高IOPS DB（Oracle/SQL Server） EFS は 35K IOPS 上限 io2 Block Express で 256K IOPS、<500µs保証
複数インスタンス共有 Single-Attach が基本 io2 Multi-Attach で最大16インスタンス同時アタッチ
コスト最適化 gp2 で単価が割高 gp3 で 60-87% コスト削減、IOPS独立設定
増分バックアップ 手動 rsync では検証困難 EBS Snapshots で S3 に自動増分保存、整合性保証

EBS が解決する課題

EBS は以下の課題に対応します:

  1. EC2 のブロック I/O ニーズ: ファイルシステムをマウント、POSIX セマンティクス提供
  2. 低遅延・高IOPS要求: io2 Block Express で平均<500µs、99.9%が<0.8ms
  3. データ耐久性: 99.8-99.999% の信頼性、AZ 障害対応
  4. スナップショット・バックアップ: 増分保存で S3 に効率的に保管
  5. 暗号化・コンプライアンス: KMS マネージドキーでデータ保護、デフォルト暗号化設定可能

主な特徴

  • ✅ gp3 がデフォルト推奨: 3,000 IOPS/125 MiB/s ベースから 80,000 IOPS/2,000 MiB/s にスケーラブル
  • ✅ IOPS/スループット独立設定: ボリュームサイズと切り離して最適化
  • ✅ io2 Block Express: 256K IOPS、4,000 MiB/s、<500µs、99.999% 耐久性
  • ✅ Multi-Attach（io1/io2）: 最大16インスタンス同時アタッチで共有ストレージ
  • ✅ Elastic Volumes: ダウンタイムなしでライブ拡張
  • ✅ EBS Snapshots Archive: 90日以上保持で90%コスト削減
  • ✅ Fast Snapshot Restore: スナップショット復元後、初回 I/O 遅延を解消
  • ✅ 暗号化（KMS）: AWS マネージド or カスタマーマネージドキー

アーキテクチャ

graph TB
    subgraph EC2_AZ["Availability Zone"]
        EC2A["EC2 Instance<br/>t3.xlarge"]
        EC2B["EC2 Instance<br/>i3.large"]
        EC2C["EC2 Instance<br/>m5.2xlarge"]
    end
    
    subgraph EBS_Storage["EBS Storage Plane"]
        VOL_BOOT["Boot Volume<br/>gp3 50GB"]
        VOL_APP["Data Volume<br/>io2 Block Express<br/>100GB, 40K IOPS"]
        VOL_SHARED["Shared Volume<br/>io1 Multi-Attach<br/>500GB, 32K IOPS"]
        SNAP["EBS Snapshot<br/>in S3<br/>Incremental"]
    end
    
    subgraph Control["Control Plane"]
        KMS["AWS KMS<br/>Customer Managed Key"]
        MONITOR["CloudWatch<br/>Metrics/Alarms"]
        BACKUP["AWS Backup<br/>Lifecycle"]
    end
    
    EC2A -->|attach| VOL_BOOT
    EC2A -->|attach| VOL_APP
    EC2B -->|attach| VOL_SHARED
    EC2C -->|attach| VOL_SHARED
    
    VOL_BOOT -->|snapshot| SNAP
    VOL_APP -->|encrypt| KMS
    VOL_SHARED -->|monitor| MONITOR
    BACKUP -->|schedule| SNAP

データフロー

  1. EC2 インスタンスがボリューム attach: iSCSI/NVMe プロトコルで接続
  2. ブロック I/O 実行: ファイルシステム（ext4/xfs/NTFS）がマウント
  3. スナップショット作成: EBS が S3 に増分ブロック保存（ユーザー見えず）
  4. 復元: スナップショットから新ボリュームを別 AZ で作成可能
  5. 暗号化: KMS キーで保存時暗号化、データ転送時も暗号化

コアコンポーネント詳細

1. EBS ボリュームタイプの全体像

SSD ボリューム（ランダム I/O）

タイプ Max IOPS Max スループット レイテンシ 耐久性 用途 2025-2026 状況
gp3 80,000 2,000 MiB/s <10ms（99%） 99.8-99.9% 汎用・推奨 2025年9月に拡張。gp2完全置換可能
gp2 16,000 250 MiB/s <10ms（99%） 99.8-99.9% レガシー gp3へ移行推奨。保守性低下
io2 Block Express 256,000 4,000 MiB/s <500µs（平均） 99.999% 超高IOPS DB 全リージョン対応。Oracle/SAP HANA向け
io1 64,000 1,000 MiB/s <1ms（99%） 99.9% 高IOPS（レガシー） io2 Block Express推奨

HDD ボリューム（シーケンシャル I/O）

タイプ Max IOPS Max スループット 用途 ブート
st1 500 500 MiB/s BigData、DWH、ログ処理 不可
sc1 250 250 MiB/s コールドデータ、低アクセス 不可

2. ボリュームタイプ選定マトリックス

flowchart TD
    A["ボリュームタイプ選定フロー"] -->|ブートボリューム| B["gp3<br/>推奨"]
    A -->|高IOPS DB| C{IOPS要件}
    C -->|<16K IOPS| D["gp3<br/>コスト最適"]
    C -->|16K-64K IOPS| E["io1<br/>または gp3高設定"]
    C -->|>64K IOPS| F["io2 Block Express<br/>256K IOPS/4000MiB/s"]
    A -->|シーケンシャル大容量| G["st1<br/>500MiB/s"]
    A -->|コスト最優先| H["sc1<br/>or st1"]
    A -->|複数インスタンス共有| I{"Multi-Attach"}
    I -->|必須| J["io1/io2"]
    I -->|不要| K["gp3推奨"]

3. gp3 の独立プロビジョニング

gp3 の革新的な特徴は IOPS とスループットをボリュームサイズから切り離せる こと:

基本設定:
  ボリュームサイズ: 50 GB
  IOPS: 3,000（基本）
  スループット: 125 MiB/s（基本）
  → コスト: $5 + ゼロ追加

スケールアップ:
  ボリュームサイズ: 50 GB（変わらず）
  IOPS: 16,000（+13,000）
  スループット: 500 MiB/s（+375）
  → コスト: $5 + $208/月（16K IOPS@$0.016/IOPS/月）

最大設定:
  ボリュームサイズ: 50 GB
  IOPS: 80,000
  スループット: 2,000 MiB/s
  → コスト: $5 + $1,280/月（80K IOPS）+ $600/月（1,875 MiB/s超過分）

gp2 との違い:

  • gp2: IOPS = 3 × GiB（50GB→150 IOPS固定）、スループットも連動
  • gp3: サイズ 50GB でも 80,000 IOPS 可能、独立制御で柔軟性向上

4. Multi-Attach（io1/io2）

最大16個の EC2 インスタンスが 同一 AZ 内 で同一ボリュームをアタッチ:

使用例: Oracle Real Application Clusters（RAC）
  ┌─ Oracle RAC Node 1（10.0.1.10）
  ├─ Oracle RAC Node 2（10.0.1.11）
  ├─ Oracle RAC Node 3（10.0.1.12）
  └─ Oracle RAC Node 4（10.0.1.13）
       ↓
     io2 Block Express Volume（500GB, 64K IOPS）
       ↓ iSCSI/NVMe
     Shared Disk（/dev/sdf）

重要: ファイルシステムレベルでのロック制御（STONITH等）は EC2 側で実装必須

5. Elastic Volumes（ライブ変更）

稼働中のインスタンスをダウンタイムなしで変更:

# ボリュームサイズを 100GB → 200GB に拡張
aws ec2 modify-volume \
  --volume-id vol-xxxxx \
  --size 200 \
  --region ap-northeast-1

# IOPS を 3,000 → 16,000 に増加
aws ec2 modify-volume \
  --volume-id vol-xxxxx \
  --iops 16000

# スループットを 125 → 500 MiB/s に増加（gp3）
aws ec2 modify-volume \
  --volume-id vol-xxxxx \
  --throughput 500

注意: OS 側でパーティション/ファイルシステム拡張が別途必要

6. スナップショット戦略

スナップショットの仕組み

初回スナップショット（フル）:
  ボリューム全体 100GB → S3 に保存（完全コピー）
  コスト: GB/月で課金

2回目以降（増分）:
  前回スナップショット以降の差分ブロックのみ保存
  例：10GB 差分 → 10GB 分のみ S3 追加
  効率的なコスト削減

復元:
  スナップショット（snap-xxxxx）から
    → 新ボリューム（vol-yyyyy）を別 AZ で作成可能
    → 災害復旧、環境複製に活用

Fast Snapshot Restore（FSR）

スナップショットから復元後、初回 I/O のレイテンシを解消する有料機能:

  • 通常: スナップショット復元後、初回 I/O で遅延（数秒〜分単位）

  • FSR 有効: ほぼ即座に最大 I/O 提供可能

  • コスト: 約 $0.75/snapshot-AZ/時間

  • 使用例: ゲーム・金融システムで頻繁に復元試験が必要な場合

EBS Snapshots Archive

90日以上保持するスナップショットをアーカイブ層に移動:

  • Standard Snapshot: $0.05 per GB/月
  • Archive Snapshot: $0.005 per GB/月（90%削減）
  • 取り出し料金: 復元時に$0.03/GB（1回限り）

主要ユースケース（15パターン）

1. Web サーバー＋WordPress

構成:
  ブートボリューム: gp3 30GB, 3K IOPS（デフォルト）
  データボリューム: gp3 100GB, 6K IOPS（uploads/wp-content用）
  コスト: $3 + $10/月（データ）= 約$13/月

メリット:
  - 自動スケーリングで IOPS 調整可能
  - スナップショット → AMI で環境複製

2. 高IOPS データベース（MySQL/PostgreSQL）

構成:
  ボリューム: io2 Block Express 500GB, 32K IOPS
  暗号化: KMS（Customer Managed Key）
  バックアップ: AWS Backup（日次、30日保持）
  コスト: $50 + $512（IOPS）= 約$562/月

メリット:
  - <500µs 平均レイテンシで OLTP 処理最適
  - 99.999% 耐久性で SLA 充足

3. Oracle Real Application Clusters（RAC）

構成:
  共有ストレージ: io2 Block Express 1TB, 64K IOPS, Multi-Attach
  4 ノードが同時アタッチ
  コスト: $100 + $1,024（IOPS）= 約$1,124/月

メリット:
  - 4 ノード統合で HA・負荷分散
  - I/O Fencing で データ破損防止

4. SAP HANA インメモリ DB

構成:
  メモリ: 6TB（インスタンス内蔵）
  永続化: io2 Block Express 2TB, 100K IOPS
  レイテンシ: <500µs で リアルタイム分析
  コスト: $200 + $1,600（IOPS）= 約$1,800/月

メリット:
  - <500µs で トランザクション 10万件/秒超え

5. SQL Server AlwaysOn Availability Group

構成:
  Primary: io2 300GB, 16K IOPS
  Secondary（別AZ）: スナップショット復元
  同期レプリケーション: EBS 自体の距離<50km
  コスト: $30 + $256 = 約$286/月

メリット:
  - RTO < 1分、RPO ほぼゼロ

6. Elasticsearch クラスター

構成:
  各ノード: gp3 1TB, 8K IOPS, 500 MiB/s
  3 ノード × $100 + $128 = 約$384/月

メリット:
  - スケーリング時に IOPS 動的調整
  - スナップショットで索引バックアップ

7. MongoDB シャードクラスター

構成:
  Shard 1-4: 各 io2 500GB, 16K IOPS
  コンフィグサーバー: gp3 50GB, 3K IOPS
  コスト: 約$1,500/月

メリット:
  - 低遅延 write concern "majority"

8. Cassandra マルチリージョン

構成:
  各リージョン: gp3 500GB, 10K IOPS
  スナップショット定期: クロスリージョンコピー
  コスト: リージョン × $550/月

メリット:
  - 地理分散で レプリケーション低遅延

9. ビッグデータ（Hadoop/Spark）

構成:
  ブートボリューム: gp3 50GB
  データボリューム: st1 10TB, 500 MiB/s（シーケンシャル最適）
  コスト: $5 + $500 = 約$505/月

メリット:
  - st1 で 500 MiB/s スループット確保
  - BigData エコシステム最適

10. 機械学習（SageMaker トレーニング）

構成:
  データセット: gp3 500GB, 6K IOPS
  モデルチェックポイント: EBS Snapshots（各エポック）
  コスト: $50 + $96 = 約$146/月

メリット:
  - 高速データロード with gp3
  - スナップショット復元で失敗時の復旧迅速

11. データウェアハウス（Redshift）

構成:
  ブート: gp3 100GB
  スロー用: st1 50TB（スループット最適）
  コスト: $10 + $5,000/月

メリット:
  - st1 の 500 MiB/s で 大規模クエリ処理

12. 動画エンコーディング（Media Services）

構成:
  入力: gp3 2TB, 10K IOPS
  出力: st1 5TB, 500 MiB/s
  ワーク: gp3 500GB（インスタンスストア+EBS）
  コスト: 約$2,500/月

メリット:
  - 並列エンコーディング時に gp3 で I/O 分散

13. マルチテナント SaaS

構成:
  テナント#1-100: 各 gp3 100GB, 3K IOPS
  共有バックアップ: EBS Snapshots Archive
  コスト: 100 × $15 = $1,500/月

メリット:
  - テナント数増加時に IOPS スケール
  - Snapshots Archive で長期保存コスト削減

14. 金融システム（コンプライアンス重視）

構成:
  トランザクション DB: io2 Block Express 500GB, 32K IOPS
  暗号化: KMS（Customer Managed Key）
  監査ログ: CloudTrail + Snapshots
  バックアップ: AWS Backup（日次、7年保持）
  コスト: 約$1,200/月

メリット:
  - 99.999% 耐久性で SLA 保証
  - KMS Audit で コンプライアンス監査 実装可能

15. ハイブリッドクラウド（オンプレ + AWS）

構成:
  オンプレ DB: NFS 経由で EBS に定期同期
  AWS データベース: io1 Multi-Attach で段階的移行
  コスト: DataSync 転送料金 + EBS

メリット:
  - 無停止で段階的移行可能
  - スナップショットで バージョン管理

設定・操作の具体例

AWS CLI で gp3 ボリューム作成

# 基本的な gp3 ボリュームを作成
aws ec2 create-volume \
  --volume-type gp3 \
  --size 100 \
  --iops 3000 \
  --throughput 125 \
  --availability-zone ap-northeast-1a \
  --encrypted \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=my-app-data},{Key=Environment,Value=prod}]'

# 結果例
{
  "Volume": {
    "VolumeId": "vol-0a1b2c3d4e5f6g7h8",
    "State": "creating",
    "Size": 100,
    "VolumeType": "gp3",
    "Iops": 3000,
    "Throughput": 125
  }
}

gp3 ボリュームを EC2 インスタンスにアタッチ

# ボリュームをインスタンスにアタッチ
aws ec2 attach-volume \
  --volume-id vol-0a1b2c3d4e5f6g7h8 \
  --instance-id i-0123456789abcdef0 \
  --device /dev/sdf

# OS 側でマウント（Linux）
sudo lsblk  # デバイス確認（例：nvme1n1）
sudo mkfs.ext4 /dev/nvme1n1
sudo mkdir /data
sudo mount /dev/nvme1n1 /data
sudo chown -R ubuntu:ubuntu /data

# fstab に追加（永続化）
echo 'UUID=$(blkid -s UUID -o value /dev/nvme1n1) /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

Elastic Volumes で IOPS 変更

# IOPS を 3,000 → 10,000 に変更（ダウンタイムなし）
aws ec2 modify-volume \
  --volume-id vol-0a1b2c3d4e5f6g7h8 \
  --iops 10000

# スループットを同時に変更
aws ec2 modify-volume \
  --volume-id vol-0a1b2c3d4e5f6g7h8 \
  --iops 10000 \
  --throughput 500

# 変更状況を確認
aws ec2 describe-volumes-modifications \
  --volume-id vol-0a1b2c3d4e5f6g7h8 \
  --query 'VolumesModifications[0].[Progress,ModificationState]' \
  --output text
# 出力例: 100 completed

EBS スナップショット作成・管理

# スナップショットを作成
aws ec2 create-snapshot \
  --volume-id vol-0a1b2c3d4e5f6g7h8 \
  --description "Daily backup - $(date +%Y-%m-%d)" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=AutoDelete,Value=30days}]'

# スナップショット一覧
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[*].[SnapshotId,StartTime,State,VolumeSize]' \
  --output table

# Fast Snapshot Restore を有効化（USA/Tokyo のみ $0.75/snap-AZ/時間）
aws ec2 enable-fast-snapshot-restores \
  --source-snapshot-ids snap-0a1b2c3d4e5f6g7h8 \
  --availability-zones ap-northeast-1a ap-northeast-1c

# スナップショットからボリュームを復元（別 AZ）
aws ec2 create-volume \
  --snapshot-id snap-0a1b2c3d4e5f6g7h8 \
  --availability-zone ap-northeast-1c \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 250

AWS Backup で自動スナップショット管理

# バックアッププランを作成
aws backup create-backup-plan \
  --backup-plan '{
    "BackupPlanName": "daily-ebs-backup",
    "Rules": [
      {
        "RuleName": "DailyBackup",
        "TargetBackupVault": "Default",
        "ScheduleExpression": "cron(0 5 ? * * *)",
        "StartWindowMinutes": 60,
        "CompletionWindowMinutes": 120,
        "Lifecycle": {
          "DeleteAfterDays": 30,
          "MoveToColdStorageAfterDays": 90
        }
      }
    ]
  }'

# EBS ボリュームをバックアッププランに割り当て
aws backup create-backup-selection \
  --backup-plan-id 12345678-1234-1234-1234-123456789012 \
  --backup-selection '{
    "SelectionName": "ebs-volumes",
    "Type": "RESOURCES",
    "Resources": ["arn:aws:ec2:ap-northeast-1:123456789012:volume/*"],
    "ListOfTags": [
      {
        "ConditionType": "StringEquals",
        "ConditionKey": "Backup",
        "ConditionValue": "true"
      }
    ]
  }'

Terraform での gp3 + io2 設定例

# gp3 ボリューム作成
resource "aws_ebs_volume" "app_data" {
  availability_zone = "ap-northeast-1a"
  size              = 100
  type              = "gp3"
  iops              = 6000
  throughput        = 250
  encrypted         = true
  kms_key_id        = aws_kms_key.ebs.arn

  tags = {
    Name        = "app-data-volume"
    Environment = "prod"
  }
}

# io2 Block Express ボリューム
resource "aws_ebs_volume" "database" {
  availability_zone = "ap-northeast-1a"
  size              = 500
  type              = "io2"
  iops              = 32000
  encrypted         = true

  tags = {
    Name = "database-volume"
  }
}

# EC2 インスタンスにアタッチ
resource "aws_volume_attachment" "app_data_attach" {
  device_name = "/dev/sdf"
  volume_id   = aws_ebs_volume.app_data.id
  instance_id = aws_instance.app_server.id
}

# スナップショット自動作成ルール
resource "aws_dlm_lifecycle_policy" "ebs_snapshots" {
  description        = "EBS daily snapshots with 30-day retention"
  execution_role_arn = aws_iam_role.dlm_role.arn
  state               = "ENABLED"

  policy_details {
    policy_type = "EBS_SNAPSHOT_MANAGEMENT"

    schedule {
      name = "Daily"
      
      create_rule {
        interval      = 24
        interval_unit = "HOURS"
        times         = ["03:00"]
      }

      retain_rule {
        count = 30
      }

      tags_to_add = {
        Backup = "daily"
      }

      copy_tags = true
    }

    target_tags = {
      Backup = "true"
    }
  }
}

他の類似ツール・サービスとの比較

観点 EBS EFS FSx for Windows S3
アクセス形態 ブロック（単一AZ） NFS（複数AZ） SMB（複数AZ） オブジェクト API
ファイルシステム ext4/xfs/NTFS POSIX（Linux/Mac） NTFS（Windows） -
レイテンシ <1ms ~1ms ~1ms ~100ms
最大IOPS 256K（io2） 2.5M（Elastic） 8K-32K N/A（API）
複数インスタンス共有 Multi-Attach（特殊） 標準対応 標準対応 標準対応
AZ 制約 単一AZ 複数AZ 複数AZ グローバル
主な用途 OS、DB コンテナ共有 Windows共有 静止データ、バックアップ
2026年推奨判断 gp3がデフォルト Elastic推奨 Windows環境 大容量アーカイブ

クライアントとエコシステム

AWS コンソール・CLI との統合

  • AWS Management Console: EC2 → ボリューム → ダッシュボード（容量、IOPS 可視化）
  • AWS CLI: aws ec2 {create,modify,describe}-volume* で完全操作
  • CloudWatch: VolumeReadBytes, VolumeWriteBytes, BurstBalance（gp2）メトリクス
  • AWS Backup: ボリューム自動バックアップ、ライフサイクル管理

IaC ツール

  • Terraform: aws_ebs_volume, aws_volume_attachment リソース
  • CloudFormation: AWS::EC2::Volume タイプ
  • AWS CDK: Python/TypeScript で定義

OS サポート

  • Linux: ext4、xfs、btrfs（ファイルシステム）
  • Windows: NTFS、ReFS（EBS for Windows）
  • Unix: UFS（BSD互換）

ベストプラクティス（✅ / ❌）

✅ DO

  • gp3 をデフォルトに: gp2 は廃止予定。新規は全て gp3
  • IOPS/スループット独立設定: ボリュームサイズから切り離して最適化
  • EBS 最適化インスタンス使用: io1/io2 で性能を完全発揮
  • スナップショット自動化: AWS Backup or Data Lifecycle Manager で日次バックアップ
  • 暗号化（KMS）: デフォルト暗号化を有効化し、カスタマーマネージドキー導入
  • モニタリング: CloudWatch で CPU、I/O メトリクスを常時監視
  • Elastic Volumes: 必要に応じてダウンタイムなく容量調整
  • マルチ AZ 構成: スナップショット復元で別 AZ への DR 対応

❌ DON’T

  • gp2 を使い続ける: 性能は同じ、単価は割高。gp3 移行で 60-87% コスト削減
  • スナップショット未設定: AZ 障害でデータ消失リスク
  • Multi-Attach で排他制御なし: データ破損のリスク。クラスターファイルシステム（GFS2等）または STONITH 実装必須
  • HDD（st1/sc1）をランダム I/O に使用: IOPS 極端に低い（<500）
  • io1 新規導入: io2 Block Express が優位。64K IOPS が必要なら io2
  • ボリュームサイズを過剰プロビジョニング: gp3 は IOPS をサイズから切り離せるため最小限で OK
  • 暗号化なし: コンプライアンス要件で必須化。デフォルト暗号化設定
  • Fast Snapshot Restore を常時有効: 費用高い($0.75/snap-AZ/時間)。復元試験時のみ有効化推奨

トラブルシューティング

症状 原因 対策
I/O が遅い（>50ms） gp2 で IOPS 上限到達、またはバースト枯渇 gp3 へ移行し IOPS 増加、または IOPS 値を増加
レイテンシ高い（>1ms） EBS 最適化インスタンス非使用、またはネットワーク混雑 EBS 最適化インスタンスに変更、またはインスタンスタイプ変更
スナップショット作成に時間 ボリューム変更中、またはスナップショット数超過 変更完了待つ、またはスナップショット削除
復元後の初回 I/O 遅い Fast Snapshot Restore 未設定 復元前に FSR を有効化（コスト有）
スナップショットから復元できない スナップショット所有権喪失、または容量超過 所有権確認、または復元ボリューム容量を確認
Multi-Attach で接続できない セキュリティグループで NVMe ポート（TCP/UDP 4420）遮断 セキュリティグループのインバウンドルール確認
Elastic Volumes で IOPS 変更できない 変更中に別の変更リクエスト、または上限到達 変更完了確認（describe-volumes-modifications）、または AWS サポートに上限申請
EBS 暗号化で性能低下 KMS キー操作が遅い 暗号化オーバーヘッド~5%（許容内）、キーキャッシュ確認
AMI 作成時にスナップショット失敗 EBS 容量不足 スナップショット数削減、または古いスナップショット削除
gp2 から gp3 移行で コスト増加 IOPS 高すぎる設定 不要な IOPS 削減（測定ツール：fio、dd で実測）

2025-2026 最新動向

1. gp3 の拡張（2025年9月）

  • IOPS 上限: 16,000 → 80,000 に拡張（前5倍）
  • スループット: 1,000 → 2,000 MiB/s（倍増）
  • 容量: 最大 64 TiB まで対応
  • 影響: io1 がほぼ不要に。新規は全て gp3 推奨

2. io2 Block Express 全リージョン対応

  • 2025年内に全リージョンで io2 Block Express 利用可能
  • 東京、シンガポール、シドニーリージョンでも稼働
  • グローバル高IOPS DB 構成が容易に

3. EBS Snapshots Archive

  • 90日以上保持で自動アーカイブ可能
  • コスト 90% 削減（0.05/GB → 0.005/GB/月）
  • 規制要件の7年保持を低コストで実現可能

4. Multi-Attach with I/O Fencing

  • io2 Block Express で I/O Fencing 実装
  • RAC、クラスターDB のネイティブサポート向上

5. CloudWatch 監視強化

  • PercentIOLimit メトリクスでボトルネック可視化
  • BurstBalance が廃止（Elastic での無制限化）

学習リソース

AWS 公式

テックブログ

実装ガイド

オープンソース

  • fio: EBS ベンチマークツール
  • DD: シーケンシャル I/O テスト

実装例

小規模（スタートアップ向け）

構成:
  - Web サーバー×2: gp3 30GB, 3K IOPS（Auto Scaling）
  - RDS MySQL: io1 100GB, 3K IOPS（別途管理）
  - バックアップ: AWS Backup（日次、30日保持）

コスト: 約 $100/月

イメージ: WordPress + eコマース（月PV 10万）

中規模（成長期スタートアップ）

構成:
  - Web サーバー×5: gp3 50GB, 6K IOPS
  - キャッシュ（Redis）: io1 50GB, 10K IOPS
  - MySQL DB（Primary）: io2 300GB, 16K IOPS
  - MySQL DB（Replica, 別AZ）: スナップショット復元
  - バックアップ: AWS Backup + DLM（日次+月次）

コスト: 約 $1,500/月

イメージ: SaaS アプリ（DAU 1万）

大規模（エンタープライズ）

構成:
  - Web サーバー×50: gp3 100GB, 10K IOPS（ALB+ASG）
  - Oracle RAC（4ノード）: io2 Block Express 1TB, 64K IOPS, Multi-Attach
  - キャッシュ（Redis Cluster）: 複数ノード×io1 100GB
  - バックアップ: AWS Backup（時間単位）+ Snapshots Archive（長期保存）
  - DR: クロスリージョン スナップショット複製

コスト: 約 $15,000/月

イメージ: エンタープライズ ERP（同時接続1万+）

導入ロードマップ

Phase 1: 評価・計画（1-2週間）

  1. 既存 EBS 構成調査（gp2 台数、IOPS 使用率）
  2. CloudWatch メトリクス取得（過去30日）
  3. gp3 へのコスト削減幅計算
  4. バックアップ戦略決定（自動化レベル）

Phase 2: PoC（2-4週間）

  1. テスト環境で gp3 ボリューム作成
  2. fio/dd で性能ベンチマーク（gp2 vs gp3）
  3. Elastic Volumes での IOPS 変更テスト
  4. スナップショット復元テスト

Phase 3: 本番移行（4-12週間）

  1. バッチ処理: gp2 → gp3 Elastic Volumes で段階的変更
  2. AWS Backup でスナップショット自動化開始
  3. CloudWatch アラーム設定（I/O 上限、スナップショット失敗）
  4. 運用トレーニング（SRE チーム）

Phase 4: 最適化・運用（継続）

  1. CloudWatch メトリクス監視（月1回レビュー）
  2. 不要な IOPS 削減（コスト最適化）
  3. Snapshots Archive 活用（90日以上保持）
  4. 災害復旧訓練（年2回以上）

実装チェックリスト

  • [ ] gp2 → gp3 移行計画書を作成したか
  • [ ] IOPS/スループット要件を定義したか（fio/CloudWatch で測定）
  • [ ] EBS 最適化インスタンスを使用しているか
  • [ ] デフォルト暗号化を有効化し、カスタマーマネージドキー導入したか
  • [ ] AWS Backup またはスナップショット自動化を設定したか（日次以上）
  • [ ] Snapshots Archive で長期保存コスト削減できるか確認したか
  • [ ] CloudWatch で BurstBalance（gp2）, VolumeThroughputPercentage を監視しているか
  • [ ] Multi-Attach を使う場合、排他制御（GFS2等）を実装したか
  • [ ] Fast Snapshot Restore が必要か（復元テスト頻度）確認したか
  • [ ] ディザスタリカバリー テストを実施したか（スナップショット復元→起動）
  • [ ] 運用チーム向けに Elastic Volumes の IOPS 変更手順を文書化したか
  • [ ] Cost Explorer で EBS コスト削減効果をモニタリングしているか

まとめ

Amazon EBS は EC2 インスタンスのブロックストレージ基盤 であり、2025-2026年では gp3 が全用途のデフォルト推奨 となりました。gp3 の IOPS/スループット拡張（80K/2000 MiB/s）により gp2 から 60-87% のコスト削減が可能です。

超高IOPS（>80K）や99.999%耐久性が必要な場合は io2 Block Express（256K IOPS、<500µs）を選択。Multi-Attach により RAC・クラスターDB への対応も容易化しました。

スナップショット自動化（AWS Backup/DLM）、EBS Snapshots Archive、KMS 暗号化を初期段階から組み込むことで、エンタープライズグレードの信頼性と規制対応を同時に実現できます。

参考文献

AWS 公式（10+）

テックブログ・OSS（5+）

最終更新: 2026-04-26
バージョン: v2.0