MODULE 06 / STORAGE

データの保存先を、 使い方から選ぶ

ディスクとして使う、オブジェクトとして保存する、ファイルを共有する。アクセス方法・寿命・共有範囲から、EBS・S3・EFSを整理します。

9つの学習セクション図解+比較表+復習公式資料確認:2026.10.06

このModuleで学ぶこと

01ブロック・オブジェクト・ファイルを使い分ける

02インスタンスストアとEBSの寿命を区別する

03S3の構造・権限・ストレージクラスを理解する

04EFSとStorage Gatewayの役割を説明する

01

保存の形で、 使い方が変わる

ブロック・オブジェクト・ファイルの比較
方式 どうアクセスするか AWSの例・用途
ブロック OSからディスクの領域として読み書きする EBS:OS・アプリ・自分で運用するDB
オブジェクト キーを指定し、APIでデータを取得・保存する S3:画像・ログ・バックアップ・配信元
ファイル ディレクトリとファイル名で共有する EFS:複数サーバーが使う共有ファイル
同じデータでも、 必要な操作から選ぶCOMPARISON
EBSEC2のディスク
Amazon S3キーでオブジェクトを取得
Amazon EFSNFSでファイルを共有
判断すること更新方法・寿命・共有範囲
サービスの優劣ではなく、アプリが必要とする保存方式を合わせます。S3をEC2の通常のローカルディスクとして扱うことはできません。
02

ディスクの寿命を、 インスタンスと分ける

インスタンスストアは、EC2ホストに直接接続された一時的なストレージです。高速な作業領域や再作成できるキャッシュに使います。Amazon EBSは、EC2とは別に管理するブロックストレージで、同じAZのEC2に接続します。

保存が続く条件を確認する
操作・性質 インスタンスストア EBS
再起動 通常は保持される 通常は保持される
停止・終了、ホスト障害 データが失われる。永続保存にしない 停止後も保持。終了時は削除設定に依存
共有・配置 そのインスタンスに結び付く 同じAZで接続。別AZへの復元にはスナップショットなど
向く用途 一時データ・再生成できるデータ OS・継続して必要なアプリのデータ

EBSは必要な容量、IOPS(1秒あたりのI/O回数)、スループットなどでボリュームタイプを選びます。容量を増やす操作もできますが、OS側のパーティションやファイルシステムの拡張が必要な場合があります。性能は実際の処理を測って選びます。

03

変更分を保存し、 時点を復元する

EBSスナップショットは、ボリュームのある時点のデータをバックアップします。初回以降は変更されたブロックを保存する増分方式です。

保存する差分と、 復元できる全体は別CHANGE OVER TIME

① 初回

ABCD

使用中のブロックを保存。空き領域まで丸ごとコピーするわけではありません。

② 次の保存

AXCD

変更したB→Xを保存。復元時には必要な既存ブロックも使います。

③ さらに変更

AXYD

変更したC→Yを保存。各時点のボリュームを復元できます。

A〜Dは使用中のブロック、オレンジは変更したブロック。増分でも、各スナップショットからその時点のボリュームを復元できます。

以前のスナップショットを削除しても、後の復元に必要なブロックは保持されます。別AZへの復元、別リージョンへのコピーなどにも使えます。Data Lifecycle Managerで、対象やスケジュール・保持期間を決めてEBSの保存を自動化できます。

公式資料:EBSスナップショット ↗
04

S3は、 キーでデータを扱う

Amazon S3はオブジェクトストレージです。バケットの中に、データ本体・キー・メタデータを持つオブジェクトを保存します。容量を先に固定したディスクとして作成する必要はありません。

バケットとオブジェクトを、 階層と属性で理解するOBJECT MODEL
バケット:study-media-example
キー
images/lesson-01.png
データ本体
画像ファイルの内容
メタデータ
Content-Type:image/png など
タグ
用途や分類を付ける別の仕組み
images/はキーのプレフィックスです。コンソールのフォルダー表示は整理のための見せ方で、通常のファイルシステムの階層とは異なります。

バージョニング

更新前のバージョンを保持し、誤った上書きや削除から戻せるようにします。全バージョンを削除できる権限まで防ぐ仕組みではありません。

耐久性と可用性

S3は高い耐久性を目標に設計されています。データを失いにくいことと、いつでもアクセスできることは異なります。単一AZのクラスではAZ喪失のリスクも考えます。

通常のオブジェクト保存では、キーを指定してPUTで保存・更新し、GETで取得します。オブジェクト数や全体容量を増やせても、個々のオブジェクトやリクエストには上限があります。現在のマルチパートアップロードの最大オブジェクトサイズは48.8 TiBです。上限値の暗記より、保存方式の違いを優先して理解します。

公式資料:S3の基本 ↗公式資料:マルチパートアップロードの上限 ↗
05

誰に、何を、 許可するかを決める

S3の権限はIAMポリシーやバケットポリシーなどで設定します。Block Public Accessで意図しない公開を防ぎ、必要なら署名付きURLで有効期限付きのアクセスを提供します。アクセスの入口を分けたい場合はS3 Access Pointsも使えます。

特定プレフィックスを許可する例
操作 対象 考え方
ListBucket バケットARN 一覧の範囲を、プレフィックス条件で絞る
GetObject / PutObject 対象キーのオブジェクトARN images/など、指定範囲の取得・保存を許可する
アクセス記録 CloudTrailデータイベントなど 記録対象を明示的に設定し、監査する

コンソールでは、バケット作成、オブジェクトのアップロード、メタデータ・タグ・バージョニング・権限をそれぞれ確認します。すべての操作ログが何も設定せず自動記録されるとは考えず、必要な監査方法を有効にします。

06

アクセス頻度で、 保存と取得の 費用を変える

主なS3ストレージクラス
クラス 利用の目安 取得・配置の注意
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ストレージクラス ↗公式資料:アーカイブの復元時間 ↗
07

共有ファイルと、 既存拠点の保存を つなぐ

複数のEC2から、 同じファイルへ アクセスFLOW
EC2 A / EC2 BNFSクライアント
Amazon EFS共有ファイルを保存
複数サーバーが同じファイルシステムをマウントする例です。図の矢印はアクセスの関係で、共有のための通信・権限設定が必要です。

Amazon EFSは、NFSで使う共有ファイルストレージです。ファイルの増減に応じて容量が変わります。複数AZのRegionalと、単一AZのOne Zoneを区別します。別VPC・別リージョンからの利用には、通信経路やレイテンシー・転送費用を考えます。

Storage Gateway:教材で扱う3方式
方式 オンプレミス側の入口 AWS側との関係
S3 File Gateway ファイル共有(NFS / SMB) S3オブジェクトとして保存
Volume Gateway ブロックボリューム(iSCSI) EBSスナップショットとしてバックアップ
Tape Gateway 仮想テープライブラリ 既存のテープバックアップ方式をAWS保存へ接続

Storage Gatewayは、オンプレミスの保存・バックアップ方式をAWSへつなぐ橋渡しです。EFSのようなクラウドの共有ファイルサービスとは、利用する入口と目的が異なります。ここではトランスクリプトにある3方式を整理しています。

公式資料:EFSの機能と配置 ↗公式資料:Storage Gatewayの各方式 ↗
08

Webシステムで、 保存先を組み合わせる

Webシステムでの使い分け
保存したいもの 候補 理由
OSやEC2上のDBのディスク EBS ブロックとして継続的に読み書きする
配信する画像・HTML・ログ S3 キーで保存し、アプリや配信サービスから取得する
複数サーバー共通のファイル EFS 共有ファイルシステムを利用する
拠点の既存バックアップ Storage Gateway 既存のファイル・ボリューム・テープ方式をつなぐ
公式資料:S3ウェブサイトエンドポイント ↗公式資料:CloudFrontからS3へのアクセス制限 ↗
09

重要ポイントと、 理解の確認

  • EBSはディスク、S3はオブジェクト、EFSは共有ファイル。
  • インスタンスストアは一時保存。EBSの保持も終了時の設定に依存する。
  • スナップショットは増分保存でも、各時点の全体を復元できる。
  • S3は頻度・取得時間・費用・配置と、権限・バージョンを合わせて設計する。
Q1. EC2を終了したら、EBSのデータは必ず残る?

いいえ。終了時削除の設定を確認します。必要なデータはバックアップも用意します。

Q2. S3のimages/は、通常のディスク上のフォルダーと同じ?

いいえ。オブジェクトキーのプレフィックスを、フォルダーのように表示しています。

Q3. Deep Archiveが安ければ、頻繁に読む画像も移してよい?

取得に復元待ちが必要なため適しません。費用と取得時間を一緒に比較します。

Q4. 複数AZのEC2から同じファイルを使いたい場合は?

RegionalのEFSなどの共有ファイル方式を検討します。通信・権限も設定します。

10

確認に使った、 公式資料

元データ:scripts/module6.txt。提供されたトランスクリプトを意味のまとまりで再構成し、誤解しやすい箇所を以下のAWS公式資料で確認しました(2026年10月6日)。実際の操作・仕様・料金は最新版を確認してください。