EC2のストレージとAMIを理解する

前回の記事では、EC2インスタンスの起動と接続方法について解説しました。本記事では、EC2のストレージサービスであるEBS（Elastic Block Store）と、インスタンスのテンプレートであるAMI（Amazon Machine Image）について詳しく解説します。EBSボリュームの種類と選び方、スナップショットによるバックアップ、AMIの作成と活用方法を理解し、EC2インスタンスのストレージ管理スキルを身につけましょう。

EC2のストレージオプション

EC2インスタンスで使用できるストレージには、大きく分けて「EBS（Elastic Block Store）」と「インスタンスストア」の2種類があります。それぞれの特性を理解し、用途に応じて適切に選択することが重要です。

EBSとインスタンスストアの違い

graph TB
    subgraph "EC2ストレージの種類"
        subgraph EBS["EBS（ネットワーク接続）"]
            E1[永続的ストレージ]
            E2[スナップショット対応]
            E3[サイズ変更可能]
            E4[別インスタンスに付け替え可能]
        end
        
        subgraph Instance["インスタンスストア（ローカル）"]
            I1[一時的ストレージ]
            I2[高速I/O]
            I3[追加コストなし]
            I4[停止・終了でデータ消失]
        end
    end
    
    EC2[EC2インスタンス] --> EBS
    EC2 --> Instance

インスタンスストアの特徴

インスタンスストア（エフェメラルストレージ）は、EC2インスタンスが動作するホストコンピューターに物理的に接続されたディスクです。高いI/O性能を提供しますが、データの永続性が保証されません。

インスタンスストアのデータが失われるケース

• インスタンスの停止（Stop）
• インスタンスの終了（Terminate）
• ホストコンピューターのハードウェア障害
• インスタンスの休止（Hibernate）

インスタンスストアが適しているユースケース

• バッファ、キャッシュ、スクラッチデータ
• 一時的なコンテンツ（セッションデータなど）
• 複製されているデータ（分散ファイルシステムのレプリカなど）

インスタンスストアは、すべてのインスタンスタイプで利用できるわけではありません。i3、d3、c5dなどの特定のインスタンスタイプでのみ利用可能です。

EBS（Elastic Block Store）の基礎

EBSは、EC2インスタンスで使用する永続的なブロックストレージサービスです。ファイルシステムの作成、データベースの実行、OSのインストールなど、幅広い用途で利用されます。

EBSの主な特徴

EBSボリュームのライフサイクル

EBSボリュームは、インスタンスとは独立したライフサイクルを持ちます。インスタンスを終了してもボリュームを保持したり、別のインスタンスにアタッチし直したりできます。

stateDiagram-v2
    [*] --> creating: ボリューム作成
    creating --> available: 作成完了
    available --> in_use: アタッチ
    in_use --> available: デタッチ
    in_use --> in_use: スナップショット作成
    available --> deleting: 削除
    deleting --> [*]: 削除完了

EBSとインスタンスの関係

1つのEBSボリュームは、基本的に1つのインスタンスにのみアタッチできます（マルチアタッチ機能を使用する場合を除く）。一方、1つのインスタンスには複数のEBSボリュームをアタッチできます。

graph LR
    subgraph "EC2インスタンス"
        EC2[インスタンス]
    end
    
    subgraph "EBSボリューム"
        Root[ルートボリューム<br/>/dev/xvda]
        Data1[データボリューム1<br/>/dev/xvdb]
        Data2[データボリューム2<br/>/dev/xvdc]
    end
    
    EC2 --> Root
    EC2 --> Data1
    EC2 --> Data2

ルートボリュームとデータボリューム

• ルートボリューム: OSがインストールされているボリューム。インスタンス起動時に自動的に作成される
• データボリューム: アプリケーションデータ用に追加でアタッチするボリューム

EBSボリュームタイプの種類と選び方

EBSには複数のボリュームタイプがあり、パフォーマンス要件とコストのバランスに応じて選択します。大きく「SSDベース」と「HDDベース」に分類されます。

SSDベースのボリュームタイプ

SSDベースのボリュームは、ランダムI/Oが多いワークロードに適しています。IOPSがパフォーマンスの主要指標です。

gp3（汎用SSD）

gp3は、コストパフォーマンスに優れた汎用SSDボリュームです。多くのワークロードで第一選択となります。

gp3では、IOPS とスループットをボリュームサイズとは独立してプロビジョニングできます。必要な分だけ性能を追加できるため、コスト効率が高いです。

gp2（汎用SSD、旧世代）

gp2は、gp3の前世代の汎用SSDボリュームです。IOPSがボリュームサイズに比例する特性があります。

gp2は新規利用には推奨されません。既存のgp2ボリュームはgp3への移行を検討してください。

io2 Block Express（プロビジョンドIOPS SSD、最高性能）

io2 Block Expressは、ミッションクリティカルなワークロード向けの最高性能ボリュームです。

io2 Block Expressの用途

• 大規模なリレーショナルデータベース（Oracle、SQL Server、SAP HANA）
• NoSQLデータベース（MongoDB、Cassandra）
• I/O集約的なトランザクション処理

io1（プロビジョンドIOPS SSD）

io1は、io2の前世代のプロビジョンドIOPSボリュームです。

io1は高い性能が必要な場合に使用しますが、可能であればio2への移行を推奨します。

HDDベースのボリュームタイプ

HDDベースのボリュームは、シーケンシャルI/Oが多いワークロードに適しています。スループットがパフォーマンスの主要指標です。

st1（スループット最適化HDD）

st1は、高スループットを必要とするワークロード向けの低コストHDDボリュームです。

st1の用途

• ビッグデータ処理
• データウェアハウス
• ログ処理
• ETL処理

sc1（Cold HDD）

sc1は、アクセス頻度の低いデータ向けの最低コストHDDボリュームです。

sc1の用途

• アーカイブデータ
• バックアップ
• アクセス頻度の低いデータ

ボリュームタイプの比較と選択基準

flowchart TD
    Start[ボリュームタイプ選択] --> Q1{ブートボリューム?}
    Q1 -->|はい| SSD[SSDを選択]
    Q1 -->|いいえ| Q2{高IOPSが必要?}
    
    Q2 -->|はい| Q3{最高性能が必要?}
    Q2 -->|いいえ| Q4{高スループットが必要?}
    
    Q3 -->|はい| io2[io2 Block Express]
    Q3 -->|いいえ| gp3_1[gp3]
    
    Q4 -->|はい| Q5{アクセス頻度は?}
    Q4 -->|いいえ| gp3_2[gp3]
    
    Q5 -->|高い| st1[st1]
    Q5 -->|低い| sc1[sc1]
    
    SSD --> gp3_3[gp3]

EBSボリュームの操作

EBSボリュームの作成

AWSマネジメントコンソールからEBSボリュームを作成する手順を説明します。

1. EC2コンソールを開き、左メニューから「ボリューム」を選択
2. 「ボリュームを作成」をクリック
3. 以下の設定を入力
   • ボリュームタイプ: gp3など
   • サイズ: 必要なサイズ（GiB）
   • IOPS: gp3/io2の場合、必要に応じて設定
   • スループット: gp3の場合、必要に応じて設定
   • アベイラビリティゾーン: インスタンスと同じAZを選択
   • 暗号化: 推奨
4. 「ボリュームを作成」をクリック

EBSボリュームのアタッチ

作成したボリュームをインスタンスにアタッチする手順です。

1. ボリューム一覧から対象ボリュームを選択
2. 「アクション」→「ボリュームのアタッチ」を選択
3. アタッチ先のインスタンスとデバイス名を指定
4. 「アタッチ」をクリック

デバイス名の命名規則

Linuxでのボリュームマウント

アタッチしたボリュームをLinuxで使用するには、ファイルシステムの作成とマウントが必要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# アタッチされたボリュームの確認
lsblk

# ファイルシステムの作成（新規ボリュームの場合のみ）
sudo mkfs -t xfs /dev/xvdb

# マウントポイントの作成
sudo mkdir /data

# ボリュームのマウント
sudo mount /dev/xvdb /data

# マウントの確認
df -h

永続的なマウント設定

再起動後も自動マウントするには、/etc/fstabに設定を追加します。

1
2
3
4
5
6
7
8

# UUIDの確認
sudo blkid /dev/xvdb

# /etc/fstabに追加
echo "UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults,nofail 0 2" | sudo tee -a /etc/fstab

# 設定のテスト
sudo mount -a

EBSボリュームのサイズ変更

EBSボリュームは、ダウンタイムなしでサイズを拡張できます（縮小はできません）。

コンソールでのサイズ変更

1. ボリュームを選択し、「アクション」→「ボリュームの変更」を選択
2. 新しいサイズを入力
3. 「変更」をクリック

ファイルシステムの拡張（Linux）

ボリュームサイズ変更後、ファイルシステムも拡張する必要があります。

1
2
3
4
5
6
7
8

# パーティションの拡張（パーティションがある場合）
sudo growpart /dev/xvdb 1

# XFSファイルシステムの拡張
sudo xfs_growfs /data

# ext4ファイルシステムの拡張
sudo resize2fs /dev/xvdb

EBSスナップショット

EBSスナップショットは、EBSボリュームのポイントインタイムバックアップです。Amazon S3に保存され、増分バックアップとして効率的に管理されます。

スナップショットの特徴

graph TB
    subgraph "スナップショットの仕組み"
        Vol[EBSボリューム] -->|初回| Snap1[スナップショット1<br/>フルバックアップ]
        Vol -->|2回目| Snap2[スナップショット2<br/>変更分のみ]
        Vol -->|3回目| Snap3[スナップショット3<br/>変更分のみ]
        
        Snap1 --> S3[(Amazon S3)]
        Snap2 --> S3
        Snap3 --> S3
    end

スナップショットの作成

1
2
3
4
5

# AWS CLIでスナップショットを作成
aws ec2 create-snapshot \
    --volume-id vol-0123456789abcdef0 \
    --description "Daily backup $(date +%Y-%m-%d)" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=daily-backup}]'

コンソールでの作成手順

1. ボリュームを選択し、「アクション」→「スナップショットを作成」を選択
2. 説明とタグを入力
3. 「スナップショットを作成」をクリック

スナップショットからのボリューム復元

スナップショットから新しいEBSボリュームを作成できます。

1
2
3
4
5
6
7

# スナップショットからボリュームを作成
aws ec2 create-volume \
    --availability-zone ap-northeast-1a \
    --snapshot-id snap-0123456789abcdef0 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

スナップショットのライフサイクル管理

Amazon Data Lifecycle Manager（DLM）を使用して、スナップショットの自動作成と保持期間の管理を自動化できます。

graph LR
    subgraph "Data Lifecycle Manager"
        Policy[ライフサイクルポリシー] --> Schedule[スケジュール<br/>毎日 03:00]
        Schedule --> Create[スナップショット作成]
        Create --> Retain[保持<br/>7日間]
        Retain --> Delete[古いスナップショット削除]
    end

DLMポリシーの設定例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [
        {
            "Key": "Backup",
            "Value": "true"
        }
    ],
    "Schedules": [
        {
            "Name": "DailySnapshots",
            "CreateRule": {
                "Interval": 24,
                "IntervalUnit": "HOURS",
                "Times": ["03:00"]
            },
            "RetainRule": {
                "Count": 7
            },
            "CopyTags": true
        }
    ]
}

スナップショットのクロスリージョンコピー

災害復旧（DR）対策として、スナップショットを別リージョンにコピーできます。

1
2
3
4
5
6

# スナップショットを別リージョンにコピー
aws ec2 copy-snapshot \
    --source-region ap-northeast-1 \
    --source-snapshot-id snap-0123456789abcdef0 \
    --destination-region us-west-2 \
    --description "DR copy from Tokyo"

AMI（Amazon Machine Image）

AMIは、EC2インスタンスを起動するためのテンプレートです。OS、アプリケーション、設定、EBSボリュームの構成情報が含まれており、同じ構成のインスタンスを繰り返し作成できます。

AMIの構成要素

graph TB
    subgraph "AMIの構成"
        AMI[AMI]
        
        subgraph "起動許可"
            Public[パブリック]
            Private[プライベート]
            Shared[共有]
        end
        
        subgraph "ブロックデバイスマッピング"
            Root[ルートボリューム<br/>スナップショット]
            Data[データボリューム<br/>スナップショット]
        end
        
        AMI --> Public
        AMI --> Private
        AMI --> Shared
        AMI --> Root
        AMI --> Data
    end

AMIの種類

AMIは、ルートデバイスのタイプによって2種類に分類されます。

現在は、EBS-backed AMIが主流です。

カスタムAMIの作成

既存のインスタンスからカスタムAMIを作成する手順を説明します。

作成前の準備

1. インスタンスにインストールしたソフトウェアや設定を確認
2. 不要なファイル（ログ、キャッシュ、秘密鍵など）を削除
3. 必要に応じてインスタンスを停止（データの整合性を確保）

1
2
3
4
5

# 不要なファイルのクリーンアップ例
sudo rm -rf /var/log/*
sudo rm -rf /tmp/*
sudo rm -f /root/.ssh/authorized_keys
sudo rm -f /home/ec2-user/.ssh/authorized_keys

コンソールでのAMI作成

1. EC2コンソールでインスタンスを選択
2. 「アクション」→「イメージとテンプレート」→「イメージを作成」を選択
3. 以下の情報を入力
   • イメージ名: 識別しやすい名前
   • イメージの説明: 用途やバージョン情報
   • 再起動しない: チェックを外す（推奨、データ整合性のため）
4. 「イメージを作成」をクリック

AWS CLIでのAMI作成

1
2
3
4
5
6

# AMIの作成
aws ec2 create-image \
    --instance-id i-0123456789abcdef0 \
    --name "web-server-v1.0-$(date +%Y%m%d)" \
    --description "Web server with Apache and PHP" \
    --no-reboot false

AMIの活用パターン

graph TB
    subgraph "AMI活用パターン"
        Base[ベースAMI<br/>Amazon Linux 2023]
        
        Base --> Custom1[カスタムAMI<br/>Webサーバー]
        Base --> Custom2[カスタムAMI<br/>アプリサーバー]
        Base --> Custom3[カスタムAMI<br/>バッチサーバー]
        
        Custom1 --> Instance1[本番Webサーバー1]
        Custom1 --> Instance2[本番Webサーバー2]
        Custom1 --> Instance3[開発Webサーバー]
        
        Custom2 --> ASG[Auto Scalingグループ]
    end

ゴールデンイメージパターン

組織で標準化されたAMI（ゴールデンイメージ）を作成し、すべてのインスタンスで使用するパターンです。

AMIのバージョン管理

AMIの命名規則を定め、バージョン管理を行うことが重要です。

{プロジェクト名}-{用途}-{バージョン}-{日付}
例: myapp-web-v1.2.0-20260125

AMIのクロスリージョンコピー

AMIを別リージョンにコピーして、マルチリージョン展開やDR対策に活用できます。

1
2
3
4
5
6
7

# AMIを別リージョンにコピー
aws ec2 copy-image \
    --source-region ap-northeast-1 \
    --source-image-id ami-0123456789abcdef0 \
    --name "web-server-v1.0-us-west-2" \
    --description "Copy of web server AMI for DR" \
    --region us-west-2

AMIの共有

AMIを他のAWSアカウントと共有できます。

1
2
3
4
5
6
7
8
9

# 特定のアカウントとAMIを共有
aws ec2 modify-image-attribute \
    --image-id ami-0123456789abcdef0 \
    --launch-permission "Add=[{UserId=123456789012}]"

# 共有を解除
aws ec2 modify-image-attribute \
    --image-id ami-0123456789abcdef0 \
    --launch-permission "Remove=[{UserId=123456789012}]"

AMI共有時の注意点

• 暗号化されたAMIを共有する場合、KMSキーも共有が必要
• 機密情報が含まれていないか確認
• 共有先アカウントを定期的に確認

EBSの暗号化

EBSボリュームとスナップショットの暗号化は、データ保護の重要な要素です。AWS KMS（Key Management Service）を使用した透過的な暗号化を提供します。

暗号化の仕組み

graph LR
    subgraph "EBS暗号化の流れ"
        App[アプリケーション] -->|平文データ| EC2[EC2インスタンス]
        EC2 -->|暗号化| EBS[EBSボリューム]
        EBS -->|暗号化データ| Snap[スナップショット]
        KMS[AWS KMS] -->|データキー| EC2
    end

デフォルト暗号化の有効化

アカウントレベルでデフォルト暗号化を有効にすると、新規作成されるすべてのEBSボリュームが自動的に暗号化されます。

1
2
3
4
5
6

# デフォルト暗号化を有効化
aws ec2 enable-ebs-encryption-by-default

# デフォルト暗号化キーを設定
aws ec2 modify-ebs-default-kms-key-id \
    --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

既存ボリュームの暗号化

既存の非暗号化ボリュームを暗号化するには、スナップショットを経由して暗号化ボリュームを作成します。

graph LR
    A[非暗号化ボリューム] -->|スナップショット作成| B[非暗号化スナップショット]
    B -->|コピー（暗号化オプション有効）| C[暗号化スナップショット]
    C -->|ボリューム作成| D[暗号化ボリューム]

1
2
3
4
5
6
7

# 非暗号化スナップショットを暗号化してコピー
aws ec2 copy-snapshot \
    --source-region ap-northeast-1 \
    --source-snapshot-id snap-0123456789abcdef0 \
    --encrypted \
    --kms-key-id alias/my-ebs-key \
    --description "Encrypted copy"

EBSのパフォーマンス最適化

EBS最適化インスタンス

EBS最適化インスタンスは、EBSとの通信に専用の帯域幅を確保し、ネットワークトラフィックとの競合を防ぎます。

現行世代のほとんどのインスタンスタイプでは、EBS最適化がデフォルトで有効になっています。

IOPSとスループットの関係

I/O性能は、IOPSとスループットの両方で決まります。

スループット（MiB/秒） = IOPS × I/Oサイズ（KiB） ÷ 1,024

小さいI/OサイズではIOPSがボトルネックになり、大きいI/Oサイズではスループットがボトルネックになります。

パフォーマンスモニタリング

CloudWatchメトリクスを使用してEBSのパフォーマンスを監視します。

まとめ

本記事では、EC2のストレージサービスであるEBSとAMIについて解説しました。

• EC2ストレージの種類: EBS（永続的）とインスタンスストア（一時的）の2種類があり、用途に応じて選択
• EBSボリュームタイプ: gp3が汎用的に推奨、高性能が必要な場合はio2 Block Express、大容量データにはst1/sc1
• スナップショット: 増分バックアップ方式でS3に保存、DLMで自動化可能
• AMI: インスタンスのテンプレート、ゴールデンイメージパターンで運用効率化
• 暗号化: デフォルト暗号化の有効化を推奨、既存ボリュームはスナップショット経由で暗号化

次回の記事では、EC2の料金体系と最適化について解説します。オンデマンド、リザーブドインスタンス、スポットインスタンス、Savings Plansの違いと使い分けを学び、コスト効率の高いEC2運用を実現しましょう。

参考リンク

• Amazon EBS ユーザーガイド
• Amazon EBS ボリュームタイプ
• Amazon EBS スナップショット
• Amazon Machine Images (AMI)
• Amazon EBS 暗号化
• Amazon Data Lifecycle Manager