MODULE 06 / STORAGE
データの保存先を、 使い方から選ぶ
ディスクとして使う、オブジェクトとして保存する、ファイルを共有する。アクセス方法・寿命・共有範囲から、EBS・S3・EFSを整理します。
このModuleで学ぶこと
01ブロック・オブジェクト・ファイルを使い分ける
02インスタンスストアとEBSの寿命を区別する
03S3の構造・権限・ストレージクラスを理解する
04EFSとStorage Gatewayの役割を説明する
保存の形で、 使い方が変わる
| 方式 | どうアクセスするか | AWSの例・用途 |
|---|---|---|
| ブロック | OSからディスクの領域として読み書きする | EBS:OS・アプリ・自分で運用するDB |
| オブジェクト | キーを指定し、APIでデータを取得・保存する | S3:画像・ログ・バックアップ・配信元 |
| ファイル | ディレクトリとファイル名で共有する | EFS:複数サーバーが使う共有ファイル |
ディスクの寿命を、 インスタンスと分ける
インスタンスストアは、EC2ホストに直接接続された一時的なストレージです。高速な作業領域や再作成できるキャッシュに使います。Amazon EBSは、EC2とは別に管理するブロックストレージで、同じAZのEC2に接続します。
| 操作・性質 | インスタンスストア | EBS |
|---|---|---|
| 再起動 | 通常は保持される | 通常は保持される |
| 停止・終了、ホスト障害 | データが失われる。永続保存にしない | 停止後も保持。終了時は削除設定に依存 |
| 共有・配置 | そのインスタンスに結び付く | 同じAZで接続。別AZへの復元にはスナップショットなど |
| 向く用途 | 一時データ・再生成できるデータ | OS・継続して必要なアプリのデータ |
EBSは必要な容量、IOPS(1秒あたりのI/O回数)、スループットなどでボリュームタイプを選びます。容量を増やす操作もできますが、OS側のパーティションやファイルシステムの拡張が必要な場合があります。性能は実際の処理を測って選びます。
変更分を保存し、 時点を復元する
EBSスナップショットは、ボリュームのある時点のデータをバックアップします。初回以降は変更されたブロックを保存する増分方式です。
① 初回
使用中のブロックを保存。空き領域まで丸ごとコピーするわけではありません。
② 次の保存
変更したB→Xを保存。復元時には必要な既存ブロックも使います。
③ さらに変更
変更したC→Yを保存。各時点のボリュームを復元できます。
以前のスナップショットを削除しても、後の復元に必要なブロックは保持されます。別AZへの復元、別リージョンへのコピーなどにも使えます。Data Lifecycle Managerで、対象やスケジュール・保持期間を決めてEBSの保存を自動化できます。
公式資料:EBSスナップショット ↗S3は、 キーでデータを扱う
Amazon S3はオブジェクトストレージです。バケットの中に、データ本体・キー・メタデータを持つオブジェクトを保存します。容量を先に固定したディスクとして作成する必要はありません。
- キー
images/lesson-01.png- データ本体
- 画像ファイルの内容
- メタデータ
- Content-Type:image/png など
- タグ
- 用途や分類を付ける別の仕組み
バージョニング
更新前のバージョンを保持し、誤った上書きや削除から戻せるようにします。全バージョンを削除できる権限まで防ぐ仕組みではありません。
耐久性と可用性
S3は高い耐久性を目標に設計されています。データを失いにくいことと、いつでもアクセスできることは異なります。単一AZのクラスではAZ喪失のリスクも考えます。
通常のオブジェクト保存では、キーを指定してPUTで保存・更新し、GETで取得します。オブジェクト数や全体容量を増やせても、個々のオブジェクトやリクエストには上限があります。現在のマルチパートアップロードの最大オブジェクトサイズは48.8 TiBです。上限値の暗記より、保存方式の違いを優先して理解します。
公式資料:S3の基本 ↗公式資料:マルチパートアップロードの上限 ↗誰に、何を、 許可するかを決める
S3の権限はIAMポリシーやバケットポリシーなどで設定します。Block Public Accessで意図しない公開を防ぎ、必要なら署名付きURLで有効期限付きのアクセスを提供します。アクセスの入口を分けたい場合はS3 Access Pointsも使えます。
| 操作 | 対象 | 考え方 |
|---|---|---|
| ListBucket | バケットARN | 一覧の範囲を、プレフィックス条件で絞る |
| GetObject / PutObject | 対象キーのオブジェクトARN | images/など、指定範囲の取得・保存を許可する |
| アクセス記録 | CloudTrailデータイベントなど | 記録対象を明示的に設定し、監査する |
コンソールでは、バケット作成、オブジェクトのアップロード、メタデータ・タグ・バージョニング・権限をそれぞれ確認します。すべての操作ログが何も設定せず自動記録されるとは考えず、必要な監査方法を有効にします。
アクセス頻度で、 保存と取得の 費用を変える
| クラス | 利用の目安 | 取得・配置の注意 |
|---|---|---|
| S3 Standard | 頻繁にアクセスするデータ | 低レイテンシーで取得。複数AZに保存 |
| S3 Standard-IA | アクセスが少なく、すぐ取り出したい | 取得料金・最低保存期間などを確認 |
| S3 One Zone-IA | 再作成可能な、低頻度のデータ | 単一AZ。AZ喪失に備えた用途判断が必要 |
| S3 Glacier Instant Retrieval | 低頻度のアーカイブを即時に読む | アーカイブでも即時取得。取得料金などを確認 |
| S3 Glacier Flexible Retrieval | 復元を待てるアーカイブ | 通常は事前の復元が必要。方式により分〜時間 |
| S3 Glacier Deep Archive | 非常に低頻度の長期保存 | 通常の復元は典型的に12時間、バルクは48時間 |
| S3 Intelligent-Tiering | 頻度が変わる/予測しづらい | 監視料金などと、自動階層化の条件を確認 |
| S3 Express One Zone | 単一AZで高性能・低レイテンシーを重視 | ディレクトリバケット。一般的なクラスと仕様が異なる |
ライフサイクルルールで、経過日数などに応じたクラス移行や有効期限を設定します。Intelligent-Tieringはアクセス状況に応じて3つの即時アクセス層を自動選択し、追加で2つのアーカイブ層を有効にできます。すべての階層が即時取得とは限りません。
公式資料:S3ストレージクラス ↗公式資料:アーカイブの復元時間 ↗Webシステムで、 保存先を組み合わせる
| 保存したいもの | 候補 | 理由 |
|---|---|---|
| OSやEC2上のDBのディスク | EBS | ブロックとして継続的に読み書きする |
| 配信する画像・HTML・ログ | S3 | キーで保存し、アプリや配信サービスから取得する |
| 複数サーバー共通のファイル | EFS | 共有ファイルシステムを利用する |
| 拠点の既存バックアップ | Storage Gateway | 既存のファイル・ボリューム・テープ方式をつなぐ |
重要ポイントと、 理解の確認
- EBSはディスク、S3はオブジェクト、EFSは共有ファイル。
- インスタンスストアは一時保存。EBSの保持も終了時の設定に依存する。
- スナップショットは増分保存でも、各時点の全体を復元できる。
- S3は頻度・取得時間・費用・配置と、権限・バージョンを合わせて設計する。
Q1. EC2を終了したら、EBSのデータは必ず残る?
いいえ。終了時削除の設定を確認します。必要なデータはバックアップも用意します。
Q2. S3のimages/は、通常のディスク上のフォルダーと同じ?
いいえ。オブジェクトキーのプレフィックスを、フォルダーのように表示しています。
Q3. Deep Archiveが安ければ、頻繁に読む画像も移してよい?
取得に復元待ちが必要なため適しません。費用と取得時間を一緒に比較します。
Q4. 複数AZのEC2から同じファイルを使いたい場合は?
RegionalのEFSなどの共有ファイル方式を検討します。通信・権限も設定します。
確認に使った、 公式資料
元データ:scripts/module6.txt。提供されたトランスクリプトを意味のまとまりで再構成し、誤解しやすい箇所を以下のAWS公式資料で確認しました(2026年10月6日)。実際の操作・仕様・料金は最新版を確認してください。